Dev/Network, Web

[Network] Cookie, Session 쿠키와 세션

헝그리둘기 2022. 11. 8. 14:05

쿠키

Http통신은 연결을 요청하고 끝나면 바로 끊어버리는 비연결성, 무상태성이라는 특징을 가지고있기 때문에 서버에 요청을 보낼 때마다 매번 파라미터에 동일한 데이터를 담아 요청해야 한다. 이런 비효율적인 리소스 낭비를 막기 위해 쿠키라는것이 존재한다.

최초로 클라이언트가 서버에 무언가를 요청하면, 서버는 응답 헤더에 쿠키라는것을 담아 클라이언트에게 전달한다. 클라이언트는 브라우저에 이 쿠키를 계속 저장해두고, 동일한 서버로 요청을 보낼 때마다 요청 헤더에 자신이 저장해둔 쿠키를 담아 함께 전달한다. 쿠키에 담기는 데이터는 key-value 형태의 텍스트로 저장되고, 쿠키의 만료시간과 목적지 서버 정보 등이 포함된다.

브라우저에 쿠키를 보관해 놓은 덕분에 우리가 해당 페이지에서 이탈하거나, 브라우저를 닫았다 열어도 로그인 정보 등이 유지될 수 있다는 장점이 있다. 하지만 브라우저에 보관되는 데이터이기 때문에 털리거나 조작될 가능성이 있어 신뢰성이 떨어진다는 단점도 존재한다. 때문에 쿠키에는 중요한 정보가 아닌 데이터만 저장하는게 좋다. 현재 브라우저에 저장된 쿠키는 개발자도구(F12)-애플리케이션 탭에서 확인할 수 있다.

 

세션

최초로 클라이언트가 서버에 요청하면, 서버는 메모리에 세션이라는 일종의 저장소를 만들어두고 각 클라이언트에게 할당할 고유한 세션ID라는것을 생성한 후 이것을 세션 쿠키에 담아 클라이언트에게 전달한다.

이후의 요청부터는 클라이언트가 자신의 세션ID를 담은 쿠키를 서버에 전달하게 되고, 서버에서는 그 세션ID에 해당하는 사용자의 정보를 확인해 알맞은 응답을 내려준다. 클라이언트가 브라우저를 닫으면 세션 쿠키(일반적인 지속쿠키와 달리 브라우저 메모리에 저장된 쿠키)가 소멸되어 세션 연결이 끊기고, 서버가 특정 세션의 정보를 제거해 세션 연결을 끊을 수 있으므로 보안상 이점이 있다. 하지만 서버에서 세션을 저장해놓고 관리하다보니 클라이언트가 급증하게되면 서버 리소스에도 부하가 생길 수 있다는 단점이 있다.

 

아래는 쿠키와 세션의 차이에 대한 이해를 돕기 위한 예시

구매자가(클라이언트) 신발을 주문하면(http요청) 판매자는(서버) 신발 택에 시리얼넘버(세션id)를 적어 택배박스(쿠키)에 담아 구매자(클라이언트)에게 전달한다.

구매자는(클라이언트) 택배박스(쿠키)를 받아 집(브라우저)에 보관하고 있다가, 환불을 할 때(http요청) 시리얼넘버(세션id) 택이 달린 신발과 환불요청서(기타 정보)를 택배박스(쿠키)에 담아 판매자에게(서버) 보낸다.

구매자가 집에서 신발이나 택을 내다 버리거나(브라우저 닫기), 판매자가 데이터베이스에서 해당 시리얼넘버 정보를 삭제(세션ID 제거)하면 추후에 구매자가 환불요청을 해도 시리얼넘버를 확인할 수 없어 환불이 어렵다.