Cookie 방식 HttpSession의 작동원리

웹프로그래밍을 하면서 request.getSession() 만 호출하면 HttpSesion을 얻어서 사용할 수 있는 걸로 알고 있는데, 가끔씩 로그인 후에 세션이 유실되어 로그아웃되고 다시 로그인을 해야 하는 일이 생긴다. 그런데, 어디에 문제가 생겨서 로그인한 정보가 사라지는지 모르는 경우가 대부분이다.

이번 글에서는 웹브라우저와 WAS가 어떤 방식으로 HttpSession을 유지하는지 확인해 보려고 한다. 이 내용을 이해하면 HttpSession이 유실되었을 때 원인을 찾기에도 도움이 될 것이다.

1. Session Cookie Name
먼저 세션을 인식하기 위해 사용자는 Cookie의 이름을 알아야 한다. 이것은 서버에서 정해지고 서버에서도 설정된 이름의 Cookie를 이용해 HttpSession을 찾고 그 안에 저장된 값을 꺼내서 사용한다. Java 기반의 WAS는 보통 JSESSIONID를 사용하므로 이 글에서는 Session Cookie Name로 JSESSIONID를 사용할 예정이다.
아주 가끔 같은 사용자에 대해 2가지 이상의 업무나 WAS 그룹이 있고 서로 다른 HttpSession을 사용하고 싶을 때는 업무나 그룹별로 다른 Session Cookie Name을 사용한다.
다시 강조하는데, JSESSIONID를 일반적으로 사용하지만 다른 값이 사용될 수도 있으니 꼭 확인해야 한다.

2. 웹브라우저의 최초 요청에 대한 서버 응답 헤더의 set-cookie
웹브라우저가 사이트에 접속해서 처음으로 요청을 서버에 보내면, 서버는 응답헤더에 set-cookie 값으로 Session Cookie를 담아서 보낸다.
응답 헤더에 set-cookie를 받은 웹브라우저는 로컬 저장소에 그 cookie값을 저장한다.

응답헤더의 set-cookie: JSESSIONID=

 

3. Session Cookie 저장 이후의 모든 요청
이렇게 서버의 도메인에 대해 cookie가 저장되면, 이후에 해당 도메인에 대해 요청을 보낼 때는 cookie가 만료되기 전까지 요청헤더에 항상 cookie: JSESSIONID=abcdefu 가 붙어서 가게 된다.
WAS 안에서는 JSESSIONID라는 cookie의 값을 꺼내서 WAS 내의 세션저장소에 저장된 이 사용자의 HttpSession을 검색해서 사용한다.

요청헤더의 cookie: JSESSIONID=

 

Web Server의 Sticky Session

WAS가 다중화된 환경에서는 앞단의 로드밸런서, 라우터, 웹서버 등에서 같은 사용자의 요청을 매번 같은 WAS 인스턴스에 전달해 주지 않을 가능성이 있어서 세션 클러스터링이 필요하다.(물론, WAS에서 HttpSession에 사용자 정보를 유지하도록 구성한 경우에 한해서) 이렇게 세션클러스터링을 준비하지 못 했을 경우에는 같은 사용자의 요청이 매번 같은 WAS 인스턴스에 전달되도록 웹서버 등에 Sticky Session 구성을 해야 한다. 세션클러스터링으로 구성해도 대개 Sticky Session을 구성을 하긴 한다.
Sticky Session을 구성하면 위에서 설명했던 Session Cookie의 값이 조금 달라진다. 톰캣이나 웹로직을 보면 Session Cookie의 값 뒤에 WAS 인스턴스 정보를 추가로 붙여 준다. Session Cookie 값이 abcdefu이고 웹서버에 설정된 WAS 인스턴스의 ID 값이 was1이라면 최초 응답헤더의 set-cookie에서 JSESSIONID의 값으로 abcdefu_was1 를 전송하는 식이다.
이 Session Cookie 값으로 웹서버가 요청을 받으면 JSESSIONID 값의 맨뒤에 있는 was1를 꺼내서 아이디가 was1인 WAS 인스턴스로 요청을 전달한다. 이렇게 해서 같은 사용자의 요청을 같은 WAS 인스턴스에 전달하도록 구성할 수 있다.
이 상태에서 해당 WAS를 재기동하고 완전히 기동되기 전에 요청이 들어오면 웹서버는 해당 WAS 인스턴스에 요청을 전달하려고 시도했다가 실패한다. 세션클러스터링이 구성되지 않았다면 재기동되어도 세션정보가 없어서 HttpSession 조회에 실패할 것이고, 세션클러스터링이 구성되어 있어도 해당 WAS 인스턴스가 죽었다고 판단한 웹서버는 다른 WAS 인스턴스로 요청을 전달하려고 시도하게 될 것이다.

 

간단하게 Cookie를 이용하는 HttpSession 작동원리에 대해서 알아 보았다.