HTTP: 캐시

도서 HTTP 완벽 가이드를 읽고 알게 된 지식을 정리한 글입니다.

---

웹 캐시란 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP 장치이다. 간단하게 말해, 캐시된 사본이 존재한다면, 원 서버가 아닌 캐시로부터 문서를 제공받는 것이다.

---

캐시의 장점

• 불필요한 데이터 전송을 줄여 네트워크 요금을 줄일 수 있다.
• 네트워크 병목을 줄여준다.
• 원 서버에 대한 요청을 줄여준다.
• 거리로 인한 지연을 줄여준다.

---

캐시 적중/부적중

적중률

캐시가 요청을 처리하는 비율이다. 적중률은 캐시의 크기, 캐시 사용자들의 관심사 일치 정도, 데이터 변경 주기, 캐시 설정 방식에 따라 달라진다. 적중률 40%면 웹 캐시로 괜찮은 편이다.

 

바이트 적중률

큰 객체는 덜 접근되지만, 그 크기 때문에 전체 트래픽에는 더 크게 기여할 수 있다. 바이트 적중률은 캐시를 통해 제공된 모든 바이트의 비율을 표현한다.

 

 

재검사

• 재검사 적중: 원 서버 객체가 변경되지 않았을 경우, 304 Not Modified
• 재검사 부적중: 서버 객체가 캐시된 사본과 다를 경우, 200 OK
• 객체 삭제: 서버 객체가 삭제되었을 경우, 캐시는 사본을 삭제한다. 404 Not Found

 

---

캐시의 종류

• 개인 전용 캐시
• 공용 프락시 캐시

---

캐시 처리 단계

 

캐시 처리 단계

 

기본 순서

1. 요청 받기
2. 파싱
3. 검색
4. 신선도 검사
5. 응답 생성
6. 전송
7. 로깅

 

---

단계 1: 요청 받기

HTTP 요청을 받는다.

 

---

단계 2: 파싱

요청 메시지를 파싱하여 URL과 헤더들을 추출하여 사용하기 편리한 자료구조에 담는다.

 

---

단계 3: 검색

URL에 해당하는 사본이 캐시에 있는지 검사한다. 만약 캐시 내부에 문서 사본이 존재하지 않는다면, 상황이나 설정에 따라 원 서버나 부모 프락시에서 가져오거나 실패를 반환한다.

 

---

단계 4: 신선도 검사

정해진 기간동안, 캐시된 문서는 신선한 것으로 간주된다. 사본을 신선도 한계보다 더 오랫동안 캐시에 가지고 있었다면, 그 사본은 신선하지 않은 것으로 간주된다. 신선하지 않은 문서는 재검사해야 한다.

 

---

단계 5: 응답 생성

• 원 서버나 부모 프락시의 응답 헤더를 토대로 응답 헤더를 생성한다. 이 때, 캐시는 클라이언트에 맞게 헤더를 조정한다. 이로 인해 기저 헤더는 수정되거나 늘어날 수 있다.
  • 클라이언트가 HTTP/1.1 응답을 기대하는데 원 서버 혹은 부모 프락시가 HTTP/1.0 응답을 반환했다면, 캐시는 반드시 헤더를 적절하게 번역해야 한다.
  • 캐시 신선도 정보를 삽입한다.
  • 요청이 프락시 캐시를 거쳐갔음을 알려주기 위해 Via 헤더를 포함시키기도 한다.
  • Date 헤더는 객체가 원 서버에서 최초로 생겨난 일시를 표현하는 것이기 때문에 조정하면 안 된다.

 

---

단계 6: 전송

클라이언트에게 응답을 돌려준다.

 

---

단계 7: 로깅

캐시 트랜잭션이 완료되고, 캐시는 캐시 적중과 부적중 횟수 등에 대한 통계를 갱신한다. 또한, 로그 파일에 요청의 종류, URL, 일어난 일에 대한 항목을 추가한다.

---

사본을 신선하게 유지하는 방법

문서 만료와 서버 재검사를 활용한다.

 

문서 만료

캐시된 문서가 만료되면, 캐시는 반드시 원 서버에 변경된 것이 있는지 검사해야 하며, 만약 변경된 것이 있다면 새 유효기간과 함께 신선한 사본을 가져와야 한다.

의미	헤더	설명
유효기간	Expires	절대 유효기간을 명시한다. 유효기간이 경과한 문서는 더 이상 신선하지 않은 것으로 간주된다. Expires: Mon, 13 March 2023, 13:40:00 KST
나이	Cache-Control: max-age	문서의 최대 나이를 정의한다. 이는 캐시된 문서가 처음 생성된 이후부터, 신선할 수 있는 최대 시간이다. 초 단위이다. Cache-Control: max-age=604800

 

서버 재검사

기본적으로 문서 만료가 일어났을 때 시행된다. 캐시가 원 서버에게 문서가 변경되었는지 여부를 물어보는 것이다.

캐시는 서버 재검사를 통해 다음 중 하나를 반환해야 한다.

• 원 서버와 재검사 결과 콘텐츠가 변경된 경우, 원 서버로부터 새롭게 캐시된 사본
• 원 서버와 재검사 결과 콘텐츠가 변경되지 않은 경우, 새 만료일을 포함하여 갱신된 헤더와 기존의 콘텐츠
• 에러 메시지 - 원 서버가 다운된 경우
• 경고 메시지가 부착된 캐시된 사본 - 부정확한 경우

조건부 GET으로 인한 재검사

조건부 GET은 원 서버가 갖고 있는 문서와 캐시가 갖고 있는 문서와 다를 때만 원 서버에게 문서를 보내달라고 하는 것이다. 이는 GET 요청 메시지에 아래의 조건부 헤더를 추가하는 것으로 구현된다. 조건부 GET은 사실상 서버 재검사이므로, 이 조건부 헤더는 조건부 GET뿐 아니라 서버 재검사에도 쓰인다.

헤더	설명
If-Modified-Since: <date>	문서가 주어진 날짜 이후로 변경되었다면 요청 메서드를 처리한다. 콘텐츠가 캐시된 이후에 원 서버에서 변경된 경우에만 콘텐츠를 가져오기 위해 사용한다. Last-Modified 서버 응답 헤더와 함께 사용된다. 만약 문서가 주어진 날짜 이후에 변경되지 않았다면, 클라이언트에게 304 Not Modified 응답을 보낸다. 이 때 보통 헤더에 새 만료 날짜를 함께 보내준다.
If-None-Match: <tags>	문서 버전에 관한 태그이다. 캐시된 태그가 서버에 있는 문서의 태그와 다를 때만 요청을 처리한다. 캐시가 객체에 대한 여러 개의 사본을 갖고 있는 경우, 그 사실을 서버에게 알리기 위해 하나의 If-None-Match 헤더에 여러 개의 엔터티 태그를 포함할 수 있다.

 

• 만약 서버가 엔터티 태그만을 반환했다면, 클라이언트는 반드시 엔터티 태그 검사기를 사용해야 한다.
• 만약 서버가 Last-Modified 값만을 반환했다면, 클라이언트는 반드시 If-Modified-Since 검사를 사용해야 한다.
• 만약 두 가지 모두 반환되었다면, 클라이언트는 두 가지 재검사 정책을 모두 사용해야 한다.

---

캐시 제어 방법

헤더	설명
Cache-Control: no-store	캐시가 그 응답의 사본을 만드는 것을 금지한다. 캐시는 클라이언트에게 응답을 전달한 후 객체를 삭제한다.
Cache-Control: no-cache	먼저 서버와 재검사한 후에만 캐시에서 클라이언트로 제공될 수 있다.
Cache-Control: must-revalidate	캐시가 이 객체의 신선하지 않은 사본을 원 서버와의 최초의 재검사 없이는 제공해서는 안 된다.
Cache-Control: max-age	캐시된 문서의 최대 나이를 정의한다. 이는 캐시된 문서가 처음 생성된 이후부터, 신선할 수 있는 최대 시간이다. 초 단위이다.
Expires: 날짜	캐시된 문서의 실제 만료 날짜를 명시한다.
체험적 방법(헤더 정보 X)	유명한 휴리스틱 만료 알고리즘인 LM 인자 알고리즘은, 최근 변경 일시를 가지고 문서가 얼마나 자주 바뀌는지 추정한다. 만약 최근 변경 일시 정보가 없다면, 기본 신선도 유지기간을 설정한다.

 

---