쿠키(Cookie) vs 세션(Session)

학부시절 인터넷 프로그래밍 과목을 수강하면서 쿠키와 세션에 대해 배웠었다. Web에 대해 공부하다 보니 기본적으로 알아야 할 것 같은데 너무 오래된 것 같아서 한번 다뤄보려고 한다.

 

먼저 쿠키와 세션이 왜 필요한 지부터 알아보자.

​대부분의 인터넷은 HTTP 프로토콜을 통해 통신한다. 그 이유는 HTTP 프로토콜이 비연결지향(Connectionless)적이며 상태가 없는(Stateless) 특징을 가지기 때문이다.

 

​비연결지향(Connectionless)

• 클라이언트가 서버에게 Request를 보내면, 서버는 클라이언트에게 Response를 보내고 접속을 끊음
• HTTP1.1에서는 Keep-Alive 기능을 통해 한 번의 세션에서 여러 번 통신이 가능함

상태가 업음(Stateless)

• 주고받은 데이터에 대한 상태(기록)가 없음 → 독립적인 데이터

 

이러한 특징 덕분에 서버는 세션과 같은 별도의 추가 정보를 관리하지 않아도 되고, 다수의 요청 처리 및 서버의 부하를 줄여 성능을 향상할 수 있기 때문에 HTTP 프로토콜을 사용한다.

​

하지만 매번 통신할 때마다 세션을 열어줘야 하기 때문에 클라이언트는 서버에게 매 요청마다 인증을 해야 한다. 또한, 현재 클라이언트와 이전 클라이언트가 동일한 클라이언트인지 확인할 방법이 없기 때문에 이를 해결하기 위해선 이전 상태를 유지할 수 있어야 한다.

​이러한 문제점을 개선하기 위해 나온 것이 바로 쿠키와 세션이다. 하나씩 살펴보면서 알아보도록 하자.

 

쿠키(Cookie)

 

ㅁ 특징

• 클라이언트 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일
• 이름, 값, 만료 날짜(쿠키 저장 기간), 전송할 경로, 전송할 도메인 등으로 구성
• 서버 측에서 만료 날짜를 지정하여 정해진 기간 동안 데이터를 유지 → 로그인 상태 유지 활용
• 클라이언트의 상태 정보를 로컬에 저장했다가 참조
• 클라이언트에 300개의 쿠키를 저장 가능하며 하나의 도메인당 20개의 값과 각각 4KB까지 저장 가능
• 서버에서 Response Header에 Set-Cookie 속성을 통해 클라이언트에 쿠키를 제공
• 클라이언트가 별도로 요청하지 않아도 브라우저에서 자동으로 Request Header에 쿠키 값을 넣어서 요청

​ㅁ 동작 방식

1. 클라이언트가 웹페이지를 서버에게 요청
2. 서버에서 쿠키를 생성 후 HTTP 헤더에 포함시켜 클라이언트에게 응답
3. 클라이언트는 응답받은 해당 쿠키를 로컬에 저장
4. 이후 클라이언트가 재요청을 할 경우 쿠키를 HTTP 헤더에 포함시켜서 서버에게 요청 → 서버 측에서 쿠키를 통해 이전 클라이언트인지를 확인할 수 있음
5. 상태 정보를 유지하는 쿠키를 활용하여 웹 서비스 제공

​ㅁ 종류

• 영속 쿠키 : 만료 날짜를 입력하면 해당 날짜까지 유지하는 쿠키
• 세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료 시까지만 유지되는 쿠키

 

매번 서버에게 요청을 할 때마다 쿠키를 전달함으로 인해 로그인 같은 상태를 유지해야 하는 서비스를 제공할 수 있게 되었다.

하지만 쿠키는 심각한 보안 문제가 존재한다.

쿠키 값을 임의로 변경할 수 있다. 또한, 쿠키에 보관된 정보를 훔쳐갈 수 있으며 이를 이용해서 악의적인 요청을 지속적으로 서버에 요청할 수 있다.

이러한 보안 문제를 해결하기 위해 나온 방법이 세션이다.

​

​세션(Session)

 

ㅁ 특징

• 일정 시간 동안 같은 브라우저로부터 들어오는 요구를 하나의 상태로 보고 그 상태를 유지하는 기술
• 서버에서 세션 ID를 부여하여 클라이언트를 구분
• 쿠키를 기반으로 한 기술
• 클라이언트의 상태 정보를 서버에 저장했다가 참조

ㅁ 동작 방식

1. 클라이언트가 웹페이지를 서버에게 요청할 경우, 서버는 세션 ID를 클라이언트에게 제공
2. 클라이언트는 제공받은 세션 ID를 쿠키로 저장
3. 이후 클라이언트가 재요청을 할 경우 세션 ID를 HTTP 헤더에 포함시켜서 서버에게 요청
4. 세션 ID에 저장된 쿠키를 활용하여 웹 서비스 제공

​

쿠키에 직접적으로 중요한 정보를 노출하지 않고, 예측 불가능한 임의의 토큰(쿠키)을 클라이언트에게 제공함으로써 다른 사용자가 탈취한다 하여도 쿠키를 해석할 수 없도록 해주는 것이다.

또한, 토큰의 만료시간을 짧게 유지함으로써 위험에 노출되었다고 하더라도 어느 정도 위험을 방지할 수 있다.

​

세션도 쿠키를 기반으로 한 기술이기 때문에 둘이 어느 정도 비슷해 보이지만 차이점이 존재한다.

​먼저 클라이언트의 상태 정보를 저장하는 공간이다. 쿠키는 로컬에서 저장하는 반면, 세션은 서버에서 저장한다. 따라서 보안상으로는 서버에서 저장하는 세션이 로컬에서 저장하는 쿠키보다 안전하지만 속도 면에서는 세션은 서버에서 추가적인 작업이 필요하기 때문에 비교적 느리다.

​또한 라이프 사이클이 다르다. 쿠키는 만료 날짜가 존재하지만 파일 형태로 로컬에 저장되기 때문에 브라우저를 종료하여도 정보가 남아있을 수 있다. 반면 세션은 브라우저가 종료되면 만료시간에 상관없이 정보가 삭제된다.

​

그렇다면 세션을 주로 사용하면 좋은데 왜 굳이 쿠키를 사용하는 것일까? 세션은 클라이언트의 상태 정보를 서버에 저장하기 때문이다.

많은 클라이언트의 상태 정보를 서버에 저장한다면 결국 서버 자원의 한계를 넘어가기 때문에 메모리 문제도 생기며 성능이 저하될 수 있기 때문이다. 물론 메모리가 아닌 데이터베이스에 저장할 수 있지만 이 방법은 상당히 복잡한 기술이다.

​

마지막으로 쿠키, 세션과 캐시는 전혀 다른 개념이다. 캐시는 이미지, css, js 파일 등이 클라이언트의 브라우저에 저장이 되는 것이다. 이를 이용해 같은 자원을 로드할 때, 해당 자원을 다시 불러오지 않고 캐시 되어 있는 자원을 써서 클라이언트의 자원을 아끼는 것이다.

​

 

​[ Reference ]

· https://jeong-pro.tistory.com/80