[네트워크/Network] 세션(Session), 쿠키(Cookie), 캐시(Cache)의 구분

0. 들어가면서

세션, 쿠키, 캐시는 기본적으로 HTTP 프로토콜의 특징을 이해해야 왜 필요한지 이해할 수 있는 개념이라고 생각합니다. 그리고 그 중에서도 이 개념들과 관련이 깊은 HTTP의 비상태(stateless) 프로토콜이란 무엇인지에 대해 짚어보려고 하는데요.

 

참고로, HTTP의 비상태성은 HTTP의 지속 연결과는 구분되는 개념입니다.

 

HTTP의 지속 연결은 서버가 응답을 보낸 후에 TCP 연결을 그대로 유지하는 특징을 말하는데, 이는 클라이언트와 서버가 하나의 지속 TCP 연결을 통해 데이터를 주고받고, 일정 시간(Timeout)동안 사용되지 않으면 연결을 닫는 것을 말합니다. HTTP 헤더의 Keep-alive가 이를 말해주고 있죠.

 

 

---

1. HTTP, 비상태 프로토콜(Stateless Protocol)

HTTP는 TCP를 전송 프로토콜로 사용합니다. HTTP 클라이언트는 서버에 TCP 연결을 시작하고, 연결이 이루어지면 브라우저와 서버 프로세스는 소켓 인터페이스를 통해 TCP로 접속합니다.

 

클라이언트는 HTTP 요청 메시지를 소켓 인터페이스로 보내고 소켓 인터페이스로부터 HTTP 응답 메시지를 받습니다. 마찬가지로 HTTP 서버는 소켓 인터페이스로부터 요청 메시지를 받고 응답 메시지를 소켓 인터페이스로 보냅니다.

 

다시 말해, 클라이언트가 메시지를 소켓 인터페이스로 보내면 해당 메시지는 이미 클라이언트의 손을 떠나 TCP의 손에 쥐어지게 되는 것입니다. 그리고 TCP는 HTTP에게 신뢰적인 데이터 전송 서비스를 제공하기 때문에 클라이언트 프로세스가 발생시킨 모든 HTTP 요청 메시지는 궁극적으로 서버에 잘 도착하게 되고, 마찬가지로 서버 프로세스가 발생시킨 각 HTTP 응답 메시지도 클라이언트에 잘 도착하게 되는 것이죠. 

 

한편, 이러한 소켓 인터페이스를 통한 통신을 들여다보면, 서버가 클라이언트에게 요청 파일을 보낼 때 서버는 클라이언트에 관한 어떤 상태 정보도 저장하지 않습니다. 만약 클라이언트가 몇 초 후에 같은 객체를 두 번 요청하면, 직전에 그 객체를 보냈다고 서버가 알려주면 좋겠지만 서버는 이전에 한 일을 기억하지 않으므로 그 객체를 또 보내게 됩니다.

 

HTTP: Stateless Protocol

 

따라서 HTTP 서버는 클라이언트에 대한 정보를 유지하지 않는다는 점에서 HTTP를 비상태 프로토콜(stateless protocol)이라고 합니다.

 

아래에서 살펴 볼 쿠키(Cookie)의 필요성은 바로 여기에서 시작합니다.

 

서버가 클라이언트에 대한 정보를 저장하고 있으면 어떨까? 하는 고민이죠.

 

 

2. 쿠키(Cookie)

개발을 하다보면 유저의 접속을 제한하거나 유저에 따라 컨텐츠 접근에 제한을 두길 원할 때가 있습니다. 서버는 이를 위해서 필연적으로 유저의 정보를 기억해야 하는데요. 이는 HTTP의 비상태성과 모순되는 개념이기 때문에 HTTP는 '쿠키'라는 기술을 통해 이 목적을 달성하려고 합니다.

 

아래 그림처럼 쿠키 기술은 네 가지 요소, (1) HTTP 응답 메시지 쿠키 헤더 라인, (2) HTTP 요청 메시지 쿠키 헤더 라인, (3) 사용자 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일, (4) 웹 사이트의 백엔드 데이터베이스를 가지고 있습니다.

 

쿠키

만약 제가 이전에 구글을 방문한 기록이 있고, 오늘 네이버를 처음 방문했다고 해보겠습니다. 그러면 아래와 같은 로직에 따라 쿠키가 생성되고 사용됩니다.

 

1) 최초에 네이버 웹 서버에 요청이 들어올 때 네이버 서버는 유일한 식별번호를 만들고 이 식별번호로 인덱스되는 백엔드 DB 안에 엔트리를 만들게 됩니다.

 

2) 그런 후 네이버 서버는 저의 브라우저에 응답을 할 때 이 HTTP 응답 식별번호를 담고 있는 Set-cookie: 헤더를 포함시켜 응답합니다.

 

3) 제 브라우저가 HTTP 응답 메시지를 받았을 때 그 Set-cookie: 헤더를 볼 수 있는데요. 그 다음 브라우저는 자신이 관리하는 특정한 쿠키 파일에 그 라인을 덧붙이게 됩니다.

 

4) 이 라인은 서버의 호스트 네임과 Set-cookie: 헤더와 식별번호를 가지고 있기 때문에 이후에 제가 네이버에 접속을 하게 되면 저의 브라우저는 쿠키 파일을 참조해서 네이버 사이트에 대한 저의 식별 번호를 발췌하고, HTTP 요청에 식별 번호를 포함하는 쿠키 헤더 파일을 넣어서 보내게 됩니다.

 

5) 그러면 네이버 서버는 식별번호를 통해 저를 식별할 수 있게 되고, 저의 활동 기록들을 추적할 수 있게 되는 것입니다.

 

 

 

3. 세션(Session)

세션은 쿠키를 기반으로 하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리를 합니다.

 

서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며, 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지합니다. 물론 우리가 웹 서버에 로그인을 해두고 외출을 하고 오면 로그아웃이 되는 것처럼, 일정 시간을 설정해서 세션을 날릴 수도 있죠.

 

세션의 동작 원리를 설명하자면 아래와 같이 정리할 수 있습니다.

 

1) 클라이언트가 서버에 접속할 때 세션 ID를 발급합니다.

 

2) 클라이언트는 세션 ID에 대해 쿠키를 사용해서 저장하고 있습니다.

 

3) 클라이언트가 서버에 요청을 할 때 쿠키의 세션 ID를 같이 서버에 전달해서 요청합니다.

 

4) 서버는 세션 ID를 받아서 세션에 존재하는 클라이언트의 정보를 가져와서 사용합니다.

 

앞서 말했듯, 세션은 쿠키와 비슷한 방식으로 동작하지만 쿠키는 브라우저에 저장되기 때문에 서버의 자원을 사용하지 않으며, 세션은 서버에 저장되기 때문에 서버의 자원을 사용하는 차이점이 있습니다.

 

그리고 이 차이점으로 인해 세션은 쿠키보다 보안에서 우수하고, 메모리 상으로는 불리한 면을 가지게 되는데요.

 

쿠키는 클라이언트 브라우저에 저장되기 때문에 요청을 보낼 때 스니핑을 당할 수 있어서 보안에 취약하지만 세션은 쿠키를 이용해서 세션 아이디만 저장하고 이를 통해 클라이언트를 식별해서 서버에서 처리를 하기 때문에 보안에서 이점을 가지게 됩니다. 반면, 세션은 서버의 자원을 사용하기 때문에 모든 쿠키를 대신하여 세션을 이용하게 되면 서버에 대한 부하가 커지게 되는 단점을 가지게 되는 것이죠.

 

 

 

4. 웹 캐시(Cache)

웹 캐시에 대한 설명은 이전에 작성한 [네트워크/Network] 웹 캐시(Web Cache; 프록시 서버)를 통한 응답 속도 향상 원리 이해하기 에서 자세히 다뤘기 때문에 간단히만 설명하도록 하겠습니다.

 

웹 캐시는 쉽게 말해 원래 웹 서버를 대신하여 HTTP 통신을 대신하는 네트워크 개체를 말합니다.

 

웹 캐시는 자체적인 저장 디스크를 가지고 있어서 최근에 호출된 객체의 사본을 저장 및 보존하고 있습니다. 그래서 사용자의 HTTP 데이터 요청이 있으면 웹 캐시에서 해당 데이터를 찾아서 있으면 보내주고, 없으면 원래 서버에게 해당 데이터를 요청받아 사용자에게 넘겨주고 자신의 저장소 안에도 저장해두는 것이죠.

 

즉, 캐시는 사용자의 요청을 자신이 대신 처리해줌으로써 원래 서버에 대한 트래픽 강도를 낮추게 하고, 이를 통해 응답 속도를 개선하는 역할을 한다고 이해하면 됩니다.

 

 

---

이번 포스팅에서는 웹 쿠키, 세션, 캐시에 대해 공부했습니다. 

 

정리를 하기 전에는 세 가지 개념이 약간 비슷하면서 헷갈렸었는데, 정리를 하고 보니 분명히 구분되는 지점이 있는 개념들이라는 생각이 듭니다.

 

감사합니다.