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

캐시

• 브라우저 내부에서 캐시저장
• cache-control 헤더를 조정하여 cache에 대한 설정을 해줄 수 있음 (Pragma, Expires 헤더도 존재하지만 cache-control의 하위호환임)
• 캐시가 존재하더라도 만료될 경우 서버로부터 데이터를 다시 받아야함

---

cache-control

• cf. 클라이언트에서 사용하는 캐시 저장소 이외에도 서버와 데이터 전송을 원활하도록 하기위한 '프록시캐시'도 존재한다.
• cache-control: no-cache : 데이터를 캐시하지만 항상 origin 서버(프록시캐시 서버x)까지 와서 검증을 받고 사용해야함
• cache-control: no-store : 데이터에 민감한 정보가 있으므로 저장하지 않도록함
• cache-control: must-revalidate : 캐시 만료후 최초 조회시 반드시 원서버에서 검증필요 (no-cache는 원서버에 접근할 수 없는 경우 프록시 캐시에서 값을 받아올수도 있음, 하지만 must-revalidate는 원서버에 접근할 수 없는 경우 504 Gateway Timeout 오류 발생)
• cache-control: public : 응답이 프록시캐시에 저장되어도 됨
• cache-control: private : 클라이언트 캐시 저장소에만 저장되어야함 (default)
• cache-control: maxage : 캐시유효기간, 초단위
• cache-control: s-maxage : 프록시캐시에만 적용되는 max-age

---

검증헤더와 조건부요청

• 캐시 데이터는 기간이 만료되더라도 캐시 저장소에 존재할 수 있다. 이 때, 데이터가 이미 존재하는데 서버에서 데이터를 다시 받아오는 것은 비효율적이 하지만 만약 서버 데이터가 수정되었는데 그대로 값을 사용하는 것은 잘못된 처리방법이다.
• 따라서 '검증헤더'와 '조건부요청'을 이용해 이를 확인할 수 있도록 한다.
• 검증헤더 : 데이터의 수정여부를 확인할 수 있을만한 헤더
• 조건부요청 : 요청시 서버에서 조건을 만족할 경우에만 데이터를 넘겨받도록 함

---

Last-Modified & If-modified-sine

• Last-Modified : 데이터가 마지막으로 수정된 시간 (검증헤더)
• If-modified-since : 캐시가 가지고 있는 Last-Modified값을 서버로 보내고, 서버는 해당 값 이후로 데이터가 수정된 경우에만 데이터를 보내주도록 한다. (조건부요청)
• 수정되지 않은 경우 304 Not Modified 응답만을 보낸다. (HTTP 바디에는 아무런 데이터가 없음) 그럼 클라이언트에서는 캐시 저장소에 존재하는 캐시의 메타데이터(유효기간 등)을 갱신하고 이를 사용한다.
• 수정된 경우 200 OK로 HTTP 바디에 데이터를 포함하여 전송한다.

---

ETag & If-None-Match

• Last-Modified와 If-modified-sine는 1초 미만의 단위로는 캐시 조정이 어렵고, 날짜를 기준으로 하기때문에 수정 결과가 이전과 같아지더라도 데이터를 다시 받아온다는 단점이 있다. (스페이스나 주석처럼 큰 영향이 없는 수정사항의 경우에도 데이터를 다시 받아온다.)
• ETag : 캐시데이터의 고유한 버전이름 (검증헤더)
• If-None-Match : 캐시가 가진 ETag값을 서버로 보내고, 서버는 해당 값과 현 데이터의 ETag을 확인하여 일치하지 않는 경우에만 데이터를 보내도록 한다. (조건부요청)
• 요청에 대한 응답은 Last-Modified& If-modified-sine와 동일