[HTTP] HTTP Cache - 프로세스와 기본 헤더

안녕하세요. 오늘 여러분들에게 소개해드릴 내용는 HTTP의 Cache 프로세스와 관련된 기본 헤더들입니다. 웹사이트를 통해 이미지 , js, html 파일 등의 데이터를 가지고 올 때 해당 데이터의 크기만큼의 통신 데이터 처리가 필요합니다. 동일한 이미지를 접속할 때 마다 받아온다면 클라이언트 입장에서도 부담이며 여러 클라이언트를 동시에 상대하는 서버에는 더더욱 부담이 될 것입니다. 이렇게 때문에 HTTP에서는 캐싱(caching)를 지원하고 있습니다.

오늘은 HTTP Cache의 종류와 그 과정에 대해서 알아보는 시간을 가져보도록 하겠습니다.

HTTP 캐싱

캐싱은 크게 두가지의 종류가 있습니다. 사설(private) 캐시와 공유(shared) 캐시입니다. 사설 캐시는 각 Client의 로컬 캐시에 데이터를 저장하는 것으로 브라우저 캐시를 주로 이용합니다. 그리고 또 다른 한가지는 공유 캐시입니다. 공유 캐시는 바르우저와 서버 사이에 있는 캐시로 리버스 프록스, 게이트웨이, CDN 등등에 저장되는 캐시입니다.

사설 브라우저 캐시(private cache)

사설 캐시는 개인 전용으로 사용하는 캐시입니다. 브라우저 캐시라고도 불리며 windows의 IE를 사용하신다면 C:\Users\사용자명\AppData\Local\Microsoft\Windows\INetCache에 저장이 될 것이며 chrome을 사용하신다면 C:\Users\사용자명\AppData\Local\Google\Chrome\User Data\Default\Cache에 저장될것입니다. 이렇게 저장된 캐시는 서버에서 추가로 데이터를 받아오지 않고 바로 사용할 수 있게 해줍니다.

공용 프록시 캐시(shared cache)

사설 캐시는 캐싱하기 위해서 모든 Client가 한번씩은 실제 리소스를 접근해야합니다. 10만명이 접속한다면 실제 리소스에 10만번 접근하게 되는 것입니다. 공유 캐시는 서버와 클라이언트 가운데 프록시 등을 통해 캐시를 하는 것입니다. 이렇게 하면 서버에 접근하기 전에 캐시에 먼저 접근하여 확인을 합니다. 10만명이 접속 한다고 하더라도 실제 리소스는 1번만 접근되고 나머지 9만 999번은 캐시에서 처리하여 바로 반환할 수 있게 됩니다.

HTTP 캐시의 기본 동작 프로세스

HTTP 캐시의 기본적인 프로세스에 대해서 알아보도록 하겠습니다. 위 다이어그램은 공용 캐시를 사용할 때 나올 수 있는 flow입니다. 사설 캐시를 사용한다면 서버와 클라이언트가 직접 캐싱에 대해서 확인하기 때문에 조금 다른 플로우를 가질 것입니다.

먼저 요청이 처음 들어왔을 경우입니다. 이때는 캐시가 없을 것입니다.

1. 캐시를 확인합니다.
2. 캐시가 없기때문에 서버에서 가져옵니다.
3. 캐싱에 저장합니다.
4. 응답합니다.

그리고 얼마 지나지 않아 동일한 요청이 들어온다고 해보겠습니다.

1. 캐시를 확인합니다.
2. 캐시를 확인했을때 만료기간이 경과하였는지 확인합니다.
3. 충분히 사용할만할 경우 바로 응답합니다.

이제 캐시 시간이 만료되는 일정 시간이 경과하여 요청이 들어왔다고 해보겠습니다.

1. 캐시를 확인합니다.
2. 캐시가 존재하는 것을 확인하여 만료되었는지 확인합니다.
3. 캐시가 만료되었으므로 서버에 데이터가 만료되었는지 조건부 헤더를 통해 재검사를 시작합니다.
4. 재검사 결과 동일한 리소스로 판단되면 304 응답코드와 헤더만 캐시에게 줍니다.
5. 캐시는 만료 시간을 갱신합니다.
6. 캐시는 클라이언트에게 기존에 캐시된 결과를 반환합니다.

캐시의 시간이 만료되었고 서버에서도 해당 리소스가 업데이트 되었다면 어떻게 될까요?

1. 캐시를 확인합니다.
2. 캐시가 존재하는 것을 확인하여 만료되었는지 확인합니다.
3. 캐시가 만료되었으므로 서버에 데이터가 만료되었는지 조건부 헤더를 통해 재검사를 시작합니다.
4. 재검사 결과 동일하지 않은 리소스로 판단되면 200 응답코드와 바디를 반환합니다.
5. 캐시는 만료 시간을 갱신하며 캐시의 리소스도 반환합니다.
6. 캐시는 클라이언트에게 캐시된 결과를 반환합니다.

캐시 관련 기본 헤더

HTTP 캐싱 프로세스를 확인하며 여러 조건들이 있다는 사실을 확인했습니다. 이런 조건들은 HTTP Header를 통해서 판단합니다. 이번 포스팅에서는 캐싱 공통 헤더인 Expired와 Cache-Control에 대해서 알아보도록 하겠습니다. 이를 두 헤더를 제외하고 ETag, Last-Modified를 이용한 조건부 헤더라는 것이 있습니다. 이 헤더들은 서버에 재검사를 요청할 때 사용하는 헤더들입니다. 이 헤더들은 다음 포스팅에서 좀 더 자세히 다루도록 하겠습니다.

Expired

HTTP/1.0+ 에서는 만료기간을 명시하기 위해서 절대시간을 사용하였습니다. 이때 사용하던 헤더가 바로 Expired 헤더입니다. 아래의 예제를 보시겠습니다. Expired는 GMT (그리니치 표준시)를 기준으로 합니다. 그래서 우리나라 시간 기준으로 하면 9시간 늦다는 것을 유의하셔야합니다.

Expres: Fri, 05 Feb 2021, 05:00:00 GMT

Cache-Control

HTTP/1.1로 넘어오면서 만료기간을 명시하기 위한 새로운 헤더가 추가 되었습니다. 바로 Cache-Control 입니다. Cache-Control은 Cache 조작과 관련된 다양한 일을 진행합니다. 아래 예제를 보도록 하겠습니다. max-age를 이용하여 해당 Http 메시지가 생성된 Date 헤더를 기준으로 상대적인 시간으로 캐시만료를 표시합니다. Expired 같은 경우 절대시간으로 표기하는데 이는 서버간 시간 차이가 생길 수 있고 이는 문제가 될 수 있기때문에 상대시간으로 표시하는 max-age가 1.1에 추가로 나왔다고합니다.

Cache-Control: max-age=3600

이어서 Cache-Control의 또 다른 옵션들을 보도록 하겠습니다. no-store 옵션을 사용하면 캐시는 클라이언트 요청 혹인 서버 응답에 관하여 어떠한 것도 저장하지 않습니다. 항상 서버로 부터 받아오는 옵션입니다.

Cache-Control: no-store

no-cache 옵션을 사용하면 클라이언트의 요청에 대해서 cache를 그대로 사용하지 않습니다. 항상 서버에 재검증을 요청하여 반환된 결과에 대해서 캐시가 응답해줍니다.

Cache-Control: no-cache

사설 캐시로 저장 할 지 아니면 공유 캐시로 저장할지에 대해서도 지정할 수 있습니다. public 옵션을 주시면 클라이언트와 서버사이의 어떠한 캐시로든 캐시되어도 좋다라는 것을 가리킵니다. 반면 private 옵션을 통해 응답하게 되면 개인 사용자만을 위한 것이며 공유 캐시에 의해 저장되어서는 안된다는 것을 가리킵니다.

Cache-Control: private
Cache-Control: public

이러한 캐시 관련 옵션들은 Entity 헤더로써 요청 / 응답에 모두 사용될 수 있습니다.

마무리

오늘은 이러헥 HTTP의 캐싱에대한 구조도와 기본이 되는 프로세스에 대해서 알아보는 시간을 가져보았습니다.

다음 시간에는 조건부 헤더에 대해서 알아보는 시간을 가져보도록 하겠습니다.

감사합니다.

참조

mozilla_Caching

HTTP 완벽 가이드