먼저, 쿠키와 세션에 대해 들어가기 전에 기억해야 할 것이 있다.
HTTP는 Stateless한 상태라는 것.
stateless라는 것은, 클라이언트와 서버의 통신이 각각 독립적이라는 것이다.
따라서 장점으로는 서버의 확장성이 용이하다는 것이고 단점으로는 클라이언트가 매번 요청을 보내야 한다는 것이다.
특히 로그인 후 특정 데이터에 접근할 때는..?
매번 유저 정보를 보내기 번거로울 것이다. 이 때 사용하는 것이 쿠키, 세션, 더 나아가서 토큰의 개념이다.
여기서는 쿠키와 세션에 대해서만 살펴보고자 한다.
쿠키
클라이언트에 저장되는 작은 데이터 파일이다. 이 때 만료 날짜가 들어있어 쿠키가 만료되면 해당 정보로 데이터에 접근할 수 없다.
클라이언트에 저장되어 사용되기 때문에 편리한 만큼, 해커에게도 편리하다는 단점이 있다.
쿠키에는 민감하지 않은 정보들을 주로 저장한다. set-cookie 헤더에 넣어서 보낸다!
이러한 보안점을 해결하기 위해 등장한 개념이 세션이다.
세션
쿠키와 달리, 서버에 저장되는 데이터이다. 따라서 보안성을 향상시킬 수 있다는 단점이 있다.
일단 과정을 먼저 살펴보면,
1. 클라이언트에서 유저 정보 전송
2. 서버에서 세션 ID를 생성하고 유저 정보를 서버 스토리지에 저장
3. 클라이언트는 세션 아이디를 쿠키에 저장
4. 매 요청마다 서버는 쿠키에 있는 세션 ID와 스토리지에 저장되어 있는 유저 정보를 매핑
특이한 점은 세션 ID가 클라이언트의 '쿠키'로 저장된다는 것이다. 이 역시 쿠키보다야 낫지만, 역시 보안에 취약하다는 단점이 있다.
또 있다.
만약 서비스 규모가 커져서 로드밸런서를 사용했다고 하자.
처음 클라이언트가 요청했을 때는 로드밸런서가 서버A에 연결을 했는데, 두 번째 요청 시 서버B에 연결했다면?
서버B에는 세션 ID에 대한 유저 정보가 없기 때문에 오류가 발생한다.
물론 이는 세션 스토리지 라는 것을 사용하여 해결할 수 있다.
세션을 별도로 관리하는 스토리지를 두어서 요청에 들어올 때는 해당 스토리지로 무조건 갈 수 있도록 설정하는 것이다.
하지만 대용량 트래픽이라면...이 역시 과부하가 걸려 터질 수도 있다.
그래서 토큰을 사용한다!
토큰에 대해서는 다음 포스트에서...
