Chapter 7. Caching
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
✏️ 원문 번역
Weak and Strong Validators
Caches use entity tags to determine whether the cached version is up-to-date with respect to the server (much like they use last-modified dates). In this way, entity tags and last-modified dates both are cache validators.
-
캐시는 캐싱된 사본이 서버의 문서와 비교했을 때 최신 버전인지 확인하기 위해 ETag를 사용합니다. Last-Modified Date도 마찬가지입니다.
-
이러한 관점에서 ETag와 Last-Modified Date는 모두 Cache Validator입니다.
Servers may sometimes want to allow cosmetic or insignificant changes to documents without invalidating all cached copies. HTTP/1.1 supports “weak validators,” which allow the server to claim “good enough” equivalence even if the contents have changed slightly.
-
종종 서버가 캐싱된 모든 사본을 무효화하지 않고 외관상 혹은 사소한 변화를 허용하고자 할 때가 있습니다.
-
HTTP/1.1은 "Week Validator"를 제공하여 사소한 콘텐츠의 변화가 발생하더라도 서버가 "충분히 좋은" 동등성을 주장할 수 있게 합니다.
Strong validators change any time the content changes. Weak validators allow some content change but generally change when the significant meaning of the content changes. Some operations cannot be performed using weak validators (such as conditional partial-range fetches), so servers identify validators that are weak with a “W/”
prefix:ETag: W/"v2.6"
If-None-Match: W/"v2.6"
-
Strong Validator는 콘텐츠가 변화할 때마다 사본을 변경합니다.
-
Weak Validator는 일부 콘텐츠의 변경을 허용하지만 일반적으로 콘텐츠가 유의미하게 변화하였을 때는 사본도 변경됩니다.
-
어떤 연산(조건부 부분 조회 등)은 Weak Validator를 통해 수행할 수 없습니다.
-
따라서 서버는 "W/" 접두사를 사용해서 Weak Validator를 구분합니다.
ETag: W/"v2.6" If-None-Match: W/"v2.6"
A strong entity tag must change whenever the associated entity value changes in any way. A weak entity tag should change whenever the associated entity changes in a semantically significant way.
-
Strong ETag는 연관된 엔티티 값이 변화할 때마다 교체되어야 합니다.
-
Weak ETag는 연관된 엔티티가 의미적으로 유의하게 변화할 때마다 교체되어야 합니다.
Note that an origin server must avoid reusing a specific strong entity tag value for two different entities, or reusing a specific weak entity tag value for two semantically different entities. Cache entries might persist for arbitrarily long periods, regardless of expiration times, so it might be inappropriate to expect that a cache will never again attempt to validate an entry using a validator that it obtained at some point in the past.
-
원본 서버가 서로 다른 엔티티에 대해 특정 Strong ETag 값을 재사용해서는 안 된다는 점에 유의합니다.
-
마찬가지로 의미적으로 다른 엔티티에 대해서도 특정 Week ETag 값을 재사용해서는 안 된다는 점에 주의합니다.
-
캐시 항목들은 만료일자와 관계없이 장기간 보존될 수 있습니다.
-
따라서 캐시가 이전과 얻었던 Validator를 사용해서 다시 항목을 검증하려고 시도할 수도 있습니다. (캐시가 Validator를 재사용하지 않을 것이라고 기대하는 것은 적절하지 않습니다.)
When to Use Entity Tags and Last-Modified Dates
HTTP/1.1 clients must use an entity tag validator if a server sends back an entity tag. If the server sends back only a Last-Modified value, the client can use If-Modified-Since validation. If both an entity tag and a last-modified date are available, the client should use both revalidation schemes, allowing both HTTP/1.0 and HTTP/1.1 caches to respond appropriately.
-
HTTP/1.1 클라이언트는 ETag를 반환하는 서버에 대해 ETag Validator를 사용해야 합니다.
-
만약 서버가 Last-Modified 값만 반환한다면, 클라이언트는 If-Modified-Since 검증 방식을 사용할 수 있습니다.
-
만약 ETag와 Last-Modified Date를 모두 이용할 수 있다면, 클라이언트는 두 가지 재검증 Scheme을 모두 사용하여 야 HTTP/1.0과 HTTP/1.1 캐시에서 모두 적절한 응답이 올 수 있도록 해야 합니다.
HTTP/1.1 origin servers should send an entity tag validator unless it is not feasible to generate one, and it may be a weak entity tag instead of a strong entity tag, if there are benefits to weak validators. Also, it’s preferred to also send a last-modified value.
-
HTTP/1.1 원본 서버는 ETag 식별자를 생성할 수 없는 경우를 제외하고는 항상 ETag를 전송해야 합니다.
-
만약 Weak Validator를 사용해서 얻는 이점이 더 많다면 해당 ETag는 Strong Entity Tag가 아닌 Weak Entity Tag일 것입니다.
-
추가로 Last-Modified Date를 함께 보내는 것이 좋습니다.
If an HTTP/1.1 cache or server receives a request with both If-Modified-Since and entity tag conditional headers, it must not return a 304 Not Modified response unless doing so is consistent with all of the conditional header fields in the request.
- HTTP/1.1 캐시나 서버가 If-Modified-Since와 ETag 조건부 헤더가 모두 포함된 요청을 받는다면, 모든 조건부 헤더 필드가 일치하지 않는 한 304 Not Modified 응답을 반환해서는 안 됩니다.
✏️ 요약
Weak and Strong Validators
- Cache Validator : Last-Modified Date, ETag 등
- Strong Validator : 콘텐츠가 변경될 때마다 Validator 변경
- Weak Validator : 콘텐츠가 유의하게 변경될 때마다 Validator 변경 (사소한 변경사항은 Not Modified로 취급) -> "W/" 접두사로 구분
When to Use ETags and Last-Modified Dates
- 서버가 ETag를 반환하는 경우 : If-None-Match 로 요청
- 서버가 Last-Modified Date를 반환하는 경우 : If-Modified-Since로 요청
- 서버가 둘 다 반환하는 경우 : 둘 다 넣어서 요청 -> 두 조건부 헤더 필드가 모두 일치할 때만 304 Not Modified 반환
✏️ 감상
Semantically Different의 기준
글을 읽다 보니 Weak Validator에서 이야기하는 Semantically Different의 기준이 모호하다는 생각이 들었다. 아마도 나름대로의 기준이 있겠지만 이 책에서 자세히 언급하지 않았으리라고 본다.
GPT한테 물어보니 어떤 코드가 있을 때 주석이나 공백을 제외하고 핵심 내용이 변화하면 보통 Semantically Different라 칭한다고 한다. 만약 서버에서 ETag를 수동으로 붙인다면 문제가 없겠지만, 이게 주석을 수정한 건지 내용을 수정한 건지 어떻게 알고 자동으로 ETag를 붙일 수 있는 걸까?
GPT가 서버에서 미리 데이터를 전처리해서 주석과 공백을 제거한 후 주요 콘텐츠를 해시화하여 비교하는 등 여러 가지 방법들을 제안해주긴 했지만... 전처리 후 304 Not Modified를 전송하는 것과 전처리 없이 200 OK를 전송하는 것 중 어떤 게 더 효율적일지는 나도 잘 모르겠다.
분량 조절 실패하다
지금까지는 캐시를 어떻게 "Fresh"하게 유지할 수 있는지에 대한 내용에 대해 배웠다면, 이 다음에 나오는 것은 Cachability에 대한 내용이다. 하나의 큰 주제가 바뀌다 보니 분량이 조금 짧지만 여기서 한 번 끊고 가기로 했다. 뒷장을 넘기니 영어가 고봉밥으로 있어서 더 읽기도 귀찮아졌다(...) 블로그 쓰고 어차피 영어 공부하러 갈 건데 뒷장까지 읽으면 약간 눈물날지도~
자세한 내용은 내일 다시 알아보는 걸로 하자!!
