http權威指南 - 6.代理

代理的概念：

Web代理服務器是網絡的中間實體。位於客戶端和服務器之間，扮演「中間人」的角色，在各端點之間來回傳送HTTP報文。

私有和共享代理： 代理服務器能夠是某個客戶端專用的，也能夠是不少客戶端共享的。單個客戶端專用的代理被稱爲 私有代理，衆多客戶端共享的代理被稱爲 共享代理。

爲何使用代理：

代理服務器能夠實現各類時髦且有用的功能。它們能夠 改善安全性，提升性能，節省費用。代理服務器能夠看到並接觸到全部流過的 HTTP流量，因此代理能夠監視流量並對其進行修改，以實現不少有用的增值Web服務。

 

代理使用方法示例：

1. 過濾器：針對不一樣人羣設定不一樣內容；
2. 文檔訪問控制：能夠將代理服務器在大量Web服務器和Web資源之間實現統一的訪問控制策略，建立審覈跟蹤機制；
3. 安全防火牆：一般使用代理服務器來提升安全性，代理服務器會在網絡中的單一安全節點上限制哪些應用層協議的數據能夠流入或流出一個組織，還能夠提供用來消除病毒的 Web 和 Emai 代理使用的掛鉤程序，以便對流量進行詳細檢查。
4. Web緩存：代理緩存維護了經常使用文檔的本地副本，並將它們按需提供；
5. 反向代理：代理能夠假扮Web服務器收發請求給真實Web服務器，但與Web服務器不一樣的是，它們能夠發起與其它服務器的通訊。
6. 內容路由器：根據因特網流量情況以及內容類型將請求導向特定的Web服務器。
7. 轉碼器：代理服務器在將內容發送給客戶端以前，能夠修改內容的主題格式。在這些表示法之間進行透明轉換成爲轉碼，如將GIF圖片轉換爲JPG圖片，以減少尺寸；

代理服務器的部署：

1. 出口代理：能夠將代理固定在本地網絡的出口點，以便控制本地網絡與大型因特網之間的流量；
2. 入口代理：常被放在ISP訪問點上，用以處理來自客戶的聚合請求；
3. 反向代理：一般會被部署在網絡邊緣，在 Web服務器 以前，做爲替代物使用。在那裏它們能夠處理全部傳送給 Web服務器的請求，並只在必要時向Web服務器請求資源；
4. 網絡交換代理：能夠將具備足夠處理能力的代理放在網絡之間的因特網對等交換點上，經過緩存來減輕因特網節點的擁塞，並對流量進行監控；
5. 代理的層次結構：能夠經過代理層次結構將代理級聯起來。在層次結構中，代理服務器被賦予了父和子的關係，下一個入口代理<靠近服務器>被成爲父代理，下一個出口<靠近客戶端>被成爲子代理；
6. 負載均衡：子代理可能會根據當前父代理的工做負載級別來決定如何選擇一個父代理， 以均衡負載；
7. 地理附近的路由：子代理可能會選擇負責原始服務器所在物理區域的父代理；
8. 協議 / 類型路由：子代理可能會根據 URI 將報文轉發到不一樣的父代理和原始服務器上去。某些特定的 URL 可能要經過一些特殊的代理服務器轉發請求，以便進行特殊的協議處理；
9. 基於訂購的路由：若是發佈者爲高性能服務額外付費，它們的URI就會被轉發到大型緩存或壓縮引擎上，以提升性能；

代理是如何獲取流量的？

有 四種 常見方式可使客戶端流向代理：

1. 修改客戶端：若是將客戶端配置爲使用代理服務器，客戶端就會將HTTP請求有意地發送給代理；
2. 修改網絡：依賴監視HTTP流量的交換設備及路由設備，在客戶端絕不知情的狀況下，將其進行攔截，並將流量導入一個代理，這種代理被成爲攔截代理；
3. 修改DNS的命名空間：編輯DNS名稱列表，或者用特殊的動態DNS服務器根據須要來肯定適當的代理或服務器；
4. 修改Web服務器：將某些Web服務器配置爲想客戶端發送一條HTTP重定向命令（305），將客戶端請求定向到一個代理上去；

客戶端的代理設置：

1. 手工配置：顯式地設置要使用的代理；
2. 預先配置瀏覽器：瀏覽器廠商或發行商會在瀏覽器發送其客戶以前預先對瀏覽器的代理設置進行手工設置；
3. 代理的自動設置：提供一個 URI，指向一個用 Javascript語言 編寫的代理自動配置文件，客戶端或讀取這個 Javascript 文件，並運行它以決定是否應該使用一個代理，若是是，應該使用哪一個代理服務器；
4. WPAD的代理髮現：有些瀏覽器支持 Web代理自動發現協議（Web Proxy Auto Discovery: WPAD） 這個協議會自動檢測出瀏覽器能夠從哪一個「配置服務器」下載到一個自動配置文件；

實現WPAD協議的客戶端須要：

1. 用WPAD找到PAC的URI；
2. 從指定的URI獲取PAC文件；
3. 執行PAC文件來斷定代理服務器；
4. 爲請求使用代理服務器；

代理請求的一些問題

客戶端向Web服務器發送請求時，請求行中只包含部分URI（沒有方案、主機或端口），但當客戶端向代理髮送請求時，請求行中則包含完整的URI。

HTTP/1.1 要求服務器爲代理請求和服務器請求都提供完整的URI處理，但實際上，不少已經部署的服務器仍然只接受部分URI。根據是否有代理，瀏覽器對URI的解析會有所不一樣。沒有代理時，瀏覽器會獲取你輸入的URI，嘗試着尋找相應的IP地址，若是找到了主機名，瀏覽器會嘗試相應的IP地址知道獲取到成功的鏈接爲止。若是沒有找到主機，不少瀏覽器都會嘗試着提供某種主機名自動「擴展」機制，以防用戶輸入的是「簡短」的縮寫形式。例如：當你輸入 yahoo 時，大多數瀏覽器都會自動將其擴展成 www.yahoo.com，相似地，瀏覽器容許用戶省略前綴，http://，若是省略了瀏覽器會自動插入。當使用顯式代理時，用戶的URI會將直接發送給代理，因此瀏覽器就再也不執行這些便捷操做了。

Via首部

Via首部 列出了與報文途徑的每一箇中間節點（代理或網關）有關的信息，報文每通過一個節點，都必須將這個中間節點添加到Via列表的末尾。

例如： 
Via： 1.1 Proxy – 6.2 . irenes – isp.net （第一個代理名，實現了HTTP/1.1）
      1.0 cache – joes – hardwave.com （第二個代理名，實現了HTTP/1.0）

Via語法： Via首部字段信息包含一個由逗號分隔的路標，每一個路標都表示一個獨立的代理服務器或網關，且包含與那個中間節點的協議和地址有關的信息。

每一個Via路標中最多包含4個組件：

1. 一個可選協議名，默認爲HTTP
2. 一個必選協議版本
3. 一個必選的節點名
4. 可選的描述行註釋

協議名： 中間點收到的協議。若是協議爲HTTP的話，協議名就是可選的。不然，要在版本以前加上協議名，中間用「/」分隔，網關將HTTP請求鏈接其它協議時，可能會使用非HTTP協議；
協議版本： 版本的格式與協議有關；
節點名： 中間節點的主機和可選端口號；
節點註釋： 進一步描述這個中間節點的可選註釋。一般會在這裏包含廠商和版本信息；

請求和響應報文都會通過代理進行傳輸，所以，請求和報文中都要有Via首部，可是響應Via一般與請求Via相反。

OPTIONS首部：發現對可選特性的支持

經過 HTTP OPTIONS 方法，客戶端能夠發現Web服務器或者其上某個特定資源所支持的功能（好比：它們所支持的方法），經過使用 OPTIONS，客戶端能夠在與服務器進行交互以前，肯定服務器的能力，這樣就能夠方便地與具有不一樣特性的代理和服務器進行交互了。若是OPTIONS請求的URI是個*，請求的是整個服務器所支持的功能。若是成功，OPTIONS方法就會返回一個包含了各類首部字段的 200 OK 迴應，這些字段描述了服務器所支持的，或資源可用的各類可選特性。

Allow首部：

列出了請求URI標識的資源所支持的方法列表，若是請求URL爲 *的話，列出的就是整個服務器所支持的方法列表。