---

Chapter 7. Caching

(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)

---

❤️ 원문 번역 ❤️

Hits and Misses

So caches can help. But a cache doesn’t store a copy of every document in the world.*

• 따라서 캐시는 매우 유용합니다.

• 그러나 캐시가 이 세상에 존재하는 모든 문서의 사본을 저장할 수는 없습니다.

Some requests that arrive at a cache can be served from an available copy. This is called a cache hit (Figure 7-4a). Other requests arrive at a cache only to be forwarded to the origin server, because no copy is available. This is called a cache miss (Figure 7-4b).

• 어떤 요청은 캐시로부터 이용 가능한 사본을 제공받을 수 있습니다.

• 이것을 cache hit이라고 합니다. (Figure 7-4a)

• 캐시에 도착한 또다른 요청이 사본을 이용할 수 없다면 반드시 origin 서버로 향해야만 합니다.

• 이것을 cache miss라고 합니다. (Figure 7-4b)

---

Revalidations

Because the origin server content can change, caches have to check every now and then that their copies are still up-to-date with the server. These “freshness checks” are called HTTP revalidations (Figure 7-4c). To make revalidations efficient, HTTP defines special requests that can quickly check if content is still fresh, without fetching the entire object from the server.

• origin 서버 콘텐츠는 언제든 변경될 수 있습니다. 따라서 캐시는 서버와 비교하여 사본이 최신의 것(up-to-date)인지 이따금씩 확인해주어야 합니다.

• 이러한 "최신성(Freshness) 검사"를 HTTP revalidation이라고 합니다. (Figure 7-4c)

• HTTP는 재검증을 보다 효율적으로 하기 위해 콘텐츠가 최신인지 빠르게 확인할 수 있는 특수한 요청을 정의하고 있습니다. 이 요청은 서버로부터 전체 객체를 가져오지 않으면서 최신성을 검증합니다.

A cache can revalidate a copy any time it wants, and as often as it wants. But because caches often contain millions of documents, and because network bandwidth is scarce, most caches revalidate a copy only when it is requested by a client and when the copy is old enough to warrant a check. We’ll explain the HTTP rules for freshness checking later in the chapter.

• 캐시는 원하는 만큼 자주 사본을 검증할 수 있습니다.

• 하지만 일반적으로 캐시에 포함된 문서는 수백만 개에 달합니다. 반면 네트워크의 대역폭은 협소합니다. 위와 같은 이유로 대부분의 캐시는 클라이언트에 의해 요청을 받은 경우나 재확인이 필요할 만큼 사본이 오래된 경우에만 유효성을 검증합니다.

• 이번 챕터에서는 최신성을 검사하는 HTTP의 규칙을 설명할 것입니다.

When a cache needs to revalidate a cached copy, it sends a small revalidation request to the origin server. If the content hasn’t changed, the server responds with a tiny 304 Not Modified response. As soon as the cache learns the copy is still valid, it marks the copy temporarily fresh again and serves the copy to the client (Figure 7-5a). This is called a revalidate hit or a slow hit. It’s slower than a pure cache hit, because it does need to check with the origin server, but it’s faster than a cache miss, because no object data is retrieved from the server.

• 저장된 사본을 재검증해야 하는 경우, 캐시는 작은 크기의 재검증 요청을 origin 서버에 전송합니다.

• 만약 콘텐츠가 변하지 않았다면 서버는 작은 크기의 304 Not Modified 응답을 반환할 것입니다.

• 캐시는 사본이 여전히 유효하다는 것을 확인하면 사본을 일시적으로 최신인 것으로 표시하고 클라이언트에게 사본을 반환합니다. (Figure 7-5a)

• 이것을 revalidate hit 혹은 slow hit이라고 합니다.

• revalidate hit은 origin 서버에 확인 요청을 전송하는 과정이 필요하므로 순수한 cache hit에 비해 느립니다.

• 하지만 서버로부터 객체가 반환되는 cache miss에 비해서는 빠릅니다.

HTTP gives us a few tools to revalidate cached objects, but the most popular is the If-Modified-Since header. When added to a GET request, this header tells the server to send the object only if it has been modified since the time the copy was cached.

• HTTP는 저장된 객체를 재검증하기 위한 몇 가지 도구를 제공하고 있습니다. 그 중 가장 잘 알려진 것은 If-Modified-Since 헤더입니다.

• GET 요청에 이 헤더를 추가하면 사본이 캐싱된 시점 이후에 수정된 객체에 한해서만 전송할 것을 서버에 요구할 수 있습니다.

Here is what happens when a GET If-Modified-Since request arrives at the server in three circumstances—when the server content is not modified, when the server content has been changed, and when the object on the server is deleted:

• GET If-Modified-Since 요청이 서버에 도착했을 때 발생할 수 있는 세 가지 상황은 다음과 같습니다.
  • 서버 콘텐츠가 수정되지 않은 경우
  • 서버 콘텐츠가 수정된 경우
  • 서버에서 콘텐츠가 삭제된 경우

Revalidate hit

If the server object isn’t modified, the server sends the client a small HTTP 304 Not Modified response. This is depicted in Figure 7-6.

• 만약 서버 콘텐츠가 수정되지 않았다면, 서버는 클라이언트에게 크기가 작은 HTTP 304 Not Modified 응답을 반환합니다.

• 이는 Figure 7-6에 나타납니다.

Revalidate miss

If the server object is different from the cached copy, the server sends the client a normal HTTP 200 OK response, with the full content.

• 만약 서버 콘텐츠가 캐싱된 사본과 다르다면, 서버는 전체 콘텐츠를 포함하여 클라이언트에게 일반적인 HTTP 200 OK 응답을 반환합니다.

Object deleted

If the server object has been deleted, the server sends back a 404 Not Found response, and the cache deletes its copy.

• 만약 서버 콘텐츠가 삭제되었다면, 서버는 404 Not Found 응답을 반환하고 캐시에서 사본을 삭제합니다.

---

Hit Rate

The fraction of requests that are served from cache is called the cache hit rate (or cache hit ratio),* or sometimes the document hit rate (or document hit ratio). The hit rate ranges from 0 to 1 but is often described as a percentage, where 0% means that every request was a miss (had to get the document across the network), and 100% means every request was a hit (had a copy in the cache).†

• 캐시로부터 제공되는 요청의 비율을 cache hit rate(cache hit ratio) 혹은 document hit rate(document hit ratio)라고 부릅니다.

• hit rate의 범위는 0부터 1까지지만 종종 퍼센트로 나타내는 경우가 있습니다. 0%는 모든 요청이 miss(네트워크를 통해 문서를 가져와야 함)임을 의미하고, 100%는 모든 요청이 hit(캐시에 사본이 존재함)임을 의미합니다.

Cache administrators would like the cache hit rate to approach 100%. The actual hit rate you get depends on how big your cache is, how similar the interests of the cache users are, how frequently the cached data is changing or personalized, and how the caches are configured. Hit rate is notoriously difficult to predict, but a hit rate of 40% is decent for a modest web cache today. The nice thing about caches is that even a modest-sized cache may contain enough popular documents to significantly improve performance and reduce traffic. Caches work hard to ensure that useful content stays in the cache.

• 캐시 관리자는 캐시의 hit rate가 100%에 가까워지는 것을 목표로 합니다.

• 실제 hit rate는 캐시의 용량이 얼마나 거대한지, 캐시 사용자의 관심사와 얼마나 유사한지, 캐싱된 데이터가 얼마나 자주 바뀌고 개인화되는지, 캐시가 어떻게 구성되는지에 따라 다릅니다.

• hit rate를 예측하는 것은 너무나도 어려운 일이지만, 오늘날 일반적인 웹 캐시에서는 hit rate가 40% 정도 되면 적당하다고 여깁니다.

• 캐시의 장점은 적당한 사이즈의 캐시가 인기 있는 문서를 충분히 포함하여 성능을 향상시키고 트래픽을 줄이는 데 있습니다.

• 캐시는 유용한 콘텐츠가 캐시 내부에서 계속 관리되도록 하기 위해 최선을 다합니다.

---

Byte Hit Rate

Document hit rate doesn’t tell the whole story, though, because documents are not all the same size. Some large objects might be accessed less often but contribute more to overall data traffic, because of their size. For this reason, some people prefer the byte hit rate metric (especially those folks who are billed for each byte of traffic!).

• 그러나 document hit rate만으로는 전체를 이해할 수 없습니다. 문서의 크기가 모두 다 똑같은 것은 아니기 때문입니다.

• 일부 거대한 콘텐츠들은 자주 접근되지 않더라도, 크기 때문에 전체 데이터 트래픽에 더 많이 기여할 수 있습니다.

• 이러한 이유로 어떤 사람들은 byte hit rate 지표를 더 선호합니다. 특히 트래픽의 바이트 단위로 비용을 지불하는 사람들이 그렇습니다.

The byte hit rate represents the fraction of all bytes transferred that were served from cache. This metric captures the degree of traffic savings. A byte hit rate of 100% means every byte came from the cache, and no traffic went out across the Internet.

• byte hit rate는 캐시에서 전달되는 모든 바이트의 비율을 나타냅니다.

• 해당 지표는 트래픽 절약 정도를 파악합니다.

• byte hit rate가 100%라는 것은 모든 바이트가 캐시로부터 도착했으며, 어떠한 트래픽도 인터넷을 통해 외부로 나가지 않았다는 뜻입니다.

Document hit rate and byte hit rate are both useful gauges of cache performance. Document hit rate describes how many web transactions are kept off the outgoing network. Because transactions have a fixed time component that can often be large (setting up a TCP connection to a server, for example), improving the document hit rate will optimize for overall latency (delay) reduction. Byte hit rate describes how many bytes are kept off the Internet. Improving the byte hit rate will optimize for bandwidth savings.

• document hit rate와 byte hit rate는 모두 캐시의 성능을 측정하는 유용한 지표입니다.

• document hit rate는 외부 네트워크로 향하는 웹 트랜잭션이 얼마나 많이 줄어들었는지를 나타냅니다.

• 트랜잭션은 고정 시간 요소를 필요로 하기 때문에(ex. TCP 연결 설정) 크기가 클 수 있습니다. 그러므로 document hit rate를 향상시켜 전체적인 지연 시간을 감소시킬 수 있습니다.

• byte hit rate는 얼마나 많은 바이트가 인터넷에서 유지되는지를 나타냅니다.

• byte hit rate을 향상시킨다는 것은 대역폭 절약을 통해 최적화를 수행함을 의미합니다.

---

Distinguishing Hits and Misses

Unfortunately, HTTP provides no way for a client to tell if a response was a cache hit or an origin server access. In both cases, the response code will be 200 OK, indicating that the response has a body. Some commercial proxy caches attach additional information to Via headers to describe what happened in the cache.

• 안타깝게도 HTTP는 응답이 cache hit인지 origin 서버로부터 온 것인지 클라이언트에게 전달할 방법이 없습니다.

• 두 경우 모두 응답 코드는 body를 가지고 있음을 나타내는 200 OK일 것입니다.

• 일부 상용 프록시 캐시는 Via 헤더를 통해 캐시에서 발생한 일을 설명하는 추가 정보를 덧붙입니다.

One way that a client can usually detect if the response came from a cache is to use the Date header. By comparing the value of the Date header in the response to the current time, a client can often detect a cached response by its older date value. Another way a client can detect a cached response is the Age header, which tells how old the response is (see “Age” in Appendix C).

• 일반적으로 클라이언트가 응답이 캐시로부터 왔는지 알 수 있는 방법은 Date 헤더를 사용하는 것입니다.

• 클라이언트는 응답의 Date 헤더 값을 현재 시간과 비교하여 더 오래된 날짜 값으로 캐싱된 응답을 감지할 수 있습니다.

• 클라이언트가 캐싱된 응답을 감지하는 또다른 방법은 Age 헤더를 사용하는 것입니다. 이 헤더는 응답이 얼마나 오래되었는지를 나타냅니다. (Appendix C의 "Age" 참고)

---

🧡 요약 정리 🧡

Hits and Misses

• Hit : 캐시로부터 원본 콘텐츠의 사본을 제공받는 것
• Miss : origin 서버로부터 콘텐츠를 제공받는 것
• 클라이언트는 Age 헤더나 Date 헤더를 통해 Hit or Miss 여부 확인

Revalidations

• 필요성 : origin 서버의 콘텐츠가 변경된 경우 캐시에도 반영되어야 함

• Revalidate Hit : 캐시가 서버로부터 304 Not Modified 응답을 돌려받은 경우 클라이언트에게 사본을 반환하는 것

  • 순수한 Cache Hit에 비해 느림
  • Cache Miss에 비해 빠름

• Revalidate Miss : 서버 콘텐츠가 변경된 경우 서버가 클라이언트에게 일반적인 200 OK 응답을 반환하는 것

  • (cf) 서버 콘텐츠가 삭제된 경우 -> 서버가 클라이언트에게 404 Not Found 응답을 반환

Hit Rate

• Cache Hit Rate (Document Hit Rate)

  • 캐시로부터 제공되는 요청의 비율
  • Cache Hit Rate가 클수록 외부로 향하는 웹 트랜잭션이 많이 이루어지지 않음
  • Cache Hit Rate가 클수록 TCP 연결 설정 등으로 인한 전체 지연 시간 감소
  • 오늘날 일반적인 웹 캐시에서 40% 정도가 이상적

• Byte Hit Rate

  • 캐시로부터 제공되는 바이트의 비율
  • Byte Hit Rate가 클수록 외부로 트래픽이 많이 나가지 않음
  • Byte Hit Rate가 클수록 대역폭을 절약할 수 있음

---

💛 감상 💛

• 오늘은 캐시 프록시 서버의 Hit, Miss에 대해 공부했습니다. 전혀 다른 캐시지만 Computer Architecture에서 다루는 캐시와 용어가 비슷해서 이해하기 쉬웠습니다.

• 호기롭게 시작했는데 생각보다 양이 많아서 너무 오래 걸렸네요...! Hit & Miss 부분을 중간에 끊기가 좀 애매해서 그냥 한 번에 다 했더니 엄청나네용 🤣 다음부터는 진짜 2~3페이지만 읽을 겁니다.