HTTP 웹 기본 지식 (캐시)

캐시

서버에서 응답시 헤더에 캐시 헤더를 추가해서 응답할 경우 클라이언트 웹 브라우저 캐시 저장소에 저장된다.

• cache-control: max-age=60 캐시의 만료시간을 60초로 지정
• 같은 요청을 할 경우 캐시 저장소를 찾아보고 캐시를 사용할 수 있는 경우 서버에 요청하지 않고 데이터를 받을 수 있음
• 네트워크 사용량을 줄일 수 있음
• 브라우저 로딩 속도가 매우 빠름
  -> 빠른 사용자 경험

캐시 유효 시간 초과시

서버에서 데이터를 받을 때 캐시를 사용하면 비싼 네트워크 비용을 지불하지 않아도 된다.
그렇다면 캐시 유효 시간이 만료되었지만, 서버에서 다운 받을 데이터가 변경되지 않았을 때 캐시를 다시 사용한다면 얼마나 좋을까? -> 검증헤더 추가

검증헤더와 조건부 요청

검증헤더

• 검증헤더 = Last-Modified, ETag
• 조건부 요청헤더 = if-Modified-Since:, if-None-Match:
• 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
• Last-Modified, if-Modified-Since: 또는 ETag, if-None-Match: 사용(데이터가 수정됐나요? 물어보는 조건부 헤더)
• 조건이 만족하면(데이터가 수정됐다면) 200 OK, 만족하지 않으면(데이터가 수정되지않았다면) 304 Not Modified

1. 서버에서 응답 시 검증 헤더 Last-Modified: 2022-03-12T12:00:00 데이터의 최종 수정일을 추가해서 응답
2. 클라이언트 웹 브라우저에 캐시되고 클라이언트가 서버에 재 요청시 캐시에 저장돼 있는 if-modified-since: 2022-03-12T12:00:00 헤더를 추가로 전송
3. 서버에서 받은 요청 헤더에 if-modified-since:의 값을 확인하고 데이터 최종 수정일과 같다면 HTTP/1.1 304 Not Modified 응답을 내려주고(캐시정보 포함) Message body가 빠져있음
4. 클라이언트는 응답을 받아 캐시를 갱신하고 캐시에서 데이터를 불러옴

Last-Modified, if-Modified-Since: 의 단점

• 1초 미만의 단위로 캐시 조정이 불가능
• 날짜 기반의 로직 사용 (원본 데이터가 이전과 같아도 파일이 날짜만 갱신이 됐을 경우 원본 데이터가 같더라도 다시 다운받아야 함)

단점을 극복한 ETag, if-None-Match

• 캐시용 데이터에 임의의 고유한 버전 이름을 담 ex) ETag:"v1.0", ETag: "s3iuijfu2l"
• 데이터가 변경되면 고유한 버전 이름을 변경(Hash 다시 생성) ex) ETag: "ab23s" -> ETag: "bb23b"
• ETag 헤더를 추가해서 보내고 같으면 캐시 재활용, 다르다면 서버에서 다운
• 캐시 제어 로직을 완전히 서버에서 관리하기 때문에 클라이언트는 캐시 매커니즘을 알 수 없음

Cache-Control

• 캐시 지시어

  • Cache-Control: max-age 캐시의 유효시간(초 단위)
  • Cache-Control: no-cache 데이터는 캐시해도 되지만, 항상 origin 서버에 검증하고 사용
  • Cache-Control: no-store 데이터에 민감한 정보가 있으므로 저장하면 안됨

• 캐시 만료일 지정

  • expires: Mon, 01 Jan 2000 00:00:00 GMT
  • 캐시 만료일을 정확한 날짜로 지정
  • HTTP 1.0 부터 사용
  • Cache-Control: max-age과 함께 사용하면 expires는 무시됨, 그러므로 좀 더 유연한 Cache-Control: max-age사용 권장

프록시 캐시

한국에 있는 클라이언트와 우루과이에 있는 서버가 데이터를 주고 받는다고 하면 대척점에 있기 때문에 다른 나라중에서도 응답이 가장 느릴텐데, 한국에 캐시 서버를 만들어 origin서버로 직접 요청을 하는게 아닌 한국에 있는 캐시 서버에 접근하도록 한다면 훨씬 빠른 응답을 받을 수 있다. 이처럼 지리적으로 가까운곳에 만든 캐시 서버를 프록시 서버라고 하며 프록시 서버에 저장된 캐시를public 캐시라고 하며 클라이언트에 저장된 캐시를 private 캐시라고 한다.

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

캐시 무효화 🖐🏻

정말 정말 이 데이터는 캐시되어선 절대 절대 절대!!!!!! 안된다고 한다면 아래 헤더를 다 추가할 것

• Cache-Control: no-cache, no-store, must-revalidate

  • must-revalidate는 캐시 만료 후 최초 조회시 origin 서버에 검증, 원 서버 접근 실패시 반드시 오류가 발생해야함 (504 Gateway Timeout), 캐시 유효 시간이라면 캐시를 사용

• Pragma: no-cache (HTTP 1.0 하위 호환)

  	참고 no-cache는 프록시 캐시서버가 origin 서버에 접근할 수 없는 경우 프록시 캐시 서버 설정에 따라 캐시 데이터를 반환할 수 있으나 must-revalidate는 항상 오류를 발생시킴 504 상태 코드 반환