HTTP 완벽 가이드 7장

캐시

웹 캐시

• 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP 장치
• 웹 요청이 캐시에 도착했을 때, 캐시된 로컬 사본이 존재하면 캐시로부터 제공된다.
• 장점
  • 불필요한 데이터 전송을 줄인다. → 네트워크 요금 비용 감소
  • 네트워크 병목을 줄여준다.
  • 원 서버에 대한 요청을 줄여준다 → 서버의 부하를 줄임, 빠른 응답 가능
  • 거리로 인한 지연을 줄여준다.

캐시 적중, 부적중

• 캐시 적중
  • 캐시에 요청이 도착했을 때, 그에 대응하는 사본이 있다면 요청이 처리
• 캐시 부적중
  • 대응하는 사본이 존재하지 않다면, 요청이 원 서버로 전달됨
• 캐시 재검사
  • 캐시에 존재하는 사본이 원 서버 콘텐츠와 일치하지 않을 수있다.
  • 일치하는지 확인하는 과정을 재검사(Revalidation)이라고 함
  • 성공한 재검사(느린 적중) - 원 서버의 콘텐츠가 변경되지 않았을 경우
  • 실패한 재검사(부적중) - 원 서버의 콘텐츠가 변경된 경우

캐시 처리 단계

1. HTTP 요청 메세지 받기
2. 메세지 파싱 - 메세지 파싱하여 URL과 헤더를 추출
3. 검색 - 로컬 복사본이 있는지 확인, 없다면 받아온다.
4. 신선도 검사 - 캐시된 사본이 신선한지 검사한다.
5. 응답 생성 - 새로운 헤더와 캐시된 본문으로 응답 메세지를 생성한다.
6. 발송 - 네트워크를 통해 응답을 클라이언트에게 발송한다.
7. 로깅 - 선택적으로 로그 작성

캐시 제어

HTTP는 문서가 만료되기 전까지 얼마나 오랫동안 캐시될 수 있게 할 것인지 서버가 설정할 수 잇는 여러가지 방법을 정의한다.

• Cache-Control: no-store
• Cache-Control: no-cache
• Cache-Control: must-revalidate
• Cache-Control: max-age
• Expires
• 만료 정보 제공 x, 휴리스틱 방법으로 결정

 

생각해보자!

 

HTTP는 클라이언트에게 응답이 캐시 적중이었는지 아니면 원 서버 접근인지 말해줄 수 있는 방법을 제공하지 않는다.

→ 상용 프록시 캐시는 캐시에 무슨 일이 일어났는지 설명하기 위해 Via 헤더에 추가 정보를 붙인다.

정말 방법이 없을까?

 

X-Cache

X-Cache 헤더는 주로 웹 서버나 프록시 서버에서 사용되며 특히 서버의 응답이 캐시에서 적중했는지 여부를 클라이언트에게 알려주기 위해 추가한다.

• X-Cache: HIT: 클라이언트의 요청이 캐시에서 적중되어 응답이 캐시에서 제공됨
• X-Cache: MISS: 클라이언트의 요청이 캐시에서 적중되지 않아 원 서버가 응답 제공함
• X-Cache: BYPASS or NOCACHE: 캐시를 우회하고 원 서버로부터 직접 응답이 제공됨

Fastly Community 사이트에서 사용하는 X-Cache 헤더

X의 의미는 사용자 정의 헤더라는 것을 알려주기 위한 것, 사용하지 않아도 되지만 대체적으로 사용한다고 함

 

 

참고 자료

X-Cache | Fastly Developer Hub

X-Cache | Fastly Developer Hub

Fastly Community 사이트

Fastly Community

Fastly Community

X-Cache 설명 by 스택오버플로우

X-Cache Header Explanation

X-Cache Header Explanation