[네트워크] 애플리케이션 계층(5) - 쿠키와 웹 캐싱

 

서론

[네트워크] 애플리케이션 계층(4) - 웹과 HTTP(비지속, 지속 연결)

이전 게시글에서 웹과 HTTP에 대해서 알아보고, HTTP의 비지속 연결과 지속 연결에 대해 살펴보았습니다.

이번 게시글에서는 사용자와 서버 간의 상호작용인 쿠키와 캐싱에 대해 정리해 보겠습니다.

목차
1. 쿠키
2. 캐싱
3. 조건부 GET

 

쿠키

HTTP 서버는 상태를 유지하지 않는 비 상태 서버입니다. 이것은 서버 설계를 간편하게 하고 동시에 수천 개의 TCP 연결을 다룰 수 있는 고성능의 웹 서버를 개발하도록 해주었습니다. 그러나 서버가 사용자 접속을 제한하거나 사용자에 따라 콘텐츠를 제공하기 원하므로 웹 사이트가 사용자를 확인하는 작업이 필요할 경우가 생깁니다. 이 목적으로 HTTP는 쿠키(coockie)를 사용합니다. 

쿠키를 이용한 사용자 상태 유지

위 이미지처럼 쿠키 기술은 아래의 네 가지 요소를 가지고 있습니다.

1. HTTP 응답 메시지 쿠키 헤더 라인
2. HTTP 요청 메시지 쿠키 헤더 라인
3. 사용자의 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일
4. 웹 사이트의 백엔드 데이터베이스

위 이미지를 참고하여, 예를 통해 쿠키가 어떻게 동작하는지를 알아보도록 합시다.

1. 집에 있는 PC로 인터넷 익스플로러를 이용하여 항상 웹 접속을 하는 제니가 처음으로 아마존 닷컴에 접속했다고 가정합시다.
2. 과거에 제니는 이미 이베이 사이트를 방문한 적이 있다고 가정합니다.
3. 아마존 웹 서버에 요청이 들어올 때 그 서버는 유일한 식별변호를 만들고 이 식별번호로 인덱스 되는 백엔드 데이터베이스 안에 엔트리를 만듭니다.
4. 그리고 난 후 아마존 웹 서버는 제니의 브라우저에 응답하는데, 이 HTTP 응답에 식별번호를 담고 있는 Set - cookie: 헤더가 포함됩니다.
5. 위 이미지에서 헤더 라인은 다음과 같습니다. Set - cookie: 1678
6. 제니의 브라우저가 HTTP 응답 메시지를 받았을 때 그 Set - cookie: 헤더를 볼 수 있습니다.
7. 그다음 브라우저는 관리하는 특정한 쿠키 파일에 그 라인을 덧붙이게 됩니다.
8. 이 라인은 서버의 호스트 네임과 Set - cookie: 헤더와 식별번호를 포함합니다.
9. 제니가 과거에 이베이 사이트를 방문했기 때문에 쿠키 파일은 이베이에 대한 엔트리를 가지고 있습니다.

제니가 계속해서 아마존 사이트를 살펴봄에 따라, 그녀가 웹 페이지를 요청할 때 그녀의 브라우저는 쿠키 파일을 참조하고 이 사이트에 대한 그녀의 식별 번호를 발췌하고, HTTP 요청에 식별번호를 포함하는 쿠키 헤더 파일을 넣습니다. 특히 아마존 서버로의 각 HTTP 요청은 다음과 같은 헤더 라인을 포함합니다.

Cookie: 1678

이러한 방식으로 아마존 서버는 제니의 아마존 사이트에서의 활동을 추적할 수 있습니다. 비록 아마존 웹사이트는 제니의 이름을 알 필요는 없지만 1678 사용자가 어느 페이지를, 어떤 순서로, 몇 시에 방문했는지 정확히 알 수 있습니다.

위 내용으로부터 쿠키는 사용자 식별에 사용할 수 있음을 알 수 있습니다. 사이트에 처음으로 사용자가 방문하면 사용자는 사용자 확인(이름)을 제공합니다. 다음 세션 동안에, 브라우저는 서버에 쿠키 헤더를 전달하여 서버에게 사용자를 확인합니다. 따라서 쿠키는 비 상태 HTTP 위에서 사용자 세션 계층을 생성하는 데 이용될 수 있습니다. 

 

웹 캐싱

웹 캐시[Web cache, 프록시 서버(proxy server)]는 원출처의 웹 서버(origin Web server)를 대신하여 HTTP 요구를 충족시키는 네트워크 개체입니다. 웹 캐시는 자체의 저장 디스크를 갖고 있어 최근 호출된 객체의 사본을 저장 및 보존합니다. 

웹 캐시를 통한 클라이언트의 객체 요청

위 이미지처럼 브라우저는 사용자의 모든 HTTP 요구가 웹 캐시에 가장 먼저 보내지도록 구성될 수 있습니다. 일단 브라우저가 설정되면 객체에 대한 각각의 브라우저 요청은 웹 캐시에 가장 먼저 보내집니다.

예를 들어 http://www.someschool.edu/campus.gif라는 객체를 요구한다고 생각해 봅시다.

1. 브라우저는 웹 캐시와 TCP 연결을 설정하고 웹 캐시에 있는 객체에 대한 HTTP 요청을 보낸다.
2. 웹 캐시는 객체의 사본이 자기에게 저장되어 있는지 확인한다. 만일 저장되어 있다면 웹 캐시는 클라이언트 브라우저로 HTTP 응답 메시지와 함께 객체를 전송한다.
3. 만약 웹 캐시가 객체를 가지고 있지 않다면, 웹 캐시는 원 출처의 서버인 www.someschool.edu로 TCP 연결을 설정한다. 그리고 나서 웹 캐시는 캐시와 서버 간의 TCP 연결로 객체에 대한 HTTP 요청을 보낸다. 이러한 요청을 받은 후에 기점 서버는 웹 캐시로 HTTP 응답 메시지와 함께 객체를 보낸다.
4. 웹 캐시가 객체를 수신할 때, 객체를 지역 저장장치에 복사하고 클라이언트 브라우저에 HTTP 응답 메시지와 함께 객체의 사본을 보낸다.

캐시는 서버이면서 클라이언트이며, 일반적으로 웹 캐시는 ISP가 구입하고 설치합니다.

웹 캐싱의 장점은 아래와 같습니다.

1. 웹 캐시는 클라이언트의 요구에 대한 응답 시간을 줄일 수 있다.
2. 클라이언트가 요청한 객체를 캐시가 가지고 있다면, 캐시는 그 객체를 클라이언트로 매우 빠르게 전달할 수 있다.
3. 웹 캐시는 한 기관에서 인터넷으로 접속하는 링크 상의 웹 트래픽을 대폭으로 줄일 수 있다.

 

조건부 GET

웹 캐싱이 사용자가 느끼는 응답 시간을 줄일 수 있지만, 캐시 내부에 있는 객체의 복사본이 새것이 아닐 수 있다는 문제가 있습니다. 즉, 복사본이 클라이언트에 캐시 된 이후에 웹 서버에 있는 객체가 갱신되었을 수 도 있다는 것입니다. HTTP는 이러한 문제를 해결하는 방법으로 모든 객체들이 최신의 것임을 확인하면서 캐싱하는 방식을 갖고 있습니다. 이러한 방식을 조건부 GET(conditional GET()이라고 합니다.

HTTP 요청 메시지가 아래를 만족한다면 조건부 GET 메시지입니다.

• GET 방식을 사용한다.
• If - Modified - Since: 헤더 라인을 포함한다.

조건부 GET이 어떻게 동작하는지를 설명하기 위해, 한번 예를 들어보겠습니다.

1) 브라우저의 요청을 대신해 프록시 캐시는 요청 메시지를 웹 서버로 보낸다.

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com 

 

2) 웹 서버는 캐시에게 객체를 가진  응답 메시지를 보낸다.

HTTP/1.1 200 OK
Date: Sat, 3 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
Last-Modified: Wed, 9 Sep 2015 09:23:24
Content-Type: image/gif
(data data data data data ...)

 

캐시는 요청하는 브라우저에게 객체를 보내 주고 자신에게도 객체를 저장합니다. 중요한 것은 캐시가 객체와 더불어 마지막으로 수정된 날짜를 함께 저장한다는 것입니다.

3) 일주일 후에 다른 브라우저가 같은 객체를 캐시에게 요청하면 객체는 여전히 저장되어 있습니다. 이 객체는 지난주에 웹 서버에서 수정되었으므로 브라우저는 조건부 GET으로 갱신 조사를 수행합니다. 브라우저는 다음과 같은 내용을 보냅니다.

Host: www.exotiquecuisine.com
If-modified-since: Wed, 9 Sep 2015 09:23:24

If-modified-since: 헤더 라인의 값이 일주일 전에 서버가 보낸 Last-modified: 헤더 라인의 값과 정확히 일치하는 것을 잘 봐야 합니다. 이 조건부 GET은 서버에게 그 객체가 명시된 날짜 이후 수정된 경우에만 그 객체를 보낼 것을 말하고 있습니다. 그 객체가 7 Sep 2011 09:23:24 이후 변경되지 않았다고 가정합시다.

4) 그러면 웹 서버는 클라이언트에게 다음과 같은 응답 메시지를 보냅니다.

HTTP/1.1 304 Not Modified
Date: Sat, 10 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
(빈 개체 몸체)​

조건부 GET에 대한 응답으로 웹 서버가 여전히 응답 메시지를 보내지만 응답 메시지에 요청된 객체를 포함하지 않음을 볼 수 있습니다. 요청 객체를 포함하는 것은 대역폭을 낭비하는 것이고, 특히 그 개체가 크다면 사용자가 느끼는 응답 시간이 증가합니다. 이 마지막 응답 메시지는 304 Not Modified 상태 라인을 갖고 있으며, 이는 클라이언트에게 요청 객체의 캐시 된 복사본을 사용하라는 것을 의미합니다.

 

정리

	캐시(Cache)	쿠키(Cookie)
정의	캐시는 웹 페이지 요소를 저장하기 위한 임시 저장소이다.  특히, 후에 필요할 것 같은 요소들을 저장한다.  이러한 요소들은 그림 파일이나 문서 파일 등이 될 수 있다.	쿠키 또한 정보를 저장하기 위해 사용된다.  기본적으로 웹서버에서 PC로 보내는 작은 파일들을 저장한다.  보통 쿠키는 누군가 특정한 웹 사이트를 접속할 때 발생한다.
목적	캐시는 웹 페이지가 빠르게 렌더링 할 수 있도록 도와준다.	쿠키는 사용자의 인증을 도와준다.
삭제	사용자가 직접 수동으로 삭제해주어야한다.	만료기간이 있어 시간이 지나면 자동삭제 된다.
예시	오디오, 비디오 파일 등이 있다.	유저의 선호도 (로그인 정보, 방문기록, 방문횟수)

- 참고: https://zorba91.tistory.com/163