[HttpSession] session의 동작 원리 살펴보기

세션 방식 로그인

세션은 인증된 사용자의 정보를 SESSION ID와 매핑하여 서버에 저장하고 클라이언트에게 식별자와 문자열로 이루어진 SESSION ID를 응답헤더에 넣어 전송한다. 매 응답마다 SESSION ID 만 보내기때문에 네트워크 부하가 커지지 않고 서버에 저장되므로 클라이언트의 웹브라우저의 호환성 문제가 해결된다. 그리고 많은 정보의를 유지할 수 있게 된다. 하지만 서버에 데이터 저장량이 많아지므로 서버 메모리에 부담이 갈 수 있다.

 

 

백엔드 개발을 하다보면 로그인 구현은 필수라고 해도 과언이 아니다. 지금까지 진행했던 여러 프로젝트에서 로그인 기능이 없었던 프로젝트는 거의 없는 것 같다.

 

이렇게 아무렇지 않게 사용했던 세션에 대해 의문점이 생겼다. 

 

session.getAttribute("user")

 

이렇게 사용자 A가 접속해도 user를 Key값으로 값을 가져오고,

사용자 B가 접속해도 user를 Key값으로 가져온다. 

 

같은 Key값을 쓰는데 어떻게 이들을 구별해서 가져올 수 있는걸까??

 

 

아래 코드는 HttpSession을 사용한 간단한 로그인 예제 코드이다. 

코드를 보면 알다싶이 A가 요청한 HTTP 요청인지 B가 요청한 HTTP 요청인지 구분할 수 있는 방법은 따로 보이지 않는다. 여기서 session tracking 이라는 개념이 등장한다. 

@Controller
public class LoginController {
			
        @PostMapping("/login")
	    public String login(MemberLoginDto memberLoginDto, HttpSession session , Model model){
	       
	        Member loginMember = loginService.login(memberLoginDto.getUserId(), memberLoginDto.getPassword());
	
	        if (loginMember == null) {
	            result.reject("loginFail", "아이디 또는 비밀번호가 맞지 않습니다.");
	            return "member/loginForm";
	        }
	
	        //로그인 성공 처리
	        //세션이 있으면 있는 세션 반환, 없으면 신규 세션을 생성
	        HttpSession session = request.getSession();
	        //세션에 로그인 회원 정보 보관
	        session.setAttribute("loginMember", loginMember);
	
	        model.addAttribute("member",loginMember);
	        return "/member/memberInfo";
	    }
}

 

 

Session Tracking

일반적인 HTTP 요청에는 내가 누구인지에 대한 정보가 없다. 받고 싶어 하는 리소스 주소, 파라미터 정도 있을 뿐이다. 서블릿 컨테이너가 수신한 요청에 누가 보낸 요청인지에 대한 정보, 즉 식별자가 있어야 내부에 저장하고 있는 Session객체를 읽어서 참조할 것이다.

다시 말하면, 서블릿 컨테이너가 누구인지 어떻게 식별하게 하느냐에 대한 이야기가 Session Tracking Mechanism 이다.

 

Session을 추적하기 위해서 Cookie를 사용하는 게 가장 일반적이다. 컨테이너에서 요청에 대한 응답을 내릴 때 Session을 만들고 그 SessionID를 Cookie로 내려보내는 것이다. 클라이언트에 내려간 Cookie는 그 뒤에 이어오는 요청에 덧붙여져서 오기 때문에 컨테이너가 요청을 받았을 때 Cookie에 있는 Session 정보를 이용해서 요청자를 식별할 수 있다. 그래서 웹브라우저의 개발자 도구로 현재 페이지의 쿠키목록을 보면 JSESSIONID 가 있는 것이다.

 

 

아래 사진은 실제로 쿠키에 세션이 담기는 모습이다. 

 

 

 

로그인 요청을 보내면 Response Header로 JSESSIONID를 가진 쿠키를 전달 받는 것을 볼 수 있다.

 

 

 

위 과정을 그림으로 표현하면 다음과 같다. 

 

즉,  세션키를 담은 쿠키를 요청에 담아 보내기 때문에 스프링 서버에선 사용자 마다의 세션을 구분할 수 있는 것이다.