HTTP는 stateless, connectionless한 특성을 가지기 때문에 매번 클라이언트가 누구인지 확인해줘야 합니다. 이러한 특성을 보완하기 위해 쿠키와 세션을 사용하는 것입니다.
Cookie
HTTP의 일종으로 사용자가 어떤 웹 사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일입니다. HTTP에서 클라이언트의 상태 정보를 클라이언트의 PC에 저장하였다가 필요 시 정보를 참조하거나 재사용할 수 있습니다.
다음은 쿠키의 특징입니다.
- 이름, 값, 만료일(저장기간), 경로 정보로 구성되어 있습니다.
- 클라이언트 총 300개의 쿠키를 저장할 수 있습니다.
- 하나의 도메인 당 20개의 쿠키를 가질 수 있습니다.
- 하나의 쿠키는 4KB까지 저장할 수 있습니다.
다음은 쿠키의 동작 순서입니다.
- 클라이언트가 페이지를 요청합니다. (사용자가 웹 사이트에 접근합니다.)
- 웹 서버는 쿠키를 생성합니다.
- 생성한 쿠키에 정보를 담아 HTTP 화면을 돌려줄 때, 같이 클라이언트에게 돌려줍니다.
- 넘겨받은 쿠키는 클라이언트가 가지고 있다가(로컬 PC에 저장) 다시 서버에 요청할 때 요청과 함께 쿠키를 전송합니다.
- 동일 사이트 재방문 시 클라이언트의 PC에 해당 쿠키기 있는 경우, 요청 페이지와 함께 쿠키를 전송합니다.
Session
일정 시간 동안 같은 사용자(브라우저)로부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 유지시키는 기술입니다. 일정 시간은 방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점부터 웹 브라우저를 종료하여 연결을 끝내는 시점을 의미합니다. 즉, 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라고 합니다.
다음은 세션의 특징입니다.
- 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장합니다.
- 웹 서버의 저장되는 쿠키인 세션 쿠기가 있습니다.
- 브라우저를 닫거나, 서버에서 세션을 삭제했을 때만 삭제가 되므로 쿠키보다 비교적 보안이 좋습니다.
- 서버 용량이 허용하는 한 저장 데이터에 제한이 없습니다.
- 각 클라이언트에 고유 세션 ID를 부여합니다. 세션 ID로 클라이언트를 구분해 각 요구에 맞는 서비스를 제공합니다.
다음은 세션의 동작 순서입니다.
- 클라이언트가 서버에 접속 시 세션 ID를 발급받습니다.
- 클라이언트는 쿠키를 사용해서 세션 ID를 저장합니다.
- 클라이언트는 서버에 요청할 때, 세션 ID를 같이 서버에 전달합니다.
- 서버는 세션 ID를 전달 받아서 별다른 작업없이 세션 ID로 세션에 있는 클라이언트 정보를 가져와서 사용합니다.
- 클라이언트 정보를 가지고 서버 요청을 처리하여 클라이언트에게 응답합니다.
차이점
세션이 결국 쿠키를 사용하기 때문에 동작하는 원리는 비슷합니다. 가장 큰 차이점은 결국 사용자의 정보가 저장되는 위치입니다. 쿠키는 서버의 자원을 사용하지 않고 로컬에 정보를 저장합니다. 반면, 세션은 세션 ID만 로컬에 저장하고 저장한 세션 ID를 통해 서버의 세션이 있는 클라이언트 정보를 사용합니다.
쿠키는 로컬에 정보가 저장되어 있기 때문에 서버의 처리가 필요한 세션보다 속도 면에서 유리합니다.
쿠키는 로컬에 저장되기 때문에 변질되거나 요청에서 스니핑당할 우려가 있어서 보안에 취약합니다. 반면, 세션은 쿠키를 이용해서 세션 ID만 저장하고 ID로 구분하여 서버에서 처리하기 때문에 비교적 보안이 좋습니다.
쿠키는 파일로 저장되기 때문에 브라우저를 종료해도 정보가 유지될 수 있고 만료기간을 지정해 쿠키를 삭제할 때까지 유지할 수도 있습니다. 반면, 만료기간을 지정할 수 있지만 브라우저가 종료되면 만료기관에 상관없이 삭제됩니다.
Why Cookie?
세션이 비교적 보안이 좋음에도 쿠키를 사용하는 이유는 세션은 서버의 자원을 사용합니다. 서버 자원에는 한계가 있고, 로컬에 정보를 저장하는 쿠키에 비해 속도가 느려질 여지가 있습니다.
쿠키만 사용하는 것은 아닙니다. 보안이 중요한 정보에는 세션을 사용하고 보안을 신경쓰지 않아도 되는 정보에는 쿠키를 사용합니다. 적절하게 병행 사용하면 웹 사이트의 속도를 높일 수 있습니다.
Session is Stateful
세션은 서버에 클라이언트 정보가 저장되기 때문에 stateless하지 않습니다. 하지만 사용하는 이유는 분명히 있습니다. 하지만 stateless를 위배하더라도 세션을 사용함으로써 얻는 이점은 확실합니다. 앞서 설명드린 것처럼 쿠키만 사용한다면 보안 상으로 문제가 생길 것입니다.
If multi server
HTTP가 stateless의 특성을 가진 이유는 서버의 확장성때문이였습니다. 서버가 여러 개가 된다면 각 서버마다 세션을 가지게 될 것이고 세션을 공유하지 않는다면 세션을 쓰는 이유 자체가 많이 퇴색될 수도 있을 것입니다. 이를 해결하기 위한 여러가지 방법이 있습니다.
방법을 설명하기 전에 로드 밸런싱에 대해 설명드리겠습니다. 다중 서버를 효율적으로 사용할 수 있는 이유입니다. 여러 대의 서버로 트래픽을 균등하게 분산해주는 기술이라고 합니다. 즉, 여러 클라이언트의 여러 요청을 적절하게 여러 대의 서버로 분산시켜주는 기술입니다.
Sticky Session
첫 요청에 대한 응답을 준 서버에게만 계속 요청하는 방법입니다. 하지만 이 방법은 로드 밸런싱이 의미가 없어지게 됩니다. 한 서버에만 요청이 집중될 수 있기 때문입니다. 이렇게 되면 한 서버에 대한 의존성이 커집니다. 이 서버가 죽게 되면 세션도 전부 사라지게 됩니다. 이를 해결하기 위한 방법들이 2가지 있습니다.
Session Clustering
클러스터링이란 여러 대의 서버를 하나의 서버처럼 운영하는 것입니다. 세션 클러스터링은 각 서버의 세션 저장소를 하나로 묶어서 관리하는 것입니다.
모든 서버가 동일한 세션을 공유하기 때문에 특정 서버로 요청이 몰릴 필요가 없을 것이며, 서버가 하나 죽게 되더라도 세션 정보는 유지가 됩니다.
하지만 모든 서버가 세션 데이터를 동일하게 유지하기 위해서 하나의 세션이 생기면 모든 서버의 세션 저장소를 업데이트 해줘야합니다. 또한 많은 메모리도 필요할 것이기 때문에 그만큼의 성능 저하가 발생할 수 있습니다.
새로운 서버를 만들 때마다 기존 세션 데이터를 옮겨서 클러스터링해줘야 하는 번거로움도 존재합니다.
Session Server
세션만 관리하는 별도의 서버를 하나 두는 방식입니다. 세션 서버를 사용하기 때문에 모든 서버의 세션 저장소를 업데이트해줄 필요가 없으며 클러스터링할 필요도 없습니다.
또한, Redis 같은 인메모리 데이터 저장소를 사용함으로써 빠르게 세션을 조회할 수 있습니다.
세션 서버가 죽어버리면 세션 데이터가 사라진다는 단점은 존재합니다. 하지만 Redis 같은 인메모리 데이터 저장소는 메모리에 데이터를 저장하면서 실시간으로 다른 서버에 복사본을 저장하거나 디스크에 직접 저장하여 데이터 보관 및 백업이 가능합니다.
또한, Master - Slave 형식으로 구성이 가능하기 때문에 Master Server가 죽어도 Slave Server로 접속하면 서비스를 유지할 수 있다는 장점이 있습니다.
다만 데이터를 별도로 저장하기 위한 메모리가 추가적으로 필요하고, 메모리 파편화가 발생하는 단점도 있습니다.
