[🍎CS] 쿠키와 세션

HTTP의 특징과 쿠키,세션을 사용하는 이유

쿠키와 세션을 사용하는 이유는 뭘까?
그것은 바로 HTTP 프로토콜의 특성이자 약점을 보완하기 위해서 라고 말할 수 있다.
기본적으로 HTTP 프로토콜 환경은 conntectionless, stateless한 특성을 가지기 때문에 서버는 클라이언트가 누구인지 매번 확인해야 한다. 이러한 특성을 보완하기 위해서 쿠키와 세션을 사용하는 것이다.

• connectionless: 클라이언트가 요청을 한 후 서버로부터 응답을 받으면 그 연결을 끊어버리는 특성

• stateless: 연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성

쿠키와 세션은 위의 두 가지 특징을 해결하기 위해 사용한다. 예를 들어, 네이버에 로그인한 뒤 메일쓰기 페이지로 이동했더니 다시 로그인하라고 한다면? 그 다음에 이번엔 블로그를 들어갔더니 또 로그인하라고 한다면? 🤬😤

쿠키와 세션은 한 번 로그인하고 나면 어떠한 방식에 의해 그 사용자에 대한 인증을 유지하게 된다. 지금부터 쿠키와 세션에 대해 좀 더 자세히 알아보자.

쿠키

클라이언트(브라우저) 로컬에 저장되는 키와 값 형식으로 저장되는 작은 데이터 파일

쿠키는 클라이언트의 상태 정보를 사용자의 컴퓨터에 저장했다가 참조한다. 각 사용자마다의 브라우저에 정보를 저장하니 고유 정보 식별이 가능한 것이다. 쿠키는 사용자 인증이 유효한 시간을 명시할 수 있으며, 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지된다는 특징이 있다.
클라이언트에는 300개까지 쿠키를 저장할 수 있고, 하나의 도메인당 20개, 하나의 쿠키값은 4KB까지 저장 가능하다.

쿠키 동작 방식

1) 브라우저가 서버에 요청을 보낸다
2) 서버는 클라이언트의 요청에 대한 응답을 작성할 때, 클라이언트 측에 저장하고 싶은 정보를 응답 헤더의 set-cookie에 담는다.
3) 이후 해당 클라이언트는 요청을 보낼 때마다, 매번 저장된 쿠키를 요청 헤더의 cookie에 담아 보낸다. 서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트가 누군지 식별하거나 정보를 바탕으로 추천 광고를 띄우기도 한다.

쿠키 방식의 단점

• 가장 큰 단점은 보안에 취약하다는 점이다. 요청 시 쿠키의 값을 그대로 보내기 때문에 유출 및 조작당할 위험이 존재한다
• 쿠키에는 용량 제한이 있어 많은 정보를 담을 수 없다.
• 웹 브라우저마다 쿠키에 대한 지원 형태가 다르기 때문에 브라우저간 공유가 불가능하다.
• 쿠키의 사이즈가 커질수록 네트워크에 부하가 심해진다.

쿠키 사용 예시

✅ 방문했던 사이트에 다시 방문하였을 때 아이디와 비밀번호 자동 입력
✅ 쇼핑몰의 장바구니 기능
✅ 팝업에서 "오늘 더 이상 이창을 보지 않음" 체크

세션

쿠키를 기반으로 하되, 사용자 정보 파일을 부라우저가 아닌 서버 측에 저장

위에서 봤던 쿠키의 보안적인 이슈 때문에, 세션은 비밀번호 등 클라이언트의 민감한 인증 정보를 서버측에 저장하고 관리한다. 서버의 메모리에 저장하기도 하고, 서버의 로컬 파일이나 데이터베이스에 저장하기도 한다.

서버에서는 클라이언트를 구분하기 위해 각 클라이언트별 고유 세션id를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지한다.
접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정할 수도 있다. 사용자에 대한 정보를 서버에 두기 때문에 쿠키보다는 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 된다. 즉, 동시 접속자 수가 많은 웹 사이트인 경우 서버에 과부하를 주게 되므로 성능 저하의 요인이 될 수 있다.

세션의 동작 방식

1) 유저가 웹사이트에 로그인하면 세션이 서버 메모리(혹은 데이터베이스)상에 저장된다. 이 때, 세션을 식별하기 위한 session Id를 기준으로 정보를 저장한다.
2) 서버에서 브라우저의 쿠키에 session Id를 저장한다.
3) 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 request에 session Id를 담아 전송한다.
4) 서버는 클라이언트가 보낸 session Id와 서버 메모리로 관리하고 있는 session Id를 비교하여 수행한다.

세션 방식의 단점

• 쿠키를 포함한 요청이 외부에 노출되더라도 session Id자체는 유의미한 개인정보를 담고 있지는 않는다. 그러나 해커가 세션 Id 자체를 탈취하여 클라이언트인척 위장할 수 있다는 한계가 존재한다.
• 서버에서 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 심해진다.

세션 사용의 예

로그인 같이 보안상 중요한 작업을 할 때 주로 사용한다.

여러모로 세션이 보안이 더 뛰어나보이는데 굳이 쿠키를 사용하는 이유?

세션은 서버에 저장되고, 서버자원을 사용하기 때문에 사용자가 많을 경우 소모되는 자원이 상당하다. 이러한 자원관리 차원에서 쿠키와 세션을 적절한 요소 및 기능에 병행 사용하여, 서버 자원의 낭비를 방지하며 웹사이트의 속도를 높일 수 있다.

쿠키 vs 세션

	쿠키	세션
저장 위치	클라이언트(=접속자PC)	웹서버
저장 형식	text	Object
만료 시점	쿠키 저장시 설정(브라우저가 종료돼도,만료시점이 지나지 않으면 자동삭제되지 않음)	브라우저 종료시 삭제(기간 지정 가능)
사용하는 자원(리소스)	클라이언트 리소스	웹서버 리소스
용량 제한	총 300개/하나의 도메인당 20개/하나의 쿠키당 4KB	서버가 허용하는 한 용량제한 없음
속도	세션보다 빠름	쿠키보다 느림
보안	세션보다 안좋음	쿠키보다 좋음

---

참고 사이트
RyanGomdoriPooh님
99C0RN님
Inpa Dev님