[HTTP] 웹 기본 지식 정리 - HTTP 헤더(캐시와 조건부 요청)②

- 이 게시글은 인프런 "모든 개발자를 위한 HTTP 웹 기본지식"의 김영한님 강의를 보고 요약한 내용입니다

---

1. 캐시와 조건부 요청 헤더

캐시 제어 헤더

 

1) Cache-Control : 캐시 지시어

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

 

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

• Pragma: no-cache
• HTTP 1.0 하위 호환
• 지금 거의 사용하지 않음

 

3) Expires : 캐시 만료일 지정(하위 호환)

• 캐시 만료일을 날짜로 지정
• HTTP 1.0 부터 사용
• 날짜보다 더 유연한 초 단위인 Cache-Control: max-age 권장

 

2. 프록시 캐시

 

원(origin) 서버 직접 접근

▶ 미국에 있는 원 서버에서 데이터 받을 경우 0.5초 걸린다고 가정 → 느린 응답

 

 

 

프록시 서버 도입

▶ 프록시 캐시 서버가 원 서버에게 캐시를 받아 보관해두고, 클라이언트 웹 브라우저에서는 프록시 서버에서 해당 데이터를 받는다. → 빠른 응답을 받을 수 있음

▶ 첫 번째 요청은 느림

▶ 프록시 캐시 서버에 저장되어있는 캐시는 public 캐시

▶ 클라이언트 웹 브라우저에 있는 캐시는 private 캐시 

 

Cache-Control : 캐시 지시어 - 기타 부분

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

 

3. 캐시 무효화

확실한 캐시 무효화 응답

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

Pragma: no-cache(HTTP 1.0에서 요청올 경우를 대비하여 하위 호환)

 

Cache-Control: must-revalidate

- 캐시 만료 후 최초 조회시 원 서버에 검증해야 함

- 원 서버 접근 실패 시 반드시 오류 발생하도록 → 504 Gateway Timeout

- 캐시 유효 시간이라면 캐시 사용

 

no-cache VS must-revalidate

no-cache 기본 동작

▶ 프록시 캐시 서버가 원 서버에 접근할 수 없는 상황이라면?(순간 네트워크 단절 가정)

 

→ no-cache 경우

- 캐시 서버 설정에 따라서 캐시 데이터 반환 가능

- Error or 200 OK (오류보다는 오래된 데이터 보내기)

 

→ must-revalidate 경우

- 원 서버 접근 불가능할 경우 항상 오류 발생

- 504 Gateway Timeout 발생