[네트워크] 쿠키(Cookie)와 세션(Session)

쿠키 (Cookie)

---

쿠키는 클라이언트(로컬) 에 저장되는 키와 값이 들어있는 작은 데이터 파일이에요. 

이러한 쿠키는 클라이언트에 저장되어 필요시 정보를 참조하거나 재사용할 수 있어요.

 

보통 웹 환경에서는 클라이언트와 서버가 HTTP 프로토콜을 이용해 통신을 하는데요, 하지만 HTTP 프로토콜은 아래와 같은 특징들을 지니기 때문에 쿠키를 사용합니다.

     

          

1.  Connectionless [비연결성] 

HTTP 는 TCP 연결을 맺고 요청(Request) 을 보내면 서버는 응답 (Response)  을 보내고 연결이 끊어집니다.

물론 HTTP 1.1 버전은 커넥션을 계속 유지하는 keep-alive 옵션이 디폴트이긴 해요. 하지만, HTTP 1.0 버전은 기본적으로 connectionless 이에요.

 

참고 : [Web] HTTP 1.0 과 HTTP 1.1의 차이

[Web] HTTP 1.0 과 HTTP 1.1의 차이

 

 

 

2. Stateless [무상태]

HTTP 는 상태를 따로 저장하지 않아요. 즉 연결이 끊어지는 순간 모든 상태 정보가 사라지게 되죠.

따라서 서버는 클라이언트가 첫 번째 통신 때 보낸 정보를 두 번째 통신 때 알 수 없습니다.

이러한 HTTP 의 특성 때문에 쿠키가 사용되는 되요. 

쿠키는 아래와 같이 구성되어 있습니다.

• 이름 : 쿠키를 구별하는 이름
• 값 : 쿠키에 저장되는 값
• 유효시간 : 쿠키 유지시간
• 도메인 : 쿠키를 전송할 도메인
• 경로 : 쿠키를 전송할 요청 경로

 

클라이언트 ---- 1. HTTP 요청 --->      서버     

     서버      ---- 2. HTTP 응답 ---> 클라이언트

쿠키저장소  ---- 3. 쿠키 저장소에 저장 

클라이언트(웹 브라우저) 가 서버에 로그인을 요청한다고 해보자.
서버는 클라이언트의 요청을 받고 클라이언트의 정보를 담은 쿠키를 생성한다.
이후 HTTP 헤더에 set-cookie 옵션을 통해 쿠키를 포함해 응답을 보낸다.
클라이언트는 해당 쿠키를 쿠키 저장소에 저장해 놓는다.

 

쿠키저장소 --- 1. 쿠키 저장소에서 조회 ---> 클라이언트

클라이언트 ---- 2. 쿠키를 포함한 HTTP 요청 --->      서버     

     서버      ---- 3. HTTP 응답 ---> 클라이언트

클라이언트가 로그인을 완료하고 첫 페이지인 welcome 페이지에 접근한다고 해보자.
이때 클라이언트는 쿠키 저장소에서 쿠키를 꺼내 HTTP 요청에 쿠키를 담아 전송한다.
그럼 서버는 HTTP 요청의 쿠키를 읽어 클라이언트를 식별할 수 있다.
만약 쿠키가 없었다면 다시 로그인 정보를 보내야 하는 불상사가 일어났을 것이다.

 

 

 

 

 

 

 

 

세션 (Session)

---

세션은 일정 기간 동안 같은 사용자(클라이언트) 로 부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시키는 기술이에요.

세션은 쿠키를 기반으로 하지만 쿠키과 다르게 서버 측에서 저장하고 관리해요. 

서버는 세션ID 를 이용해 클라이언트를 구분하며, 웹 브라우저가 서버에 접속해 브라우저를 종료할 때까지 세션을 유지합니다.

 

클라이언트 ---- 1. HTTP 요청 --->      서버     

                           2. 세션 생성

     서버      ---- 3.. HTTP 응답 +sessionId ---> 클라이언트

쿠키저장소  ---- 3. 쿠키 저장소에 저장 

라이언트(웹 브라우저) 가 서버에 로그인을 요청한다고 해보자.
서버는 클라이언트의 요청을 받고 클라이언트의 정보를 담은 세션을 생성한다.
이후 세션ID 를 담은 쿠키를 생성하고, HTTP 헤더에 set-cookie 옵션을 통해 쿠키를 포함한 응답을 보낸다.
클라이언트는 해당 쿠키를 쿠키 저장소에 저장해 놓는다.

 

쿠키저장소 --- 1. 쿠키 저장소에서 조회 ---> 클라이언트

클라이언트 ---- 2. 쿠키를 포함한 HTTP 요청 --->      서버     

                          3. 세션 조회

     서버      ---- 4. HTTP 응답 ---> 클라이언트

클라이언트가 로그인을 완료하고 첫 페이지인 welcome 페이지에 접근한다고 해보자.
이때 클라이언트는 쿠키 저장소에서 쿠키를 꺼내 HTTP 요청에 쿠키를 담아 전송한다.
그럼 서버는 HTTP 요청의 쿠키를 읽어 쿠키 안의 세션ID를 이용해 클라이언트를 식별할 수 있다.

 

 

 

 

 

 

---

1. 쿠키와 세션의 차이에 대해 설명해 주세요.

쿠키와 세션은 둘 다 사용자 정보를 저장하고 인증을 관리하기 위해 사용됩니다.

• 쿠키: 사용자의 브라우저에 저장되며, 클라이언트 쪽에서 관리됩니다. 주로 간단한 데이터(예: 사용자 ID, 설정 값 등)를 저장하며, 서버에 요청 시마다 함께 전송됩니다.
• 세션: 서버에서 관리되며, 사용자의 브라우저에 고유한 세션 ID만 저장됩니다. 세션 ID를 통해 서버에서 사용자의 데이터를 식별합니다.
  차이점은 쿠키는 클라이언트 중심이고, 세션은 서버 중심이라는 점이에요.

---

2. 세션 방식의 로그인 과정에 대해 설명해 주세요.

1. 사용자가 로그인 정보를 서버에 전송합니다.
2. 서버는 사용자의 정보를 인증한 뒤, 고유한 세션 ID를 생성합니다.
3. 생성된 세션 ID를 클라이언트의 쿠키에 저장해 브라우저로 전송합니다.
4. 이후 클라이언트는 요청마다 세션 ID를 서버로 전송하며, 서버는 이를 기반으로 사용자 정보를 확인하고 인증합니다.
   이 방식은 민감한 정보를 서버에 저장해 보안을 강화할 수 있다는 장점이 있어요.

---

3. HTTP의 특성인 Stateless에 대해 설명해 주세요.

Stateless는 HTTP가 각각의 요청이 독립적임을 의미합니다. 즉, 서버는 이전 요청에 대한 정보를 기억하지 않아요.
예를 들어, 사용자가 로그인했다고 해서 다음 요청에서도 자동으로 사용자 정보를 기억하지 못하며, 매 요청마다 필요한 인증 정보를 포함해야 합니다.

---

4. Stateless의 의미를 살펴보면, 세션은 적절하지 않은 인증 방법 아닌가요?

Stateless 환경에서는 서버가 상태를 기억하지 않는 것이 원칙이지만, 세션은 상태를 유지하도록 설계된 방식이에요. 이 때문에 HTTP의 Stateless 특성과는 반대되는 개념처럼 보일 수 있습니다.
하지만 세션 방식은 쿠키의 보안 약점을 보완하고, 사용자 정보를 더 안전하게 관리할 수 있어 실제로는 널리 사용되고 있습니다. 다만, 세션을 관리하려면 추가적인 리소스가 필요하고 서버 부담이 커질 수 있다는 단점이 있습니다.

---

5. 규모가 커져 서버가 여러 개가 된다면, 세션을 어떻게 관리할 수 있을까요?

서버가 여러 개로 확장되면, 각 서버가 독립적으로 세션 정보를 저장하면 일관성이 깨질 수 있습니다. 이를 해결하기 위해 아래와 같은 방법이 사용됩니다:

1. 세션 클러스터링: 서버 간에 세션 데이터를 동기화합니다. 그러나 성능 문제가 발생할 수 있습니다.
2. 세션 스토리지 공유: Redis나 Memcached와 같은 인메모리 데이터베이스를 사용해 세션 데이터를 중앙에서 관리합니다. 이 방식은 성능이 뛰어나고 확장성도 좋습니다.
3. JWT (JSON Web Token): 세션 대신 상태를 클라이언트에 저장하는 방식으로, Stateless 환경에 적합합니다. 하지만 토큰이 클라이언트에 저장되므로 만료 및 갱신 관리가 필요합니다.

이러한 방법들을 상황에 맞게 선택해 사용하면 확장성과 효율성을 모두 확보할 수 있습니다.