HTTP 통신에서 캐시

https://web.dev/http-cache/

https://pjh3749.tistory.com/264

https://toss.tech/article/smart-web-service-cache

캐시와 사설 브라우저 캐시

HTTP 통신에서 리소스등을 재사용하기 위해 캐시를 사용한다. 캐시는 사설 브라우저 캐시와 공유 프록시 캐시로 나뉠 수 있는데, 지금 얘기를 하는 것은 사설 브라우저 캐시이다. (내가 이해하기 쉽기도 하다.) 사설 브라우저 캐시란, 서버에 대한 추가적인 요청 없이 방문했던 문서들을 브라우저 수준에서 제어하는 캐시이다. 공유 프록시 캐시는 일반적으로 ISP 회사에서 제공하거나, CDN 등이 공통된 네트워크 망에서 요청을 효율적으로 처리하기 위해 별도로 캐시하는 것을 이야기한다.

캐시의 위치 (사설 브라우저 캐시, 공유 프록시 캐시)

일반적으로 캐싱 동작의 대상은 다음의 HTTP STATUS에 해당한다.
* (ok)200, (relocation)301, (not found)404, 206...

캐시의 동작 원리와 Resquest Header와 Response Header

브라우저에서 일어나는 모든 HTTP 요청은 먼저 브라우저 캐시를 검사한다. 그리고 해당 요청을 만족시킬 수 있는 유효한 캐시 응답을 찾는다. 만약 만족되는 게 있으면 네트워크 응답 시간과 응답에 따른 데이터 비용을 줄일 수 있다. 

HTTP 캐시는 Request Header와 Response Header 두 개를 활용해서 전략을 수립할 수 있다. 이상적인 시나리오로는 웹 어플리케이션에서 Request Header를 조정하고, 웹 서버에서 Response Header를 조정한다.

Request Headers : stick with the defaults (usually)

브라우저에서 가는 요청 중에 자동으로 설정되는 헤더가 있다. If-None-Match와 If-Modified-Since 등이 있는데, 이는 요청 헤더에 자동으로 붙게 된다. '<img src="my-image.png">' 등의 태그에 브라우저는 자동으로 HTTP Caching을 통해 가져온다는 것이다. 

단, 커스텀하게 HTTP Cache를 제어하거나,직접 fetch API 등을 이용할 때는 조금 다를 수 있다. (...off topic)

Response Headers: configure your webserver

HTTP caching 설정 중 가장 많은 부분을 차지 하는 것은 웹 서버에서 응답으로 나가는 헤더를 설정하는 것이다. 대표적으로 Cache-Control, ETag, Last-Modified 가 있다.

어떤 웹서버들은 어떤 헤더들에 대해 기본적으로 제공해주기 때문에, 직접적으로 캐시를 설정하지 않아도 된다. 다만, 웹 서비스의 성격에 따라 어떻게 헤더를 정의하고 사용하는 것은 굉장히 다양하게 달라진다. 그렇기에 더 정확하고 디테일하게 사용하기 위해 문서를 잘 참조하는게 중요하다.

express https://expressjs.com/en/api.html#express.static  

nginx http://nginx.org/en/docs/http/ngx_http_headers_module.html 

Cache-Control 헤더

캐시 컨트롤 헤더는 HTTP 캐시 전략을 가장 시작하기 좋습니다. 

Cache-Control
no-store : 캐시를 저장하지 말라는 것이다. 예를 들어, 은행 데이터의 private한 개인 정보를 포함한다면, 이 요청은 로컬에서 재활용하면 안되고 매번 서버로 보내지고 전체 응답을 다운로드 하고 사용되야 할 것 이다. 
no-cache : 실제로는 캐시를 쓰는 것이다. 다만, 캐시를 사용하기 "전"에 서버에게 항상 내가 저장하고 있는 버전이 맞는지 검사하는 단계가 중간에 들어간다. 
private : 브라우저는 파일을 캐시할 수 있으나, 중간 CDN 등의 캐시 처리장치는 해당 데이터를 저장하지 못하는 것이다.
public : 공유된 중간 개체들이 해당 데이터를 캐시할 수 있다.
max-age : 특정 시간대 동안 해당 데이터를 캐시함을 뜻한다. 만약 31536000 으로 설정한다면 1년간 해당 데이터를 재요청 없이 저장된 데이터를 쓴다.

1년간 같은 데이터를 쓰는데에 JS, CSS 파일이 가장 잘 활용된다. 웹 프론트엔드 서비스를 배포할 때마다, CSS, JS는 임의의 버전 번호를 붙여서 번들링 되어 나오는데, 해당 컨텐츠 내용이 바뀌지 않는 이상 파일 버전 이름이 바뀌진 않는다. 그래서 내용이 바뀌지 않는 경우엔 해당 버전의 캐시된 내용을 활용한다. 새로 배포가 된 경우 서버로 요청을 하고, 파일을 받아오게 된다.

고유 버전 번호가 붙어 있는 javascript 파일

max-age=0와 no-cache, no-store의 차이

no-cache는 캐시된 파일을 사용하기 전에 검증 체크를 한다. max-age=0은 no-cache와 같으나, 브라우저마다 그리고 공유 프록시 캐시이냐에 따라 디테일한 동작은 조금 다르다. 일반적으로 max-age=0 = no-cache 이다.
가장 다른 것은 no-store 이며 절대 캐시 하지 않음으로 반드시 새로 응답을 받기위해 요청한다.

 

Cache-Control의 흐름도

캐시 컨트롤은 콤마-구분자로 여러 옵션을 동시에 설정가능하다. https://web.dev/http-cache/#examples