[TIL] 22.12.23 HTTP 헤더 - 캐시와 조건부 요청(2)

김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 듣고 정리한 내용입니다.

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

 

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

프록시 캐시

클라이언트가 아주 멀리 있는 서버에 접근한다면 시간이 오래 걸리게 된다. 대략 500ms가 걸린다고 한다면 모든 사람들이 다 500ms씩 기다려야 한다.

 

그래서 중간에 프록시 캐시 서버를 둔다. 이를 CDN 서비스라고 하고 대표적인 것이 AWS Cloud Front이다.

 

요청이 오면 원 서버가 아니라 프록시 캐시 서버를 거친다. 이는 클라이언트와 좀 더 가깝게 있기 때문에 응답 시간이 빨라진다. 처음 요청한 유저는 느릴 수 있지만 그 다음 요청한 유저는 더 빠르게 사용할 수 있다.

 

프록시 캐시 서버처럼 공용으로 사용하는 곳은 public 캐시, 로컬에서 사용하는 웹 브라우저 캐시는 private 캐시라고 한다.

 

Cache-Control 캐시 지시어(directives) - 기타

Cache-Control: 오른쪽에 있는 내용이 캐시 지시어이다.

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

 

캐시 무효화

Cache-Control에 확실한 캐시 무효화를 할 수 있는 응답이 있다.

캐시 설정과 관계없이 브라우저가 임의로 캐싱을 하는 경우가 있는데, 이를 막기 위한 설정이다.

 

Cache-Control 캐시 지시어(directives) - 확실한 캐시 무효화

• Cache-Control: no-cache
  • 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용
• Cache-Control: no-store
  • 데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서 사용하고 최대한 빨리 삭제)
• Cache-Control: must-revalidate
  • 캐시 만료 후 최초 조회 시 원 서버에 검증해야 함
  • 원 서버 접근 실패 시 반드리 오류가 발생해야 함 - 504 Gateway Timeout
  • 캐시 유효 시간이라면 캐시를 사용함
• Pragma: no-cache
  • HTTP 1.0 하위 호환

 

no-cache vs must-revalidate

클라이언트가 no-cache로 서버에 요청하면 프록시 서버는 no-cache이기 때문에 원 서버로 요청을 전달하고, 원 서버에서는 적절한 응답을 내려준다.

 

no-cache로 보냈는데 순간적으로 원 서버에 접근할 수 없는 경우 프록시 캐시 서버의 설정에 따라 오류 보다는 기존의 캐시 데이터를 반환할 수도 있고, 그런 경우 200 OK로 응답을 하게 된다.

 

must-revalidate의 경우에는 원 서버에 접근할 수 없는 경우 항상 오류가 발생해야 하기 때문에 응답으로 504 Gateway Timeout을 보낸다.

통장 잔고 등 예전 데이터로 떴을 때 큰 문제가 생길 경우에는 must-revalidate를 써야 한다.