Session

출처 :https://tansfil.tistory.com/58

 

SESSION : 클라이언트의 웹의 방문 기록을 서버에 저장하여 클라와 서버를 연결해주는 매개 정보.                    또는 서버에 로그인이 지속되어 있는 상태

 

◎ 특징 : 1. 쿠키보다 보안에 유리함. 본인의 session만 접속 가능. 서버가 해킹당하지 않는 한 탈취당할 위험은 적다. 2. 브라우저를 하나 열어서 탭을 여러개 세팅해도 하나의 session, 하나의 user임. > 다른 종류의 브라우저를 켜면 별개의 user id로 간주 >> 컴퓨터별이 아닌, 브라우저별임. (크롬 새로 열어도 다른 session이었습니다!) 3. 기본 시간 : 30분(1800초) 끝나면 기존 session파기, 새로운 session발급됨 29분 59초에 refresh하면, + 30분 추가. (setMaxInactiveInterval; 초단위)30분도 길어서 줄이곤 함

◎ 과정 :  1. 처음 접속시 서버는 클라이언트별 session id발급, 쿠키에 저장. 2. 쿠키에 있는 session id를 가지고 클라에 응답 3. 클라는 session id를 브라우저에 저장(jsessionid) 4. 서버는 클라이언트에 넘겨준 session id로  request 호출마다 판별. (request.getSession; 기본값:true)

◎ session의 자원관리 주의점 : 발급해준 session id별로 session을 할당해주기 때문에 서버에 부담이 될 수 있다는 단점이기도 함 >>  session에는 최소 data만! 최적화해서 넣어야함. (개발자는 sessionScope에 data를 다 때려넣으면 개발할때 어디서든 꺼내쓰면 돼서 편하지만 그러면 안된다,,,) >>requestScope에는 대용량 데이터를 넣어도 되므로(request끝나면 사라지니까) request를 최대한 이용하기!

정리해보면

http, cookie, session을 공부했을때 크게 보이는 것은 http만 사용했을때 유저의 정보가 헤더에 그대로 노출되는 보안 문제를 해결하기 위해 cookie에 session id를 담아서 서버에 보낸다는 것.

또한 cookie에 보안상 중요한 정보를 담을 경우 해킹의 위험이 있으므로 서버의 session을 구분할 수 있는 session id '만' 쿠키에 저장을 해놓고, 중요한 정보가 들어있는 session객체는 서버에 저장해서 클라이언트를 판별한다. 

 

서버에서 아무리 session을 관리하더라도 data가 많을수록 메모리를 많이 먹고, 서버에 한 번 문제가 생겨서 꺼졌다......... 하면 저장해뒀던 session data가 다 날라가므로....

user가 많은 규모있는 서비스 서버는 token을 사용한다고 한다. 토큰 공부하러 출발~~