HTTP 헤더 (2)

1. 캐시 기본 동작
2. 검증 헤더와 조건부 요청
3. 캐시와 조건부 요청 헤더
4. 프록시 캐시
5. 캐시 무효화

캐시 기본 동작

클라이언트가 데이터를 요청하면 서버는 응답 메시지 헤더에 캐시 설정 값을 담아 보내준다.
ex) cache-control: max-age=60

만료시간이 적힌 해당 데이터를 브라우저 캐시에 저장하고 만료시간 동안 유효하게 된다. 유효한 시간동안은 클라이언트가 같은 요청을 보낼 때, 네트워크를 사용하지 않고 캐시에 저장되어 있는 데이터를 사용하게 되면서, 빠른 로딩속도를 경험할 수 있다.
하지만 캐시 시간이 초과되면 다시 요청을 보내고 그만큼의 네트워크 사용이 발생한다. 이러한 기본 캐시를 보완하기 위해 검증 헤더와 조건부 요청을 사용한다.

검증 헤더와 조건부 요청

1. Last-Modified
   서버에서 응답 시, 캐시 설정값과 함께 데이터의 최종 수정일을 헤더에 담아 보내준다.
   ex) Last-Modified: Fri, 27 Sep 2019 01:00:00 GMT (데이터의 최종 수정일)

   클라이언트는 서버에 데이터를 요청할 때, 캐시를 먼저 살펴보고 만약 캐시 시간이 초과되었다면 데이터가 변경되었는지 확인하는 요청 메시지를 보낸다. 헤더에는 최종 수정일을 담아 보낸다.
   ex) If-modified-since: Fri, 27 Sep 2019 01:00:00 GMT

   만약 서버가 가지고 있는 데이터의 최종 수정일이 요청에서의 최종 수정일과 다르지 않다면 304 응답을 보내고 클라이언트는 캐시의 메타 정보를 갱신하고, 캐시에 저장되어 있는 데이터 재활용 가능하게 된다.
   ex) 304 Not Modified (바디 없음)

   이 방식은 네트워크 사용이 발생하지만 용량이 적은 헤더 정보만 다운로드 하므로, 매우 실용적인 해결책이다.

• 한계

  • 날짜 기반의 로직을 사용하여 1초 미만 단위로 캐시 조정이 불가능하다.
  • 수정해서 데이터 결과가 똑같은 경우에도 수정일이 달라져서 캐시 사용이 불가능하다.
  • 서버에서 별도의 캐시 로직을 관리하고 싶은 경우에도 캐시 사용이 불가능하다.
  
  

2. ETag
   캐시용 데이터에 버전 이름이나, 해시를 생성해서 클라이언트에게 전달해준다.
   ex) ETag: "aaaaaaa"

   클라이언트는 데이터 변경을 확인할 때, ETag 값을 넣어 서버로 보내주게 되고 서버는 ETag 값을 이용하여 일치하면 304 응답을 보내고 일치하지 않으면 데이터를 전송해준다.
   ex) If-None-Match: "aaaaaaa"

   
   
   

캐시와 조건부 요청 헤더

1. 캐시 제어 헤더

   • Cache-Control

     • : max-age => 캐시 유효 시간, 초 단위
     • : no-cache => 데이터는 캐시해도 되지만, 항상 원(orgin) 서버에 검증하고 사용
     • : no-store => 데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서 사용하고 최대한 빨리 삭제)

   • Pragma 캐시제어(하위 호환)
     ex) Pragma: no-cache

   • Expires 캐시 만료일 지정(하위 호환)
     캐시 만료일을 정확한 날짜로 지정
     ex) expires: Mon, 01 Jan 1990 00:00:00 GMT
     Cache-Control: max-age 권장

2. 검증 헤더와 조건부 요청 헤더

• 검증헤더

  • ETag
  • Last-Modified

• 조건부 요청 헤더

  • If-Match, If-None-Match: ETag 값 사용
  • If-Modified-Since, If-Unmodified-Since: Last-Modified 값 사용

프록시 캐시

네트워크의 전송시간을 줄이기 위해 사용자에게 물리적으로 가까운 곳에 프록시 서버를 운영하고 DNS를 조작하여 사용자가 프록시 서버에 먼저 방문하도록 한다. 프록시 서버는 public 캐시 데이터를 저장해놨다가 사용자가 요청시 캐시 데이터를 전송해준다.

Cache-Control

• : public => 응답이 public 캐시에 저장되어도 됨
• : private => 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)
• : s-maxage => 프록시 캐시에만 적용되는 max-age
• Age: 60 => 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

캐시 무효화

Cache-Control: no-cache, no store, must-revalidate
Pragma: no-cache (하위 호환용으로 추가)

• must-revalidate => 캐시 만료후 최초 조회시 원 서버에 검증해야함, 캐시 유효시간이라면 캐시를 사용하고 원서버 접근 실패시 반드시 오류가 발생해야한다.
  no-cache의 경우 원 서버 접근 불가할 때, Error 또는 Not Modified가 아닌 200 응답으로 프록시 캐시의 데이터를 보내주는 경우도 있기 때문에 must-revalidate를 같이 설정해줘야한다.

해당 포스팅은 김영한님의 인프런 강의 "모든 개발자를 위한 HTTP 웹 기본 지식"를 수강하고 배운 내용을 정리한 글입니다.