Chapter 7. Caching
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
✏️ 원문 번역
If-Modified-Since: Date Revalidation
The most common cache revalidation header is If-Modified-Since. If-Modified-Since revalidation requests often are called “IMS” requests. IMS requests instruct a server to perform the request only if the resource has changed since a certain date:
-
가장 흔히 사용되는 캐시 재검증 헤더로는 If-Modified-Since가 있습니다.
-
If-Modified-Since 재검증 요청을 "IMS"라고 부릅니다.
-
IMS 요청은 리소스가 특정 시점 이후로 변경되었을 때만 서버가 요청을 수행하도록 합니다.
• If the document was modified since the specified date, the If-Modified-Since condition is true, and the GET succeeds normally. The new document is returned to the cache, along with new headers containing, among other information, a new expiration date.
-
만약 문서가 특정 시점 이후로 변경되었다면 If-Modified-Since 조건이 true로 설정되어 GET 요청을 성공적으로 수행합니다.
-
이때 캐시에는 갱신된 만료일시와 같은 새로운 헤더가 포함된 새로운 문서가 반환됩니다.
• If the document was not modified since the specified date, the condition is false, and a small 304 Not Modified response message is returned to the client, without a document body, for efficiency.† Headers are returned in the response; however, only the headers that need updating from the original need to be returned. For example, the Content-Type header does not usually need to be sent, since it usually has not changed. A new expiration date typically is sent.
-
만약 문서가 특정 시점 이후로 변경되지 않았다면 조건은 false로 처리되며, 304 Not Modified 응답 메시지가 클라이언트에 반환됩니다.
-
이때 응답 메시지에는 문서 본문을 효율상 포함하지 않습니다.
-
다만 원본과 달라져 업데이트가 필요한 헤더들만 응답으로 반환되어야 합니다.
-
이를 테면 Content-Type 헤더가 바뀌지 않는다는 가정하에 그것을 항상 전송할 필요는 없습니다.
-
일반적으로 새로운 만료일시는 전송됩니다.
The If-Modified-Since header works in conjunction with the Last-Modified server response header. The origin server attaches the last modification date to served documents. When a cache wants to revalidate a cached document, it includes an If-Modified-Since header with the date the cached copy was last modified:
If-Modified-Since: <cached last-modified date>
-
If-Modified-Since 헤더는 Last-Modified 서버 응답 헤더와 함께 동작합니다.
-
원본 서버는 마지막으로 문서를 변경한 시점을 해당 문서에 첨부합니다.
-
캐시가 캐싱된 문서에 대해 재검증을 수행하려 할 때, 캐싱된 사본이 마지막으로 변경된 시점을 If-Modified-Since 헤더에 포함하여 전송합니다.
If-Modified-Since: (cached last-modified date)
If the content has changed in the meantime, the last modification date will be different, and the origin server will send back the new document. Otherwise, the server will note that the cache’s last-modified date matches the server document’s current last-modified date, and it will return a 304 Not Modified response.
-
만약 그 사이에 콘텐츠에 변경이 발생한 경우 last-modifed date가 달라질 것이고, 원본 서버는 새로운 문서를 반환할 것입니다.
-
반대로 콘텐츠 변경이 발생하지 않았다면 서버는 캐시의 last-modified date가 서버가 가진 문서의 현재 last-modified date가 일치함을 확인하고 304 Not Modified 응답을 반환할 것입니다.
For example, as shown in Figure7-14, if your cache revalidates Joe’s Hardware’s Fourth of July sale announcement on July 3, you will receive back a Not Modified response (Figure7-14a). But if your cache revalidates the document after the sale ends at midnight on July 5, the cache will receive a new document, because the server content has changed (Figure7-14b).
-
Figure 7-14에 나타나는 것처럼 Joe's Hardware의 7월 4일 세일 발표 문서를 7월 3일에 재검증한다고 가정해봅시다.
-
그렇다면 사용자는 Not Modified 응답을 돌려받을 것입니다. (Figure 7-14a)
-
하지만 세일이 끝난 7월 5일 자정 이후에 해당 문서를 재검증하면, 서버의 콘텐츠가 변경되었기 때문에 캐시는 새로운 문서를 돌려받을 것입니다. (Figure 7-14b)
Note that some web servers don’t implement If-Modified-Since as a true date comparison. Instead, they do a string match between the IMS date and the last-modified date. As such, the semantics behave as “if not last modified on this exact date” instead of “if modified since this date.” This alternative semantic works fine for cache expiration, when you are using the last-modified date as a kind of serial number, but it prevents clients from using the If-Modified-Since header for true time-based purposes.
-
일부 웹 서버는 If-Modified-Since를 실제 날짜를 비교하는 방식으로 구현하지 않을 수도 있습니다.
-
대신 IMS 일자와 Last-modified Date간의 문자열 매칭을 수행합니다.
-
따라서 실제로는 "어떤 시점 이후로 수정되었음"을 나타내는 것이 아니라 "정확히 그 날짜에 마지막으로 수정하지 않았음"을 나타낼 수 있습니다.
-
사용자가 Last-modified Date를 일종의 시리얼 번호로 사용할 때에는 이러한 대안이 캐시 만료에 대해 잘 작동합니다.
-
하지만 클라이언트가 실제 시간 기반의 목적으로 If-Modified-Since 헤더를 사용하는 것은 불가능하게 합니다.
If-None-Match: Entity Tag Revalidation
There are some situations when the last-modified date revalidation isn’t adequate:
• Some documents may be rewritten periodically (e.g., from a background process) but actually often contain the same data. The modification dates will change, even though the content hasn’t.
• Some documents may have changed, but only in ways that aren’t important enough to warrant caches worldwide to reload the data (e.g., spelling or comment changes).
• Some servers cannot accurately determine the last modification dates of their pages.
• For servers that serve documents that change in sub-second intervals (e.g. real-time monitors), the one-second granularity of modification dates might not be adequate.
-
때로는 Last-Modified Date 재검증이 적합하지 않은 상황도 있습니다.
-
일부 문서가 백그라운드 프로세스로 주기적으로 재작성되지만 여전히 동일한 데이터를 포함하고 있는 경우가 있습니다. Modification Date는 바뀌지만 콘텐츠는 바뀌지 않은 것입니다.
-
어떤 서버는 페이지의 Last Modification 일자를 정확하게 판단할 수 없습니다.
-
밀리초 간격으로 변화하는 문서를 제공하는 서버의 경우, 1초 단위의 수정 일자가 적합하지 않을 수 있습니다.
To get around these problems, HTTP allows you to compare document “version identifiers” called entity tags (ETags). Entity tags are arbitrary labels (quoted strings) attached to the document. They might contain a serial number or version name for the document, or a checksum or other fingerprint of the document content.
-
이러한 문제들을 회피하기 위해 HTTP는 문서의 Entity Tag(ETag)라고 부르는 "버전 식별자"를 비교할 수 있게 합니다.
-
Entity Tag는 문서에 첨부된 임의의 라벨입니다.
-
ETag가 주로 포함하는 내용에는 문서의 시리얼 번호나 버전명, 혹은 문서 콘텐츠에 대한 Checksum이나 다른 식별자 등이 있습니다.
When the publisher makes a document change, he can change the document’s entity tag to represent this new version. Caches can then use the If-None-Match conditional header to GET a new copy of the document if the entity tags have changed.
-
Publisher가 문서를 변경하면 새로운 버전의 Entity Tag로 교체할 수 있습니다.
-
만약 Entity Tag가 바뀌었다면 캐시는 If-None-Match 조건부 헤더를 사용하여 문서의 새로운 사본을 불러올 수 있습니다.
In Figure7-15, the cache has a document with entity tag “v2.6”. It revalidates with the origin server asking for a new object only if the tag “v2.6” no longer matches. In Figure7-15, the tag still matches, so a 304 Not Modified response is returned.
-
Figure 7-15에서, 캐시는 "v2.6"이라는 ETag를 가지고 있습니다.
-
캐시는 더 이상 "v2.6"과 일치하지 않을 때에만 원본 서버에 새로운 오브젝트를 요청하도록 재검증합니다.
-
Figure 7-15는 여전히 태그가 일치하므로 304 Not Modified 응답이 반환됩니다.
If the entity tag on the server had changed (perhaps to “v3.0”), the server would return the new content in a 200 OK response, along with the content and new ETag.
- 서버의 ETag가 (아마도 v3.0으로) 변경되면 서버는 200 OK 응답으로 새로운 콘텐츠와 새로운 ETag를 반환할 것입니다.
Several entity tags can be included in an If-None Match header, to tell the server that the cache already has copies of objects with those entity tags:
If-None-Match: "v2.6"
If-None-Match: "v2.4","v2.5","v2.6"
If-None-Match: "foobar","A34FAC0095","Profiles in Courage"
-
If-None-Match 헤더에는 여러 개의 ETag가 포함될 수 있습니다.
-
캐시가 이미 해당 ETag의 오브젝트 사본을 가지고 있다는 것을 서버에 알리는 것입니다.
✏️ 요약
Revalidation with Conditional Methods
- 조건부 GET 메서드를 통해 한 번의 요청으로 Revalidation 수행 가능
- If-Modified-Since <date> : 특정 날짜 이후로 문서가 변경되었다면 원본 서버로부터 문서를 가져오게 함
- If-None-Match <tags> : 사본과 서버의 문서가 가진 ETag가 다르면 원본 서버로부터 문서를 가져오게 함
[1] If-Modified-Since
If-Modified-Since: <cached last-modified date>- 리소스가 특정 시점 이후로 변경되었다면 IMS=true -> GET(200)
- 리소스가 특정 시점 이후로 변경되지 않았다면 IMS=false -> GET(304)
- 엄밀히는 IMS의 일시와 마지막 수정 시점에 대해 문자열 매칭을 수행하므로 "어떤 시점을 이후로 수정됨"보다는 "정확히 그 시점에 수정되지 않음"에 더 가까움
- 304 Not Modified 응답은 업데이트가 필요한 헤더만 포함
[2] If-None-Match
If-None-Match: "v2.6"
If-None-Match: "v2.4","v2.5","v2.6"
If-None-Match: "foobar","A34FAC0095","Profiles in Courage"- Last-Modified Date가 바뀌었지만 콘텐츠는 바뀌지 않은 경우, Last-Modified Date를 정확히 알 수 없는 경우, 밀리초 간격으로 Last-Modifed Date가 바뀌는 경우 대안적으로 사용 가능
- Entity Tag(ETag) : 리소스 버전 식별자
- 리소스가 변경되었다면 ETag 변화 -> GET(200)
- 리소스가 변경되지 않았다면 ETag 유지 -> GET(304)
- 캐시가 이미 가지고 있는 오브젝트들은 If-None-Match 헤더에 복수 개의 ETag로 포함 가능
✏️ 감상
크롤링할 때 써먹을 걸
한때 KBO 문자 중계를 크롤링해서 만들던 웹 사이트에 실시간 중계 서비스를 적용하려고 했던 적이 있었다. 문제는 야구 시즌이 이미 끝나버려서 더 이상 실시간으로 문자 중계가 올 일이 없는 상황이었다. 개발자 모드를 켜보니 몇 초에 한 번씩 동일한 문서에 대한 요청을 주기적으로 보내고 응답을 받아오고 있었는데, 그때 마주한 것이 바로 304 Not Modified 응답이었다.
당시에는 앎이 부족해서 304 Not Modified가 뜨고 응답으로 아무런 문서가 오지 않자 크롤링을 중단했었다. 지금 생각해보니 If-Modified-Since나 If-None-Match 헤더를 바꿔서 디버깅을 했으면 충분히 비시즌에도 중계 서비스를 테스트할 수 있었을 것 같다는 생각이 든다. 다음에 또 그런 상황이 온다면 헤더를 더 유연하게 조작할 수 있는 사람이 되어야겠다.
