쿠키(Cookie)와 세션(Session)

JISU LIM·2023년 8월 28일

network tech-interview

CS-Tech

목록 보기

2/16

🔴 쿠키 vs 세션

쿠키와 세션은 비슷한 역할을 하며, 동작원리도 비슷합니다. 그 이유는 세션도 결국 쿠키를 사용하기 때문입니다.
가장 큰 차이점은 사용자의 정보가 저장되는 위치입니다. 때문에 쿠키는 서버의 자원을 전혀 사용하지 않으며, 세션은 서버의 자원을 사용합니다. (쿠키 : 클라이언트 / 세션 : 서버)
보안 :쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어서 보안에 취약하지만, 세션은 쿠키를 이용해서 sessionid 만 저장하고 그것으로 구분해서 서버에서 처리하기 때문에 비교적 보안성이 좋습니다. (세션 > 쿠키)
라이프 사이클: 쿠키도 만료시간이 있지만 파일로 저장되기 때문에 브라우저를 종료해도 계속해서 정보가 남아 있을 수 있습니다. 또한 만료기간을 넉넉하게 잡아두면 쿠키를 삭제할 때 까지 유지될 수도 있습니다.
- 반면에 세션도 만료시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제됩니다.
- 예를 들어, 크롬에서 다른 탭을 사용해도 세션은 공유됩니다. 다른 브라우저를 사용하게 되면 다른 세션을 사용 할 수 있습니다.
속도: 쿠키에 정보가 있기 때문에 서버에 요청시 속도가 빠르고 세션은 정보가 서버에 있기 때문에 처리가 요구되어 비교적 느린 속도를 가집니다. (쿠키 > 세션)

🍪 쿠키 동작 방식

클라이언트가 페이지를 요청
서버에서 쿠키를 생성, HTTP 헤더에 쿠키를 포함시켜 응답
클라이언트는 쿠키를 쿠키 저장소에 저장, 브라우저가 종료되어도 쿠키 만료 기간이 되지 않았다면 클라이언트에서 보관

같은 요청을 할 경우 쿠키 저장소에서 해당 쿠키를 찾음
해당 쿠키를 HTTP 헤더에 쿠키를 함께 보냄
서버에서 쿠키를 읽어 이전 상태 정보를 변경 할 필요가 있을 때 쿠키를 업데이트하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답

䷍ 세션 동작 방식

클라이언트가 서버에 login 요청
클라이언트가 서버에 접속 시 세션 ID를 발급받고, 서버의 세션 저장소에 해당 세션ID가 저장됨
서버는 응답과 함께 해당 세션 ID를 담은 쿠키를 클라이언트에 전달함
클라이언트는 쿠키를 활용해 세션ID를 저장해서 갖고 있게 됨

클라이언트는 서버에 요청할 때 쿠키 저장소에서 쿠키를 찾음
요청 메시지와 함께 세션 ID가 포함된 쿠키를 전달
서버는 세션 저장소에서 세션 ID를 찾음
서버는 세션 ID를 이용해 클라이언트를 식별하여 응답할 수 있음

🟠 HTTP의 Stateless와 세션

HTTP의 Stateless

HTTP 프로토콜은 요청과 응답을 교환하는 동안 상태(Status)를 저장하지 않습니다. 따라서 HTTP 레벨에서는 이전에 보냈던 request나 response를 기억하지 못합니다.
즉, HTTP 요청은 직전의 요청과 전혀 관련이 없고, 이를 HTTP의 비상태성(Stateless)이라고 합니다.

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

Stateless가 무상태를 의미하기 때문에 상태를 유지하는 세션 방식은 이에 반합니다. 하지만 그렇다고 인증을 매번 하는 것 또한 사용자 입장에서 굉장히 불편할 수 있습니다.

그래서 대부분의 웹/앱 서비스에서는 클라이언트의 상태 정보를 유지하는 방향으로 편의성을 제공하고 있고, 이는 보안적인 측면에서 이점이 있습니다.

이를 위해서 Stateless 특성에 반할 수는 있지만 서버측에 클라이언트 상태 정보를 저장하는 세션 방식을 활용하고 있다고 이해하고 있습니다.

또한, 무상태를 지향하기 위해 매 요청마다 필요한 정보를 모두 담아 서버와 I/O하는 경우 통신에서 오는 부하와 코스트가 더 클 수 있기에 세션 방식을 사용한다고 생각합니다.

🟡 규모가 커져 세션이 여러 개가 된다면?

보통 프로젝트의 규모가 커지게 되면, 서버를 수평적으로 확장하게 됩니다. 이때 로드밸런싱을 거쳐 여러대의 서버에 할당된 세션 저장소를 활용하는 방법에서 문제가 발생할 수 있습니다. (A 서버의 세션 저장소에 세션이 저장된 유저가 이후 B 서버로 요청하는 경우)
이러한 문제를 해소하기 위해 아래와 같이 세션 저장소를 활용 가능합니다.

Sticky Session

Sticky Session은 첫 요청에 대한 응답을 준 서버에게 끈적끈적하게 붙어서 이후의 모든 요청들을 해당 서버로만 보내는 방법입니다.
쿠키나 클라이언트의 IP tracking을 활용하여 기능을 제공합니다.
단점은 로드 밸런싱의 효율이 떨어질 수 있습니다. 로드 밸런싱은 트래픽을 여러 대의 서버로 적절하게 분산시켜줘야 하는데 Sticky Session은 특정 서버에게 트래픽을 보내기 때문입니다. 따라서 최악의 경우에는 여러 대의 서버를 둬도 하나의 서버만 사용되는 상황이 발생하게 됩니다.
또한, 세션은 하나의 서버에서만 관리되기 때문에 서버가 죽어버리면 서버의 세션 저장소에 있는 모든 세션들이 사라지게 됩니다.
이러한 단점은 여러 대의 서버가 세션을 공유한다면 해결할 수 있습니다. 바로 Session Clustering과 Session Server입니다.

Session Clustering

클러스터링이란 여러 대의 서버를 하나의 서버처럼 운영하는 것을 의미합니다. 즉, Session Clustering이란 각 서버의 세션 저장소를 하나로 묶어서 관리하는 것입니다.
모든 서버가 동일한 세션을 공유하기 때문에 특정 서버로만 트래픽이 몰릴 필요가 없으며, 하나의 서버가 죽어도 세션 정보를 잃어버릴 일은 없게 됩니다.
하지만 모든 서버의 세션 데이터를 동일하게 유지하기 위해서 하나의 세션이 생기면 모든 서버의 세션 저장소를 업데이트해줘야 하며 그만큼 많은 메모리가 필요하기 때문에 성능 저하가 발생하게 됩니다.
- 또한, 새로운 서버를 만들 때마다 기존의 세션 데이터를 옮겨서 클러스터링 해줘야 하는 번거로움도 존재합니다.
이러한 번거로움을 없애기 위해 세션만 관리하는 별도의 서버를 하나 두는 방식이 바로 Session Server 방식입니다.

Session Server

서버마다 세션 저장소를 둬서 관리하지 말고 세션만 관리하는 별도의 서버를 하나 두는 방식입니다.
세션 서버를 사용하기 때문에 모든 서버의 세션 저장소를 업데이트해줄 필요가 없으며, 클러스터링할 필요도 없습니다.
또한, Redis 같은 In-memory(인메모리) 데이터 저장소를 사용함으로써 빠르게 세션을 조회할 수 있습니다.
Session Server 방식은 Session Clustering의 단점을 해결하지만, 결국 하나의 Session Server를 통해 관리하기 때문에 서버가 죽어버리면 모든 세션 데이터를 잃게 됩니다.
하지만 Redis 같은 In-memory(인메모리) 데이터 저장소는 메모리에 데이터를 저장하면서 다른 서버의 메모리에 실시간으로 복사본을 저장하거나, 디스크에 직접 저장하여 데이터를 보관 및 백업이 가능합니다.
또한, Master - Slave 형식으로 구성이 가능하기 때문에 Master Server가 죽어도 Slave Server로 접속하면 서비스를 계속 유지할 수 있는 장점이 있습다.
다만, 데이터를 별도로 저장하기 위한 메모리가 추가적으로 필요하고, 메모리 파편화가 발생하는 단점도 있습니다.