Cookie & Session
쿠키
, 세션
을 공부하겠다고 한지도 너무 오래된 것 같기도하고... 너무 많이 듣게 되는 단어기도해서 이번에 확실하게 정리하고자 한다.
1. Stateless 프로토콜
영어사전에 저 단어를 검색해보면 상태가없는으로 나온다. 그럼 쿠키,세션 이야기를하다가 왜 뜬금없이 Stateless protocol이냐? 쿠키와 세션의 등장이유에 대해서 알아보기 위해서다. 그 이유는 생각보다 간단하다. 웹개발자라면 많이볼수 밖에 없는 http 프로토콜은 기본적으로 stateless 프로토콜이다. 즉 서버가 클라이언트에 대한 상태를 저장하지 않는다는 말이다. 첫번째 request와 두번째 request는 클라이언트의 상태와 전혀 독립적인 상태가 된다는 뜻이다.
근데 실제로 웹을 개발하다보면 stateless 방식으로는 한계가 있다. 왜? 아주 쉽게 생각하면 로그인을
생각해보자 stateless가 맞다면 로그인이 필요한 서비스에 관한 모든 페이지에서 로그인을 새로해주어야한다. 왜? 서버가 받는 request는 이 클라이언트가 로그인을 했는지 안 했는지에 대한 상태를 가지고 있지 않기 때문이다.
결국 웹개발자 입장에서는 statefull방식을 이용을 해야하는데 이 방법들이 쿠키와 세션, 캐시가 된다.
2. Connectionless 프로토콜
여기서 또 http의 특성중 Connectionless를 또 말을 안하고 넘어갈 수 없다. 위에서 말한 stateless와 이 Connectionless는 http의 큰 특징들중 하나로써 장점이자 단점이 된다. Connectionless는 연결지양으로 클라이언트가 request를 보내면 서버가 response를 하고나면 끝!인것을 의미한다. 즉 왔다갔다한번하고 연결을 끊는 것이다. 잉? 이게 왜 장점이자 단점이냐?
장점으로써는 서버는 리소스 낭비를 최소화 할 수 있게된다. 왜냐면 연결을 시켜놓는 것만으로도 상당한 리소스를 차지하기 때문에 필요할때만 연결을 하고 끊으면 당연히 리소스가 절약된다.
단점으로는 역시 통신을 할 때마다 계속 request를 보낸 클라이언트가 누구인가를 인증할 필요가 있다는 것이다.
3. Cookie 쿠키
쿠키는 브라우저에 유지되고, 통신시에 http 헤더에 저장되어지는 텍스트 파일이다. 그럼 뭘 유지하느냐? 그건 개발자가 정하기 나름이다. sk같은 경우는 로그인시 response로 받는 유저정보를 저장한다고 가정을하고 쿠키를 이용한 흐름을 파악해보도록 하겠다.
- 첫번째 request(처음 request할때에는 클라이언트는 쿠키를 가지고 있지 않는다.)
- 서버는 request의 헤더를 까본다 ==> 쿠키없음 ==> request data의 id와 pw를 확인한다 ==> 서버가 토큰에대한 데이터를 쿠키로 만들어서 쿠키를 response에 실어서 보낸다.
- 클라이언트는 쿠키를 브라우저에 유지한다.
- 두번째 request(http 헤더에 쿠키를 실어서 보낸다)
- 서버는 request의 헤더를 까본다 ==> 쿠키있음 ==> 쿠키로 판별한다.
- 제한조건
- 클라이언트는 총 300개의 쿠키를 저장할 수 있다.
- 하나의 도메인 당 20개의 쿠키를 가질 수 있다.
- 하나의 쿠키는 4096byte까지 저장할 수 있다.
- 만료일이 존재하면 만료일이 존재하면 삭제된다.
아닠ㅋ이럴꺼면 왜 쿠키를 쓰는것인가? 그냥 로컬스토리지나 세션스토리지를 쓰는게 더 효율적인게 아닌가?라는 생각이 든다. 로컬스토리지야 영구저장이니깐 쿠키보다 보안이 약하긴 하지만 세션스토리지 같은 경우에는 브라우저가 종료되면 자동으로 리셋되니 보안이 더 강력할터, 뿐만아니라 용량의 차이도 크다. 로컬스토리지 같은 경우에는 브라우저마다 다르지만 용량이 20Mb가 된다. 단일 쿠키 4kb에 비하면 어마어마하게 큰 값이다. 그리고 쿠키는 자동으로 http header에 포함이 된다. 4kb가 작긴하지만 그래도 매번 요청할 때마다 낭비가 생긴다.
그래서 찾아보았다. 쿠키와 로컬,세션스토리지에대한 비교를...
html5가 도입되고나서 쿠키의 단점을 보완하기위해 만든 것이 로컬, 세션 스토리지 라는 것이였다.
추가적으로 쿠키라고 이름이 불리게된 이유가 참으로 신선하다. 핸젤과 그레텔에서 꼬꼬마친구들이 집을 찾아가기 위해서 과자부스러기를 흘리는데 그걸 모티브로 해서 쿠키로 이름을 명명한 것이라고 한다. (쿠키를 통해 유저의 데이터를 찾아가는건가..?)
4. Session 세션
일단 세션의 정의부터 알아야한다. 상당히 세션은 범용적으로 많이 쓰이는데 웹에서의 세션이란 클라이언트와 웹서버 간 네트워크 연결이 지속 유지되고 있는 상태를 말한다.
http는 Connectionless라 하지 않았는가? 근데 Session은 네트워크 연결이 지속 유지되고 있는 상태이다. 즉 웹개발에서 사용하려는 세션은 http의 장점이자 단점을 깨고자하는 것이다. 그럼 어떻게 쓰는지 알아보자.
- 클라이언트가 로그인데이터(id,pw)를 서버로 보낸다.(첫번째 request)
- 서버는 인증을 하고 들어온 request에 한하여 세션id를 생성/저장한다.
- 서버는 세션id를 response한다.
- 클라이언트는 이 세션id를 쿠키에 저장한다.
- 클라이언트가 이 세션id를 서버로 보낸다.(두번째 request)
- 서버는 이 세션id를 보고 클라이언트의 id를 확인할 수 있다.
클라이언트에 대한 데이터를 클라이언트가 아닌 서버에 저장함으로써 쿠키보다는 확실히 안전하다고 생각이 든다. 하지만 서버에 저장되는 세션정보라 서버에서 세션id를 구분하는데 드는 비용, 계속해서 서버에서 세션정보를 저장해야하는 비용이 드는 것이 단점이다.
5.결론
문제는 결국 Stateless를 깨기위한 이 state를 어디에 어떤식으로 저장할 것인가에 있다. 이건 저장할 데이터에 따라 다른 문제고 보는 관점에 따라 다른 문제라 생각한다.