이 글은 인프런의 모든 개발자를 위한 HTTP 웹 기본 지식를 보며 작성했습니다.
캐시가 없다면?
데이터가 변경되지 않아도 네트워크를 통해 데이터를 다시 받아야 한다.
이 네트워크는 매우 느리고 비싸며, 이로 인해 브라우저는 느린 속도로 로딩되며 이는 안 좋은 사용자 경험으로 이어진다.
캐시를 적용하는 이점
캐시가 저장되있는 시간동안 네트워크에서 데이터를 요청하지 않아도 되므로, 네트워크 사용량을 줄이며 이는 빠른 로딩 속도로 이어지므로 빠른 사용자 경험을 제공할 수 있다.
캐시 시간 초과
웹 브라우저 내부에는 캐시를 저장하는 저장소가 있다.
만약 캐시의 유효 시간이 만료되더라도 서버를 통해 데이터를 조회하고 캐시를 갱신한다.
cache-control
저장된 캐시를 다시 사용해도 되는지는 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인해야 지 사용가능하므로 이때는 검증 헤더라는 것을 사용한다.
검증 헤더
캐시 데이터와 서버 데이터가 같은지 검증하는 데이터다
Last-Modified : 데이터의 최종 수정일을 정의하며 클라언트와 서버의 데이터의 해당 해더 값이 같다면 서버는 HTTP Body 없이 메세지를 전송한다.
응답 헤더를 받은 클라이언트는 캐시의 저장된 데이터를 재활용하며 해더 정보로 캐시의 메타 정보를 갱신한다.
네트워크 다운로드 자체는 발생하지만 훨씬 적은 용량의 헤더 정보만을 받으므로 실용적인 방법이다.
조건부 헤더
If-Modified-Since 데이터가 변경 유무에 따라 2가지 상황으로 나뉜다.
- 데이터 미변경
304 Not Modified라는 status와 함께 헤더 데이터만 전송된다 (Body x) - 데이터 변경
200 OK status와 Body를 포함한 모든 데이터가 전송된다.
만약 날짜 기반이 아닌 별도로 캐시 로직을 구현할때는 ETag (Entity Tag) 정보를 사용한다.
이는 캐시용 데이터에 임의의 고유 버전 이름을 달아두고, 데이터가 변경되면 이름을 변경한다.
만약 클라이언트는 ETag가 같으면 기존 데이터를 유지하고 다르면 다시 다운받는다.
캐시 제어 헤더
Cache-Control
캐시를 제어하는 정보로
- max-age : 유효 시간, 초 단위
- no-cache : 데이터는 캐시해도 되나 항상 원래(origin) 서버에서 검증을 받은 다음 사용한다.
- no-store : 민감안 정보를 담은 데이터로 저장 없이 메모리에서 사용만 한다음 최대한 빠르게 삭제한다.
- must-revalidate : 캐시가 만료후 최초 조회시 원래 서버에 검증해야한다.
원래 서버와 단절이 돼서 접근이 불가하면 에러가 난다.
no-cache는 프록시 서버에서 기존 데이터를 200 status와 함께 응답한다. (과거의 데이터 )
위에서 Origin 이라는 원래 서버가 나오는데 이는 중간에 있는 프록시 캐시 서버가 아닌 원래 서버를 의미한다.
만약 미국의 원래 서버와 한국 클라이언트가 통신하려면 많은 시간이 소요된다. 때문에 중간에 프록시 캐시 서버라는 것을 둔다.
이 중간 서버를 거쳐 미국 서버와 통신한다.
유튜브를 예로 들면 사람들이 많이 보는 영상은 빠르게 다운로드되고 볼 수 있는데 이 또한 프록시 중간 서버 덕분이다.
이때 Cache-Control이 public이라면 중간 서버에 캐시가 저장되지만,
private 라는 해당 사용자만을 위한 값이라면 클라이언트에 저장된다.
기본값은 private다.
하위 호환으로 Pragma , Expires등이 존재한다.
Expires는 날짜 단위이다. 현재는 더 유연한 max-age가 일반적으로 사용된다.
