Chapter 15. Entities and Encodings
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
✏️ 원문 번역
Validators and Freshness
Look back at Figure 15-8. The client does not initially have a copy of the resource, so it sends a request to the server asking for it. The server responds with Version 1 of the resource. The client can now cache this copy, but for how long?
-
Figuer 15-8의 그림으로 되돌아가 봅시다.
-
클라이언트는 초기에 리소스의 사본을 보유하고 있지 않으므로 서버에 리소스를 요청합니다.
-
서버는 리소스의 Version 1로 응답합니다.
-
이제 클라이언트는 사본을 캐싱할 수 있지만 얼마나 오래 캐싱할 수 있을까요?
Once the document has “expired” at the client (i.e., once the client can no longer consider its copy a valid copy), it must request a fresh copy from the server. If the document has not changed at the server, however, the client does not need to receive it again—it can just continue to use its cached copy.
-
문서가 만료되어 더 이상 유효하지 않게 되면 클라이언트는 서버에 최신 사본을 요청해야 합니다.
-
그러나 서버에서 문서가 변경되지 않았다면 클라이언트는 해당 문서를 다시 받을 필요가 없습니다.
-
캐싱된 사본을 계속해서 사용하면 됩니다.
This special request, called a conditional request, requires that the client tell the server which version it currently has, using a validator, and ask for a copy to be sent only if its current copy is no longer valid. Let’s look at the three key concepts—freshness, validators, and conditionals—in more detail.
-
이처럼 특수한 조건부 요청은 클라이언트가 Validator를 통해 현재 보유하고 있는 문서의 버전을 서버에게 전달하고, 현재 사본이 유효하지 않은 경우에만 사본을 전송하도록 요청합니다.
-
이제 세 가지 주요한 개념인 Freshness(최신성), Validator, Conditionals에 대해 자세히 알아봅시다.
Freshness
Servers are expected to give clients information about how long clients can cache their content and consider it fresh. Servers can provide this information using one of two headers: Expires and Cache-Control.
-
서버는 클라이언트에게 콘텐츠를 캐싱하고 그것을 fresh로 간주할 수 있는 기간에 대한 정보를 제공해야 합니다.
-
서버는 아래의 두 가지 헤더 중 하나를 사용하여 정보를 제공할 수 있습니다.
- Expires
- Cache-Control
The Expires header specifies the exact date and time when the document “expires”—when it can no longer be considered fresh. The syntax for the Expires header is:
Expires: Sun Mar 18 23:59:59 GMT 2001
-
Expires 헤더는 문자가 만료되는 정확한 날짜와 시각을 지정합니다.
-
즉 문서가 더 이상 "fresh"로 여겨지지 않는 시점을 의미합니다.
-
Expires 헤더의 문법은 다음과 같습니다.
Expires: Sun Mar 18 23:59:59 GMT 2001
For a client and server to use the Expires header correctly, their clocks must be synchronized. This is not always easy, because neither may run a clock synchronization protocol such as the Network Time Protocol (NTP). A mechanism that defines expiration using relative time is more useful. The Cache-Control header can be used to specify the maximum age for a document in seconds—the total amount of time since the document left the server. Age is not dependent on clock synchronization and therefore is likely to yield more accurate results.
-
클라이언트와 서버가 Expires 헤더를 적절히 사용하기 위해서는 시계가 정확히 동기화되어 있어야 합니다.
-
서버와 클라이언트 모두 NTP와 같은 시간 동기화 프로토콜을 사용하지 않을 수 있기 때문에 동기화는 쉬운 일이 아닙니다.
-
때문에 상대적인 시간을 사용하여 만료일시를 정의하는 매커니즘이 더 유용하게 사용됩니다.
-
Cache-Control 헤더는 문서가 서버에서 출발한 후로 문서의 최대 보존기간을 초 단위로 지정하는 데 사용할 수 있습니다.
-
보존기간은 시간 동기화에 의존적이지 않으므로 더 정확한 결과를 얻을 수 있습니다.
The Cache-Control header actually is very powerful. It can be used by both servers and clients to describe freshness using more directives than just specifying an age or expiration time. Table 15-3 lists some of the directives that can accompany the Cache-Control header.
-
실제로 Cache-Control 헤더는 매우 강력합니다.
-
서버와 클라이언트 모두 "freshness"를 설명하기 위해 Cache-Control 헤더를 사용할 수 있습니다.
-
Cache-Control 헤더에는 단순히 보존기간이나 만료일시를 지정하는 것 이상으로 많은 지시어가 포함되어 있습니다.
-
Table 15-3은 Cache-Control 헤더에 수반되는 몇 가지 지시어의 목록을 나타냅니다.
Caching and freshness were discussed in more detail in Chapter 7.
- 캐싱과 Freshness에 대해서는 Chapter 7에서 자세히 다루었습니다.
Conditionals and Validators
When a cache’s copy is requested, and it is no longer fresh, the cache needs to make sure it has a fresh copy. The cache can fetch the current copy from the origin server, but in many cases, the document on the server is still the same as the stale copy in the cache. We saw this in Figure 15-8b; the cached copy may have expired, but the server content still is the same as the cache content. If a cache always fetches a server’s document, even if it’s the same as the expired cache copy, the cache wastes network bandwidth, places unnecessary load on the cache and server, and slows everything down.
-
더 이상 유효하지 않은 사본에 대하여 요청이 온 경우, 캐시는 해당 사본이 최신의 사본이 되도록 보장할 필요가 있습니다.
-
캐시는 원본 서버로부터 현재의 사본을 불러올 수 있지만, 대부분 서버의 문서는 캐시에 있는 오래된 사본과 동일한 경우가 많습니다.
-
Figure 15-8b에서도 이러한 모습이 나타납니다.
-
캐싱된 사본이 만료되었음에도 서버 콘텐츠가 캐시의 콘텐츠와 동일한 상황이라고 볼 수 있습니다.
-
만료된 사본과 동일한 서버의 문서를 항상 가져오는 것은 네트워크 대역폭을 낭비하는 일입니다.
-
동시에 캐시와 서버에 불필요한 부하를 가하게 되고 속도를 느리게 만듭니다.
To fix this, HTTP provides a way for clients to request a copy only if the resource has changed, using special requests called conditional requests. Conditional requests are normal HTTP request messages, but they are performed only if a particular condition is true. For example, a cache might send the following conditional GET message to a server, asking it to send the file /announce.html only if the file has been modified since June 29, 2002 (the date the cached document was last changed by the author):
GET /announce.html HTTP/1.0 If-Modified-Since: Sat, 29 Jun 2002, 14:30:00 GMT
-
이러한 현상을 해소하기 위해 HTTP는 리소스가 변경되었을 때만 사본을 요청할 수 있는 수단을 클라이언트에게 제공합니다.
-
바로 조건부 요청이라고 부르는 특수 요청입니다.
-
조건부 요청은 일반적인 HTTP 요청 메시지와 동일하지만 특정 조건이 참일 때만 수행됩니다.
-
가령 캐시는 /announce.html이 2002년 6월 29일 이래로 변경되었을 때만 파일을 전송하도록 서버에 조건부 GET 메시지를 요청할 수 있습니다.
-
이 날짜는 캐싱된 사본이 저자에 의해 마지막으로 수정된 날짜입니다.
Conditional requests are implemented by conditional headers that startwith “If-”. In the example above, the conditional header is If-Modified-Since. A conditional header allows a method to execute only if the condition is true. If the condition is not true, the server sends an HTTP error code back.
-
조건부 요청은 "If-"로 시작하는 조건부 헤더와 함께 구현됩니다.
-
위의 예시에서 조건부 헤더는
If-Modified-Since입니다. -
조건부 헤더는 조건이 참일 때만 메서드를 실행하게 합니다.
-
만약 조건이 참이 아니라면 서버는 HTTP 에러 코드를 반환해야 합니다.
✏️ 요약
Freshness
: 캐시에 저장된 사본이 유효(Fresh)한 정도
- 서버로부터 리소스를 받아올 때
Expires,Cache-Control헤더를 통해 리소스의 만료일시를 명시할 수 있다Expires: 리소스가 만료되는 날짜와 시각 (NTP를 통한 Clock Synchronization 필요)Expires: Sun Mar 18 23:59:59 GMT 2001Cache-Control: 서버에서 응답이 생성된 시점(Date)부터 Cache-Control에 포함된 상대적인 시간(초 단위)을 더하여 리소스의 만료일시를 계산하는 데 사용max-age: 사본의 보존 기간 지정no-store: 서버로부터 응답을 저장하지 않음 + 캐싱된 사본을 전달하지 않음(항상 서버로부터 리소스 전달)no-cache: 서버에 재검증을 거치지 않고 캐싱된 사본을 전달할 수 없음
✏️ 감상
캐싱 정책 복습, 그리고 나한테 하고 싶은 말
오늘은 Expires와 Cache-Control 헤더를 통하여 캐싱 정책을 제어하는 방식에 대해 복습했다. Chapter 7 이후로 자주 등장하는 내용인데도 불구하고 드문드문 기억이 나지 않는 부분이 있는 것 같다(...) 그래도 이제 하도 많이 봐서 그런지 Expires와 Cache-Control 헤더 정도는 쉽게 구분할 수 있고, 해석하는 것도 가능하다 !!
사람의 기억은 한정적이어서 많은 내용을 기억하고 싶어도 대부분 휘발되어 버리고는 한다. 그래서 그런지 열심히 책을 읽고 나서도 머릿속에 남는 게 많이 없다는 생각에 종종 회의감이 들었다. 요즘들어 HTTP 책은 그냥 '읽어야 하니까 읽는 것'이라는 생각이 든 것도, 오래 사귄 연인과 권태기가 온 것마냥 의욕적이지 않게 된 것도 다 그런 기분 때문이었다.
그런데 오늘 보니 꼭 그렇지만은 않은 것 같다. 한참 전에 읽었던 Chapter 7의 내용이 완벽한 형태는 아니어도 머릿속에 남아있긴 한 걸 보니. 그동안 입 밖으로 내뱉지 않았으니 남아있는지도 몰랐을 뿐이다. 완벽하게 기억하는 것만큼 완벽하게 잊는 것 또한 어려운 일이다. 한 번 공부한 부분을 어떻게 완벽하게 잊을 수가 있을까.
내가 도대체 뭘 하고 있는 건지 모르겠고 쓸데없는 일이라는 생각이 들 때는 오늘을 기억하면 좋을 것 같다. 전부 까먹은 것처럼 보여도 여기저기서 보고 듣고 느낀 내용들은 어딘가에 캐싱되어 있다가 언젠가 나에게 도움을 주는 날이 올 것이다.
헛둘 파이팅~!~!
