Cookie와 Session, 그리고 Token

목차

 

 

HTTP의 특징

HTTP는 비연결성(Connectionless)과 무상태(Stateless)라는 특징이 있다.

 

클라이언트는 서버에게 Request를 보내면서 서버와 연결되는데

이때 서버가 클라이언트에게 Response하면서 맺었던 연결을 끊어버린다.

=> 서버는 클라이언트를 기억하지 않으므로, 서버 입장에서 모든 요청은 다 처음보는 요청이다 (stateless)

 

stateful은 서버가 클라이언트를 기억하는 것이고

stateless는 서버가 클라이언트를 기억하지 않는 것이다.

 

 

 

상태 유지 방법 1 : 쿠키 (Stateless서버) 

서버가 클라이언트를 기억할 수 있도록 클라이언트(웹브라우저)에게 인증정보를 준다.

 

1. 클라이언트가 서버에게 로그인을 요청하면 

   서버는 로그인 정보를 확인하고, 인증정보가 담긴 쿠키를 헤더에 담아 응답해준다. (Set-Cookie)

2. 클라이언트는 받은 쿠키를 key-value로 저장하고

   서버에게 매 요청마다 헤더에 쿠키를 담아서 요청을 보낸다. (Cookie)

3. 서버는 요청받은 쿠키의 인증정보를 확인하여 맞으면 로그인 과정을 패스한다

쿠키 만료시점은 저장시 설정할 수 있고, 저장할 수 있는 쿠키의 용량이 제한되어있다.

 

도메인 명시하면 명시한 도메인과 하위 도메인 모두 쿠키 접근 가능

도메인 생략하면 현재 도메인에만 쿠키 접근 가능

 

경로 명시하면 명시한 경로와 하위 경로 모두 쿠키 접근 가능

경로 생략하면 모든 경로에서 쿠키 접근 가능 ( "/" 와 같음)

 

 

단점 : 사용자의 인증정보가 담긴 쿠키가 네트워크를 이동해야한다 (개인정보 위험해!!)

 

쿠키는 계속 저장될 수 있다. 쿠키는 로그아웃 시 만료시켜야한다.

 

 

 

 

상태 유지 방법 2 : 세션 (Stateful서버)

서버가 클라이언트를 기억할 수 있도록 세션ID를 클라이언트와 서버 모두 저장한다.

 

1. 클라이언트가 서버에게 로그인을 요청하면

   서버는 사용자 정보를 확인하고, 세션ID를 생성하여 서버에 저장한 후

   세션ID가 담긴 쿠키를 헤더에 담아 응답해준다 

2. 클라이언트는 세션ID가 담긴 쿠키를 Object로 저장하고

   서버에게 매 요청마다 헤더에 쿠키를 담아서 요청을 보낸다.

3. 서버는 요청받은 쿠키의 세션ID를 확인하여 맞으면 로그인 과정을 패스한다

쿠키는 사용자의 인증정보가 네트워크를 이동했지만

세션은 사용자의 세션ID가 네트워크를 이동한다(세션ID는 노출되어도 위험적다)

 

단점 : 서버에 저장공간이 필요하다

 

---

 ++ 2022-02-03 내용 추가

 

 

서버의 트래픽이 증가하는 경우

세션은 기본적으로 서버의 메모리에 저장되게된다(정확히는 톰캣의 세션 저장소)

서버 1개의 메모리에는 세션이 100개가 저장될 수 있다면, 동접자가 300명이라면 어떤 일이 일어나게될까?

 

 

동접자 300명을 처리하기 위해선, 서버가 3대가 필요하다.

클라이언트가 어떻게 서버 3대에 분산되어 접속할 수 있을까?

로드 밸런싱 기술을 이용하면 된다.

 

로드밸런싱 이용

로드밸런싱 : 서버에 가해지는 트래픽을 여러대의 서버에 균등하게 분산시켜주는 기술.

 

 

자 여기서 문제가 발생한다

1. 🐵101번째가 로그인을 요청하여 SessionId는 서버B에 저장되었다.

2. 🐵101번째는 로그인이 완료되었다는 응답을 받았다

3. 이때, 1번째~10번째가 로그아웃을 하여 서버A에 여유가 생겨났다

4. 🐵101번째가 구매내역을 요청한다

5. 🐯로드밸런서는 서버A에 여유가 생겼으니 🐵101번째의 요청을 서버A로 보낸다.

6. 서버A 저장소에는 🐵101번째의 SessionId가 없다. 서버A는 로그인페이지를 응답해준다

7. 🐵101번째는 로그인했는데 로그인을 다시하라고 응답받았다 << !!

 

 

 

이 문제를 해결하기 위해서는 어떻게 하면 될까?

세션 저장소를 하나로 통합하면 되지 않을까?

가장 대표적인 DB로 서버 저장소를 만들어볼까?

 

문제점 발견

오! 테스트 해보니 잘 동작하네 근데 너무 느리다..

세션이 메모리(RAM)에 있을때는 빠르게 동작했는데 ㅜㅜ 

 

생각해보니 사용자가 100만명이되면.. 100만명의 데이터를 서버 저장소(DB)도 1개로 감당할 수 있을까?

그럼 1번째부터 1000번째는 1번 서버 저장소로, 1001번부터 2000번째는 2번 서버 저장소로.....?

너무 복잡하다!

 

 

 

 

상태 유지 방법 3 : Token (Stateless 서버)

세션방식의 문제점

1. 로그인 유저가 많아질수록 저장할 DB리소스가 더 많이 필요하다

2. 매 요청마다 유저정보를 찾기위해 헤매야한다

 

토큰은 이러한 세션의 문제점을 개선하기 위해 등장했다.

 

토큰은 서버가 기억하는 텍스트이다.

1. 클라이언트가 로그인을 요청하면

2. 회원 DB에서 사용자를 확인하고

3. 회원정보를 기반으로 Signing 알고리즘을 수행하여 토큰을 생성한다

4. 토큰을 클라이언트에게 응답해준다

5. 클라이언트는 요청과 토큰을 함께 보낸다

 

 

JWT에 대해서는 다음 글에서 확인하자