(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
Caches can be dedicated to a single user or shared between thousands of users. Dedicated caches are called private caches. Private caches are personal caches, containing popular pages for a single user (Figure7-7a). Shared caches are called public caches. Public caches contain the pages popular in the user community (Figure7-7b).
캐시는 단일 사용자 전용으로 할 수도, 수천 명의 유저들을 대상으로 공유될 수 있습니다.
이때 단일 사용자를 위한 캐시를 Private Cache라고 합니다.
Private Cache는 단일 사용자가 자주 접근하는 페이지를 저장하는 개인적인 캐시입니다. (Figure 7-7a)
Shared Cache는 Public Cache라고도 불립니다.
Public Cache는 특정 사용자 커뮤니티에서 자주 접근되는 페이지들을 포함하고 있습니다. (Figure 7-7b)
Private caches don’t need much horsepower or storage space, so they can be made small and cheap. Web browsers have private caches built right in—most browsers cache popular documents in the disk and memory of your personal computer and allow you to configure the cache size and settings. You also can peek inside the browser caches to see what they contain. For example, with Microsoft Internet Explorer, you can get the cache contents from the Tools➝ Internet Options... dialog box. MSIE calls the cached documents “Temporary Files” and lists them in a file display, along with the associated URLs and document expiration times. You can view Netscape Navigator’s cache contents through the special URL about:cache, which gives you a “Disk Cache statistics” page showing the cache contents.
Private Cache는 스토리지 공간이나 추가적인 처리를 요구하지 않기 때문에 작은 규모로 저렴한 값에 만들어집니다.
웹 브라우저는 내장 Private Cache를 가지고 있습니다.
대부분의 브라우저는 인기 있는 문서들을 PC 내부의 디스크와 메모리에 캐싱하며 캐시 사이즈와 설정을 직접 구성할 수 있게 합니다.
사용자가 브라우저 캐시 내부를 들여다 보고 무엇을 포함하고 있는지 확인할 수도 있습니다.
예를 들어, Microsoft Internet Explorer에서 사용자는 Tools > Internet Options... dialog 박스를 통해 캐싱된 콘텐츠를 확인할 수 있습니다.
MSIE(Microsoft Internet Explorer)는 캐싱된 문서들을 "임시 파일"이라 명명하여 파일 디스플레이에 나열합니다.
여기에 연관된 URL과 문서의 만료 시간도 함께 나열됩니다.
사용자는 about:cache 라는 특수한 URL을 통해 Netscape Navigator의 캐싱 콘텐츠를 볼 수 있습니다.
해당 URL은 캐싱 콘텐츠를 보여주는 "Disk Cache Statistics" 페이지를 사용자에게 제공합니다.
Public caches are special, shared proxy servers called caching proxy servers or, more commonly, proxy caches (proxies were discussed in Chapter6). Proxy caches serve documents from the local cache or contact the server on the user’s behalf. Because a public cache receives accesses from multiple users, it has more opportunity to eliminate redundant traffic.*
Public Cache는 Caching Proxy Servers 혹은 Proxy Cache라고 불리는 특수한 공유 프록시 서버입니다. (Proxy는 Chapter6에서 다루었습니다)
Proxy Cache는 로컬 캐시로부터 문서를 전달하거나 사용자를 대신해 서버에 연결하는 작업을 수행합니다.
Public Cache는 다양한 사용자로가 접근하기 때문에 중복된 트래픽을 제거하기 쉽습니다.
In Figure7-8a, each client redundantly accesses a new, “hot” document (not yet in the private cache). Each private cache fetches the same document, crossing the network multiple times. With a shared, public cache, as in Figure7-8b, the cache needs to fetch the popular object only once, and it uses the shared copy to service all requests, reducing network traffic.
Figure 7-8a에서 각각의 클라이언트는 새롭게 떠오르는 문서에 중복해서 접근합니다. 그러나 이 문서는 아직 Private Cache에 저장되지 않았습니다.
각각의 Private Cache는 네트워크를 통해 여러 번에 걸쳐 동일한 문서를 가져갑니다.
하지만 Figure 7-8b처럼 공유된 Public Cache가 있으면 캐시는 인기 있는 오브젝트를 딱 한 번만 가져가면 됩니다.
Public Cache가 공유된 사본을 모든 요청에 제공하여 네트워크 트래픽을 줄일 수 있습니다.
Proxy caches follow the rules for proxies described in Chapter6. You can configure your browser to use a proxy cache by specifying a manual proxy or by configuring a
proxy auto configuration file (see “Client Proxy Configuration: Manual” in Chapter6). You also can force HTTP requests through caches without configuring your browser by using intercepting proxies (see Chapter20).
Proxy Cache는 Chapter6에서 언급한 프록시 규칙을 따릅니다.
사용자는 브라우저가 수동 프록시를 특정하거나 Proxy Auto Configuration File을 통해 Proxy Cache를 사용하도록 구성할 수 있습니다. (Chapter 6의 Client Proxy Configuration: Manual 참조)
혹은 브라우저를 구성하지 않고도 Intercepting Proxies를 사용하여 HTTP 요청이 캐시를 통과하도록 강제할 수도 있습니다. (Chapter 20 참조)
In practice, it often makes sense to deploy hierarchies of caches, where cache misses in smaller caches are funneled to larger parent caches that service the leftover “distilled” traffic. Figure7-9 shows a two-level cache hierarchy.† The idea is to use small, inexpensive caches near the clients and progressively larger, more powerful caches up the hierarchy to hold documents shared by many users.
실제로는 작은 캐시에서 Cache Miss가 발생하면 남은 "증류된" 트래픽을 더 큰 상위 캐시로 퍼널링하는 캐시 계층 구조를 배포하는 것이 더 합리적일 때가 있습니다.
Figure 7-9는 두 단계의 캐시 계층 구조를 나타냅니다.
작고 저렴한 캐시를 클라이언트 근처에 두고 점진적으로 크고 성능이 좋은 캐시를 배치하여 많은 사용자에게 공유되는 문서를 저장하는 방식입니다.
Hopefully, most users will get cache hits on the nearby, level-1 caches (as shown in Figure7-9a). If not, larger parent caches may be able to handle their requests (Figure7-9b). For deep cache hierarchies it’s possible to go through long chains of caches, but each intervening proxy does impose some performance penalty that can become noticeable as the proxy chain becomes long.*
다행히 대부분의 사용자는 가까운 캐시인 level-1 캐시에서 Cache Hit가 발생합니다. (Figure 7-9a)
만약 Cache Miss가 발생한다면 상위 계층의 캐시가 요청을 처리할 것입니다. (Figure 7-9b)
캐시 계층이 깊게 형성된 경우 긴 캐시 체인을 통과해야 할 수 있습니다.
각각의 Proxy는 체인이 길어질수록 눈에 띄는 성능 저하를 발생시킬 수 있습니다.
Some network architects build complex cache meshes instead of simple cache hierarchies. Proxy caches in cache meshes talk to each other in more sophisticated ways, and make dynamic cache communication decisions, deciding which parent caches to talk to, or deciding to bypass caches entirely and direct themselves to the origin server. Such proxy caches can be described as content routers, because they make routing decisions about how to access, manage, and deliver content.
몇몇 네트워크 설계자들은 단순한 캐시 계층 대신 복잡한 Cache Mesh를 구축합니다.
Cache Mesh 내부의 프록시 캐시들은 보다 정교한 방식으로 서로 통신하고, 동적으로 어떤 상위 캐시와 통신할지, 캐시를 완전히 우회하고 origin server로 직접 연결할지와 같은 통신 의사결정을 내립니다.
이러한 프록시 캐시는 콘텐츠 라우터로 종종 표현됩니다. Cache Mesh 내의 프록시 캐시들은 콘텐츠를 어떻게 접근하고 관리하고 전송할지에 대한 의사결정을 라우팅하기 때문입니다.
Caches designed for content routing within cache meshes may do all of the following (among other things):
- Select between a parent cache or origin server dynamically, based on the URL.
- Select a particular parent cache dynamically, based on the URL.
- Search caches in the local area for a cached copy before going to a parent cache.
- Allow other caches to access portions of their cached content, but do not permit Internet transit through their cache.
These more complex relationships between caches allow different organizations to peer with each other, connecting their caches for mutual benefit. Caches that provide selective peering support are called sibling caches (Figure7-10). Because HTTP doesn’t provide sibling cache support, people have extended HTTP with protocols, such as the Internet Cache Protocol (ICP) and the HyperText Caching Protocol(HTCP). We’ll talk about these protocols in Chapter20.
캐시 사이의 복잡한 관계는 서로 다른 조직이 피어링하여 상호 이익을 위해 조직간의 캐시를 연결할 수 있게 합니다.
이처럼 피어링을 지원하는 캐시를 Sibling Caches라고 합니다. (Figure 7-10)
HTTP는 Sibling Cache를 지원하지 않기 때문에 사람들은 ICP(Internet Cache Protocol)와 HTCP(HyperText Caching Protocol)와 같은 프로토콜이 함께 적용된 extended HTTP를 사용합니다.
해당 프로토콜에 대해서는 Chapter 20에서 다룹니다.
: PC 내부의 디스크와 메모리상에 위치한 Personal Cache
: 여러 사용자가 동시에 접근할 수 있도록 공유된 Proxy Cache
컴퓨터에는 캐시가 참 많다. CPU 안에도 캐시가 있고, CPU랑 램 사이에도 캐시가 있고, 네트워크에도 캐시가 있고... 연산이든 트래픽이든 처리 속도를 빠르게 하기 위해 일단 냅다 캐시부터 갖다 붙이는 것은 컴퓨터쟁이들의 특징인 것 같다. 생각해보면 나도 효율적인 것을 참 좋아한다. 좋아하는 언어 C언어, 최근 관심 있는 것 쿼리 최적화, 아름답다고 생각하는 것 DP 알고리즘~!~!~! 무야호
너무 오랜만에 읽었더니 앞의 내용이 잘 기억이 안 난다. 정리해둔 내용을 차근차근 한 번 읽어봐야겠다. 이럴까봐 게시글마다 내용을 예쁘게 요약해놓았다 😎
프록시 이론만 읽으니 이해도 잘 안 되고 조금 지루한 감이 있어서 프록시 구성을 직접 해보는 것도 재미있을 것 같다. 아직 방법은 잘 모르겠지만 친절한 구글 선생님이 알려줄 것이다..! 나중에 velog에 후기를 남길 생각이다 ^0^
+) 새로운 한 해가 시작되었으니(이미 시작한 지 6일이나 지났지만) 오늘부터 다시 힘차게 달려보겠습니다‼️‼️