Cookie와 Session 을 사용하는 이유?
- 쿠키와 세션은 HTTP 프로토콜의 특징이자 약점을 보완하기 위해서 사용한다.
HTTP 특징이 뭐길래
- 비연결지향(Connectionless)
- 클라이언트가 요청(Request)를 서버에 보내고, 서버가 적절한 응답(Response)를 보낸 뒤 연결(Connection)을 끊는다.
- 헤더에 keep-alive라는 값을 줘서 커넥션을 재활용할 수 있는데, HTTP 1.1 버전에서는 연결을 유지하고, 재활용하는 기능이 Default로 추가되었다.
- 상태없음(Stateless)
- 커넥션을 끊는 순간 클라이언트와 서버의 통신이 끝나며, 통신이 끝나면 상태를 유지하지 않는 특징
장점과 단점
- 장점
비연결지향이라는 특성 덕분에 커넥션을 유지하지 않아 서버 리소스 낭비가 줄어든다. - 단점
통신할 때마다 새로 커넥션을 만들기 떄문에 클라이언트 측면에서는 상태를 유지할 때마다 계속 어떠한 절차를 가져야하는 단점이 있다. 페이지에서 페이지 이동할 때마다 인증하기 위한 절차를 가져야한다.
✔ 그래서 !
- HTTP의 상태를 유지하지 않는 특성 때문에 1요청에 1인증을 해야하는 번거로움이 생긴다.
- 때문에 이를 해결하고자 쿠키와 세션을 사용한다.
Cookie
Cookie의 특징
- 쿠키는 클라이언트 로컬에 저장되는 키, 값이 들어있는 작은 데이터 파일이다.
- 사용자 인증이 유효한 시간을 명시할 수 있고, 유효 시간을 정하면 브라우저가 종료되어도 인증이 유지된다.
- 클라이언트에 300개까지 쿠키 저장 가능, 하나의 쿠키값은 4KB까지 저장
- 하나의 도메인당 20개의 값만 가질 수 있음
- Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있음
- 쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request 시에 Request Header를 넣어서 자동으로 서버에 전송
쿠키 구성 요소
- 이름
- 값
- 유효시간
- 도메인
- 경로
쿠키의 동작 방식
- 클라이언트가 페이지를 요청(Request)
- 서버가 요청에 응답(Response) 할 때, 쿠키를 생성해서 Header에 심어 보낸다.
- 클라이언트는 그 쿠키를 로컬에 저장해두었다가 다시 서버에 요청할 때 쿠키를 함께 전송한다.
- 동일 사이트 재방문시 클라이언트의 PC에 해당 쿠키가 있는 경우 쿠키와 함께 요청한다.
사용 사례
- 자동 로그인
- 팝업 등에서 '오늘만 보지않기'
- 쇼핑몰의 장바구니
Session
Session의 특징
- 일정 시간동안 같은 사용자(브라우저)로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 일정하게 유지시키는 기술이다.
- 여기서 일정 시간이란 웹 브라우저를 통해 웹 서버에 접속한 시점부터 웹 브라우저를 종료하여 연결을 끝내는 시점을 말한다.
- 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장한다.
- 쿠키보다 비교적 보안이 좋다.
- 서버 용량이 허용하는 한 저장 데이터에 제한은 없다.
- 각 클라이언트 고유 Session ID를 부여한다. Session ID로 클라이언트를 구분하여 각 클라이언트 요구에 맞는 서비스를 제공하게 된다.
세션의 동작 방식
- 클라이언트가 요청(Request)
- 서버는 접근한 클라이언트의 Request-Header 필드에 Cookie를 확인하여 클라이언트의 해당 Session-ID를 보냈는지 확인한다.
- Session-ID가 존재하지 않는다면 생성해서 클라이언트에 돌려준다.
- 서버에서 클라이언트로 돌려준 Session-ID를 쿠키를 사용해서 서버에 저장한다. (쿠키 이름 : JSESSIONID)
- 클라이언트는 재접속 시, 이 JSESSIONID를 이용하여 Session-ID값을 서버에 전달한다.
사용 사례
- 로그인 상태 유지
Cookie와 Session의 차이점
- 저장 위치
- 쿠키 : 클라이언트(브라우저) 메모리 or 파일
- 세션 : 서버 메모리에 저장 - 보안
- 쿠키 : 클라이언트의 로컬(local)에 저장되기도 하고, 특히 파일로 저장되는 경우 탈취, 변조될 위험이 있고 Request/Response 과정에서 스나이핑 당할 위험이 있어 보안이 비교적 취약
- 세션 : 클라이언트의 정보가 서버에 저장되어 있어 비교적 안전 - 라이프 사이클
- 쿠키 : 브라우저를 종료하더라도 쿠키를 삭제하거나 만료되지 않는 이상 계속 사용 가능
- 세션 : 브라우저를 통해 웹 서버에 접속한 시점부터 웹 서버를 종료하여 연결을 끝낸 시점 - 속도
- 쿠키 : 쿠키에 정보가 있기 때문에 서버에 요청 시 헤더를 바로 참조하면 되어 속도면에서 유리
- 세션 : 제공받은 세션 아이디 (key)를 이용해서 서버에서 다시 데이터를 참조해야하므로 속도면에서 불리
📌 쿠키와 세션을 적절히 사용해야 하는 이유
- 세션은 서버에 데이터를 저장하므로 서버의 자원을 사용하기 때문에 서버 자원에 한계가 있다. 때문에 보안이 중요한 회원 정보 같은 것을 저장할 땐 세션에, 비교적 보안에 민감하지 않거나 삭제되어도 무관한 정보 같은 것들을 쿠키에 담아 적절히 배분해서 사용한다.
서버가 여러 대라면?
- 보통 회사에서는 하나의 서버만 운영하지 않는다.
- 이 때, A라는 서버와 B라는 서버가 있다고 가정해보자.
- 클라이언트 C는 A서버에서 sessionID를 받고 A서버에 정보가 저장이 되어있다.
- 클라이언트가 요청을 할 때, 항상 A 서버에서만 응답하는 것이 아니다.
- 한 서버에만 여러 사용자가 몰릴 경우에 비효율적이며 서버가 터질 수 있기 때문에 로드 밸런서라는 라운드 로빈이라는 알고리즘을 가지고 요청을 분배 시켜주는 존재가 있다. (A,B,A,B.. 돌아가면서 배분해준다.)
- 이 때, 클라이언트 C가 B서버에 가게되면?
- 인증할 수 없는 상태가 되어버린다. 이를 서버가 상태를 가지고 있다고 한다.
- A, B, C 이런 식으로 병렬 구조를 가진 것을 수평적 확장이라고 하는데 이러한 문제 때문에 수평적 확장이 쉽지 않다.
- 이를 해결하기 위하여 정보를 서버에 저장하는 것이 아니라 인-메모리 방식 DB(ex.redis) 같은 캐시를 사용해서 가져오도록 한다. (사용자가 굉장히 많은 경우에도 유리)
Reference!
https://hahahoho5915.tistory.com/32
https://interconnection.tistory.com/74
https://nesoy.github.io/articles/2017-03/Session-Cookie
https://jeong-pro.tistory.com/80
thanks to https://donghyeon.dev/
공부 기록