20.4 快取的重定向方法
阿新 • • 發佈:2019-01-08
1. WCCP 重定向
Cisco 系統公司開發的 WCCP 可以使路由器將 Web 流量重定向到代理快取中去。WCCP 負責路由器和快取伺服器之間的通訊,這樣路由器就可以對快取進行驗證(確保它們已啟動且正在執行),在快取之間進行負載均衡,並將特定型別的流量傳送給特定的快取了。WCCP 版本 2(WCCP2)是個開放的協議。這裡我們會探討 WCCP2。
1. WCCP 重定向工作流程
- 啟動包含了一些支援 WCCP 的路由器和快取的網路,這些路由器和快取之間可以相互通訊。
- 一組路由器及其目標快取構成一個 WCCP 服務組。服務組的配置說明了要將何種流量發往何處、流量是如何傳送的以及如何在服務組的快取之間進行負載均衡。
- 如果服務組配置為重定向 HTTP 流量,服務組中的路由器就會將 HTTP 請求傳送給服務組中的快取。
- HTTP 請求抵達服務組中的路由器時,路由器會(根據對請求 IP 地址的雜湊,或者“掩碼/值”的配對策略)選擇服務組中的某個快取為請求提供服務。
- 路由器向快取傳送請求分組,可以用快取的 IP 地址來封裝分組,也可以通過 IP MAC 轉發來實現。
- 如果快取無法為請求提供服務,就將分組返回給路由器進行普通的轉發。
- 服務組中的成員會互相交換心跳報文,不斷驗證對方的可用性。
2. WCCP2 報文
- WCCP2 報文有 4 種:
- WCCP2_HERE_I_AM 的報文格式為:
WCCP Message Header Security Info Component Service Info Component Web-cache Identity Info Component Web-cache View Info Component Capability Info Component ( 可選 ) Command Extension Component ( 可選 )
- WCCP2_I_SEE_YOU 的報文格式為:
WCCP Message Header
Security Info Component
Service Info Component
Router Identity Info Component
Router View Info Component
Capability Info Component ( 可選 )
Command Extension Component ( 可選 )
- WCCP2_REDIRECT_ASSIGN 的報文格式為:
WCCP Message Header Security Info Component Service Info Component Assignment Info Component, or Alternate Assignment Component
- WCCP2_REMOVAL_QUERY 的報文格式為:
WCCP Message Header
Security Info Component
Service Info Component
Router Query Info Component
3. 報文元件
- 每條 WCCP2 報文都由一個首部和一些元件構成。WCCP 首部資訊包含報文型別 (Here I Am、I See You、Assignment 或 Removal Query)、WCCP 版本和報文長度 (不包括首部的長度)。
- 每個元件都以一個描述元件型別和長度的 4 位元組首部開始。元件長度不包括元件首部的長度。
- WCCP2 報文元件:
4. 服務組
- 服務組(service group)由一組支援 WCCP 的路由器和快取組成,它們之間可以交換 WCCP 報文。路由器會向服務組中的快取傳送 Web 流量。服務組的配置確定瞭如何將流量分配到服務組的快取中去。路由器和快取會在 Here I Am 和 I See You 報文中交換服務組的配置資訊。
5. GRE 分組封裝
- 支援 WCCP 的路由器會用伺服器的 IP 地址將 HTTP 分組封裝起來,將其重定向到特定的伺服器上去。
- 分組封裝中還包含了 IP 首部的 proto 欄位,用來說明通用路由器封裝(GRE)。proto 欄位的存在告訴接收代理,它有一個封裝的分組。分組被封裝起來,客戶端的 IP 地址就不會丟失了。下圖顯示了 GRE 分組的封裝過程。
6. WCCP 的負載均衡
- 除了路由功能之外,WCCP 路由器還可以在幾個接收伺服器之間進行負載均衡。 WCCP 路由器及其接收伺服器會交換心跳報文(heartbeat message),以便相互通知自己處於啟動執行狀態。
- 如果某特定接收伺服器停止傳送心跳報文,WCCP 路由器就會將請求流量直接傳送到因特網上,而不會將其重定向給那個節點。節點重新提供服務時,WCCP 路由器會再次開始接收心跳報文,並繼續向節點發送請求流量。
2. 因特網快取協議
- ICP(因特網快取協議)允許快取在其兄弟快取中查詢命中內容。如果某個快取中沒有 HTTP 報文所請求的內容,它可以查明內容是否在附近的兄弟快取中,如果在,就從那裡獲取內容,以避免查詢原始伺服器而帶來的更多開銷。
- 可以把 ICP 當作一個快取叢集協議。HTTP 請求報文的最終目的地可以通過一系列的 ICP 查詢確定,從這個角度來說,它就是一個重定向協議。
- ICP 是一個物件發現協議。它會同時去詢問附近的多個快取,看看它們的快取中是否有特定的 URL。附近的快取如果有那個 URL 的話,就會返回一個簡短的報文 HIT,如果沒有,就返回 MISS。然後,快取就可以開啟一條到擁有此物件的鄰居快取的 HTTP 連線了。
- ICP 是很簡單直接的。ICP 報文是一個以網路位元組序表示的 32 位封裝結構,這樣更便於進行解析。為了提高效率,可以由 UDP 資料報承載其報文。UDP 是一種不可靠的因特網協議,說明在傳輸的過程中資料可能會被破壞,因此使用 ICP 的程式要具有超時功能,以檢測丟失的資料報。
- 簡要描述一下 ICP 報文中的部分資訊:
- Opcode(操作碼):Opcode 是個 8 位的二進位制值,用以描述 ICP 報文的含義。基本的 opcode 包括 ICP_OP_QUERY 請求報文和 ICP_OP_HIT 和 ICP_OP_MISS 響應報文。
- 版本:8 位的版本號描述了 ICP 協議的版本編號。Squid 使用的 ICP 版本記錄在 RFC 2186 第 2 版中。
- 報文長度:以位元組為單位的 ICP 報文總長。因為只有 16 位,所以 ICP 報文的長度不能超過 16383 位元組。URL 通常都小於 16 KB,如果超過這個長度,很多 Web 應用程式就無法處理它了。
- 請求編號:支援 ICP 的快取會用請求編號來記錄多個同時發起的請求和響應。ICP 應答報文數必須與觸發應答的 ICP 請求報文數相同。
- 選項:32 位的 ICP 選項欄位是個包含了若干標記的位向量,這些標記可用來修改 ICP 的行為。ICPv2 定義了兩個標記,這兩個標記都會修改 ICP_OP_QUERY 請求。ICP_FLAG_HIT_OBJ 標記用來啟動或禁止在 ICP 響應中返回文件資料。ICP_ FLAG_SRC_RTT 標記請求由兄弟快取測量的、到原始伺服器的環回時間的估計值。
- 可選資料:保留了 32 位的可選資料用於可選特性。ICPv2 使用了可選資料的低 16 位來裝載從兄弟快取到原始伺服器的可選環回時間的估計值。
- 傳送端主機地址:承載了報文傳送端 32 位 IP 地址的著名欄位。實際中並未使用。
- 淨荷:淨荷內容的變化取決於報文的型別。對 ICP_OP_QUERY 來說,淨荷是一個 4 位元組的原始請求端主機地址,後面跟著一個由 NUL 結尾的 URL。對 ICP_OP_ HIT_OBJ 來說,淨荷是一個由 NUL 結尾的 URL,後面跟著一個 16 位的物件長度,接著是物件資料。
3. 快取陣列路由協議
- 代理伺服器通過攔截來自單個使用者的請求,提供所請求 Web 物件的快取副本,極大地降低了發往因特網的流量。但隨著使用者數的增加,大量流量可能會使代理伺服器自身超載。
- 對此問題的一種解決方案就是使用多個代理伺服器將負載分散到一組伺服器上。CARP(快取陣列路由協議)是微軟公司和網景公司提出的一個標準,通過這個協議來管理一組代理伺服器,使這組代理伺服器對使用者來說就像一個邏輯快取一樣。
- CARP 是 ICP 的一個替代品。CARP 和 ICP 都允許管理者通過使用多個代理伺服器來提高效能。下面討論 CARP 與 ICP 的區別,用 CARP 代替 ICP 的優缺點以及 CARP 協議實現上的一些技術細節。
- ICP 中出現快取未命中時,代理伺服器會用 ICP 報文格式來查詢附近的快取,以確定 Web 物件是否存在。附近的快取會以 HIT 或 MISS 進行響應,請求代理伺服器會用這些響應來選擇能夠獲取到物件的最適當的位置。如果 ICP 代理伺服器是以層次結構排列的,未命中的查詢會被提交給其父代理。
- 注意,通過 ICP 協議連線起來的每個代理伺服器都是將內容進行了冗餘映象的獨立快取伺服器,這就說明在不同的代理伺服器之間複製 Web 物件條目是可行的。
- 相反,用 CARP 連線起來的一組伺服器會被當作一個大型的伺服器,其中每個元件伺服器都只包含全部快取文件中的一部分。通過對某個 Web 物件的 URL 應用雜湊函式,CARP 就可以將此物件對映到特定的代理伺服器上去。每個 Web 物件都有一個唯一的家,所以我們可以通過單次查詢確定物件的位置,而無須去查詢集合中配置的每個代理伺服器。
- CARP 對代理伺服器做出的確定性解析說明它無須向所有鄰居傳送查詢,這也就意味著這種方法所需傳送的快取間報文會比較少。隨著越來越多的代理伺服器新增到配置系統中來,快取系統叢集的規模會變得相當大。但 CARP 的一個缺點就是,如果某個代理伺服器不可用了,就要重新修改散列表以反映這種變化,而且必須重新配置現存代理伺服器上的內容。如果代理伺服器經常崩潰的話,這麼做的開銷可能會很高。相反,ICP 代理伺服器中存在的冗餘內容就表示它不需要重新配置。
- CARP 重定向方法要完成下列任務(以下 4 項任務可以由瀏覽器、外掛執行,也可以在一箇中間伺服器上計算。):
- 儲存一個參與 CARP 的代理伺服器列表。週期性地查詢這些代理伺服器,看看它們是否仍然活躍。
- 為每個參與的代理伺服器計算一個雜湊函式。雜湊函式的返回值要考慮此代理所能處理的負載量。
- 定義一個獨立的雜湊函式,這個函式會根據所請求 Web 物件的 URL 返回一個數字。
- 將 URL 雜湊函式的結果代入代理伺服器的雜湊函式,得到一個數字陣列。這些數字中的最大值決定了要為這個 URL 使用的代理伺服器。由於算出來的值是確定的,所以對同一個 Web 物件的後繼請求會被轉發給同一臺代理伺服器。
- 為每個代理伺服器叢集建立一個表,表中列出了叢集中的所有伺服器。表中的每個條目都應該包含全域性引數的相關的資訊,比如,負載因子、生存時間(TTL)、倒計數值和應該以何頻率查詢成員之類的全域性引數。負載因子說明機器可以處理多少負載,這取決於那臺機器的 CPU 速度和硬碟容量。可以通過 RPC 介面對此表進行遠 程維護。只要表中的欄位被 RPC 修改了,就可以使其對下游的客戶端和代理可見,或將其釋出給它們。這項釋出工作是在 HTTP 中進行的,這樣,所有的客戶端或代理伺服器就都可以在不引入另一種代理間協議的基礎上消化表格資訊了。客戶端和代理伺服器只用了一個知名 URL 來獲取這張表。
- 所使用的雜湊函式必須能夠確保 Web 物件在參與的代理伺服器間是統計分佈的。應該用代理伺服器的負載因子來確定分配給那臺代理的 Web 物件的統計概率。
- 總之,CARP 協議允許將一組代理伺服器看成單個的叢集快取,而不是(像 ICP 中那樣的)一組相互合作但又相互獨立的快取伺服器。確定的請求解析路徑會在一跳內找到某個特定的 Web 物件的家。這樣會降低 ICP 在一組代理伺服器中查詢 Web 物件時常會產生的代理間流量。CARP 還可以避免在不同的代理伺服器上儲存 Web 物件的多個副本的問題,這樣做的優點是快取系統叢集的 Web 物件儲存容量較大,缺點是任意一個代理的故障都要改寫現存代理的部分快取內容。
4. 超文字快取協議
- 之前我們討論了 ICP,這個協議允許代理快取向兄弟快取查詢檔案是否存在。但設計 ICP 時考慮的是 HTTP/0.9 協議,因此,向兄弟快取查詢資源是否存在時,只允許快取傳送 URL。HTTP 版本 1.0 和 1.1 引入了很多新的請求首部,這些首部可以和 URL 一起用來確定檔案是否匹配。因此,只在請求中傳送 URL 可能無法得到精確的響應。
- HTCP(超文字快取協議)允許兄弟快取之間通過 URL 和所有的請求及響應首部來相互查詢文件是否存在,以降低錯誤命中的可能。而且 HTCP 允許兄弟快取監視或請求在對方的快取中新增或刪除所選中的文件,並修改對方已快取文件的快取策略。
- HTCP 報文的結構如下圖所示。首部中包含了報文的長度和報文版本。資料部分開始是資料長度,包含了 opcode、響應程式碼、一些標記及 ID,最後是實際的資料。可選的認證部分跟在 Data 小節的後面。
- 報文欄位的詳細內容如下所述:
- 首部:Header 部分包含 32 位的報文長度,8 位的主要協議版本和 8 位的次要協議版本。報文長度包含所有首部、資料和認證部分的長度。
- 資料:Data 部分包含了 HTCP 報文,結構如上圖所示。資料元件如下表所示。
下表列出了 HTCP Opcode 程式碼及其相應的資料型別:
1. HTCP 認證
- HTCP 報文的認證部分是可選的。下表列出了它的認證元件。
2. 設定快取策略
- SET 報文允許快取請求對已快取文件的快取策略進行修改。下表給出了可以在 SET 報文中使用的首部:
- HTCP 允許通過查詢報文將請求和響應首部發送給兄弟快取,這樣可以降低快取查詢中的錯誤命中率。通過進一步允許在兄弟快取間交換策略資訊,HTCP 還可以提高兄弟快取之間的合作能力。