Session- 이론

1. 세션이란?

 Session은 서로 관련된 HTTP 트렌젝션을 서버가 구별할 수 있도록 한데 묶어 놓는 것을 말한다. 

하나의 브라우저에 대응하는 세션 객체(저장소)는 하나이다. (1대1 대응)

(다른 PC에서 나온 브라우저, 한 PC에서도 서로 다른 브라우저라면 세션 ID가 서로 다르다.)

(HTTP트렌젝션 - 요청과 응답 한 세트를 말함.

 요청들은 서로 독립적이라, 세션이나 쿠키가 없으면 서버는 해당 요청이 같은 클라이언트에게서 온 것인지 아닌지 구별하지 못한다.) 

세션은 서버에 객체로서 존재하고, 서로 연관된 요청들을 하나로 묶기 위해 쿠키를 이용한다.

2. 세션이 돌아가는 과정. 

  (1) 세션의 생성

브라우저에서 첫 번째 요청이 오는 순간, 서버에서는 해당 요청에 대한 세션을 만든다. 

그리고 요청에 대한 응답을 할 때, 응답 메세지 Header에 세션 ID가 적힌 쿠키를 보낸다. 

  (2) 세션ID를 이용해 서버와 클라이언트가 요청,응답을 주고 받는 과정.

두 번째 요청부터는 요청 메세지의 Header에 아까 적어보낸 세션 ID가 적힌 쿠키가 써져있다. 

서버는 이 세션 ID를 보고, 어느 브라우저에서 온 요청이고, 어떤 다른 요청이나 응답과 연관되어 있는지 구별할 수 있다. (이건 브라우저 마다 대응하는 세션이 유일무이하기 때문에 가능하다.)

서버는 같은 세션 ID를 가진 요청이나 응답은 서로 연관되어 있는 것으로 묶어 생각할 수 있다.

 

이때 같은 세션 ID를 가진 요청들은 해당 세션ID를 가진 세션을 똑같이 사용할 수 있다. 위에서 2,3번 요청들은 모두 Session #2F460A를 사용할 수 있는 것이다.

 

** 컨트롤러에서 세션 객체를 불러다 쓰는 방법**

// 컨트롤러에서 세션 객체를 생성하고, 여기다가 이미 첫 요청에 의해 만들어진 세션 객체를 맵핑

/* 	requst 객체에서 세션 객체를 찾을 수 있는 이유
	request 요청의 Header에 세션 ID가 뭔지 적혀 있으므로, 
    우리는 request에 적힌 이 Session ID를 이용해 해당 요청에 써야할 세션 객체를 찾을 수 있다.
    */
HTTPSession session = request.getSession();


//해당 세션 객체에 값 집어넣기.
session.setAttribute("id","asdf");

  (3) 세션의 종료

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

 a. 수동종료: 컨트롤러에서 매소드 호출해서 세션을 종료시켜버림.

// 이미 존재하는 세션 객체를 맵핑
HttpSession session = request.getSession();

session.invalidate(); 					// 1. 세션을 즉시 종료
session.setMaxInacitveInterval(30*60); 	// 2. 예약 종료(해당 매소드는 초 단위, 따라서 30분 뒤 종료)

 b. 자동종료: web 설정을 담당하는 web.xml을 열어 session의 수명을 설정한다. 

                      그러면 수명이 다 되면 어떤 session이든 자동 종료가 된다.

<session-config>
	<session-timeout> 30 </session-timeout>
</session-config>

<!--이 녀석은 분 단위-->

c. 세션이 종료되면? 

세션이 종료되면, 그 다음 요청부터는 첫 요청으로 간주되어 새로운 세션이 생성된다. 

해당 요청에 대한 응답 시 , 응답 header에는 새로 생성된 세션의 id가 쿠키로 적힌다.

3. 세션과 쿠키 비교 

종류	쿠키	세션
저장 위치	브라우저에 저장	서버에 저장
서버에 부담 주는지?	서버에 부담x  (저장 자체가 브라우저에 되므로, 용량으로 서버에 부담을 주지 않는다.)	서버에 부담 O (세션은 클라이언트마다 만들어지고, 클라이언트가 늘어날수록 서버에 계속 생성되어 저장됨. 용량이 늘어날수록 서버에 부담이다.)
보안	보안에 불리(그래서 인코딩 하는 가)	보안에 유리 (서버는 보안이 철저!)
서버 다중화에 유리?	다중화에 유리 쿠키는 브라우저에서 됨.  따라서 서버가 늘어나든 말든 상관이 없음.  따라서 서버 규모가 큰 사이트에서는 쿠키를 애용함.	다중화에 불리 예를 들어 A 서버에 클라이언트의 ID 정보를 저장한 세션이 있다고 치자.  해당 클라이언트가 다시 접속 했을 때, B 서버가 연동되면, B 서버의 세션에는 클라이언트의 ID 정보가 없으므로, 로그인이 안되어 있다고 뜰 것이다.  이러한 오류를 없애기 위해서는 서버마다 가지고 있는 정보가 같도록 서버 동기화 작업을 해줘야 한다.  서버가 다중화 될수록 세션 땜에 동기화 작업이 많아지므로, 세션은 서버 다중화에 불리하다.

** 서버 다중화

하나의 기본 서버가 존재하고, 그 기본 서버랑만 연결되어 있는 다수의 서버들이 존재한다. 

기본 서버로 데이터가 들어오면, 기본 서버는 데이터를 다른 서버들한테 골고루 나눠준다. 

하지만, 기본 서버를 제외한 다른 서버들 간에는 연결이 되어있지 않으므로, 서버들 간에 데이터 공유는 안된다.

다중화된 서버의 모습.

4. 브라우저 설정으로 쿠키 차단 시, 서버는 어떻게 요청들이 같은 브라우저에서 왔는지 구별할까? 

이렇게 차단 해두면  브라우저에서 요청을 계속 보내도, 쿠키로 session id가 저장되지 않는다.

 

이는 서버에서 세션 id 를 안 보낸 것이 아니라, 세션 id는 계속 보내는데, 브라우저가 차단하고 안 받는 것이다. 

이렇게 되면 로그인 해도, 로그인 후 할 수 있는 행동을 못할 것이다. 왜냐하면, 연관된 요청끼리 서로 묶어 간주할 수 있게 해주던 session id를 못 쓰게 되어서, 서버가 요청들을 분간할 수 없기 때문이다. 

하지만 웹 페이지는 잘 돌아간다.  왜 그럴까? 

 

왜냐하면, 우리가 JSP 문서에서 썼던 C 태그 중 C:url이라는 태그가 URL 뒤에 Session ID를 자동으로 붙여주기 때문이다. 

서버는 URL 뒤에 붙은 세션 아이디를 통해 요청이 들어올 때 어떤 브라우저에서 온 것인지 구분할 수 있다. 

로그인 한 후 홈페이지에서 GET으로 갈 수 있는 어느 링크건 뒤에 세션 아이디가 붙어 있음을 JSP 문서를 통해 확인할 수 있다. 

이는 C 태그 덕이다. 

C 태그를 안 쓰고  form action 옆 URL을 하드 코딩 하면, URL 뒤에 자동으로 Session ID가 붙지 않는다. 

하드 코딩한 경우에 쿠키 차단해버리면, 요청을 보낼 때 마다 응답 메세지에 다른 세션 아이디가 온다. 

이유는 서버가 오는 요청들이 같은 클라이언트에서 온다는 걸 분간하지 못한다. 따라서 오는 요청들을 전부 첫 번째 요청으로 간주하고 요청마다 세션을 생성해버린 것이다.

 

C:url 태그 쓰는 서버는 첫번 째 요청에 대한 응답으로 URL 뒤에도 세션 아이디를 붙이고 응답 메세지 쿠키로도 세션 아이디를 보낸다. 이유는 해당 브라우저가 쿠키를 차단하는지 아닌지 알 수 없기 때문이다. 

만약 해당 브라우저가 쿠키를 저장하고, 요청 메세지에 쿠키를 같이 보낸다면, 서버는 C:url 태그의 URL 변경 기능을 더 이상 쓰지 않는다.