JWT (1)

세션

처음 웹에서 서버로 어떤 요청을 보낼때 서버에서는 웹에 html을 보내면서 http의 header에 쿠키를 담아 보낸다. 이때 쿠키에 세션ID를 담는다. 그 다음 같은 요청을 보낼때는 받은 세션ID를 요청에 담아 보내서 처음 보내는 요청이 아님을 알린다. 이때 세션ID를 다른 사람이 가져가면 막기 위해 자체 목록에 방문자 카드를 만들어서 담아둔다.(세션에 세션값을 담는다) 그러면서 최초요청에 대해 header에 쿠키를 담아 보내면서 새 방문자 카드도 같이 header에 담는다.

이때 이 세션ID는 이런 일련의 과정속에서 계속 유지되다가 3가지 상황에서 사라진다.

1. 서버에서 세션의 값을 날린다(목록에서 방문자 카드를 날린다.).
2. 사용자가 브라우저를 종료한다.(이때 목록에 방문자 카드는 남아있기 때문에 재요청시 서버는 새 방문자 카드를 발급해준다. 기존 카드는 특정 시간이 지나면 사라진다. 보통 30분정도가 걸린다.)
3. 위 기존카드의 경우에서 알 수 있듯이 특정 시간이 지나면 세션값은 사라진다.

아래는 세션의 구조를 나타낸 것이다.

1. 클라이언트의 최초 request
2. 세션이라는 저장소에 세션ID를 하나 만듬.(ID 하나에 별도의 저장소가 딸려있다.)
3. 서버에서 클라이언트으로 response할때 header에 세션ID를 담아서 보낸다.
4. 클라이언트에 세션ID 저장.
5. 서버로 로그인 request (id:ssar, pw:1234, 세션ID를 들고감)
6. db에서 값이 있는지 확인
7. 세션ID 별도의 저장소에 그 유저의 유저정보를 저장
   (7번 중복)
8. html파일로 리턴(보통 메인페이지)
9. 유저정보 request(세션ID를 들고감)
10. 서버에서 세션ID의 영역을 찾고 값을 확인(로그인 한지 안한지)
11. db에 해당 유저정보 요청
12. 서버에서 해당 정보 응답
13. 클라이언트에 해당 정보 response

세션의 단점

세선에는 단점이 있다. 보통 서버보다 많은 양의 리퀘스트를 처리하기 위해 서버를 여러대 두어 로드밸런싱을 하는데, 이때 1번서버의 세션에 접속을 한 유저가 로드밸런싱을 통해 다른서버로 접속을 하게 되면 세션값이 없기 때문에 로그인이 안된다. 이 문제는 다음과 같이 해결 가능하다.

1. 로드밸런싱을 무시하고 한 서버에만 접속하게 한다.(스티키 서버)
2. 최초접속한 서버의 세션값을 다른 서버에 복제한다.
3. 세션을 통합하여 DB에서 값을 가져오게 한다.

어느 쪽이든 굉장히 번거롭다. 1번과 2번은 문제가 명확하고, 3번같은 경우 세션을 DB로 묶게 되면 request가 올때마다 I/O가 일어나 굉장히 속도가 느려진다.(기존 세션은 메모리에 담아 조회할때 캐싱하는 방식이라 빠름) 따라서 메모리DB에 묶는다.( ex) redis)