前端學HTTP之重定向和負載均衡

前面的話

　　HTTP並非獨自運行在網上的。不少協議都會在HTTP報文的傳輸過程當中對其數據進行管理。HTTP只關心旅程的端點(發送者和接收者)，但在包含有鏡像服務器、Web代理和緩存的網絡世界中，HTTP報文的目的地不必定是直接可達的

　　重定向技術一般能夠用來肯定報文是否終結於某個代理、緩存或服務器集羣中某臺特定的服務器。重定向技術能夠將報文發送到客戶端沒有顯式請求的地方去。本文將詳細介紹重定向技術以及負載均衡

 

總括

　　因爲HTTP應用程序須要可靠地執行HTTP事務，最小化時延，而且節約網絡帶寬，因此在現代網絡中重定向是廣泛存在的

　　出於這些緣由，Web內容一般分佈在不少地方。這麼作是出於可靠性的考慮。這樣，若是一個位置出問題了，還有其餘的可用，若是客戶端能去訪問較近的資源，就能夠更快地收到所請求的內容，以下降響應時間；將目標服務器分散，還能夠減小網絡擁塞。能夠將重定向看成一組有助於找到「最佳」分佈式內容的技術

　　大多數重定向部署都包含某些形式的負載均衡。也就是說，它們能夠將輸入報文的負載分攤到一組服務器中去。反之，由於輸入報文必定會在分擔負荷的服務器之間進行某種分佈，因此任意形式的負載均衡都包含了重定向

　　從客戶端向目標發送HTTP請求，目標對其進行處理的角度來看，服務器、代理、緩存和網關對客戶端來講都是服務器。不少重定向技術均可用於服務器、代理、緩存和網關，由於它們具備共同的，與服務器相似的特徵。其餘一些重定向技術是專門爲特定類型的端點設計的，沒有通用性

　　Web服務器會根據每一個IP來處理請求。將請求分攤到複製的服務器中去，就意味着應該把對某特定URL的每條請求都發送到最佳的Web服務器上去(最靠近客戶端的、或負載最輕的或採用其餘優化策略選擇的服務器)。重定向到某臺服務器就像將全部須要給汽車加油的司機都送到最近的加油站去同樣

　　代理但願根據每一個協議來處理請求。在理想狀況下，某個代理附近的全部HTTP流量都應該經過這個代理傳輸。好比，若是某代理緩存靠近各類不一樣的客戶端，那麼理想狀況下，全部請求都應流經這個代理緩存，由於代理緩存上會存儲經常使用的文檔，能夠直接提供，從而避免經過更長、更昂貴的路徑鏈接到原始服務器。重定向到代理就像從一條主要通路(不管它通往何處)上將流量分流到一條本地快捷路徑上去同樣

　　重定向的目標是儘快地將HTTP報文發送到可用的Web服務器上去。在穿過因特網的路徑上，HTTP報文傳輸的方向會受到HTTP應用程序和報文經由的路由設備的影響

　　配置建立客戶端報文的瀏覽器應用程序，使其將報文發送給代理服務器；DNS解析程序會選擇用於報文尋址的IP地址。對不一樣物理地域的不一樣客戶端來講，這個IP地址可能不一樣；報文通過網絡傳輸時，會被劃分爲一些帶有地址的分組，交換機和路由器會檢查分組中的TCP/IP地址，並據此來肯定分組的發送路線；Web服務器能夠經過HTTP重定向將請求反彈給不一樣的Web服務器；瀏覽器配罝、DNS、TCP/IP路由以及HTTP都提供了重定向報文機制

　　[注意]有些方法，好比瀏覽器配置，只有在將流量重定向到代理的時候纔有意義，而其餘一些方法(好比DNS重定向)，則可用於將流量發送給任意服務器

　　重寫向方法包括通用重定向、代理重定向及緩存重定向等

 

通用重定向

　　能夠經過通用重定向方法將流量重定向到不一樣的(可能更優的)服務器，或者經過代理來轉發流量。具體來講，包括HTTP重定向、DNS重定向、任播尋址、IP MAC轉發以及IP地址轉發

【HTTP 重定向】

　　Web服務器能夠將短的重定向報文發回給客戶端，告訴他們去其餘地方試試。有些Web站點會將HTTP重定向做爲一種簡單的負載均衡形式來使用。處理重定向的服務器(重定向服務器)找到可用的負載最小的內容服務器，並將瀏覽器重定向到那臺服務器上去

　　對普遍分佈的Web站點來講，肯定「最佳」的可用服務器會更復雜一些，不只要考慮到服務器的負載，還要考慮到瀏覽器和服務器之間的因特網距離。與其餘一些形式的重定向相比，HTTP重定向的優勢之一就是重定向服務器知道客戶端的IP地址，理論上來說，它能夠作出更合理的選擇

　　下面是HTTP重定向的工做過程

　　在圖a中，Alice向www.joes-hardware.com發送了一條請求

GET /hammers.html HTTP/1.0
Host: www.joes-hardware.com
User-Agent: Mozilla/4.51 [en] (X11; U; IRIX 6.2 IP22)

　　在圖b中，服務器沒有回送帶有HTTP狀態碼200的Web頁面主體，而是回送了一個帶有HTTP狀態碼302的重定向報文

HTTP/1.0 302 Redirect
Server: Stronghold/2.4.2 Apache/1.3.6
Location: http://161.58.228.45/hammers.html

　　如今，在圖c中，瀏覽器會用重定向URL從新發送請求，此次會發送給主機161.58.228.45

GET /hammers.html HTTP/1.0
Host: 161.58.228.45
User-Agent: Mozilla/4.51 [en] (X11; U; IRIX 6.2 IP22)

　　另外一個客戶端可能會被重定向到另外一臺服務器上去。在圖d-f中，Bob的請求會被重定向到161.58.228.46

　　HTTP重定向能夠在服務器間導引請求，但它有如下幾個缺點：須要原始服務器進行大量處理來判斷要重定向到哪臺服務器上去。有時，發佈重定向所需的處理量幾乎與提供頁面自己所需的處理量同樣；增長了用戶時延，由於訪問頁面時要進行兩次往返；若是重定向服務器出故障，站點就會癱瘓

　　因爲存在這些弱點，HTTP重定向一般都會與其餘一種或多種重定向技術結合使用

【DNS重定向】

　　每次客戶端試圖訪問Joe的五金商店的網站時，都必須將域名www.joes-hardware.com解析爲IP地址。DNS解析程序多是客戶端本身的操做系統，多是客戶端網絡中的一臺DNS服務器，或者是一臺遠距離的DNS服務器

　　DNS容許將幾個IP地址關聯到一個域中，能夠配置DNS解析程序，或對其進行編程，以返回可變的IP地址。解析程序返回IP地址時所基於的原則能夠很簡單(輪轉)，也能夠很複雜(好比查看幾臺服務器上的負載，並返回負載最輕的服務器的IP地址)

　　在下圖中，Joe爲www.joes-hardware.com運行了4臺服務器。DNS服務器要決定爲www.joes-hardware.com返回4個IP地址中的哪個。最簡單的DNS決策算法就是輪轉

　　一、DNS輪轉

　　DNS輪轉是最多見的重定向技術之一也是最簡單的重定向技術之一。DNS輪轉使用了DNS主機名解析中的一項特性，在Web服務器集羣中平衡負載。這是一種單純的負載均衡策略，沒有考慮任何與客戶端和服務器的相對位置，或者服務器當前負載有關的因素

　　咱們來看看CNN.com實際上都作了些什麼。咱們用Unix中的工具nslookup來查找與CNN.com相關的IP地址。下面給出告終果

% nslookup www.cnn.com
Name: cnn.com
Addresses: 207.25.71.9, 207.25.71.12, 207.25.71.20, 207.25.71.22, 207.25.71.23, 207.25.71.24, 207.25.71.25, 207.25.71.26, 207.25.71.27, 207.25.71.28, 207.25.71.29, 207.25.71.30, 207.25.71.82, 207.25.71.199, 207.25.71.245, 207.25.71.246
Aliases: www.cnn.com

　　網站www.cnn.com其實是20個不一樣的IP地址組成的集羣。每一個IP地址一般都意味着一臺不一樣的物理服務器

　　二、多個地址及輪轉地址的循環

　　大多數DNS客戶端只會使用多地址集中的第一個地址。爲了均衡負載，大多數DNS服務器都會在每次完成查詢以後對地址進行輪轉。這種地址輪轉一般稱做DNS輪轉

　　例如，對www.crni.com進行三次連續的DNS查找可能會返回下面給出的IP地址輪轉列表

　　第一次DNS查找時的第一個地址爲207.25.71.5；第二次DNS查找時的第一個地址爲207.25.71.6；第三次DNS查找時的第一個地址爲207.25.71.7

　　三、用來平衡負載的DNS輪轉

　　因爲大多數DNS客戶端只使用第一個地址，因此DNS輪轉能夠在多臺服務器間提供負載均衡。若是DNS沒有對地址進行輪轉，大部分客戶端就老是會將負載發送給第一臺服務器

　　下圖說明了DNS輪轉循環是如何平衡負載的

　　Alice試圖鏈接www.cnn.com時，會用DNS查找IP地址，獲得207.25.71.5做 爲第一個1P地址。在圖c中，Alice鏈接到Web服務器207.25.71.5

　　Bob隨後試圖鏈接www.cnn.com時，也會用DNS查找IP地址，但因爲地址列表在Alice上次請求的基礎上輪轉了一個位置，因此他會獲得一個不一樣的結果。Bob獲得207.25.71.6做爲第一個IP地址，在圖f中它鏈接到了這臺服務器上

　　四、 DNS緩存帶來的影響

　　DNS對服務器的每次查詢都會獲得不一樣的服務器地址序列，因此DNS地址輪轉會將負載分攤。可是這種負載均衡並不完美，由於DNS查找的結果可能會被記住，並被各類應用程序、操做系統和一些簡易的子DNS服務器重用。不少Web瀏覽器都會對主機進行DNS查找，而後一次次地使用相同的地址，以減小DNS查找的開銷，並且有些服務器也更願意保持與同一臺客戶端的聯繫。另外，不少操做系統都會自動進行DNS查找，並將結果緩存，但並不會對地址進行輪轉。所以，DNS輪轉一般都不會平衡單個客戶端的負載——一個客戶端一般會在很長時間內鏈接到一臺服務器上

　　儘管DNS沒有對單個客戶端的事務進行跨服務器副本的處理，但在分散多個客戶端的總負荷方面它作得至關好。只要有大量具備相同需求的客戶端，就能夠將負載合理地分散到各個服務器上去

　　五、其餘基於DNS的重定向算法

　　前面討論了DNS是如何對每條請求進行地址列表輪轉的。可是，有些加強的DNS服務器會使用其餘一些技術來選擇地址的順序

　　a、負載均衡算法

　　有些DNS服務器會跟蹤Web服務器上的負載，將負載最輕的Web服務器放在列表的最前面

　　b、鄰接路由算法

　　Web服務器集羣在地理上分散時，DNS服務器會嘗試着將用戶導向最近的Web 服務器

　　c、故障屏蔽算法

　　DNS服務器能夠監視網絡的情況，並將請求繞過出現服務中斷或其餘故障的 地方

　　一般，運行復雜服務器跟蹤算法的DNS服務器就是在內容提供者控制之下的一個權威服務器

　　有一些分佈式主機服務會使用這個DNS重定向模型。對於那些要查找附近服務器的服務來講，這個模型的一個缺點就是，權威DNS服務器只能用本地DNS服務器的IP地址，而不能用客戶端的IP地址來作決定

【任播尋址】

　　在任播尋址中，幾個地理上分散的Web服務器擁有徹底相同的IP地址，並且會經過骨幹路由器的「最短路徑」路由功能將客戶端的請求發送給離它最近的服務器

　　要使這種方法工做，每臺服務器都要向鄰近的骨幹路由器廣告，代表本身是一臺路由器。Web服務器會經過路由器通訊協議與其鄰近的骨幹路由器通訊。骨幹路由器收到發送給任播地址的分組時，會(像日常同樣)尋找接受那個IP地址的最近的 「路由器」。因爲服務器是將本身做爲那個地址的路由器廣告出去的，因此骨幹路由器會將分組發送給服務器

　　下圖中，三臺服務器爲同一個IP地址10.10.10.1服務。洛杉磯(LA)服務器將此地址廣告給LA路由器，紐約(NY)服務器一樣將此地址廣告給NY路由器，以此類推。服務器會經過路由器協議與路由器進行通訊。路由器會將目標爲10.10.10.1的客戶端請求自動地轉發到廣告這個地址的最近的服務器上去。對IP地址10.10.10.1的請求會被轉發給服務器3

　　任播尋址仍然是項實驗性技術。要使用分佈式任播技術，服務器就必須「使用路由器語言」，並且路由器必須可以處理可能出現的地址衝突，由於因特網地址基本上都是假定一臺服務器只有一個地址的。(若是沒有正確地實現，可能會形成很嚴重的 「路由泄露」問題。)分佈式任播是一種新興技術，能夠爲那些本身控制骨幹網絡的內容提供商提供一種解決方案

【IP MAC轉發】

　　在以太網中，HTTP報文都是以攜帶地址的數據分組的形式發送的。每一個分組都有一個第四層地址，由源IP地址、目的IP地址以及TCP端口號組成，它是第四層設備所關注的地址。每一個分組還有一個第二層地址，MAC(Media Access Control,媒體訪問控制)地址，這是第二層設備(一般是交換機和Hub)所關注的地址。第二層設備的任務是接收具備特定輸入MAC地址的分組，而後將其轉發到特定的輸出MAC地址上去

　　好比，下圖交換機的程序會未來自MAC地址MAC3的全部流量都發送到MAC地址MAC4上去

　　第四層交換機可以檢測出第四層地址(IP地址和TCP端口號)，並據此來選擇路由。好比，一臺第四層交換機能夠將全部目的爲端口80的Web流量都發送到某個代理上去。在下圖中，編寫交換機程序，將MAC3上全部端口80的流量都轉發到MAC6(代理緩存)上去。MAC3上全部其餘流量都會被轉發到MAC5上去

　　一般，若是緩存中有所請求的HTTP內容，並且是新鮮的，那麼就由代理緩存來提供內容。不然，代理緩存就會表明客戶端向此內容的原始服務器發送一條HTTP請求。交換機會將端口80的請求從代理(MAC6)發送給因特網網關(MAC5)

　　支持MAC轉發的第四層交換機一般會將請求轉發給幾個代理緩存，並在它們之間平衡負載。相似地，也能夠將HTTP流量轉發給備用HTTP服務器。由於MAC地址轉發只是點對點的，因此服務器或代理只能位於離交換機一跳遠的地方

【IP地址轉發】

　　在IP地址轉發中，交換機或其餘第四層設備會檢測輸入分組中的TCP/IP地址，並經過修改目的IP地址(不是目的MAC地址)，對分組進行相應的轉發。與MAC轉發相比，這麼作的優勢是目標服務器不須要位於一跳遠的地方；只須要位於交換機的上游就好了，並且一般第三層的端到端因特網路由都會將分組傳送到正確的地方。這種類型的轉發也被稱爲NAT(Network Address Translation,網絡地址轉換)

　　但還有一個問題，就是對稱路由。從客戶端接受輸入TCP鏈接的交換機管理着鏈接，交換機必須經過那條TCP鏈接將響應回送給客戶端。這樣，全部來自目標服務器或代理的響應都必須返回給交換機

　　有如下兩種方式能夠控制響應的返回路徑

　　一、將分組的源IP地址改爲交換機的IP地址。經過這種方式，不管交換機和服務器之間採用何種網絡配置，響應分組都會被髮送給交換機。這種方式被稱爲徹底NAT(full NAT)，其中的IP轉發設備會對目的IP地址和源IP地址都進行轉換

　　這樣作的缺點是服務器不知道客戶端的IP地址，那種須要認證和計費的Web服務器沒法獲知客戶端的IP地址

　　二、若是源IP地址仍然是客戶端的IP地址，就要確保(從硬件的角度來看)沒有從服務器到客戶端的直接路由(繞過交換機的)。這種方式有時被稱爲半NAT(half NAT)。這種方法的優勢是服務器知道客戶端的IP地址，但缺點是要對客戶端和服務器之間的整個網絡都有某種程度的控制

【網元控制協議】

　　NECP(Network Element Control Protocol,網元控制協議)容許網元(NE,路由器和交換機等負責轉發IP分組的設備)與服務器元素(SE,Web服務器和代理緩存等提供應用層請求的設備)進行交互。NECP並未顯式提供對負載均衡的支持，它只是爲SE提供了一種發送負載均衡信息給NE的方式，這樣NE就能夠在它認爲合適的狀況下進行負載均衡了。與WCCP同樣，NECP也提供了幾種轉發分組的方式：MAC轉發、GRE封裝和NAT

　　NECP支持例外。SE能夠決定它不能爲某些特定的源IP地址提供服務，並將這些地址發送給NE。而後，NE能夠未來自這些IP地址的請求轉發給原始服務器

　　下表描述了NECP報文

代理重定向

　　到目前爲止，咱們已經討論過通用的重定向方法了。出於潛在的安全考慮，內容也可能須要經過各類代理來訪問，或者網絡中可能有一個客戶端可利用的代理緩存，由於獲取已緩存的內容極可能要比直接鏈接到原始服務器快得多

　　但Web瀏覽器客戶端怎麼纔會知道要鏈接到某個代理上去呢？能夠用3種方法來判斷：顯式瀏覽器配置、動態自動配置以及透明攔截

　　代理能夠順次將客戶端請求重定向到另外一個代理上去。好比，沒有緩存此內容的代理緩存可能會選擇將客戶端重定向到另外一個代理緩存。這樣一來，響應就會來自與客戶端請求資源的地址不一樣的另一個地址，因此，咱們還會討論幾種用於對等代理——緩存重定向的協議：ICP、CARP和HTCP

【顯式瀏覽器配置】

　　大多數瀏覽器均可以配置爲從代理服務器上獲取內容——瀏覽器中有一個下拉菜單，用戶能夠在這個菜單中輸入代理的名字或IP地址以及端口號。而後瀏覽器的全部請求均可以發送給這個代理。有些服務提供商不容許用戶配置普通瀏覽器來使用代理，它們會要求用戶下載事先配置好的瀏覽器。這些瀏覽器知道所要使用的代理的地址

　　顯式瀏覽器配置有如下兩個主要的缺點：

　　一、配置爲使用代理的瀏覽器，即便在代理沒法響應的狀況下，也不會去聯繫原始服務器。若是代理崩潰了，或者沒有正確配置瀏覽器，用戶就會遇到鏈接方面的問題

　　二、對網絡架構進行修改，並將這些修改通知給全部的終端用戶都是很困難的。若是服務提供商要添加更多的代理服務器，或者使其中一些退出服務，用戶都要修改瀏覽器代理設置

【代理自動配置】

　　顯式配置瀏覽器使其聯繫特定的代理，這樣會限制網絡架構方面的變更，由於它是靠用戶來介入並從新配置瀏覽器的。自動配置方式能夠動態配置瀏覽器，鏈接到正確的代理服務器，以解決這個問題。這種方法已經實現了，被稱爲代理自動配 置(PAC)協議。PAC是網景公司定義的，網景公司的Navigator和微軟的IE瀏覽器都支持此協議

　　PAC的基本思想是讓瀏覽器去獲取一個稱爲PAC的特殊文件，這個文件說明了每一個URL所關聯的代理。必須配置瀏覽器，爲這個PAC文件關聯一個特定的服務器。這樣，瀏覽器每次重啓的時候均可以獲取這個PAC文件了

　　PAC文件是個JavaScript文件，其中必須定義函數：

function FindProxyForURL(url, host)

　　以下所示，瀏覽器要爲請求的每條URL調用這個函數：

return_value = FindProxyForURL(url_of_request, host_in_url);

　　其返回值爲一個字符串，用來講明瀏覽器應該到哪裏請求這個URL。返回值能夠是所關聯的代理名稱列表(好比，PROXY proxy1.domain.com, PROXY proxy2.domain.com)，或者是字符串"DIRECT"，這個字符串說明瀏覽器應該繞開全部的代理，直接鏈接原始服務器

　　下圖給出了瀏覽器對PAC文件的請求以及響應此請求的操做順序。在本例中，服務器回送了帶有JavaScript程序的PAC文件。JavaScript程序中有一個FindProxyForURL函數，用來告知瀏覽器，若是所請求的URL的主機位於netscape.com域中，就直接與原始服務器聯繫，全部其餘請求都鏈接到proxy1.joes-cache.com。瀏覽器會爲它所請求的每一個URL調用這個函數，並根據此函數返回的結果進行鏈接

　　PAC協議是至關強大的：JavaScript程序能夠請求瀏覽器根據大量與主機名相關的參數來選擇代理，好比DNS地址和子網，甚至星期幾或具體時間。只要服務器中的PAC文件保持更新，能反映代理位置的變化，PAC就容許瀏覽器根據網絡結構的變化自動與合適的代理進行聯繫

　　PAC存在的主要問題是必需要對瀏覽器進行配置，讓它知道要從哪一個服務器獲取PAC文件，所以它就是一個全自動配置的系統。就像那些預配置瀏覽器同樣，如今一些主要的ISP都在使用PAC

【Web代理自動發現協議】

　　WPAD(Web代理自動發現協議)的目標是在不要求終端用戶手工配置代理設置，
並且不依賴透明流量攔截的狀況下，爲Web瀏覽器提供一種發現並使用附近代理的方式。因爲可供選擇的發現協議有不少，並且不一樣瀏覽器的代理使用配置也存在差別，所以定義Web代理自動發現協議時，普通的問題會被複雜化

　　一、PAC文件自動發現

　　WPAD容許HTTP客戶端定位一個PAC文件，並使用這個PAC文件找到適當的代理服務器的名字。WPAD不能直接肯定代理服務器的名字，由於這樣就沒法使用PAC文件提供的附加功能了(負載均衡，請求路由到一組服務器上去，故障時自動轉移到備用代理服務器等)

　　以下圖所示，WPAD協議發現了PAC文件URL，這個URL也被稱爲配置URL(CURL)。PAC文件執行了一個JavaScript程序，這個程序會返回合適的代理服務器地址

　　實現WPAD協議的HTTP客戶端用WPAD找到PAC文件的CURL，根據這個CURL獲取PAC文件(又名配置文件或CFILE)，執行PAC文件來肯定代理服務器，向PAC文件返回的那個代理服務器發送HTTP請求

　　二、WPAD算法

　　WPAD使用了一系列資源發現技術來肯定適當的PAC文件CURL。並非全部的組織均可以使用全部技術的，因此WPAD指定了多種發現技術。在成功得到CURL以前，WPAD客戶端會一個個地嘗試每種技術

　　當前的WPAD規範按序定義了下列技術：DHCP(動態主機配置協議)、SLP(服務定位協議)、DNS知名主機名、DNS SRV記錄、DNS TXT記錄中提供的服務URL

　　在這5種機制中，要求WPAD客戶端必須支持DHCP和DNS知名主機名技術

　　WPAD客戶端會按順序用上面提供的發現機制發送一系列資源發現請求。客戶端只會嘗試它們所支持的機制。只要某次發現嘗試成功了，客戶端就會用獲得的信息來構建PAC CURL

　　若是從那個CURL上成功獲取到PAC文件，這個過程就結束了。若是沒有，客戶端就從它在預約義的資源發現請求系列裏中斷的地方開始恢復。若是嘗試了全部的發現機制後，都沒有獲取到PAC文件，WPAD協議就失敗了，客戶端會配置爲不使用代理服務器

　　客戶端首先會嘗試DHCP，而後是SLP。若是沒有獲取到PAC文件，客戶端會繼續執行那些基於DNS的機制

　　客戶端會在DNS SRV、知名主機名和DNS TXT記錄等方法中循環屢次。每次都使DNS查詢的QNAME變得愈來愈不具體。經過這種方式，客戶端就能夠定位出盡量具體的配置信息，但也可能會轉而使用一些不太具體的信息。每次DNS查找都會在QNAME前加上wpad，用以說明請求的資源類型

　　考慮主機名爲johns-desktop.development.foo.com的客戶端。下面是一個完整的WPAD客戶端會執行的發現嘗試順序：DHCP；SLP；用QNAME=wpad.development.foo.com 進行DNS A查找；用QNAME=wpad.development.foo.com進行DNS SRV查找；用QNAME=wpad.devdopment.foo.com進行DNS TXT查找；用QNAME=wpad.foo.com進行DNS A查找；用QNAME=wpad.foo.com進行 DNS SRV 查找；用QNAME=wpad.foo.com進行DNS TXT查找

　　三、用DHCP進行CURL發現

　　要使用這種機制，就必須將CURL存儲在WPAD客戶端吋以查詢的DHCP服務器上。WPAD客戶端能夠經過向DHCP服務器發送DHCP查詢來獲取CURL。(若是DHCP服務器中配置了這種信息)，就能夠在DHCP可選代碼252中獲取CURL。全部WPAD客戶端實現都必須支持DHCP

　　若是WPAD客戶端已經在其初始化過程當中執行了DHCP查詢，DHCP服務器可能就已經提供了那個值。若是沒法經過客戶端OS API得到這個值，客戶端就向DHCP服務器發送一條DHCPINFORM報文，以獲取這個值

　　WPAD的DHCP可選代碼252爲STRING類型，能夠是任意長度。這個字符串中包含了一個指向適當PAC文件的URL。好比：

"http://server.domain/proxyconfig.pac"

　　四、DNS A記錄查找

　　要讓這種機制工做，就必須將合適的代理服務器的IP地址存儲在WPAD客戶端能夠查詢的DNS服務器上。WPAD客戶端會向DNS服務器發送一個A記錄查詢，以獲取CURL。成功查詢的結果中會包含合適的代理服務器的IP地址

　　WPAD客戶端實現必須支持這種機制。這應該是很簡單的，由於它只要求基本的DNS A記錄查找。對WPAD來講，規範使用了「wpad」的「知名別名」來進行Web代理自動發現

　　客戶端執行了下列DNS查找：

QNAME=wpad.TGTDOM., QCLASS=IN, QTYPE=A

　　成功的查找中包含了IP地址，WPAD客戶端根據這個地址構建CURL

　　五、獲取PAC文件

　　只要建立了候選的CURL，WPAD客戶端一般都會向CURL發送一條GET請求。發出請求時，WPAD客戶端必需要發送一些帶有適當CFILE格式信息的Accept首部，這些CFILE格式都是它們所能處理的。好比：

Accept: application/x-ns-proxy-autoconfig

　　並且，若是CURL的結果是要進行重定向，客戶端就必須跟隨這些重定向到其最終目的地

　　六、什麼時候執行WPAD

　　至少要在出現如下狀況的時候進行Web代理自動發現：

　　a、在Web客戶端啓動的時候——WPAD只在第一個實例啓動的時候執行。後面的實例會繼承這種設置

　　b、只要有來自網絡棧的通知，就說明客戶端主機的IP地址改變了

　　哪一個選項在其環境中有意義，Web客戶端就能夠選擇哪一個。並且，客戶端還必須根據HTTP的過時時間，爲以前下載的PAC文件的過時時間嘗試一個發現週期。PAC文件過時時，客戶端遵循過時時間，從新運行WPAD過程是很重要的

　　若是PAC文件沒有提供替換方案，在當前配置的代理失效的狀況下，客戶端還能夠選擇從新運行WPAD過程

　　只要客戶端決定使當前的PAC文件失效，就必須從新運行整個WPAD協議，以確保它會發現當前正確的CURL。具體來講，就是協議不能有條件地獲取PAC文件的If-Modified-Since

　　WPAD協議廣播與/或多播通訊可能須要大量的網絡環回時間。WPAD協議的激活頻率不該該高於上面指定的頻率(好比在每次獲取URL時進行一次)

　　七、WPAD欺騙

　　WPAD的IE5實現容許Web客戶端在沒有用戶干預的狀況下，自動檢測代理設置。WPAD使用的算法會在全稱域名前加上主機名「Wpad」，並會逐漸刪除子域名，直到它找到可以響應主機名的WPAD服務器，或到達第三級域名。好比，域a.b.microsoft.com中的Web客戶端會先查詢wpad.a.b.microsoft、wpad.b.microsoft.com，而後再查詢wpad.microsoft.com

　　這樣會暴露出一個安全漏洞，由於在國際應用(及其餘特定的配置)中，第三級域名多是不可信的。惡意用戶能夠創建一個WPAD服務器，並提供他選中的代理配置命令。後繼(5.01及之後)的IE版本修正了這個問題

　　八、超時

　　WPAD會通過多個級別的發現，客戶端必須確保每一個階段都有時限保證。可能的狀況下，將每一個階段都限制在10秒之內是比較合理的，但實現者可能會選擇其餘更適合其網絡特性的值。好比，運行在無線網絡上的設備實現，因爲帶寬較低或時延較長，可能就會使用更大的時限

　　九、管理者的考慮

　　管理者至少應該在其環境中配置DHCP或DNS A記錄查找方式中的一種，由於只有這兩種方式是全部兼容客戶端都必須實現的。除此以外，經過配置環境使其支持搜索列表中順序靠前的機制，能夠縮短客戶端的啓動時間

　　使用這種協議結構的主要動力之一是支持客戶端定位附近的代理服務器。在不少環境中，都會有多個代理服務器(工做組、公司網關，ISP、骨幹網等)

　　在WPAD框架結構中，能夠在不少地方肯定代理服務器是否「鄰近」：

　　a、不一樣子網DHCP服務器會返回不一樣答案。還能夠根據客戶端的cipaddr字段或客戶端標識符選項做出決定

　　b、能夠對DNS服務器進行配置，使其爲不一樣的域名後綴(好比，QNAME wpad.marketing.bigcorp.com和wpad.development.bigcorp.com)返回不一樣的SRV/A/TXT資源記錄(RR)

　　c、處理CURL請求的Web服務器會根據user-Agent首部、Accept首部、客戶端IP地址/子網/主機名、附近代理服務器的拓撲分佈等做出決定。可能由處理CURL的CGI可執行文件進行這種處理。如前所述，甚至多是某個處理CURL請求的代理服務器來做出這些決定

　　d、PAC文件的表達能力可能足以在客戶端運行時從一組候選的代理服務器中進行選擇。CARP就是在此基礎上實現緩存陣列的。PAC文件能夠計算出到一組候選代理服務器的網絡距離(或其餘合理的度量方式)，並選擇「最近」或「響應最積極」的服務器，這並非什麼難以想象的事情

 

緩存重定向

　　咱們已經討論過一些將流量重定向到通用服務器的技術，以及一些將流量導向代理或網關的專用技術了。下面會介紹一些更復雜的、用於緩存代理服務器的重定向技術。這些技術要儘可能作到可靠、高效且能感知內容——這樣能夠將請求分配到可能包含特定內容的位置上去，所以比前面討論過的那些協議更復雜

【WCCP重定向】

　　Cisco系統公司開發的WCCP可使路由器將Web流量重定向到代理緩存中去。WCCP負責路由器和緩存服務器之間的通訊，這樣路由器就能夠對緩存進行驗證(確保它們已啓動且正在運行)，在緩存之間進行負載均衡，並將特定類型的流量發送給特定的緩存了。WCCP版本2(WCCP2)是個開放的協議。下面探討WCCP2

　　一、WCCP重定向工做流程

　　下面是WCCP重定向在HTTP上工做過程的概述(WCCP對其餘協議的重定向過程也是相似的)：啓動包含了一些支持WCCP的路由器和緩存的網絡，這些路由器和緩存之間能夠相互通訊；一組路由器及其目標緩存構成一個WCCP服務組。服務組的配置說明了要將何種流量發往何處、流量是如何發送的以及如何在服務組的緩存之間進行負載均衡；若是服務組配置爲重定向HTTP流量，服務組中的路由器就會將HTTP請求發送給服務組中的緩存；HTTP請求抵達服務組中的路由器時，路由器會(根據對請求IP地址的散列，或者「掩碼/值」的配對策略)選擇服務組中的某個緩存爲請求提供服務；路由器向緩存發送請求分組，能夠用緩存的IP地址來封裝分組，也能夠經過IP MAC轉發來實現；若是緩存沒法爲請求提供服務，就將分組返回給路由器進行普通的轉發；服務組中的成員會互相交換心跳報文，不斷驗證對方的可用性

　　二、WCCP2報文

　　WCCP2報文有4種，以下表所示

　　WCCP2_HERE_I_AM的報文格式爲

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

　　三、報文組件

每條WCCP2報文都由一個首部和一些組件構成。WCCP首部信息包含報文類型(Here I Am、I See You、Assignment或Removal Query)、WCCP版本和報文長度(不包括首部的長度)

　　每一個組件都以一個描述組件類型和長度的4字節首部開始。組件長度不包括組件首部的長度。報文組件以下表所述

　　四、服務組

　　服務組(service group)由一組支持WCCP的路由器和緩存組成，它們之間能夠交換WCCP報文。路由器會向服務組中的緩存發送Web流量。服務組的配置肯定了如何將流量分配到服務組的緩存中去。路由器和緩存會在Here I Am和I See You報文中交換服務組的配置信息

　　五、GRE分組封裝

　　支持WCCP的路由器會用服務器的IP地址將HTTP分組封裝起來，將其重定向到特定的服務器上去。分組封裝中還包含了IP首部的proto字段，用來講明通用路由器封裝(GRE)。proto字段的存在告訴接收代理，它有一個封裝的分組。分組被封裝起來，客戶端的IP地址就不會丟失了。下圖顯示了GRE分組的封裝過程

　　六、WCCP的負載均衡

　　除了路由功能以外，WCCP路由器還能夠在幾個接收服務器之間進行負載均衡。WCCP路由器及其接收服務器會交換心跳報文(heartbeat message)，以便相互通知本身處於啓動運行狀態。若是某特定接收服務器中止發送心跳報文，WCCP路由器就會將請求流最直接發送到因特網上，而不會將其重定向給那個節點。節點從新提供服務時，WCCP路由器會再次開始接收心跳報文，並繼續向節點發送請求流量

【因特網緩存協議】

　　ICP (因特網緩存協議)容許緩存在其兄弟緩存中查找命中內容。若是某個緩存中沒有HTTP報文所請求的內容，它能夠查明內容是否在附近的兄弟緩存中，若是在，就從那裏獲取內容，以免查詢原始服務器而帶來的更多開銷。能夠把ICP看成一個緩存集羣協議。HTTP請求報文的最終目的地能夠經過一系列的ICP查詢肯定，從這個角度來講，它就是一個重定向協議

　　ICP是一個對象發現協議。它會同時去詢問附近的多個緩存，看看它們的緩存中是否有特定的URL。附近的緩存若是有那個URL的話，就會返回一個簡短的報文HIT，若是沒有，就返回MISS。而後，緩存就能夠打開一條到擁有此對象的鄰居緩存的HTTP鏈接了

　　ICP是很簡單直接的。ICP報文是一個以網絡字節序表示的32位封裝結構，這樣更便於進行解析。爲了提升效率，能夠由UDP數據報承載其報文。UDP是一種不可靠的因特網協議，說明在傳輸的過程當中數據可能會被破壞，所以使用ICP的程序要具備超時功能，以檢測丟失的數據報

　　下面簡要描述一下ICP報文中的部分信息

　　a、Opcode(操做碼)

　　Opcode是個8位的二進制值，用以描述ICP報文的含義。基本的opcode包括ICP_OP_QUERY請求報文和ICP_OP_HIT和ICP_OP_MISS響應報文

　　b、版本

　　8位的版本號描述了ICP協議的版本編號。Squid使用的ICP版本記錄在RFC 2186第2版中

　　c、報文長度

　　以字節爲單位的ICP報文總長。由於只有16位，因此ICP報文的長度不能超過16383字節。URL一般都小於16KB，若是超過這個長度，不少Web應用程序就沒法處理它了

　　d、請求編號

　　支持ICP的緩存會用請求編號來記錄多個同時發起的請求和響應。ICP應答報文數必須與觸發應答的ICP請求報文數相同

　　e、選項

　　32位的ICP選項字段是個包含了若干標記的位矢量，這些標記吋用來修改ICP的行爲。ICPv2定義了兩個標記，這兩個標記都會修改ICP_OP_QUERY請求。ICP_FLAG_HIT_OBJ標記用來啓動或禁止在ICP響應中返回文檔數據。ICP_FLAG_SRC_RTT標記請求由兄弟緩存測量的、到原始服務器的環回時間的估計值

　　f、可選數據

　　保留了32位的可選數據用於可選特性。ICPv2使用了可選數據的低16位來裝載從兄弟緩存到原始服務器的可選環回時間的估計值

　　g、發送端主機地址

　　承載了報文發送端32位IP地址的著名字段。實際中並未使用

　　h、淨荷

　　淨荷內容的變化取決於報文的類型。對ICP_OP_QUERY來講，淨荷是一個4字節的原始請求端主機地址，後面跟着一個由NUL結尾的URL。對ICP_OP_HIT_OBJ來講，淨荷是一個由NUL結尾的URL，後面跟着一個16位的對象長度，接着是對象數據

【緩存陣列路由協議】

　　代理服務器經過攔截來自單個用戶的請求，提供所請求Web對象的緩存副本，極大地下降了發往因特網的流量。但隨着用戶數的增長，大量流量可能會使代理服務器自身超載

　　對此問題的一種解決方案就是使用多個代理服務器將負載分散到一組服務器上。CARP(緩存陣列路由協議)是微軟公司和網景公司提出的一個標準，經過這個協議來管理一組代理服務器，使這組代理服務器對用戶來講就像一個邏輯緩存同樣

　　CARP是ICP的一個替代品。CARP和ICP都容許管理者經過使用多個代理服務器來提升性能。下面討論CARP與ICP的區別，用CARP代替ICP的優缺點以及
CARP協議實現上的一些技術細節

　　ICP中出現緩存未命中時，代理服務器會用ICP報文格式來查詢附近的緩存，以肯定Web對象是否存在。附近的緩存會以HIT或MISS進行響應，請求代理服務器會用這些響應來選擇可以獲取到對象的最適當的位置。若是ICP代理服務器是以層次結構排列的，未命中的查詢會被提交給其父代理。下圖以圖形方式顯示瞭如何經過ICP來解決命中和未命中的問題

　　[注意]經過ICP協議鏈接起來的每一個代理服務器都是將內容進行了冗餘鏡像的獨立緩存服務器，這就說明在不一樣的代理服務器之間複製Web對象條目是可行的。相反，用CARP鏈接起來的一組服務器會被看成一個大型的服務器，其中每一個組件服務器都只包含所有緩存文檔中的一部分。經過對某個Web對象的URL應用散列函數，CARP就能夠將此對象映射到特定的代理服務器上去。每一個Web對象都有一個惟一的家，因此咱們能夠經過單次查找肯定對象的位置，而無須去查詢集合中配置的每一個代理服務器。下圖總結了CARP重定向的方式

　　做爲客戶端和代理服務器中間人的緩存代理能夠在各個代理服務器之間分配負載，但這項功能也能夠由客戶端自身提供。能夠配置瀏覽器，以插件的形式計算散列函數，來肯定應該把請求發送給哪一個代理服務器

　　CARP對代理服務器作出的肯定性解析說明它無須向全部鄰居發送查詢，這也就意味着這種方法所需發送的緩存間報文會比較少。隨着愈來愈多的代理服務器添加到配置系統中來，緩存系統集羣的規模會變得至關大。但CARP的一個缺點就是，若是某個代理服務器不可用了，就要從新修改散列表以反映這種變化，並且必須從新配置現存代理服務器上的內容。若是代理服務器常常崩潰的話，這麼作的開銷可能會很高。相反，ICP代理服務器中存在的冗餘內容就表示它不須要從新配置。另外一個潛在的問題是，因爲CARP是個新協議，CARP集羣中可能不會包含那些現存的、只運行ICP協議的代理服務器

　　CARP重定向方法要完成下列任務：保存一個參與CARP的代理服務器列表。週期性地查詢這些代理服務器，看看它們是否仍然活躍；爲每一個參與的代理服務器計算一個散列函數。散列函數的返回值要考慮此代理所能處理的負載量；定義一個獨立的散列函數，這個函數會根據所請求Web對象的URL返回一個數字；將URL散列函數的結果代入代理服務器的散列函數，獲得一個數字陣列。這些數字中的最大值決定了要爲這個URL使用的代理服務器。因爲算出來的值是肯定的，因此對同一個Web對象的後繼請求會被轉發給同一臺代理服務器

　　以上4項任務能夠由瀏覽器、插件執行，也能夠在一箇中間服務器上計算。爲每一個代理服務器集羣建立一個表，表中列出了集羣中的全部服務器。表中的每一個條目都應該包含全局參數的相關的信息。好比，負載因子、生存時間(TTL)、倒計數值和應該以何頻率查詢成員之類的全局參數。負載因子說明機器能夠處理多少負載，這取決於那臺機器的CPU速度和硬盤容量。能夠經過RPC接口對此表進行遠程維護。只要表中的字段被RPC修改了，就可使其對下游的客戶端和代理可見，或將其發佈給它們。這項發佈工做是在HTTP中進行的，這樣，全部的客戶端或代理服務器就均可以在不引入另外一種代理間協議的基礎上消化表格信息了。客戶端和代理服務器只用了一個知名URL來獲取這張表

　　所使用的散列函數必須可以確保Web對象在參與的代理服務器間是統計分佈的。應該用代理服務器的負載因子來肯定分配給那臺代理的Web對象的統計機率

　　總之，CARP協議容許將一組代理服務器當作單個的集羣緩存，而不是(像ICP中那樣的)一組相互合做但又相互獨立的緩存服務器。肯定的請求解析路徑會在一跳內找到某個特定的Web對象的家。這樣會下降ICP在一組代理服務器中查找Web對象時常會產生的代理間流量。CARP還能夠避免在不一樣的代理服務器上存儲Web對象的多個副本的問題，這樣作的優勢是緩存系統集羣的Web對象存儲容量較大，缺點是任意一個代理的故障都要改寫現存代理的部分緩存內容

【超文本緩存協議】

　　前面咱們討論了ICP，這個協議容許代理緩存向兄弟緩存查詢文件是否存在。但設計ICP時考慮的是HTTP/0.9協議。所以，向兄弟緩存查詢資源是否存在時，只容許緩存發送URL。HTTP版本1.0和1.1引入了不少新的請求首部，這些首部能夠和URL一塊兒用來肯定文件是否匹配。所以，只在請求中發送URL可能沒法獲得精確的響應

　　HTCP(超文本緩存協議)容許兄弟緩存之間經過URL和全部的請求及響應首部 來相互查詢文檔是否存在，以下降錯誤命中的可能。並且HTCP容許兄弟緩存監視或請求在對方的緩存中添加或刪除所選中的文檔，並修改對方已緩存文檔的緩存策略

　　HTCP事務是另外一個對象發現協議。若是附近的緩存中有這個文檔，發起請求的緩存能夠打開一條到此緩存的HTTP鏈接，以獲取那個文檔的副本。ICP和HTCP事務之間的區別體如今請求和響應細節上

　　HTCP報文的結構以下圖所示，首部中包含了報文的長度和報文版本。數據部分開始是數據長度，包含了opcode、響應代碼、一些標記及ID，最後是實際的數據。可選的認證部分跟在Data小節的後面

　　報文字段的詳細內容以下所述

　　a、首部

　　Header部分包含32位的報文長度，8位的主要協議版本和8位的次要協議版本。報文長度包含全部首部、數據和認證部分的長度

　　b、數據

　　Data部分包含了HTCP報文。數據組件以下表所示

　　下表列出了HTCP Opcode代碼及其相應的數據類型

　　HTCP報文的認證部分是可選的，下表列出了它的認證組件

　　SET報文容許緩存請求對已緩存文檔的緩存策略進行修改。下表給出了能夠在SET報文中使用的首部

　　HTCP容許經過查詢報文將請求和響應首部發送給兄弟緩存，這樣能夠下降緩存查詢中的錯誤命中率。經過進一步容許在兄弟緩存間交換策略信息，HTCP還能夠提升兄弟緩存之間的合做能力