[HTTP 이해하기] Cache(캐시)

많은 서비스들에서는 js, 이미지 등 정적 파일에 대해 browser cache를 이용하도록 설정합니다. 특히 이미지를 많이 보여주는 서비스들에서는 browser cache 사용이 필수 입니다. browser cache를 사용함으로써 트래픽을 많이 줄일 수 있기 때문입니다. 

하기와 같이 chrome 개발자도구의 network tab에서 어떤 파일들이 browser cache에서 가져오는지 볼수 있습니다.

교보문고 홈페이지

• 처음으로 "교보문고" 홈페이지에 들어가면 browser cache에 저장된 내용이 없기 때문에 모두 서버에서 다운받습니다.
• 브라우저는 정적파일들을 cache에 저장합니다.
• "교보문고" 홈페이지를 refresh하면 정적파일들은 cache에서 읽어옵니다.
• 사진에서 보면 메모리 캐시, 디스크 캐시가 있습니다.
  • https://ourtechroom.com/tech/chrome-memory-cache-vs-disk-cache/#:~:text=the%20following%20points.-,1%20Location,resources%20directly%20from%20the%20disk. 
  • 메모리 캐시: 메모리에 저장하는 cache입니다. 읽어오는 속도가 빠르다는 장점이 있지만 대신 저장할 수 있는 용량이 한정적이고 브라우저를 종료하면 없어집니다.
  • 디스크 캐시: 하드웨어에 파일로 저장하는 cache입니다. 메모리 캐시보다는 느리지만 서버에 요청해서 다운받는것보다는 훨씬 빠릅니다. 브라우저를 종료해도 남아있습니다.
  • chome에서 어떤 기준으로 메모리 캐시, 디스크 캐시를 나눠서 저장하는지는 자료를 찾지 못했습니다.

따로 response 헤더에서 따로 명시하지 않으면 현대 브라우저들은 정적파일을 모두 캐시에 저장해서 운영합니다.

Cache 관련 헤더

서비스에서는 하기 response 헤더들로 cache 사용 여부, cache 유효기간 등을 조절할 수 있습니다. 

"교보문고" 홈페이지의 임이의 js 파일을 보면 ETap와 Last-Modified 헤더가 있음을 볼수 있습니다.

1. ETag

ETag는 string이고 cache 검증이나 content의 유효여부 검증에 많이 사용합니다. 보통 해당 content의 hash code로 설정한다. 위의 이미지처럼 서버에서 응답 헤더에 ETag를 추가합니다.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag

ETag - HTTP | MDN

1.1 mid-air collisions 문제

If-Match 요청헤더와 ETag 헤더로 mid-air collisions 문제를 해결할 수 있습니다..

예를 들어 A, B 두 사람이 동시에 동일한 wiki page를 수정하고 A가 먼저 수정완료하여 post했다고 가정합니다.

A, B 두사람이 처음으로 해당 wiki page를 edit할 때 동일한 내용임으로 서버에서는 해당 content에 대해 똑같은 ETag를 헤더에 추가해서 보냅니다.. 해당 Etag를 "AB Start" 로 가정하자.

A가 먼저 수정하고 If-Match 헤더에 "AB Start" 값을 담아서 Post 한다. 서버에서는 자기가 가지고 있는 ETag값과 비교하니 동일함으로 문제없다고 생각하고 content를 update하고 "A Change"라는 새로운 ETag 값을 생성합니다. 

이후 B도 수정완료한 내용을 Post 합니다. 이때 If-Match에는 "AB Start"값을 담아서 보냅니다. 서버에서는 자기가 가지고 있는 ETag값과 다른 값임으로 412 error를 return 합니다.

1.2 Cache 유효여부

If-None-Match 요청헤더로 cache 유효여부를 검증할 수 있습니다.

사용자가 사이트를 재방문했을 때 브라우저는 If-None-Match에 ETag값을 담아서 서버에 요청을 합니다). 서버는 자기가 가지고 있는 ETag와 비교하고 동일하면 304 코드를 반환하고 다르면 새로운 콘텐츠와 ETag를 담아서 반환합니다.

2. Last-Modified

서버에서 해당 콘텐츠가 수정된 마지막 시간을 기록하고 요청이 오면 Last-Modified 헤더에 추가해서 반환합니다. 위의 교보문고 이미지를 보면 Last-Modified 헤더를 볼수 았습니다..

If-Modified-Since 요청 헤더와 함께 사용하게 됩니다. 

사용자가 해당 페이지를 재방문 할때 If-Modified-Since 요청헤더에 Last Modified 값을 담아서 서버에 보냅니다. 서버에서는 자기가 저장하고 있는 Last Modified 값과 비교하고 동일하면 304 코드를 반환하고 다르면 새로운 콘텐츠와 Last Modified 헤더를 반환합니다.

3. Expires

Expires는 절대 유효기간을 명시합니다. 그 기간을 경과했다면 브라우저는 더 이상 신선하지 않다고 판단하고 재요청 한다. HTTP / 1.0 에서 사용하던 헤더로 HTTP/1.1에서는 사용하지 않는다. 그러나 아직도 많은 서비스에서 해당 헤더를 사용하고 있습니다.

Expires: Wed, 25 Jul 2018 21:00:00 GMT

4. Cache-Control

• max-age: HTTP/1.1에서는 max-age 값은 문서의 최대 나이를 정의합니다. 문서가 처음 생성된 이후부터 제공하기엔 더 이상 신선하지 않다고 간주될 때까지 경과한 시간의 합법적인 최댓값(초 단위)입니다. Cache-Control은 사용자 브라우저에서 사용하는것이 아니라 CDN, cache를 위한 proxy 등에서 사용한다.

Cache-Control: max-age=484200

• public: 모든 곳에서 cache 할수 있다는 값입니다(CDN, cache proxy, 브라우저 등).
• private: 브라우저에서만 cache 할수 있다는 값입니다.
• no-cache: cache를 사용하지 말라는 뜻이 아닙니다. cache를 사용하기전에 유효여부를 서버에 확인을 해야 한다는 값입니다. 해당 값으로 설정되어도 브라우저는 콘텐츠를 cache에 저장할 수 있습니다. 단지 매번 cache에서 꺼내기 전에 서버에 유효여부를 확인하고 문제 없다는 응답을 받으면 사용합니다. ETag와 함께 많이 사용합니다.
• no-store: 브라우저는 cache를 사용하지 말고 항상 서버에 요청해라는 값입니다.
• must-revalidate: 브라우저는 성능때문에 cache가 유효기간이 지나도 그냥 사용할 수도 있습니다. 해당 값을 설정하면 브라우저는 유효기간이 지난 cache는 절대 상요할수 없습니다.

참고:

https://medium.com/@codebyamir/a-web-developers-guide-to-browser-caching-cc41f3b73e7c

A Web Developer’s Guide to Browser Caching

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788966261208 

HTTP 완벽 가이드 - 교보문고