HTTP 캐시와 조건부 요청

캐시

• 웹 브라우저에서 서버에 캐시 세팅을 하게 되는데 cache-control로 http 헤더에 넣어준다.
• 캐시가 존재하지 않으면 네트워크 비용이 계속 발생한다. 당연히, 브라우저 로딩 속도가 느리다. 느린 사용자 경험 
• 브라우저 캐시에 응답 결과를 캐시에 저장한다. 캐시의 유효시간을 검증한다. 만료되면 다시 요청해야 하는데 효율적이지 않다.
• 그래서 사용하는 방법이 검증 헤더 + 조건부 요청을 사용한다.
• 어떻게?
  • step1. 서버에서 HTTP 응답 헤더에 Last-Modified(검증 헤더)를 넣어서 보내주면 브라우저 캐시에 Last-Modified를 기록해둔다.
  • step2. 클라이언트는 이제 변경된 사항에 대해 HTTP 요청 헤더에 if-modified-since를 붙여놓고 서버에 보낸다.
  • step3. 서버에서는 변경된 날짜를 확인하고 브라우저 캐시와 비교해서 바뀌지 않았으면 
  • step4. HTTP/1.1 304 Not Modified(수정되지 않았음) 와 HTTP Body를 보내지 않는다. 즉, 메시지 헤더만 보내게 된다. (네트워크 부하가 줄어든다.)
  • step5. 브라우저 캐시가 확인하고 cache-control을 갱신한다. (Last-Modified는 브라우저에 따라 조금씩 다르다고 한다.)
  • step6. 브라우저는 캐시에 불러온것을 사용하게 된다.
• 그런데, Last-Modified, If-Modified-Since 단점이 있다.
  • 가장 큰 문제는 서버에서 별도의 캐시 로직을 관리하고 싶은 경우 - 스페이스나 주석 같은 경우가 해당될것이다.
• 이럴땐 어떻게?
  • ETag를 사용한다. 
  • ETag는 캐시용 데이터에 고유한 버전 이름을 달아둔다. 특히, Hash를 사용하기 때문에 데이터 변경되면 이름을 바꾸어서 변경해야 한다. (파일 컨텐츠가 똑같으면 같은 해시가 나온다.)
  • step1. 서버에서 HTTP 응답 헤더에 ETag를 넣어서 보내주면 브라우저 캐시에서 ETag에 저장한다. 
  • step2. ETag에 갱신 시간이 만료되었을 때 클라이언트에서는 서버에 요청을 하게 되는데 이때 조건부로 If-None-Match:"abcabc" 를 보낸다. 
  • step3. 매치가 완료되었다. 즉, 변경된 데이터가 없으면 304(Not Modified)를 보내고 Body를 비운다. 헤더값만 보낸다. 
  • step4. 응답 결과를 재사용하기 위해서 브라우저 캐시에 저장하고 브라우저는 브라우저캐시에서 데이터를 읽어온다. 
• ETag가 중요한 이유는 "캐시 제어 로직을 서버에서 완전히 관리할 수 있다는 점이다." 유즈 케이스로는 애플리케이션 배포 주기에 맞춰서 ETag를 갱신할 수 있다. 

캐시 제어 헤더

• Cache-Control - 캐시 제어
  • max-age - 캐시 유효 시간
  • no-cache - 데이터는 캐시해도 되지만, 조건부 기반으로 원서버에 항상 검증해야 한다. (중간 프록시 서버를 타고 지나간다.)
  • no-store - 민감한 데이터는 메모리에서 빨리 삭제 요청하는것 
• Pragma - HTTP 1.0 하위 호환
  • no-cache
• Expires
  • Cache-Control: max-age와 함께 쓰면 Expires는 무시
• 검증헤더와 조건부요청 헤더 정리
  • If-Match, If-None-Match: ETag
  • If-Modified-Since, If-Unmodified-Since: Last-Modified값 사용

프록시 캐시

• 원 서버를 거치기 전에 중간에 프록시 서버를 거쳐서 가게 된다.
• Cache-Control : public 
  • public 캐시 (Proxy Cache Server)
• Cache-Control : private
  • private 캐시(로컬에 저장되는 컴퓨터)

캐시 무효화

• 일부 웹 브라우저가 임의로 캐시할 수 있기 때문에 확실하게 캐시를 무효화 하는 방법에 대해 확인한다.
• Cache-Control: no-cache, no-store, must-revalidate
• must-revalidate는 no-cache에서 원 서버에 검증하는 측면은 유사하지만 다른점이 하나 존재한다. 원 서버 접근 시 실패하면 반드시 오류를 발생시켜야 한다. - 504(Gateway Timeout)
• 순간 네트워크 단절로 원 서버 접근 불가경우(유즈케이스) / no-cache + ETag 로 캐시 서버 요청을 한 경우이다.
  • no-cache + ETag로 캐시 서버 요청을 하게 되면 Proxy 캐시에서는 원 서버로 넘겨주는것이 일반적이다. 
  • 일반 웹 사이트의 경우
    • 원 서버에 접근할 수 없는 경우 캐시 서버 설정에 따라 오래된 데이터라도 보여주는 쪽으로 셋팅되어있을 수 있다. (Error or 200 OK)
  • 금융 거래 인경우
    • 이 경우에는 원 서버에 접근할 수 없고 must-revalidate 로 처리해야만 한다. (금융 잔고를 이전것을 보여주는것 크리티컬한 이슈이기 때문이다.)
    • 반드시 이 케이스에서는 503 gateway timeout이 발생하도록 http 스펙에 기재되어 있다.

 

출처 

https://dribbble.com/shots/15126018-Cloud-icon-for-digital-ecosystem-logo-design-symbol