Session과 JSESSIONID

목차

---

1. Session이란

1-1 Session과 로그인 처리

1-2 Session의 위치

2. JSESSIONID란

2-1 JSESSIONID와 클라이언트(Browser)

3. Tomcat과의 관계

 

 

 1. Session이란

HTTP 프로토콜을 사용하는 Spring WAS와의 통신은 기본적으로 무상태(StateLess) 즉 1회성이란 말이다.
그렇기 때문에 로그인 같이 상태를 유지해야 하는 상황에서는 상태를 유지할 수 있는 방안이 필요하다.
그것을 위한 방안이 Session이란 것이다.
Java에서는 ServletContainer가 생성의 주체이다.

 

1-1 Session과 로그인 처리

그렇다면 Session을 통해 로그인을 처리하는 방법은 무엇일까?

1. 사용자가 로그인 화면을 통해 아이디와 비밀번호를 입력한다.
2. 서버단에서 입력받은 아이디와 비밀번호를 통해 회원 DB를 조회한다.
3. 조회가 된 회원 데이터를 통해 Session을 생성한다.
4. 클라이언트가 사용할 수 있도록 쿠키를 만들고 클라이언트에 전달한다.
5. 클라이언트는 전달 받은 쿠키를 요청 헤더에 포함하여 요청을 날린다.

 

 

1-2 Session의 위치

위에서 말했다시피 Session을 관리하는 주체는 ServletContainer(WAS)이다.

그런데 하나의 WAS를 이용하는 고객은 한 명이 아니라 여러 명이고 그때마다 WAS는 session을 생성, 저장하고 그 정보를 담을 Cookie도 생성하여 전달해주어야 한다. 

결국 Was를 구동중인 PC(서버)의 자원을 더욱 사용하게 되는 것이고, Session이 서버에 부담을 많이 주는 상태유지 기법이라 하는 것이다.

그렇기 때문에 요즘에는 Session보다 JWT를 더 많이 사용하는 것이다. JWT는 상태 유지를 위한 정보를 서버가 아닌 
클라이언트의 browser가 가지고 있기 때문이다.

---

 

2. JSESSIONID

WAS는 Session 정보를 Cookie에 담아 클라이언트에 전달한다고 했다.

따로 지정을 하지 않으면 해당 Cookie의 이름은 JSESSIONID라고 붙여지게 된다.

 

2-1 JSESSIONID와 클라이언트(Browser)

사용자가 실제 로그인을 한 뒤 발급받은 Cookie는 개발자 도구 > 어플리케이션 탭에서 확인이 가능하다.

이렇게 로그인 정보를 담은 Cookie는 서버에서 지정한 시간 동안 유효하며 앞으로 매 요청에 해당 Cookie가 포함된다.

---

 

 3. Tomcat과의 관계

보통은 하나의 톰캣(Web Server)에 하나의 어플리케이션을 구동한다.즉 1:1 관계로 구동을 한다.

하지만 상황에 따라 하나의 톰캣에 여러 어플리케이션 구동 시킬 수 있다.
이런 상황에서는 각 어플리케이션에 port 번호를 달리하여 Web서버가 각 어플리케이션들을 식별한다.

 

하지만 이렇게 1:M 관계로 구동할 때 주의할 점이 있다. Session Cookie의 이름을 기본값인 JSESSIONID로 사용하게 되면
문제가 될 수 있다는 것이다.

그렇기 때문에 이런 경우에는 Tomcat의 Server.xml에서 각 어플리케이션에서 사용할 Session Cookie이름을 고유하게 지정해준 뒤 사용해야 한다.

 

본인은 얼마 전 개발 서버에서 이니시스 결제 모듈 테스트 중 후처리 부분에서 로그인 정보 관련된 에러가 산발적으로 발생하여 고생한 적이 있었는데 알고 보니 개발 서버에서 하나의 tomcat에 3개의 어플리케이션을 구동하고 있었고,

후처리 로직에서 로그인 Session을 가져올 때 따로 SesessionID를 지정하지 않아 에러가 났던 경험을 하여 이렇게 따로 기록을 남기게 되었다.