세션의 탄생
일상에서 웹브라우저를 열어서 무엇인가를 검색할때 세션이라고 하는 기술을 사용을 한다. 왜 세션이라는 기술을 사용할까? 그 이유는 웹브라우저는 사용자의 상태를 알지 못하기 때문이다. 좀 더 풀어서 말하면 HTTP 프로토콜은 TCP/IP라는 통신을 하는데, 이때 사용자는 어떤 검색어를 검색창에 입력하고 엔터를 누르면 웹브라우저에서 서버로 요청이 발생된다. 그리고 서버에서 응답을 한다. 그리고는 연결이 종료된다. 더 쉽게 예를 들어 보자.
1.몽실이가 아마존 사이트에 회원가입을 하고 로그인을 했다.
2.몽실이는 새아이폰을 구입하려고 아이폰12를 검색했다.
3.이때 아마존 웹사이트 화면에서 아마존 서버로 요청이 발생한다.
(www.amazon.com/search?productname=ipone 대략 이런식의 요청이다)
(아마존이 어떤 언어로 어떻게 서버가 구성되어있는지 모르지만 스프링으로 구성되어 있다 가정한다.)
4.스프링의 디스패처서블릿이 위의 url에 매핑되는 컨트롤러를 찾는다.
5.컨트롤러는 서비스에서 서비스는 DAO로 접근해서 ipone12 에 해당하는 상품목록을 가져온다.
6.다시 DAO로 부터 서비스, 서비스로부터 컨트롤러까지 데이터가 전달되고 컨트롤러에서 웹브라우저로 데이터가 뿌려진다.
7.몽실이는 어떤 아이폰12 제품이 저렴한지 찾는다. 3시간 넘게 찾다가 제일 저렴하게 올려져있는 상품을 찾았다.
8.이때 마우스를 잘못눌러서 닫기 버튼을 눌러버렸다.
9.다시 아마존 사이트로 들어갔는데.. 초기화 되어버렸다.
10.다시 로그인을 하고 검색창에 아이폰12를 검색해서 찾는다.
위의 상황은 정말 극단적인 가정이지만 순수하고 순수한 TCP/IP 통신의 예라고 할 수있다. TCP/IP 통신은 한번의 요청 그리고 한번의 응답. 그리고 끝이다. 사용자 입장에서는 정말 불편하지 않을까? 창이 실수로 닫혔다. 그런데, 다시 로그인을 해야하며, 로그인을 했어도 이전에 내가 살펴보던 제품을 다시 찾아야 한다. 어려운말로 상태를 저장할 수 없다. 그래서 세션이라는 기술이 발명되었다. 어떻게 하면 사용자가 조금 더 편리하게 웹사이트를 이용할까? 어떻게 하면 좀 더 효율적으로 데이터를 보여줄까? 하는 고민에서 나온것이다. 그럼 이 세션을 이용해서 위와 같은 문제상황을 해결할 수 있을까? 답은 그렇다 이다.
세션의 동작
세션이 어떻게 동작하는지 살펴보자.
1.몽실이가 아마존 사이트에 회원가입을 하기 위해서, 필수 입력란을 작성하고 가입버튼을 누른다.
2.이때 웹브라우저에서 서버로 요청이 발생한다.
3.서버는 HTTP 헤더에 세션이 없음을 확인한다.
4.DB에 회원정보를 저장한다.
5.세션저장소(메모리)에 세션정보(유저정보)를 생성한다.
6.서버는 웹브라우저로 응답할때 이 세션정보도 함께 웹브라우저에게 돌려준다.
7.웹브라우저는 쿠키라는 저장공간에 서버에서 받은 세션정보를 저장한다.
8.몽실이가 마우스를 잘못눌러서 창이 닫혀버렸다. 다시 아마존 사이트로 들어간다.
9.아마존 사이트로 들어온 순간 웹브라우저는 헤더에 세션정보를 담아서 메인 페이지 요청을 한다.
10.서버는 세션저장소에서 해당 세션정보가 있는지 조회를 한다.
11.확인해보니 있다.
12.로그인된 상태로 응답을 한다. (즉, 다시 로그인 할 필요가 없다.)
13.아이폰12를 검색하다가 마음에 드는것을 발견해서 클릭했다.
14.서버에 해당 상품 상세보기 url 요청이 발생한다.
15.서버는 세션에 해당 상품에 대한 정보를 저장해 놓고 웹브라우저로 응답한다.
16.몽실이는 또 보다가 마우스를 잘못 클릭해서 창을 꺼버렸다.
17.다시 웹브라우저로 들어간다. 대박.
18.이번에는 로그인도 되어있고, 조금전 보던 아이폰12도 아랫쪽에 조그맣게 떠있다.
실제로 아마존 서버가 저렇게 되어있지는 않다. 단지 세션이라는 개념에 대해서 설명하기 위해서 위의 가정을 연출했다. 즉, 세션이라는 기술은 TCP/IP 통신에서 '상태를 저장해 놓을 수 있는 기술' 이다.
세션의 소멸
세션은 언제 사라질까? 세션은 특정시간이 지나면 사라진다. 보통 30분에서 1시간 정도 지나면 서버에서 사라진다. 그리고 웹브라우저에서 쿠키삭제 같은 기능 등 브라우저 청소를 할때 사라진다.
세션의 단점
세션은 치명적인 단점이 있는데, 통신과정에서 해커에게 정보가 탈취될 수 있는 위험이 있다. 즉 보안의 위험이다.
두번째는 웹사이트에 방문하는 방문자의 수가 늘어서 10만명이 되었다고 가정해 보자. 그럼 운영자는 서버를 한대 더 증설할 수 있다. 서버를 여러대 놓고 요청의 부하를 줄이는 기법을 로드밸런싱이라고 하는데, 로드 밸런싱을 하면 부하가 분산되어서 응답속도 개선은 있지만 세션처리문제가 이슈가 될 수 있다. 예를들어 웹사이트에서 사용자가 가입을하고 버튼을 눌렀을때 요청이 1번 서버로 갔다고 가정하자. 그럼 나중에 1번 서버에 접속자 수가 많아서 2번서버로 접근했다면 2번 서버에서 세션을 다시 생성해야 한다. 즉 2번 서버는 사용자의 가입을 모를 수 있다. 그럼 이를 해결하기 위해서 세션을 DB에 저장한다면 어떨까? 속도가 엄청 느려진다. 참고로 세션은 메모리에 올려져있어서 CPU가 금방 접근해서 데이터를 읽어 올 수 있지만 DB에 저장된 데이터는 메모리에 저장된 데이터보다 CPU가 읽어 오는 속도가 몇 만배 느리다. 참고로 하드디스크는 원판으로 되어 있어서 원 바깥 부터 안쪽까지 왔다갔다하면서 풀스캔으로 찾으면 시간이 엄청 소모된다. 그래서 해결책으로 레디스 메모리 서버를 세션 저장용으로 사용하기도 한다.
'웹개발 > 보안' 카테고리의 다른 글
카카오 로그인 OAuth2.0 (0) | 2020.12.08 |
---|---|
OAuth2 인증 - 인가 코드 그랜트 (0) | 2020.12.05 |
OAuth2 인증 - 암시적 코드 그랜트 (0) | 2020.12.05 |
스프링 Session 쇼핑몰 방금 본 상품&권한체크 (0) | 2020.12.05 |
스프링 Session으로 자동 로그인 구현하기 (0) | 2020.12.01 |