[HTTP] HTTP 헤더 - 캐시와 조건부 요청

캐시 기본 동작

같은 리소스를 두 번 요청하면 데이터가 변경되지 않아도 계속 네트워크를 통해 데이터를 다운받아야한다.

인터넷 네트워크는 느리고 비싸기 때문에 비효율적이다.

 

데이터는 프록시 서버와 브라우저 내에 캐시 될 수 있다.

정해둔 기한 내에 같은 리소스를 요청하면 캐시된 데이터를 사용하게 된다.

 

네트워크를 사용하지 않아도 되어 로딩속도가 빨라진다.

 

---

검증 헤더와 조건부 요청

캐시의 유효 시간을 초과하면 서버에 다시 요청을 해야 한다.

이 때 서버의 데이터가 변경되었을 수도, 그대로일 수도 있다.

 

캐시와 서버의 데이터가 같다는 사실을 확인한다면 (서버의 데이터가 변경되지 않았다면) 데이터를 다시 보낼 필요가 없다.

어떻게 확인할 수 있을까?

 

데이터가 마지막으로 수정된 일시를 저장하는 Last-Modified 헤더를 추가한다.

 

개발자도구에서 확인한 last-modified

 

캐시의 last-modified와 서버의 last-modified가 같다면 데이터가 변경되지 않았다는 뜻이다.

이 경우 body가 없는 304 Not Modified를 보낸다. 용량이 작아지기 때문에 네트워크를 최소한으로 사용할 수 있다.

 

캐시 데이터와 서버 데이터가 같은지 검증하는 데이터로는 Last-Modified와 ETag가 있다.

이를 활용해 조건부로 요청하는 헤더는 If-Modified-Since(LastModified사용), If-None-Match(ETag사용) 이 있다.

조건을 만족하면 200 OK, 불만족하면 304 Not Modified를 반환한다.

 

Last-Modified는 1초 미만의 단위로 캐시 조정이 불가능하고, 데이터를 수정했다가 되돌리는 등 데이터는 그대로인데 수정한 날짜가 다른 경우 리소스를 다시 다운해야한다.

 

ETag (Entity Tag)를 사용하면 위의 단점을 해결할 수 있다.

데이터의 해시를 생성해서 테그를 달아두는 것이다. 데이터가 변경되어야만 Hash가 달라지기 때문에 불필요한 데이터 다운이 없어진다. 또한 캐시 제어 로직을 완전히 서버에서 관리하게 되어 더 좋은 패턴이다.

 

---

캐시와 조건부 요청 헤더

• Cache-Control: 캐시 제어

• Pragma: 캐시 제어(하위 호환, 예전 버전에서 사용)

• Expires: 캐시 유효 기간(하위 호환, 예전 버전에서 사용)

 

• Cache-Control: max-age

    캐시 유효 시간, 초 단위

• Cache-Control: no-cache

    데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용

• Cache-Control: no-store

    데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)

 

• Pragma: no-cache 

    캐시하지 않음, 하위호환

 

• expires: Mon, 01 Jan 1990 00:00:00 GMT

    캐시 만료일을 날짜로 지정, 하위호환, max-age 권장

 

---

프록시 캐시

프록시 캐시 서버는 로컬 ISP등에서 설치하여 자주 요청되는 정보를 캐시한다.

클라이언트 주변에 위치하기 때문에 원 서버에서 데이터를 받아오는 것보다 빨리 서비스할 수 있다.

 

• Cache-Control: public 

    응답이 public 캐시에 저장되어도 됨

• Cache-Control: private

    응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)

• Cache-Control: s-maxage 

    프록시 캐시에만 적용되는 max-age

• Age: 60 (HTTP 헤더) 

    오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

 

---

캐시 무효화

때에 따라 캐시되면 안 되는 정보들이 있다.

 

• Cache-Control: no-cache 

    데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용(이름에 주의!)

• Cache-Control: no-store

    데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)

• Cache-Control: must-revalidate

    캐시 만료후 최초 조회시 원 서버에 검증해야함

    원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)

    must-revalidate는 캐시 유효 시간이라면 캐시를 사용함

• Pragma: no-cache

    HTTP 1.0 하위 호환

 

no-cache vs must-revalidate

no-cache는 원 서버에 접근할 수 없는 경우 설정에 따라 프록시의 캐시 데이터를 반환함

must-revalidate는 원 서버에 접근할 수 없는 경우 504 Gateway Timeout 반환