Web Cache에 대해서
RFC 문서를 번역하고 정리한 문서입니다. https://www.rfc-editor.org/rfc/rfc9110.htm
표현(Representation)과 선택된 표현(Selected Representation)
A target resource might be provided with, or be capable of generating, multiple representations that are each intended to reflect the resource's current state. An algorithm, usually based on content negotiation (Section 12), would be used to select one of those representations as being most applicable to a given request. This selected representation provides the data and metadata for evaluating conditional requests (Section 13) and constructing the content for 200 (OK), 206 (Partial Content), and 304 (Not Modified) responses to GET (Section 9.3.1).
타겟 리소스는 리소스의 현재 상태를 반영하려는 의도를 가진 여러개의 “표현(representation)”들을 제공받거나 생성할 능력을 가지고 있는데. 주로 Content negotiation에 기반한 알고리즘이 그 여러개의 표현중 주어진 요청에 가장 적합한 표현을 선택한다. 이것이 selected representation 이다.
- 이 부분이 이해하기 어렵지만, 여기서 말하는 “표현”과 “선택된 표현”라는 단어를 기반으로 RFC문서가 설명을 하고 있어서 추가해 놓았습니다.
- MDN 에서는 “표현은 특정 리소스의 다양한 형태입니다. 예를 들어, 동일한 데이터가 XML 또는 JSON과 같은 특정 미디어 타입으로 형식화되거나, 작성된 언어 또는 지리적 지역으로 지역화되거나, 전송을 위해 압축되거나 인코딩될 수 있습니다. 기본 리소스는 각 경우에 동일하지만, 표현은 다릅니다.” 라고 설명하고 있습니다.
- RFC에서는 “표현은 프로토콜을 통해 쉽게 전달할 수 있는 형식으로 특정 리소스의 과거, 현재 또는 원하는 상태를 반영하기 위한 정보입니다. 표현은 표현 메타데이터 세트와 잠재적으로 무한한 표현 데이터 스트림으로 구성됩니다”라고 설명합니다.
- 좀 더 쉽게 설명하면, 타겟 리소스는, Content negotiation에 기반한 알고리즘으로, 요청에 적합한 형태(“표현”)의 데이터로 응답을 하는데, 이 응답이 “선택된 표현” 입니다.
Validation
요청된 URI에 하나 이상의 캐시된 정보가 있는데, 모두 신선한 응답이 아니거나, 어떤 데이터가 유효한 데이터인지 알 수 없어 선택할 수 없을 때, 다음 요청을 받게되는 서버로 request를 전달하고 그 서버에서 조건부 요청 메커니즘을 이용해 사용할 유효한 response를 선택할 수 있는 기회를 주고, 이 과정에서 캐시에 저장된 메타데이터를 업데이트 하거나(304 Not Modified), 저장된 response를 새로운 response로 교체(200 OK)할 수 있도록 한다. 이 과정을 “유효성 검사” 또는 “재검증” 이라고 합니다.
Freshness
"신선한(fresh)" 응답은 아직 신선도 수명(freshness lifetime)을 초과하지 않은 응답입니다. 반대로 '오래된(stale)' 응답은 이미 만료된 응답입니다.
응답의 '신선도 수명'은 원본 서버에서 생성된 후 만료 시간까지의 기간입니다.
"명시적 만료 시간(explicit expiration time)"은 원본 서버가 추가 유효성 검사 없이 캐시에서 저장된 응답을 더 이상 사용할 수 없도록 의도하는 시간이며, "휴리스틱 만료 시간(heuristic expiration time)"은 명시적 만료 시간이 없는 경우 캐시에 의해 할당됩니다.
응답이 신선하다고 판단되면 원본 서버에 요청하지 않고 캐시된 응답을 사용할 수 있어서 효율적입니다.
명시적 만료 시간 계산법
- 공유캐시(CDN)이고 s-maxage가 있다면 그 값을 사용
- max-age가 있다면 그 값을 사용
- Expires가 있다면, (응답 헤더의 Expires 필드 값 - 응답 헤더의 Date 필드 값) 사용
- 휴리스틱 만료 시간 적용
휴리스틱 만료 시간 계산법
- (now() - Last-Modified) * 0.10 (표준)
- firefox의 경우엔 최대 일주일
If-Modified-Since [Request, Validation]
“If-Modified-Since” 헤더 필드는 요청하는 데이터의 변경 일자가 필드 값으로 요청된 일자보다 최신일 때 GET 또는 HEAD 리퀘스트를 생성합니다.
다음과 같은 경우에는 반드시 무시됩니다.
- 리퀘스트가 “If-None-Match” 헤더 필드를 포함하고 있을때
- “If-None-Match”의 조건이 “If-Modified-Since”의 더 정확한 대안으로 여겨지고, “If-None-Match”를 사용할 수 없는 오래된 웹 매개체(HTTP 1.0을 사용하는)에서의 호환성을 위해서 동시에 사용할 수 있습니다.
- “If-Modified-Since”필드 값이 유효한 HTTP-date가 아닐때
- “If-Modified-Since”필드 값이 하나 이상의 값을 가지고 있을때
- 리퀘스트 메서드가 GET이나 HEAD가 아닐때
- 리소스가 변경 일자(Last-Modified)를 가지고 있지 않을 때
반드시 원본 서버의 시간에 따라 “If-Modified-Since” 필드 값의 타임스탬프를 해석해야 합니다.
예시: If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Last-Modified [Response, Validation]
원본 서버가 판단한 자료가 마지막으로 수정된 시간을 날짜와 시간을 표시하는 타임스탬프로 제공합니다.
예시: Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
Pragma [Request, Freshness]
“Pragma” 리퀘스트 헤더는 클라이언트가 “no-cache”를 명시 할 수 있도록 HTTP/1.0 캐시를 위해 선언되었습니다. 하지만 Cache-Control 충분히 지원되고 있기 때문에 deprecated 되었습니다.
Expires [Response, Freshness]
“Expires” 응답 헤더 필드에는 응답이 오래된 것으로 간주되는 날짜/시간이 표시됩니다.
예시: Expires: Thu, 01 Dec 1994 16:00:00 GMT
Cache-Control 헤더에 max-age 디렉티브가 포함된 경우 수신자는 헤더는 반드시 무시됩니다. 동일하게 s-maxage 디렉티브가 포함된경우 공유 캐시 수신자는 Expires 헤더가 반드시 무시됩니다. 두 경우 모두 Expires의 값은 Cache-Control 헤더 필드를 구현하지 않은 수신자만 대상으로 합니다.
If-None-Match [Request, Validation]
If-None-Match 헤더 필드 값이 “*”일때 수신자 캐시 또는 원본 서버에 타겟 리소스의 현재 “표현”(representation)이 없거나, Etag가 있는 선택된 “표현”이 필드에 나열된 어느 값과도 일치하지 않을때, 조건부로 리퀘스트 메소드가 작동하게 합니다.
계산 되는 방법
- 필드 값이 “*”이면, 원본 서버에 타겟 리소스에 대한 현재 표현(current representation)이 없다면 조건이 false이다.
- 필드 밸류가 Etag의 리스트라면, 나열된 태그중 하나와 선택된 표현(selected representation)이 일치한다면 조건이 false이다.
- 이 외의 경우에 조건은 true 이다.
이를 이해하기 쉬운 말로 정리하자면,
- 필드 값이 “*”이고 유효한 캐시가 있다면 원본 서버에 다시 요청하지 않고 캐시된 정보를 사용한다.
- 필드값이 Etag들의 나열이라면, 그것 중 하나라도 유효한 캐시와 일치하면 원본 서버에 다시 요청하지 않고 캐시된 정보를 사용한다.
- 위 두개에 해당되지 않는다면 원본 서버에 요청한다.
예시:
If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: *Etag [Response, Validation]
응답의 ETag 필드는 요청 처리가 끝날 때 결정된 선택된 표현의 현재 엔티티 태그를 제공합니다. 엔티티 태그는 같은 리소스에 대한 여러개의 표현을 구분하기 위한 불투명한 유효성 검사기입니다. (이 여러개의 표현이 시간 경과에 따른 리소스 상태 변경으로 인한 것인지, content negotiation에 의해 같은 시간에 여러개의 표현이 유효해서인지, 혹은 둘 모두 인지 상관없이.) Etag는 따옴표로 묶인 문자열로 구성되며, weakness indicator가 앞에 붙을 수 있습니다.
ETag = entity-tag
entity-tag = [ weak ] opaque-tag
weak = %s"W/"
opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text
; VCHAR except double quotes, plus obs-text예시:
ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""Cache-Control [Request/Response, Freshness]
This section defines cache request directives. They are advisory; caches MAY implement them, but are not required to.
max-age- max-age 지시문은 응답의 유효 기간이 지정된 시간(초)보다 길면 오래된(stale) 응답으로 간주하도록 합니다.
max-stale- 클라이언트가 캐시의 만료 시간을 초과한 응답을 받아들일지를 나타냅니다. 설정된 값만큼 지난 응답까지도 사용하도록 지정합니다.
min-fresh- 클라이언트가 지정된 시간(초단위) 동안 신선한 상태로 유지될 응답을 원한다는 것을 나타냅니다.
no-cache- 캐시된 버전의 URL을 사용하기 전에 매번 서버에서 유효성을 다시 검사해야 한다고 브라우저에 지시합니다.
no-store- 브라우저 및 기타 공유 캐시에 파일의 어떠한 버전도 저장하지 않도록 지시합니다.
- 캐시는 클라이언트 요청 혹은 서버 응답에 관해서 어떤 것도 저장해서는 안됩니다.
only-if-cached- 캐시된 정보만을 주고, 캐시된 응답이 없을 경우 504 상태를 돌려주어야 합니다.
- 새로운 데이터를 내려받지 않음을 나타냅니다. 클라이언트는 캐시된 응답만을 원하며, 더 최신 복사본이 존재하는지를 알아보기 위해 서버에 요청해선 안됩니다.
**Response Directives(응답 지시문)**
This section defines cache response directives. A cache MUST obey the Cache-Control directives defined in this section.
max-age- max-age 지시문은 응답의 유효 기간이 지정된 시간(초)보다 길면 오래된(stale) 응답으로 간주하도록 합니다.
s-maxagemax-age와 동일하게 동작하지만 공유 캐시에만 적용이 됩니다.
must-revalidate- 캐시에 저장된 응답이 신선한 상태일때만 재사용 될 수 있고, 오래된 상태이면 반드시 원 서버에 검증해야 하도록 합니다다.
- HTTP는 원 서버와의 연결이 끊어졌을때 캐시가 오래된 응답을 사용하도록 허락하는데 must-revalidate를 설정하면 이것을 방지할수 있습니다. - 원 서버에 검증이 되거나 504(Gateway Timeout) response가 생성됩니다.
proxy-revalidatemust-revalidate와 동일하지만, (프록시와 같은)공유 캐시에만 적용되며 사설 캐시에 의해서는 무시됩니다.
must-understand- 응답의 캐싱을 해당 응답의 상태 코드에 대한 요구 사항을 이해하고 준수하는 캐시로 제한합니다.
- 항상 no-store와 같이 사용해야 하고, 조건에 부합하는 경우 no-store는 무시됩니다.
no-cache- 캐시된 버전의 URL을 사용하기 전에 매번 서버에서 유효성을 다시 검사해야 한다고 브라우저에 지시합니다.
no-store- 브라우저 및 기타 공유 캐시에 파일의 어떠한 버전도 저장하지 않도록 지시합니다.
- 캐시는 클라이언트 요청 혹은 서버 응답에 관해서 어떤 것도 저장해서는 안됩니다.
no-transform- 응답에 대해 변형이나 변환이 일어나서는 안됩니다. Content-Encoding, Content-Range, Content-Type 헤더는 프록시에 의해서 수정되어서는 안됩니다. 반투명 프록시는, 예를 들어, 캐시 공간을 절약하고 느린 링크 상의 트래픽량을 줄이기 위해 이미지 포맷들을 변환합니다.
no-transform디렉티브는 이를 허용하지 않습니다.
- 응답에 대해 변형이나 변환이 일어나서는 안됩니다. Content-Encoding, Content-Range, Content-Type 헤더는 프록시에 의해서 수정되어서는 안됩니다. 반투명 프록시는, 예를 들어, 캐시 공간을 절약하고 느린 링크 상의 트래픽량을 줄이기 위해 이미지 포맷들을 변환합니다.
private- 브라우저는 파일을 캐시할 수 있지만, 공유 캐시(CDN)는 캐시할 수 없습니다.
public- 응답을 공유 캐시 포함 모든 캐시에 저장할수 있습니다.
