HTTP 헤더 - 캐시와 프록시 캐시, 무효화

 

 

📒 캐시 제어 헤더

📝 Cache-Control: 캐시 제어

• "Cache-Control: max-age"  -> 초 단위 캐시 유효 시간 (보통 굉장히 길게 설정)
• "Cache-Control: no-cache"  -> 데이터는 캐시해도 되지만, 중간의 프록시 캐시 서버에서는 아무것도 하면 안되고 항상 원(origin) 서버에서 검증하고 사용
• "Cache-Control: no-store" -> 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)

 

📝 Pragma: 캐시 제어(하위 호환)

• Pragma: no-cache 

• HTTP 1.0 하위 호환

* 거의 사용하지 않음

 

📝 Expires: 캐시 유효 기간(하위 호환)

• expires: Mon, 01 Jan 1990 00:00:00 GMT 

• 캐시 만료일을 정확한 날짜로 지정 

• HTTP 1.0 부터 사용 

• 지금은 더 유연한 초단위인 Cache-Control: max-age 권장
• Cache-Control: max-age와 함께 사용하면 Expires는 무시

 

 

📒 프록시 캐시

📌 프록시 서버

: 거리가 먼 원 서버(origin 서버) 대신 빠르고 가까운 프록시 캐시 서버를 사용함

 

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

• "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: 캐시 만료 후 최초 조회시 원 서버에 검증해야함. 원 서버 접근 실패시 반드시 오류가 발생해야함. - 504(Gateway Timeout)

 

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

 

근데 no-cache와 must-revalidate 뭐가 다르지???

📌 no-cache vs must-revalidate

만약 프록시 캐시와 원 서버의 네트워크가 단절된다면? 원 서버 접근 불가!?

 

📝 no-cache: 원 서버에 접근할 수 없는 경우 캐시 서버 설정에 따라서 캐시 데이터를 반환할 수 있음.

* Error or 200 OK (오류 보다는 오래된 데이타라도 보여주자)

 

📝 must-revalidate: 원 서버에 접근할 수 없는 경우, 항상 오류가 발생해야 함.

* 504 Gateway Timeout (매우 중요한 돈과 관련된 결과로 생각해보자)

 

그래서, 더더욱 확실히 하려면 must-revalidate까지 넣어주면 아주아주 확실히 캐시 무효화 가능