등장 배경
쿠키와 세션은 HTTP 프로토콜 특성의 한계점을 보완하기 위해 등장했다. 서버와 클라이언트가 데이터를 송/수신하는 동안 상태를 저장하지 않는 무상태성(Statusless)과 서버의 응답이 종료되면 클라이언트와의 연결을 끊는 비연결성(Connectionless)이 그러하다. 하지만 웹의 발전으로 요청과 응답간의 상태가 유지(로그인) 되어야 할 필요가 생겼다.
쿠키
브라우저 접속 시 생성되는 정보를 담은 임시 파일이다. 서버가 사용자의 정보를 브라우저에 저장하는 데이터를 의미하며 Key와 Value로 구성된 문자열(String)이다. 사용자가 서버로 요청을 보내면 요청안에 쿠키가 포함되어 있으므로 서버는 이 쿠키를 통해 사용자를 식별한다.
- 브라우저마다 저장되는 쿠키가 다름
- 크롬 브라우저의 쿠키와 익스플로러의 쿠키는 서로 달라 다른 쿠키로 식별
- 서버가 알아야 할 정보(사용자 이메일 닉네임 접속 시간 등)를 저장
- 크롬 기준 쿠키의 용량은 최대 4kb
쿠키의 한계
- 쿠키가 저장돼있는 브라우저에 사용자의 정보들이 기록되므로 개인 정보 유출의 가능성이 있다. 하지만 브라우저 자체에 쿠키 거부 기능이 있어 쿠키 허용 여부를 설정할 수 있다. 쿠키를 설정해놓지 않으면 쿠키가 가지는 기능을 사용할 수 없다.
- 클라이언트(브라우저)에 저장되므로 임의로 수정/삭제가 가능하며 가로채기도 쉬워 보안에 취약하다. 쿠키에 주민번호나 비밀번호 등 민감한 정보를 저장하는 건 위험하다.
- 쿠키의 용량이 커지면 오버헤드 발생
세션
쿠키를 기반으로 작동하지만 쿠키의 단점을 보완한 방식이며 세션은 서버에 저장되고 브라우저로 웹 서버에 접속한 시점부터 브라우저 종료(연결) 시까지의 요청을 하나의 상태로 간주하고 이 상태를 일정하게 유지하는 방식이다.
- 로그인/비로그인 사용자 둘 다 세션이 생성됨
- 서버에 저장되므로 쿠키보다 상대적으로 보안이 좋음
- 서버에서 세션을 삭제하거나 브라우저 종료 시 세션은 삭제
- 저장 데이터 용량 제한이 없음
세션의 한계
서버의 부하를 분산하기 위해 로드밸런싱(Scale out)을 해야 할 경우 여러 대의 서버를 둔다. 이 과정에서 최초 세션이 생성된 서버와 그 이후의 요청을 받은 서버의 세션이 일치하지 않을 경우 문제가 발생한다. 이를 해결하기 위해 요청이 세션을 생성한 서버로 향하도록 하는 Sticky Session 방식과 여러 서버가 모두 동일한 세션을 가지고 있는 Session Clustering 방식 그리고 In Memory 방식의 데이터베이스를 사용하는 Session Storage 방식이 있다.
- 서버에 저장되므로 세션의 용량이 커지면 그만큼의 부하 발생
- 로드밸런싱의 개발 난이도 증가
- 멀티 디바이스(모바일) 환경에서의 처리(중복 로그인 불가 등) 비용 증가
차이
쿠키 | 세션 | |
저장 위치 | 클라이언트(브라우저) | 서버(메모리) |
저장 형식 | 문자열(String) | 객체(Object) |
리소스 | 클라이언트 | 서버 |
용량 제한 | 쿠키 1개당 4kb / 최대 20개 | 제한 없음 |
만료 시점 | 쿠키 저장 시 설정 설정 없을 시 브라우저 종료 시 |
브라우저 종료 시 |
참고 자료
https://devuna.tistory.com/23?category=890707
https://hudi.blog/cookie-and-session/
https://hahahoho5915.tistory.com/32
'네트워크' 카테고리의 다른 글
Dto Repository Architecture (0) | 2022.08.31 |
---|---|
Nginx (0) | 2022.08.11 |
로드밸런서 (0) | 2022.08.03 |
Proxy (0) | 2022.08.01 |
HTTP 비연결성 무상태성 (0) | 2022.07.30 |