24. 세션(Session) - 이론

1. 세션이란?

요청 하나 하나는 서로 독립적이다. 즉 서로 관련이 없다. 이 요청들을 묶은 것이 세션이고 쿠키를 이용한다. 서버에서 브라우저마다 개별 저장소(session 객체)를 제공한다. 브라우저마다 세션이 생기는 이유는 쿠키를 이용하기 때문이다. 차이점은 쿠키는 브라우저에 저장되지만 세션은 서버에 저장된다.

 

session의 정의는 "a collection of related HTTP tranactions made by one brower to one server."이다. 여기서 HTTP tranactions는 요청과 응답을 말한다. 또한 one brower to one server로 브라우저와 서버에 1:1로 있음을 알 수 있다.

 

브라우저가 요청을 하면 서버가 JESSIONID을 보낸다. 첫 번째 요청 이후부터는 JESSIONID가 따라 붙는다. 원래 같은 브라우저가 요청을 보낸다 하더라도 서로 관련이 없다. 쿠키를 이용해서 자동으로 JESSIONID을 붙이니까 공통점이 생긴다. 같은 세션으로 포함되 있는 동안은 session 객체를 사용할 수 있다. 

 

세션을 없애는 방법은 수동으로 invalidate 메서드를 사용하거나 자동으로 Time out 메서드를 이용해서 특정 시간 이후에 없어지도록 할 수 있다.

 

2. 세션의 생성 과정?

브라우저가 요청을 하면 서버가 무조건 세션 객체(저장소)를 만든다. 그 세션에 ID가 있다. 이 저장소를 사용할 수 있도록 쿠키에 JESSIONID를 담아서 보낸다. 응답 메세지를 보면 Set-Cookie에 JESSIONID가 있다.

 

브라우저에 쿠키가 저장되면 요청 메세지의 헤더에 JESSIONID가 포함된 Cookie가 같이 간다.

 

3. 세션 객체 얻기?

세션은 같은 컴퓨터에 있더라도 브라우저가 다르면 서버로부터 다른 세션 아이디를 받아 저장한다. 서버에 있는 세션 저장소를 사용하고 싶으면 request의 getSession 메서드를 사용한다. 요청 메세지에 넘어온 JESSIONID를 보고 일치하는 저장소를 찾아 setAttribute 메서드를 이용하면 세션에 key, value 값을 저장한다. 세션에 있는 값을 읽고 싶다면 setAttribute가 아니라 getAttribute를 이용한다.

 

request를 사용하는 이유는 요청 헤더에 JESSIONID가 있으므로 request 객체에 Session 객체 정보가 담겨져 있다. 일치하는 Session이 있다면 session 참조 변수가 해당 저장소를 가리킨다.

 

4. 세션과 관련된 메서드?

 

 

5. 세션의 종료?

종료에는 수동, 자동 종료가 있다. 

 

자동 종료는 web.xml에 예약을 걸 수 있는데 분단위로 한다. 만약 로그인한 기록이 계속 남아있게 되면 보안에 좋지 못하고 서버에 부담이 커 꼭 설정해야한다.

 

요청 간격이 30분을 넘으면 Timeout으로 서버에서 새로운 세션을 다시 발급한다. 이전 저장소는 JESSIONID이 다르므로 이전 세션은 사용하지 못한다. StandardManager가 세션을 자동으로 생성하고 관리하지만 서버에 세션 객체가 오래 있을 가능성이 커 최소한의 정보만을 담아야 서버에 부담이 적다.

 

6. 쿠키 vs 세션?

서버는 보안에 철저하므로 세션이 상대적으로 보안에 유리하다. 쿠키는 보안을 위해 값을 암호화해서 저장한다.

 

클라이언트와 서버가 1:1이면 세션이 1개만 있어도 되지만 큰 웹사이트에서는 큰 서버를 두고 작은 서버가 딸려 있다. 만약 하나의 작은 서버에 세션을 저장하게 되면 다른 작은 서버에도 동기화 하는 작업이 필요해 다중화 하는데 불리하다. 쿠키는 브라우저에 저장하면 되므로 서버에 부담이 적어 큰 웹사이트는 쿠키를 많이 사용한다. 보안에 취약한 점은 암호화해서 저장하면 된다.

 

Application에 들어가서 처음 세션을 지운다.

 

새로고침 하면 첫 요청으로 서버가 쿠키에 JESSIONID를 응답으로 보내준다.

 

Network에 reponse 헤더를 보면 set-Cookie가 있고 이 정보를 이용해서 쿠키를 만들라는 뜻이다. set-Cookie에 의해 Application tab에 JESSIONID가 보여진다.

 

첫 호출에는 request 응답 메세지에 Cookie가 없다.

 

새로고침을 하면 두 번째 요청부터는 Cookie가 따라간다. 브라우저에 저장된 JESSIONID가 요청에 계속 포함된다. 서버는 다른 요청이어도 아이디를 통해 같은 브라우저를 통해 온 것을 알 수 있다.

 

구글 설정에 쿠키를 차단하면 응답 헤더에 set-Cookie를 아무리 보내도 브라우저에 Cookie가 저장되지 않는다. 대신 쿠키를 허용하지 않는 브라우저에는 URL에 JESSIONID가 붙어 출력되게 만들어야 한다. 그래야 쿠키가 없어도 서버가 요청을 구분할 수 있다.

 

JESSIONID가 붙는 이유는 form tag에 c:url 코드가 자동으로 붙여준다.

 

쿠키를 허용하고 첫 요청을 보내면 URL에 JESSIONID가 붙는다. 처음 요청할 때는 브라우저가 쿠키를 허용하는지 안하는지 모르기 때문에 JESSIONID를 2가지 방법으로 보내준다. 한 가지는 위와 같이 URL에 붙여서 보내고, network의 응답 헤더에 set-Cookie로 JESSIONID를 보낸다.

 

두 번째 요청을 보내면 URL에 JESSIONID가 붙지 않는다. 별거 아닌거 처럼 보여도 페이지 수가 많으면 페이지 마다 세션 ID가 붙어야 하므로 응답이 느려질 수 있다.

 

쿠키를 허용하지 않으면 모든 하이퍼링크에 JESSIONID가 붙는다.

 

쿠키도 허용하지 않고 c:url 태그도 쓰지 않을 경우 요청을 보낼 때마다 JESSIONID가 달라진다. 즉 브라우저가 요청을 처음 보내는 것으로 서버가 인식해 서버가 세션 객체를 만든다. 따라서 서버에 부담이 커진다. 따라서 c:url를 꼭 써야한다.