세션과 쿠키

HTTP 통신은 connectionless와 stateless이 기본 전제입니다.
connectionless란 클라이언트가 request를 보낸뒤 response를 서버로부터 응답받으면 연결을 끊는게 기본이라는 뜻입니다.
stateless는 클라이언트가 response를 받은 뒤 서버에게 클라이언트의 상태를 공유하지 않는다는 뜻입니다.

그렇기 때문에 사용자들을 구분하고 위해서 쿠키나 세션이라는 것을 사용합니다. 다음은 쿠키와 세션을 간단하게 비교해보겠습니다.

 

---

쿠키(로컬 파일에 저장)
1. 로그인하면 서버가 클라이언트에게 response 헤더를 통해 쿠키값을 전달
2. response 헤더의 쿠키값을 로컬 파일에 저장하는 것은 브라우저가 하는 일
3. 이후 클라이언트는 request 헤더에 쿠키값을 전달

세션(로컬, 서버 모두 저장)
1. 로그인하면 서버가 클라이언트에게 response 헤더에 세션 키를 전달
2. response 헤더의 세션 키를 로컬에 브라우저가 세팅.
3. 이후 클라이언트 request 헤더에 세션값을 세팅하여 request 전달

 

쿠키는 HTTP 통신을 할 때  cookie 값이 왔다갔다 하기 때문에 탈취 및 변조가 쉽고 세션은 이에 비해 key 값만 통신시 사용하기 때문에 비교적 보안이 뛰어나다. 하지만 key를 통해 값을 알아내야 하는 세션은 쿠키에 비해 속도가 조금 느리다는 점을 대표적인 단점으로 말할 수 있습니다.

 

---

웹 서비스를 하게 되면 많은 WAS들을 운용할 수 밖에 없는데, 이번에는 많은 서버들이 세션을 어떻게 관리하는지에 대해서 알아보겠습니다. 쿠키는 클라이언트들에게 값이 있지만 세션은 서버들에게 값이 있기 때문에 모든 서버들이 이 값을 공유해야합니다. 공유하는 방식에는 크게 네가지가 있는데 다음과 같습니다.

1. sticky 세션
처음에 로그인한 서버에 계속 request를 요청할 수 있도록 로드밸런서가 HTTP request를 리다이렉트 해줍니다. 
단점은 특정 서버에 요청이 몰릴수 있고 해당 서버가 다운되면 세션이 만료되어 재로그인을 해야합니다.

2. all-to-all session replication
모든 서버에 key-value 세션 정보를 공유하는 방법입니다. 서버의 대수가 소규모일 경우에는 쓸만한 방법이지만 서버의 대수가 늘어날 수록 세션 값을 공유해야할 대상이 많아지기 때문에 서버가 대규모인 경우 비효율적입니다.(특히 메모리)

3. primary-secondary 방식
모든 서버에 key-value 세션 정보를 공유하는게 아니라 primary 서버와 secondary(백업 서버) 서버에만 key-value를 공유하고 나머지 서버에는 key 값만 저장하는 형식입니다. 그럼 메모리 용량을 조금 더 아낄 수 있는 장점이 있습니다.
그래서 서버가 대규모라도 쓸만한 방법이 될 수 있지만 request가 primary나 secondary 서버가 아닌 다른 서버로 갈 경우 primary서버에 value 값을 요청해야 하는 단점이 있고, 이는 request 처리 속도 저하에 영향을 줄 수 있습니다.

4. 세션 스토리지 분리 방식(많이 사용하는 방식, 이 글을 쓰는 순간에도 저는 직장에서 이 방식을 쓰고있습니다)
세션 정보를 각 서버에 저장하는 것이 아니라 세션 정보를 위한 별도의 스토리지를 두는 방식입니다. 이렇게 되면 서버가 아무리 늘어나도 각 서버에 세션 스토리지에 대한 세팅만 된다면 세션 정보를 공유할 수 있습니다.
또한 어떠한 서버에 장애가 발생하여도 무중단 서비스를 제공할 수 있습니다.(적어도 세션 관련 이슈는 없음) 그리고 각 서버에 공유되어있는 세션 정보에 대한 정합성을 맞춰 줄 필요도 없습니다.