1、（第 10 章）譯者序：本人在工作中著數臺 Squid 服務器，多次參閱 Duane We人）的這本書，原書名是Squid: The Definitive Guide，由 OReillys（他也是 Squid 的創(chuàng)始。我在業(yè)余時間把它翻譯成中文，希望對中文 Squid 用戶有所幫助。對普通的上網用戶，Squid 可充當代理服務器；而對 Sina,NetEase 這樣的大型站點，Squid 又充當 WEB。這兩個角色它都扮演得異常優(yōu)秀。窗外繁星點點，開源的世界亦如這星空般美麗，而 Squid 是其中耀眼的一顆星。對本譯版有任何問題，請跟我的是：目 錄與其他Squid會話2某些術語2為何要（或不要

2、）使用堆疊？2配置Squid與鄰居通信3cache_peer選項4鄰居狀態(tài)6改變關系7對鄰居的請求限制7第 10 章10.4cache_peer_accache_peer_s8. 8never_direct9always_direct9hierarchy_stoplist10nonhierarchical_direct10prefer_direct10網絡度量數據庫（netdb）11ernet Cache協(xié)議（ICP）1310.510.6.210.6.3成為ICP服務器13成為ICP客戶16廣播ICP18Cache摘要(Cache Digest)20

3、配置squid的cache摘要20超文本cache協(xié)議（HTCP）21配置Squid使用HTCP22Cache數組路由協(xié)議(CARP)23配置Squid使用CARP24歸納所有2510.10.410.10.5步驟 1：直接決定選項25步驟 2：鄰居選擇協(xié)議25步驟 2a:ICP/HTCP應答處理26步驟 3：從父cache選擇27重試2810.11 該怎么做？2810.11.4通過另外的通過另外的發(fā)送所有請求？28發(fā)送所有請求，除非它down了？28確認squid對某些請求，不使用鄰居cache嗎？29通過父c

4、ache發(fā)送某些請求來繞過本地過濾器？291第 10 章 與其他 Squid 會話10.1 某些術語通常把一組互相轉發(fā)請求的 cache（或做鄰居或對等伙伴。）叫做 cache 堆疊。把 cache 堆疊的成員叫鄰居 cache 有 2 種關系：父子或姐妹。從拓撲上看，父 cache 在堆疊里位于頂層，而姐妹 cache 位于同一層。兩者真正的不同在于，父 cache 能為子 cache 轉發(fā) cache 丟失，然而姐妹 cache 之間不允許轉發(fā) cache 丟失。這意味著，在發(fā)送請求到姐妹 cache 前，發(fā)起者應該知道這是個 cache 命中。類似于 ICP,HTCP 和 Cache D

5、igests 之類的堆疊協(xié)議，能預知鄰居的 cache 命中。然而 CARP 不能這樣。某些時候，cache 堆疊并非真正層次性的。例如，考慮 1 組 5 個姐妹 cache。因為它們沒有父子關系，故而不存在上或下。在這種情況下，你可以叫它 cache 結網，或甚至 cache 編隊，而不是堆疊。10.2 為何要（或不要）使用堆疊？鄰居 cache 通過提供某些額外的 cache 命中而改進了執(zhí)行性能。換句話說，某些請求的cache 丟失，在鄰居 cache 里可能會命中。假如你的 cache 從鄰居 cache 里這些命中，比從原始服務器快，那 cache 堆疊可全面改善性能。是鄰居 cac

6、he 能提供一小部分的請求命中。大約 5%或 10%（假如幸運的話）的 cache 丟失請求，會在鄰居 cache 中命中。在某些情況下，這點小作用價值不高。然而有的情形下，例如網絡連接不盡人意時，cache 堆疊非常明顯的改進了終端用戶的性能。假如在有的網絡中使用 squid，就有必要配置作為父。在該情形中，squid 轉發(fā)每個請求到，因為它不直接連接到外部原始服務器。假某些原始服務器在里面，就可以配置 squid 直接連接到它們。也可以使用堆疊來在不同方向上傳送 web 數據。這點有時候叫做應用層路由，或更近的叫法：內容路由。例如，考慮某個大公司，它有 2 個ernet 連接。也許第二個連

7、接比第一個成本更低。該公司可能想利用第二個連接作為次優(yōu)先性傳輸，例如頻，或其他形式的大文件傳輸。或者，也許他們想利用某條鏈路進行 HTTP、音頻或視，而在另一條鏈進行非 HTTP。再或者，也許某些用戶的數據通過低優(yōu)先級鏈路傳輸，而用戶的數據通過更貴的鏈路傳輸。可以使用 cache堆疊來完成上述設想。信任機制對 cache 堆疊來說，是最重要的。你必須信任鄰居 cache 會服務正確的、未修改的響應。必須在敏感信息上信任它們，例如用戶請求的 URI。它們會一個安全的，不斷更新的系統(tǒng)，將未和服務的機會降至最低。2關于堆疊的另一個問題，在于它們正常錯誤的途徑。當鄰居 cache 經歷了某個錯誤，例如

8、服務不可到達，它產生一個 HTML 頁面來解釋該錯誤及錯誤。假如鄰居 cache 位于公司之外，它返回錯誤時，用戶會覺得迷惑。假如該問題繼續(xù)，用戶將很難找到幫它們解決問題的管理員。姐妹關系也有一個已知，叫做假命中。假如 squid 發(fā)送某個請求到它的姐妹，它認為這是個 cache 命中，然而它的姐妹沒有聯系過原始服務器，因此不能滿足該請求，這時就會發(fā)生假命中。有很多情況導致假命中，但通常可能性很低。甚至，squid 和其他 HTTP有自動重新請求假命中的功能，不會讓用戶感覺到已發(fā)生。轉發(fā)循環(huán)有時候是 cache 堆疊的另一個問題。當 squid 轉發(fā)某個請求到某處，但該請求又被轉發(fā)回 squi

9、d，這就發(fā)生了轉發(fā)循環(huán)。請見圖 10-1（略圖）。轉發(fā)循環(huán)典型的發(fā)生在 2 個 cache 互相把對方當作父 cache 的情況。假如你遇到這樣的問題，請確認使用 cache_peer_acs 指令來這類循環(huán)。例如，假如鄰居 cache 的 IP 地址是 ，下面的行讓 squid 不會產生轉發(fā)循環(huán)：acl FromNeighbor src cache_peer_acs deny FromNeighbor轉發(fā)循環(huán)在 HTTP路徑上時。里也能發(fā)生，特別是當設備位于 squid 和原始服務器之間的Squid 通過檢查 Via 頭部里的主機名，來檢測轉發(fā)循環(huán)。假如 2 個協(xié)作 cache 有相同的主機

10、名，實際上就會得到假轉發(fā)循環(huán)。在該情形下，unique_hostname 指令很有用。注意，假如 Via 頭部被過濾掉了（例如使用 headers_acs 指令），squid 就不能檢測到轉發(fā)循環(huán)。10.3 配置 Squid 與鄰居通信cache_peer 指令定義鄰居 cache，并告訴 squid 如何與它的鄰居通信：cache_peer hostname type http-port icp-port options第 1 個參數是鄰居的主機名，或 IP 地址。可以安全的在這里使用主機名，因為 squid 會解析它們。在 squid 運行期間，主機名對應的 IP 地址可能會改變，所以實際

11、上 squid 會周期性的主機名。鄰居主機名必須唯一：不能在 2 個鄰居 cache 上使用同樣的主機名，即使它們有不同的端口。第 2 個參數指定鄰居 cache 的類型。有 3 個選擇：父親，姐妹，或廣播。父親和姐妹關系容易理解。我在 10.6.3 節(jié)里會詳細談到廣播。第 3 個參數是鄰居 HTTP 端。它應該等同于鄰居的 http_port 設置。總是應該指定 1 個3非零的 HTTP 端。第 4 個參數指定ICP 或HTCP 端。squid 默認使用 ICP 來查詢其他cache。也就是說，squid發(fā)送 ICP 查詢到鄰居 cache 的指定端口。假如你增加了 htcp 選項，squi

12、d 就會發(fā)送 HTCP 查詢到這個端口。默認的 ICP 端口是 3130，默認的 HTCP 端口是 4827。假如增加了 htcp 選項，。將端設為 0，會ICP 和 HTCP。然而，應該使用 no-query請記得改變它的端選項來這些協(xié)議。10.3.1 cache_peer 選項cache_peer 指令有很多選項。我在這里描述其中的一些，其他的參數在與之相關的協(xié)議的章節(jié)里有描述。proxy-only該選項指示 squid 不它接受自鄰居的任何響應。如果你有 cache 集群，并且不希望資源在多個 cache 上，那么該選項有用。weight=n該選項指定給 ICP/HTCP。請見 章節(jié)。t

13、tl=n該選項指定給廣播 ICP。見 10.6.3 節(jié)。no-query該選項指定給 ICP/HTCP。見 節(jié)。default在缺少其他線索時，該選項指定鄰居 cache 作為適當的選擇。正常情況下，squid 將 cache丟失轉發(fā)給父 cache，父 cache 看起來有特定資源的緩存拷貝。有時候 squid 沒有任何線索（例如使用 no-query 禁用了 ICP/HTCP），這時 squid 會尋找父 cache，并將其作為默認選擇。round-robin該選項是簡單的負載共享技術。僅僅當你指定了 2 個或多個父 cache 作為輪轉時，它才有用。 squid 對每個父 cache 維

14、持一個計數器。當需要轉發(fā) cache 丟失時，squid 選擇計數器值最低的父 cache。multicast-responder該選項指定給廣播 ICP。見 10.6.3 節(jié)。closest-only該選項指定給 ICP/HTCP。見 節(jié)。no-digest該選項指定給 cache digest，見 10.7 章。4no-netdb-exchange該選項告訴 squid，不要請求鄰居 cache 的 netdb 數據庫（見 10.5 節(jié)）。nay該選項告訴 squid，忽略任何對鄰居 cache 請求的延遲池設置。見附錄 C 關于延遲池的信息。login= credentials該選項指示

15、 squid 發(fā)送 HTTP 驗證信息到鄰居 cache。它有 3 個不同的格式：login =usassword這是最通用的形式。它導致 squid 在每個到鄰居 cache 的請求里，增加相同的用戶名和用戶無須填寫任何驗證信息。login=PASS將值設為 PASS，導致 squid 讓用戶的驗證信息直接 pass 到鄰居 cache。它僅僅工作在 HTTP基礎的驗證機制下。squid 不會增加或修改任何驗證信息。假如 squid 被配置成需要驗證（例如使用 proxy_auCL），鄰居 cache 就必須使用同樣的用戶名和數據庫。換句話說，應該只在被同一組織擁有和操作的一組 cache

16、中使用PASS 形式。該功能是的，因為 squid 不會從轉發(fā)請求里移除驗證信息。login =* :password使用該形式，squid 改變它轉發(fā)的請求里的，但不改變用戶名。它允許鄰居 cache 來驗證獨立的用戶，但不其。該形式比使用 PASS少一些，但確實有一些隱私牽連。使用該功能需要額外。即使你不管隱私條目，該功能也可能對產生不良的副作用。例如，我知道至少 1 個其他的 cache 產品，它僅僅查看持續(xù)連接里第一個請求的信用信息。它看起來（不正確的）假設在單個連接里的所有請求，都來自同一用戶。connect-timeout= n該選項指定，在 squid 建立 TCP 連接到鄰居

17、cache 時，等待的超時時間。若沒有該選項，超時值就取自全局 connect_timeout 指令，它的默認值是 120 秒。使用低的超時值，squid速放棄到鄰居 cache 的會話，并且試著發(fā)送請求到其他鄰居 cache，或直接請求原始服務器。digest-url= url該選項指定給 cache digest。見 10.7 章。allow-miss該選項指示 squid 忽略 Cache-Control: only-if-cached 指令，該指令是針對發(fā)送給姐妹 cache的請求的。僅在如下情況下使用它：鄰居 cache 激活了 icp_hit_stale 指令，并且沒有使用miss

18、_acs 列表。5max-conn= n該選項對 squid 打開到鄰居 cache 的同時連接的數量進行限制。當抵達了該限制時，squid 從它的選擇算法里排除掉該鄰居 cache。htcp該選項指定鄰居 cache 為 HTCP 服務器。換句話說，squid 發(fā)送 HTCP 查詢，而不是 ICP 查詢，到鄰居 cache。注意 squid 不會在同一端口上接受 ICP 和 HTCP 查詢。若你增加了該選了改變 icp-port 的值。見 10.8.1 節(jié)。HTCP 支持需要在運行./configure 時，使用項，-enable-htcp 選項。carp-load-factor= f該選項

19、讓鄰居 cache（它必須是父 cache）成為 CARP 的成員。對所有父 cache 的 f 值的總和，必須等于1。我在10.9講到CARP。CARP 支持需要在運行./configure 時，使用-enable-carp選項。10.3.2 鄰居狀態(tài)Squid 對其每個鄰居 cache，維持著多種統(tǒng)計和狀態(tài)信息。最重要的信息之一，是其鄰居 cache的存活狀態(tài)。鄰居 cache 的存活/狀態(tài)影響了 squid 選擇算法的許多方面。確定鄰居 cache的存活/狀態(tài)的機制有點復雜，所以我在這里不講它。假如你想通過閱讀源代碼來了解這點，請查看 neighborUp()函數。Squid 使用 TC

20、P(HTTP)和 UDP(ICP/HTCP)通訊來確定鄰居 cache 的狀態(tài)。TCP 狀態(tài)默認是存活的，但如果連續(xù) 10 個 TCP 連接失敗，狀態(tài)會改變?yōu)椤Ｈ绻l(fā)生這種事，squid 會發(fā)起探查連接，在每個 connect_timeout 期間內（全局指令，并非 cache_peer 選項），連接不會超過 1 次。鄰居 cache 會保持狀態(tài)，直到探查連接之一成功。假如 no-query 選項沒有設置（意味著 squid 正發(fā)送 ICP/HTCP 查詢到鄰居 cache），UDP 層通訊也參與到存活/算法里來。UDP 狀態(tài)默認是存活的，但假如 squid 在超時范圍內（dead_peer_

21、timeout 指令的值），沒有接受到任何 ICP/HTCP 響應，UDP 狀態(tài)就會改變?yōu)樗劳觥＜偃玎従?cache 的主機名不可，squid 也會將其標記為。當 squid 確定其鄰居 cache時，它在 cache.log 里增加類似如下的日志：2003/09/29 01:13:46| Detected DEAD Sibling: /3128/3130當與鄰居 cache 的通信重新建立起來時，squid類似如下的日志：2003/09/29 01:13:49| Detected REVIVED Sibling: /3128/3130鄰居 cache 的狀態(tài)，在下述幾個方面影響鄰居選擇算法：

22、1)Squid 不希望接受來自鄰居的ICP/HTCP 響應。squid 在每個 dead_peer_timeout 期間內，6只發(fā)送 1 次 ICP 查詢到的鄰居。見附錄 A。2)的父 cache 從下列算法里排除掉:Digests, round-robin parent,up parent, defaultparent, 和 closest parent。3)CARP 特殊：任何失敗的 TCP 連接，會從 CARP 算法里排除掉父 cache。沒有辦法強迫squid 發(fā)送HTTP 請求到的鄰居cache。假如所有的鄰居cache 都，squid會試圖連接到原始服務器。假如你不允許 squid

23、 與原始服務器會話（使用 never_direct 指令），squid 會返回 cannot forward 的錯誤消息：This reqould not be forwarded to the origin server or to anyparent caches.The most likely cause for this error ist:The cache administrator does not allow this cache to make direct connections to origin servers, andAll configured parent cac

24、hes are currently unreachable10.3.3 改變關系neighbor_type_指令允許你改變與基于原始服務器主機名的鄰居 cache 的關系。假如鄰居 cache 期望服務任何請求的 cache 命中，但僅僅服務某些個指令就很有用。語法是：域的 cache 丟失，那么這neighbor_type_ relationship !.例如：cache_peer sibling 3128 3130neighbor_type_ parent .uk當然，該示例里的 緩存，會利用相應的 miss_acs 規(guī)則來強迫姐妹關系給 non-UK 請求。注意會按照 章節(jié)里描述的那樣，

25、匹配主機名。10.4 對鄰居的請求限制許多使用 cache 堆疊的用戶，想控制或限制 squid 發(fā)送到鄰居 cache 的請求。squid 有 7 個不同的指令 可以影響 請求路由 ： cache_peer_acs, cache_peer_always_direct, hierarchy_stoplist,nonhierarchical_direct, 和 prefer_direct。, never_direct,710.4.1 cache_peer_acscache_peer_acs 指令定義對鄰居 cache 的列表。也就是說，它決定哪個請求允許或不允許發(fā)送到鄰居 cache。例如，可以

26、使用這點來對 FTP 和 HTTP 請求進行分流。你可以發(fā)送所有的 FTP URI 到某個父 cache，所有的 HTTP URI 到另一個父 cache：cache_peer A-parent.my. cache_peer B-parent.my. acl FTP proto FTPacl HTTP proto HTTPparent 3128 3130parent 3128 3130cache_peer_accache_peer_acs A-parent allow FTPs B-parent allow HTTP改配置確保父 cache A 僅接受 FTP URI 請求，而父 cache

27、B 僅接受 HTTP URI 請求。當然也包括 ICP/HTCP 請求。也可以使用 cache_peer_acs，在一天中的某段時間來激活或鄰居 cache：cache_peer A-parent.my.parent 3128 3130acl DayTime time 07:00-18:00cache_peer_acs A-parent.my.deny DayTime10.4.2 cache_peer_cache_peer_指令是 cache_peer_acs 指令的早期形式。相對于使用完整的控制特性，它僅使用 URI 里的。它常用于通過區(qū)分一組父 cache。例如，假如你有一個遍布全球的網，

28、你也許想發(fā)送請求到位于各自大陸的 cache：cache_peer europe-cache.my. cache_peer asia-cache.my. cache_peer aust-cache.my. cache_peer africa-cache.my. cache_peer na-cache.my.cache_peer sa-cache.my.parent 3128 3130parent 3128 3130parent 3128 3130parent 3128 3130parent 3128 313parent 3128 3130cache_peer_ cache_peer_ cach

29、e_peer_ cache_peer_cache_peer_europe-cache.my. asia-cache.my. aust-cache.my.africa-cache.my.parent .ch .dk .fr .uk .nl .de .fi .parentparent.jp .kr .cn .sg .tw .vn .hk .nz .au .aq .parent .dz .ly .ke .mz .ma .mg .na-cache.my.parent.mx .ca .us .8cache_peer_sa-cache.my.parent.br .cl .ar .co .ve .當然，該機

30、制不匹配流行的全球頂級，例如.com。10.4.3 never_directnever_direct 指令是對從來不必直接發(fā)送到原始服務器的請求的問列表，它必須被發(fā)送到鄰居 cache（通常是父 cache）。列表。當請求匹配該訪例如，假如 squid 位于之后，它也許能夠直接與服務器會話，但必須通過（父 cache）發(fā)送所有的請求到外部服務器。你可以告訴 squid：“永不要直接連到防火墻之外的站點”。為了做到這點，請告訴 squid在之內：aclernalSites dst.my.never_direct allow !ernalSites語法有點奇怪。never_direct allow

31、 foo 意味著 squid 不會直接放過匹配 foo 的請求。既然站點容易指定，我使用否操作符(!)來匹配外部站點，這些站點 squid 不會直接聯系。注意該示例不會強迫 squid 直接連接到匹配ernalSites ACL 的站點。never_direct規(guī)則僅僅強迫 squid 不直接聯系某些原始服務器。你必須使用 always_direct 規(guī)則來強迫直接連接到原始服務器。在結合其他控制請求路由的指令來使用 never_direct 時，必須謹慎。可能很容易就建立一件不可能做到的事件。如下是個示例：cache_peer A-parent.my.parent 3128 3130acl

32、COM dstcache_peer_s A-parent.my.deny COMnever_direct allow COM該配置自相，因為任何以.com 結尾的請求必須通過鄰居 cache。然而僅僅定義了一個鄰居 cache，并且不允許.com 請求通過它。若發(fā)生這種情況，squid 會發(fā)布“cannot forward”的錯誤消息。10.4.4 always_direct也許你已猜到，always_direct 規(guī)則列表告訴 squid 某些請求必須直接轉發(fā)到原始服務器。例如，許多想保持他們的內網通信本地化。容易做到的方法是，定義基于 IP 地址的 ACL，并將它放入 always_dir

33、ect 規(guī)則列表：acl OurNetwork src /24always_direct allow OurNetwork910.4.5 hierarchy_stoplistSquid 內在的將每個客戶端請求標記為層疊或不可層疊。不可層疊的請求看起來不會導致cache 命中。例如，T 請求的響應幾乎從不會被 cache。在 squid 能簡單的連接到原始服務器時，轉發(fā)不可 cache 目標的請求到鄰居 cache，純粹是浪費資源。某些區(qū)分層疊和不可層疊請求的規(guī)則，在 squid 里難于編碼。例如，T 和 PUT 方式總是不可層疊的。然而，hierarchy_stoplist 指令允許你定制這種

34、算法。它包含一個字符串列表，當在 URI 里發(fā)現它們時，squid 將請求標記為不可層疊。默認的該列表是：hierarchy_stoplist ? cgi-bin這樣，任何包含問號或 cgi-bin 字符串的請求匹配該列表，變成不可層疊。默認的，squid 直接發(fā)送不可層疊的請求到原始服務器。因為這些請求不會導致 cache 命中，它們通常是鄰居 cache 的額外負擔。然而，never_direct規(guī)則之上。具體而言，squid 這樣做：控制規(guī)則凌駕于 hierarchy_stoplist從不對不可層疊的請求發(fā)送 ICP/HTCP 查詢，除非該請求匹配 never_direct 規(guī)則；從不對

35、不可層疊的請求發(fā)送 ICP/HTCP 查詢到姐妹 cache； 3)從不對不可層疊的請求查詢鄰居的 cache digest。10.4.6 nonhierarchical_direct該指令控制 squid 轉發(fā)不可層疊的請求的方法。squid 默認直接發(fā)送不可層疊的請求到原始服務器。這是因為這些請求不會導致 cache 命中。我覺得直接從原始服務器獲取它們總是好的，而不要浪費時間在鄰居 cache 上查詢它們。假如因為某些理由，你想路由這些請求通過鄰居 cache，請該指令：nonhierarchical_direct off10.4.7 prefer_direct該指令控制 squid 轉

36、發(fā)層疊請求的方法。默認的，squid 首先發(fā)送這樣的請求到鄰居 cache，然后再到原始服務器。通過激活該指令，你能反轉這種行為：prefer_direct on這樣，假如 squid 與原始服務器的通信失敗，鄰居 cache 就變成了備份。1010.5 網絡度量數據庫（netdb）Squid 的網絡度量數據庫（netdb）被設計來測量到原始服務器的遠近。換句話說，通過查詢該數據庫，squid 知道它離原始服務器有多遠。該數據庫包含 ICMP 往返時間（RTT）測量值和路由跳計數。正常情況下，squid 僅使用 RTT 測量值，但在某些情形下也使用路由跳計數。為了激活 netdb，必須使用-e

37、nable-icmp 選項來配置 squid。也必須以超級用戶權限來安裝er 程序，請見 3.6 章的描述。當運行正確后，可以在 cache.log 里見到類似如下的消息：2003/09/29 00:01:03|er socket opened on FD 28當激活了 nebdb 時，squid 發(fā)送 ICMP到原始服務器。ICMP 消息實際上由er 程序來發(fā)送和接受，er 以 root 運行。squid 會的不至于頻繁發(fā)送消息，以避免騷擾web 站點管理員。默認的，squid 在發(fā)送另一個到同一主機，或同一 24 位子網中主機時，會至少等待 5 分鐘。可以使用 netdb_period 指

38、令來調整這個時間間隙。ICMP消息通常非常小（少于 100 字節(jié)）。squid 在 ICMP 消息的有效載荷里包含了原始服務器的主機名，緊跟一個時間戳。為了減少內存需求，squid 以 24 位子網來合計 netdb 數據。squid 假設所有位于同一 24 位子網里的主機，有相似的 RTT 和路由跳計數。若某臺新的原始主機所在子網的其他主機已被測量過，該機制也允許 squid 去估算這臺新原始主機的遠近。隨同 RTT 和路由跳計數，squid 也似如下：著一份主機名結合子網的列表。典型的看起來類Subnet RTT76.5Hops20.0Hostsservi1.ieee.rgnetdb 度量

39、值主要被 ICP 和 HTCP 使用。當你在 squid.conf 里激活 query_icmp 指令時，squid在發(fā)送到鄰居 cache 的 ICP/HTCP 查詢里設置一個標記。該標記請求在 ICP/HTCP 響應里包含遠近測量值。假如鄰居 cache 也激活了 netdb，它們的響應將包含 RTT 和路由跳計數（假如可用）。注意 squid 總是立刻響應 ICP。在響應 ICP 查詢前，它不會等待 ICMP 測量。見 節(jié)關于 ICP 如何使用 netdb 的細節(jié)。11Squid 會記住它從 ICP/HTCP 響應里學到的 RTT 值。這些值在隨后的決定最佳轉發(fā)途徑時，也許會用到。通過叫

40、做 netdb 交換的機制，squid 也支持 netdb 度量值的批量遷移。squid 周期性的通過 HTTP 請求鄰居 cache 的 netdb 數據。在 cache_peer 行里設置 no-netdb-exchange選項，就可以這些請求。netdb_low 和netdb_high 指令控制度量數據庫的大小。當squid 刪除最少近來使用的條目，直到數量低于 netdb_low。子網的數量抵達 netdb_high 時，minimum_direct_hops 和 minimum_direct_rtt 指令指示 squid 直接連接到低于一定數量路由跳計數，或少于一定毫秒的原始服務器。

41、匹配該標準的請求在 acCLOSEST_DIRECT 形式記載。s.log 里以 cache 管理器的 netdb 頁顯示完整的網絡度量數據庫，包括來自鄰居 cache 的值。例如：Network DB Sistics:Networkrecv/sentRTTHops Hostnames 1/125.021.527.070.09.015.013.011.0 5/525.023.527.735.772.93.0 w 11.07.010.010.0 1/125.013.032.011.055.08.02/225.08.044.014.0 1/125.025.227.069.59.0 i 15.0 1

42、3.011.0這里，你可以見到服務器有一個 IP 地址位于 /24 子網。從 cache到這臺原始服務器的 RTT 值是 25 毫秒。鄰居 cache: 更近一點，在 21.5 毫秒。1210.6ernet Cache 協(xié)議（ICP）ICP 是輕量級的目標定位協(xié)議，它作為 Harvest 項目的一部分而被發(fā)明。ICP 客戶發(fā)送查詢消息到一個或多個ICP 服務器，詢問它們是否緩存了某個URI。每個服務器響應一個ICP_HIT（ICP 命中），ICP_MISS（ICP 丟失），或其他類型的 ICP 消息。ICP 客戶使用 ICP 響應里的信息來做轉發(fā)決定。除了指示 cache 命中，ICP 也用于

43、提供關于 squid 和鄰居 cache 之間網絡條件的線索。從這點看，ICP 消息類似于 ICMP。通過計算查詢/響應往返時間，squid 能估算網絡擁塞情況。在情況下，ICP 消息可能丟失，這意味著兩者之間的鏈路斷掉，或線路擁塞。在這種情況下，squid 會避免請求這個鄰居 cache。增加延時可能是使用 ICP 的最顯然的弊端。查詢/響應交換要花費一些時間。cache被設計來減少響應時間，而不是增加延時。如果 ICP 幫助發(fā)現在鄰居 cache 上的 cache 命中，這樣它應該全面減少響應時間。見 10.10 章關于 squid 的查詢算法實現的描述。ICP 也得承受某些設計帶來的責難

44、：安全性，伸縮性，假命中，和請求方式的缺乏。該協(xié)議不包括任何安全機制。通常 squid 不能確認某個 ICP 消息是的；它依賴于基于地址的控制來過濾掉不想要的 ICP 消息。ICP 的伸縮性也很差。ICP 消息的數量（和帶寬）增長，與鄰居 cache 的數量成正比。除非使用某種機制，這實際上限制了你能使用的鄰居 cache 的數量。我不擁有超過 5 或6 個鄰居 cache。ICP 查詢僅包含 URI，沒有另外的請求頭部。這讓它很難精確的指示 cache 命中。某個 HTTP請求可能包含附加的頭部（例如 Cache-Control: max-stale=N）將 cache 命中轉換為 cach

45、e 丟失。對姐妹關系的 cache 來說，這些假命中的弊端特別明顯。從 ICP 查詢消息里丟失的還有請求方式。ICP 假設所有的查詢采用 GET 請求。cache能使用非 GET 請求方式的 ICP 來查找緩存目標。不通過閱讀如下資料，你可以找到其他的關于 ICP 的信息：1)我寫的書： Web Caching (OReilly)2)RFCs 2186 and 21873)：ICP and the Squid Web Cachehe IEEE Journal on Selected Areas inCommunication, April 19984)10.6.1 成為 ICP 服務器當你使用

46、 icp_port 指令時，squid 自動成為 ICP 服務器。也就是說，它在你指定的端口偵聽ICP 消息，或默認的 3130 端口。假如決定使用非標準端口，別忘了告知姐妹和/或子cache。13squid 默認所有 ICP 查詢。必須使用 icp_acs 規(guī)則列表，允許來自鄰居 cache 的查詢。使用 src ACL 容易做到這點。例如：acl N1 src acl N2 src acl All src 0/0icp_ac icp_acicp_acs allow N1 s allow N2s deny All注意僅僅 ICP_QUERY 消息從屬于 icp_acs 規(guī)則。ICP 客戶端的

47、功能，例如發(fā)送查詢和接使用操作系統(tǒng)的濾功能（例如 ipfw,iptables,受響應，不需要任何特殊控制。我也和 pf）。允許來自任鄰居的 UDP 消息到 ICP 端口，并所有其他的。如果 squid 因為 icp_acs 規(guī)則而某個 ICP 查詢，它返回一個 ICP_DENIED 消息。然而，假如 squid 檢測到超過 95%的近來查詢被在 cache.log 里寫如下消息：，它停止響應 1 個小時。若發(fā)生這種情況，squidWARNING: Probable misconfigured neighbor at WARNING: 150 of the last 150 ICP reps a

48、re DENIEDWARNING: No reps will be sent for the next 3600 seconds假如你看到這樣的消息，你該聯系錯誤配置了 cache 的管理員。squid 被設計為迅速響應 ICP 查詢。也就是說，squid 通過檢查內存索引，能告知它是否有更新的、緩存的響應。這也就是為什么 squid 如此耗內存的原因。當 ICP 查詢進來時，squid計算 URI 的 MD5 hash 值，并且在索引里查找它。假如沒有找到，squid 返回 ICP_MISS 消息。假如找到了，squid 檢查超時時間。假如目標沒有刷新，squid 返回 ICP_MISS。對

49、刷新的目標，squid 返回 ICP_HIT。默認的，squid所有的 ICP 查詢（但非響應）到 acs.log。假如擁有許多繁忙的鄰居 cache，日志文件可能變得太大而難于管理。使用 log_icp_queries 指令來這些查詢。盡管會丟失 ICP 的詳細日志，你仍可以通過 cache 管理器來獲取一些合計信息。假姐妹鄰居，你也許想使用 miss_acs 指令來強迫其關系。它指定 cache 丟失的規(guī)則。它與 http_acs 相似，但僅檢查必須被轉發(fā)的請求。默認的規(guī)則是允許所有的 cache丟失。除非增加一些 miss_acs 規(guī)則，任何姐妹 cache 都可能變成子 cache，并

50、通過你的網絡連接來轉發(fā) cache 丟失，這樣就盜用了帶寬。miss_ac例：s 規(guī)則相對簡單。記包含本地客戶端（例如 web 瀏覽器）。如下是個簡單示14acl Browsers src /16 acl Child1 src acl Child2 src /24acl All src 0/0miss_ac miss_ac miss_acmiss_acs allow Browsers s allow Child1s allow Child2s deny All注意我沒有在這里列舉任何姐妹cache。子 cache 允許通過請求cache 丟失，但姐妹 cache不允許。它們的 cache 丟失

51、請求被 deny all 規(guī)則。 icp_hit_stale 指令ICP之一是，它對 cache 住的，但陳舊的響應返回 ICP_MISS。這點確實存在，即使響應陳舊但有效。考慮一個簡單的堆疊，有 1 個子 cache 和 2 個父 cache。某個目標緩存在其中 1 個父cache 上。緩存的響應是陳舊的，但未改變，需要確認。子 cache 的 ICP 查詢導致 2 條 ICP_MISS 響應。由于不知道陳舊的響應存在于第 1 個父 cache 中，子 cache 會轉發(fā)它的請求到第 2 個父 cache。現在目標在 2 個父 cache 中，浪費資源。在該情形下，icp_hit_stale

52、 指令有用。它告訴 squid 對任何 cache 住的目標，即使它是陳舊的，都返回 ICP_HIT。這在父子關系的 cache 中很安全，但對姐妹關系的 cache 有問題。回想一下姐妹關系，客戶 cache 僅僅允許發(fā)送 cache 命中的請求。激活了 icp_hit_stale 指令，增加了假命中的數量，因為 squid 必須確認陳舊響應。正常情況下，squid 這樣處理假命中：在發(fā)送給姐妹 cache 的 HTTP 請求里增加 Cache-Control: only-if-cached 指令。假如姐妹 cache不能滿足 HTTP 請求為 cache 命中，它返回一個 HTTP 504

53、（網關超時）消息。當 squid 接受到 504 響應，它再次轉發(fā)請求到父 cache 或原始服務器。假如必須轉發(fā)所有的假命中，激活 icp_hit_stale 就會給姐妹關系 cache 帶來麻煩。這時 ICP客戶端 cache_peer 的 allow-miss 選項就變得有用。當設置了 allow-miss 選項時，squid 忽略它發(fā)送到姐妹 cache 的 HTTP 請求里的 only-if-cached 指令。假如激活了 icp_hit_stale，必須確保 miss_acs 不會來自姐妹 cache 的 cache 丟失請求。不幸的是，沒有辦法讓 squid 只允許cache 住

54、的，但陳舊的目標的 cache 丟失。允許姐妹 cache的 cache 丟失請求，也讓 squid 容易被擅自改變它為父 cache。姐妹 cache 的管理員可能沒經過你的同意，而 ICP_MISS_NOFETCH 功能命令行-Y 選項的作用是：在 squid 重建內存索引時，它導致 squid 返回ICP_MISS_NOFETCH，15而不是 ICP_MISS。接受到 ICP_MISS_NOFETCH 響應的 ICP 客戶，不會對這些目標發(fā)送HTTP 請求。這減少了 squid 的負載，并讓重建過程快速完成。 test_reachability 指令假如激活了 netdb 功能（見 10

55、.5 章），你也許會對 test_reachability 指令感。它背后的目的是，squid 僅接受某些請求，這些請求的原始服務器 squid 能到。激活了 test_reachability指令，在原始服務器不響應 ICMP時，squid 返回 ICP_MISS_NOFETCH，而不是ICP_MISS。這點有助于減少假 HTTP 請求的數量，并增加終端用戶迅速接受數據的機會。然而，一定比率的原始服務器站點過濾掉了 ICMP 傳輸。對這些站點，即使 HTTP 連接成功，squid 也會返回 ICP_MISS_NOFETCH。激活 test_reachability 也導致 squid 在 I

56、CP 查詢的響應里，發(fā)起 netdb 度量。假如 squid 沒有請求中的原始服務器的任何 RTT 度量值，它會發(fā)出一個 ICMP消息。10.6.2 成為 ICP 客戶首先，必須使用 cache_peer 指令來定義鄰居 cache。見 10.3 章。接著，必須使用 icp_port 指令，即使 squid 僅作為 ICP 客戶。這是因為 squid 使用同樣的 socket來發(fā)送和接受ICP 消息。這也許是個不好的設計思路。假如僅作為ICP 客戶，請使用icp_ac來阻塞查詢。例如：sacl All src 0/0icp_acs deny AllSquid 默認的對大多數請求發(fā)送 ICP 查

57、詢到其鄰居。見 10.10 章關于 squid 決定何時查詢其鄰居 cache 的方法的完整描述。在發(fā)送一個或多個查詢后，squid 等待一定數量的時間，等候 ICP 響應抵達。假如 squid 從某個鄰居 cache 接受到 ICP_HIT，它會立刻轉發(fā)請求到那里。會則，squid 會一直等待，直到所有的響應抵達，或超時發(fā)生。squid 基于下列算法，動態(tài)的計算超時。Squid 從最近的 ICP 傳輸中，知道從它自己到每個鄰居 cache 之間的平均往返時間。在查詢一組鄰居時，squid 計算所有鄰居 ICP RTT 的平均數，然后將該數值翻倍。換句話說，查詢超時值是每個鄰居 cache 查

58、詢的 RTT 的平均值的 2 倍。在計算超時值時，squid 忽略看起來已 down 掉的鄰居。在某些情形下，該算法不會工作良好，特別在鄰居 cache 的 RTT 變化很大的情況下。使用um_icp_query_timeout 指令可以改變超時的上限。另外，也可以通過 icp_query_timeout指令，讓 squid 使用一個常量超時值。16 ICP 客戶的 cache_peer 選項weight=n 允許你在使用 ICP/HTCP 時，手工父 cache。它僅當所有父 cachecache丟失時，才變得有用。正常情況下，squid 選擇響應首先抵達的父 cache。實際上，squid

59、 會記住查詢中哪個父 cache 有最好的 RTT。squid 實際上通過權重來區(qū)分 RTT，所以 weight=2的父 cache，不管其實際距離如何，都會被對待為離 squid 很近。no-query對鄰居 cache 的 ICP/HTCP。也就是說，你的 cache 不會發(fā)送任何對 cache 丟失的查詢到鄰居。它通常以 default 選項被使用。closest-only 指squid 的netdb 功能之一。它指示squid 僅基于netdb RTT 度量值來選擇父cache，而不是響應抵達的順序。該選項要求 netdb 在兩端都被激活。 ICP 和 netdb就像 10.5提到的一

60、樣，netdb 主要用于 ICP 查詢。在本節(jié)里，跟隨在這個過程中，所有的步驟調用。1作為 ICP 客戶的 squid cache，準備發(fā)送查詢到一個或多個鄰居 cache。假如設置了 query_icmp，squid 在 ICP 查詢里設置 SRC_RTT 標記。這通知 ICP 服務器，squid 想在 ICP響應里接受 RTT 度量值。2鄰居 cache 接受到帶有 SRC_RTT 標記的查詢。假如鄰居 cache 配置了使用 netdb 度量，它會在數據庫里搜索原始服務器的主機名。注意鄰居 cache 不會查詢 DNS 來原始服務器的 IP 地址。這樣，假如指定的主機已經被度量過，它才能