前面的話
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決策算法就是輪轉
1、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地址通常都意味着一台不同的物理服務器
2、多個地址及輪轉地址的循環
大多數DNS客戶端只會使用多地址集中的第一個地址。為了均衡負載，大多數DNS服務器都會在每次完成查詢之后對地址進行輪轉。這種地址輪轉通常稱作DNS輪轉
例如，對www.crni.com進行三次連續的DNS查找可能會返回下面給出的IP地址輪轉列表
第一次DNS查找時的第一個地址為207.25.71.5；第二次DNS查找時的第一個地址為207.25.71.6；第三次DNS查找時的第一個地址為207.25.71.7
3、用來平衡負載的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中它連接到了這台服務器上
4、 DNS緩存帶來的影響
DNS對服務器的每次查詢都會得到不同的服務器地址序列，所以DNS地址輪轉會將負載分攤。但是這種負載均衡並不完美，因為DNS查找的結果可能會被記住，並被各種應用程序、操作系統和一些簡易的子DNS服務器重用。很多Web瀏覽器都會對主機進行DNS查找，然后一次次地使用相同的地址，以減少DNS查找的開銷，而且有些服務器也更願意保持與同一台客戶端的聯系。另外，很多操作系統都會自動進行DNS查找，並將結果緩存，但並不會對地址進行輪轉。因此，DNS輪轉通常都不會平衡單個客戶端的負載——一個客戶端通常會在很長時間內連接到一台服務器上
盡管DNS沒有對單個客戶端的事務進行跨服務器副本的處理，但在分散多個客戶端的總負荷方面它做得相當好。只要有大量具有相同需求的客戶端，就可以將負載合理地分散到各個服務器上去
5、其他基於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連接將響應回送給客戶端。這樣，所有來自目標服務器或代理的響應都必須返回給交換機
有以下兩種方式可以控制響應的返回路徑
1、將分組的源IP地址改成交換機的IP地址。通過這種方式，無論交換機和服務器之間采用何種網絡配置，響應分組都會被發送給交換機。這種方式被稱為完全NAT(full NAT)，其中的IP轉發設備會對目的IP地址和源IP地址都進行轉換
這樣做的缺點是服務器不知道客戶端的IP地址，那種需要認證和計費的Web服務器無法獲知客戶端的IP地址
2、如果源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地址以及端口號。然后瀏覽器的所有請求都可以發送給這個代理。有些服務提供商不允許用戶配置普通瀏覽器來使用代理，它們會要求用戶下載事先配置好的瀏覽器。這些瀏覽器知道所要使用的代理的地址
顯式瀏覽器配置有以下兩個主要的缺點：
1、配置為使用代理的瀏覽器，即使在代理無法響應的情況下，也不會去聯系原始服務器。如果代理崩潰了，或者沒有正確配置瀏覽器，用戶就會遇到連接方面的問題
2、對網絡架構進行修改，並將這些修改通知給所有的終端用戶都是很困難的。如果服務提供商要添加更多的代理服務器，或者使其中一些退出服務，用戶都要修改瀏覽器代理設置
【代理自動配置】
顯式配置瀏覽器使其聯系特定的代理，這樣會限制網絡架構方面的變動，因為它是靠用戶來介入並重新配置瀏覽器的。自動配置方式可以動態配置瀏覽器，連接到正確的代理服務器，以解決這個問題。這種方法已經實現了，被稱為代理自動配 置(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代理自動發現協議時，普通的問題會被復雜化
1、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請求
2、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查找
3、用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"
4、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
5、獲取PAC文件
只要創建了候選的CURL，WPAD客戶端通常都會向CURL發送一條GET請求。發出請求時，WPAD客戶端必須要發送一些帶有適當CFILE格式信息的Accept首部，這些CFILE格式都是它們所能處理的。比如：
Accept: application/x-ns-proxy-autoconfig
而且，如果CURL的結果是要進行重定向，客戶端就必須跟隨這些重定向到其最終目的地
6、何時執行WPAD
至少要在出現以下情況的時候進行Web代理自動發現：
a、在Web客戶端啟動的時候——WPAD只在第一個實例啟動的時候執行。后面的實例會繼承這種設置
b、只要有來自網絡棧的通知，就說明客戶端主機的IP地址改變了
哪個選項在其環境中有意義，Web客戶端就可以選擇哪個。而且，客戶端還必須根據HTTP的過期時間，為之前下載的PAC文件的過期時間嘗試一個發現周期。PAC文件過期時，客戶端遵循過期時間，重新運行WPAD過程是很重要的
如果PAC文件沒有提供替換方案，在當前配置的代理失效的情況下，客戶端還可以選擇重新運行WPAD過程
只要客戶端決定使當前的PAC文件失效，就必須重新運行整個WPAD協議，以確保它會發現當前正確的CURL。具體來說，就是協議不能有條件地獲取PAC文件的If-Modified-Since
WPAD協議廣播與/或多播通信可能需要大量的網絡環回時間。WPAD協議的激活頻率不應該高於上面指定的頻率(比如在每次獲取URL時進行一次)
7、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版本修正了這個問題
8、超時
WPAD會經過多個級別的發現，客戶端必須確保每個階段都有時限保證。可能的情況下，將每個階段都限制在10秒以內是比較合理的，但實現者可能會選擇其他更適合其網絡特性的值。比如，運行在無線網絡上的設備實現，由於帶寬較低或時延較長，可能就會使用更大的時限
9、管理者的考慮
管理者至少應該在其環境中配置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
1、WCCP重定向工作流程
下面是WCCP重定向在HTTP上工作過程的概述(WCCP對其他協議的重定向過程也是類似的)：啟動包含了一些支持WCCP的路由器和緩存的網絡，這些路由器和緩存之間可以相互通信；一組路由器及其目標緩存構成一個WCCP服務組。服務組的配置說明了要將何種流量發往何處、流量是如何發送的以及如何在服務組的緩存之間進行負載均衡；如果服務組配置為重定向HTTP流量，服務組中的路由器就會將HTTP請求發送給服務組中的緩存；HTTP請求抵達服務組中的路由器時，路由器會(根據對請求IP地址的散列，或者“掩碼/值”的配對策略)選擇服務組中的某個緩存為請求提供服務；路由器向緩存發送請求分組，可以用緩存的IP地址來封裝分組，也可以通過IP MAC轉發來實現；如果緩存無法為請求提供服務，就將分組返回給路由器進行普通的轉發；服務組中的成員會互相交換心跳報文，不斷驗證對方的可用性
2、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
3、報文組件
每條WCCP2報文都由一個首部和一些組件構成。WCCP首部信息包含報文類型(Here I Am、I See You、Assignment或Removal Query)、WCCP版本和報文長度(不包括首部的長度)
每個組件都以一個描述組件類型和長度的4字節首部開始。組件長度不包括組件首部的長度。報文組件如下表所述
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路由器會再次開始接收心跳報文，並繼續向節點發送請求流量
【因特網緩存協議】
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還可以提高兄弟緩存之間的合作能力