今天主要總結的是Web伺服器與代理。

先從Web伺服器開始。

Web伺服器是如何實現的？

Web伺服器實現了HTTP和相關的TCP連線處理。負責管理Web伺服器提供的資源，以及對Web伺服器的配置、控制及擴充套件方面的管理。
Web伺服器邏輯實現了HTTP協議，管理者Web資源，並負責提供Web伺服器的管理功能。Web伺服器邏輯和作業系統共同負責管理TCP連線。底層作業系統負責管理底層計算機的硬體細節，並提供TCP/IP網路支援，負載裝載Web資源的檔案系統以及控制當前計算活動的程序管理功能。

那麼實際中Web伺服器會做些什麼呢？

1.建立連線——接受一個客戶端的連線，或者如果不希望與這個客戶端建立連線，就將其關閉。
2.接收請求——從網路中讀取一條HTTP請求報文
3.處理請求——對請求報文進行解釋，並採取行動
4.訪問資源——訪問報文中指定的資源
5.構建響應——建立帶有正確首部的HTTP響應報文
6.傳送響應——將響應回送給客戶端
7.記錄事務處理過程——將與已完成事務有關的內容記錄在一個日誌檔案中。

下面進行各個步驟的詳細講解：
第一步：接收客戶端連線。如果客戶端已經打開了一條到伺服器的持久連線，可以使用那條連線來發送它的請求。否則，客戶端需要開啟一條新的到伺服器的連線。
如何處理新連線？
客戶端請求一條到Web伺服器的TCP連線時，Web伺服器會建立連線，判斷連線的另一端是哪個客戶端，從TCP連線中將IP解析出來。一旦新連線建立起來並被接受，伺服器就會將新連線新增到其現存Web伺服器連線列表中，做好監視連線上資料傳輸的準備。
Web伺服器可以隨意拒絕或立即關閉任意一條連線。有些Web伺服器會因為客戶端IP地址或主機名是未認證的，或者因為它是已知的惡意客戶端而關閉連線。
客戶端主機名識別可以通過：1.反向DNS解析 2.通過ident協議確定客戶端使用者

第二步：接收請求報文。連線上有資料到達時，Web伺服器會從網路連線中讀取資料，並將請求報文中的內容解析出來。

解析請求報文時，Web伺服器會：
1.解析請求行，查詢請求方法，指定的資源識別符號（URI）以及版本號，各項之間由一個空格分隔，並以一個回車換行（CRLF）序列作為行的結束。
2.讀取以CRLF結尾的報文首部
3.檢測到以CRLF結尾的、標識首部結束的空行（如果有的話）
4.如果有的話（長度由Content-Length首部指定），讀取請求主體

解析請求報文時，Web伺服器會不定期地從網路上接收輸入資料。網路連線可能隨時都會出現延遲，Web伺服器需要從網路中讀取資料，將部分報文資料臨時儲存在記憶體中，知道收到足以進行解析的資料並理解其意義。

高效能的Web伺服器能夠同時支援數千條連線。每個客戶端都向伺服器打開了一條或多條連線。下面列舉不同的Web伺服器結構：
1.單執行緒Web伺服器：一次只處理一個請求，直到其完成為止。一個事務處理結束之後，才去處理下一條連線，這種結構易於實現，但在處理過程中，所有其他的連線都會被忽略，這樣會造成嚴重的效能問題，只適用於低負荷的伺服器。
2.多程序及多執行緒Web伺服器：用多個程序，或更高效的執行緒同時對請求進行處理，但當伺服器同時要處理成百上千，甚至數以萬計的連線時，需要的程序或執行緒數量可能會消耗太多的記憶體或系統資源。因此很多多執行緒Web伺服器都會對執行緒/程序最大數量進行限制。
3.複用I/O的伺服器：為了支援大量的連線，很多Web伺服器都採用了複用結構。在複用結構中，要同時監視所有連線上的活動。當連線的狀態發生變化時（比如有資料可用，或出現錯誤時），就對那條連線進行少量的處理，處理結束之後，將連線返回到開放連線列表中，等待下一次狀態變化。只有在有事情可做時才會對連線進行處理，在空閒連線上等待的時候並不會繫結執行緒和程序。
4.複用的多執行緒Web伺服器：將多執行緒和複用功能結合在一起，以利用計算機平臺上的多個CPU

第三步：處理請求。一旦伺服器收到了請求，就可以根據方法、資源、首部和可選的主體部分來對請求進行處理。

第四步：對資源的對映及訪問。在Web伺服器將內容傳送給客戶端之前，要將請求報文中的URI對映為Web伺服器上適當的內容或內容生成器，以識別出內容的源頭。
Web伺服器支援各種不同型別的資源對映，但最簡單的資源對映形式就是用請求URI作為名字來訪問Web伺服器檔案系統中的檔案。Web伺服器的檔案系統中會有一個特殊的資料夾專門用於存放Web內容，這個資料夾被稱為文件的根目錄（docroot）。
當有一個/specials/saw-blade.gif的請求到達。伺服器的根目錄為/usr/local/httpd/files。Web伺服器會返回檔案/usr/local/httpd/files/specials/saw-blade.gif

伺服器要注意，不能讓相對URL退到docroot之外，將檔案系統的其餘部分暴露出來。比如查詢../。
下面講述虛擬託管的docroot。
虛擬託管的Web伺服器會在同一臺Web伺服器上提供多個Web站點，每個站點在伺服器上都有自己獨有的文件根目錄。虛擬託管Web伺服器會根據URI或HOST首部的IP地址或主機名來識別要使用的正確文件根目錄。

對常見的Apache Web伺服器來說，需要為每個虛擬Web站點配置一個VirtualHost塊，而且每個虛擬伺服器都要包含DocumentRoot

docroot的另一種常見應用是在Web伺服器上為人們提供私有的Web站點。通常會把那些以斜槓和波浪號（/~）開始，後面跟著使用者名稱的URI對映為此使用者的私有文件根目錄。私有docroot通常都是使用者主目錄下那個名為public_html的目錄，但也可以重新配置

Web伺服器中的目錄列表：
Web伺服器可以接受對目錄URL的請求，其路徑可以解析為一個目錄，而不是檔案。我們可以對大多數Web伺服器進行配置，使其在客戶端請求目錄URL時採取不同的動作
1.返回一個錯誤
2.不返回目錄，返回一個特殊的預設“索引檔案”
3.掃描目錄，返回一個包含目錄內容的HTML頁面
在Apache Web伺服器上，可以用配置指令DirectoryIndex會按照優先順序列出所有可以作為目錄索引檔案使用的檔名，如：
DirectoryIndex index.html index.htm home.html home.htm index.cgi
如果使用者請求目錄URI時，沒有提供預設的索引檔案，而且沒有禁止使用目錄索引，很多Web伺服器都會自動返回一個HTML檔案，此檔案中會列出那個目錄裡的檔名，以及每個檔案的大小和修改日期，還包括到每個檔案的URI連結。可以通過以下Apache指令禁止自動生成目錄索引：
Options-Indexes
動態內容資源的對映：

Web伺服器還可以將URI對映為動態資源，Web伺服器要能夠分辨出資源什麼時候是動態，動態內容生成程式位於何處，以及如何執行那個程式。
Apache允許使用者將URI路徑名元件對映為可執行檔案目錄。伺服器收到一條帶有可執行路徑元件的對URI的請求時，會試著執行相應伺服器目錄中的程式。例如，Apache配置指令就表明所有路徑以/cgi-bin/開頭的URI都應該執行在目錄/usr/local/etc/httpd/cgi-programs/中找到相應檔案：
ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-programs

Web伺服器還可以為特定資源進行訪問控制，有請求到達，要訪問受控資源時，Web伺服器可以根據客戶端的IP地址進行訪問控制，也可以要求輸入密碼來訪問資源。

第五步：構建響應。一旦Web伺服器識別出了資源，就執行請求方法中描述的動作，並返回響應報文。響應報文中包含有響應狀態碼、響應首部，如果生成了響應主體的話，還包括響應主體。
其中響應實體通常包括：
1.描述了響應主體MIME型別的Content-Type首部
2.描述了響應主體長度的Content-Length首部
3.實際報文的主體內容

Web伺服器要負責確定響應主體的MIME型別，Web伺服器可以用檔案的副檔名來說明MIME型別。

有魔法分類:Apache Web伺服器可以掃描每個資源的內容，並將其與一個已知模式表（被稱為魔法檔案）進行匹配，以決定每個檔案的MIME型別，這樣做可能比較慢，但很方便，尤其是檔案沒有標準副檔名的時候
顯示分類：可以對Web伺服器進行配置，使其不考慮問價你的副檔名或內容，強制特定檔案或目錄內容擁有某個MIME型別。
型別協商：有些Web伺服器經過配置，可以以多種文件格式來儲存資源。可以配置Web伺服器，使其可以通過與使用者的協商來決定使用哪種格式。

Web伺服器也可能返回重定向響應。重定向用於下列情況：
1.永久刪除的資源
2.臨時刪除的資源
3.URL增強
4.負載均衡
5.伺服器關聯
6.規範目錄名稱

第六步：傳送響應。Web伺服器通過傳送資料時也會面臨與接收資料一樣的問題。伺服器可能有很多條到各個客戶端的連線。伺服器要記錄連線的狀態，還要特別注意對持久連線的處理，連線可能仍保持開啟狀態，要正確地計算Content-Length首部，不然客戶端就無法知道響應什麼時候結束了

第七部：記錄日誌。當事務結束時，Web伺服器會在日誌檔案中新增一個條目，來描述已執行的事務。

下面來介紹代理！

代理與閘道器的對比？

嚴格來說，代理連線的是兩個或多個使用相同協議的應用程式，而閘道器連線的則是兩個或多個使用不同協議的端點。

但實際上，代理和閘道器之間的區別很模糊。由於瀏覽器和伺服器實現的是不同版本的HTTP，代理也經常要做一些協議轉換工作。而商業化的代理伺服器也會實現閘道器的功能來支援SSL安全協議，SOCKS防火牆，FTP訪問，以及基於Web的應用程式。

那麼為什麼使用代理？

代理伺服器可以改善安全性，提高效能，節省費用。代理伺服器可以看到並接觸到所有流過的HTTP流量，所以代理可以監視流量並對其進行修改，以實現很多增值Web服務。如：
1.兒童過濾器：可以利用過濾器來阻止學生訪問成人內容

2.文件訪問控制：可以用代理伺服器在大量Web伺服器和Web資源之間實現統一的訪問控制策略，建立稽核跟蹤機制。如：

集中式訪問控制代理：

（1）.允許客戶端1無限制地訪問伺服器A的新聞頁面
（2）.客戶端2可以無限制地訪問因特網
（3）.在允許客戶端3訪問伺服器B之前，要求其輸入口令

3.安全防火牆：網路安全工程師通常會使用代理伺服器來提高安全性。代理伺服器會在網路中的單一安全節點上限制哪些應用層協議的資料可以流入或流出一個組織。還可以提供用來消除病毒的掛鉤程式。

4.Web快取：代理快取維護了常用文件的本地副本，並將它們按需提供，以減少緩慢且昂貴的因特網通訊。

5.反向代理：代理可以假扮Web伺服器，接收發給Web伺服器的真實請求，發起與其他伺服器的通訊，以便按需定位所請求的內容。

6.內容路由器：可以根據因特網流量狀況以及內容型別將請求導向特定的Web伺服器

7.轉碼器：代理伺服器在將內容傳送給客戶端之前，可以修改內容的主體格式，轉碼代理可以再傳輸GIF圖片時，將其轉換成JPEG圖片，以減少尺寸等等。

8.匿名者：匿名者代理會主動從HTTP報文中刪除身份特性（比如客戶端IP地址、From首部、Referer首部、cookie、URI的會話ID），從而提高高度的私密性和匿名性。

代理會去往何處?

部署代理伺服器的幾種方式：
1.出口代理：可以將代理固定在本地網路的出口點，以便控制本地網路與大型因特網之間的流向。可以在公司網路中使用出口代理，提供針對公司外部惡意黑客的防火牆保護，或降低頻寬費用，提高因特網流量的效能。
2.訪問（入口）代理：代理長飛放在ISP（網際網路服務提供商）訪問點上，用以處理來自客戶的聚合請求。ISP使用快取代理來儲存常用文件的副本，以提高使用者（尤其是高速連線使用者）的下載速度，降低因特網頻寬耗費
3.反向代理：通常會被部署在網路邊緣，在Web伺服器之前。在那裡它們可以處理所有傳送給Web伺服器的請求，並只在必要時向Web伺服器請求資源。替代物可以提高Web伺服器的安全特性，或者將快速的Web伺服器快取放在較慢的伺服器之前，以提高效能。方向代理通常會直接毛用Web伺服器的名字和IP地址，這樣所有的請求就會被髮送給代理而不是伺服器了。
4.網路交換代理：可以將具有足夠處理能力的代理放在網路之間的因特網對等交換點上，通過快取來減輕因特網節點的擁塞，並對流量進行監視。

代理的層次結構？

可以通過代理層次結構將代理級聯起來。如：

會將報文從一個代理傳給另一個代理，直到最終抵達原始伺服器為止。
Proxy層次結構中代理伺服器被賦予了父和子的關係。靠近伺服器被稱為父代理，靠近客戶端被稱為子代理。
代理層次結構不一定非得是靜態的。如：

如果所請求的物件屬於一個付費使用內容分發服務的Web伺服器，代理就會將請求傳送給附近的一個快取伺服器，這個伺服器會返回已返回已快取物件，或者如果它那沒有的話，它會去取回內容。
如果請求的是特定型別的圖片，訪問代理會將請求轉發給一個特定的壓縮代理，這個代理會去獲取圖片，然後對其進行壓縮，這樣通過客戶端的慢速Modem下載時，速度會更快一些。
還有幾個動態選擇父代理的列子：
1.負載均衡：子代理可能會根據當前父代理上的工作負載級別來決定如何選擇一個父代理，以均衡負載
2.地理位置附近的路由：子代理可能會選擇負責原始伺服器所在物理區域的父代理
3.協議/型別路由：子代理可能會根據URI將報文轉發到不同的父代理和原始伺服器上去。某些特定型別的URI可能要通過一些特殊的代理伺服器轉發請求，以便進行特殊的協議處理。
4.基於訂購的路由：如果釋出者為高效能服務額外付費了，它們的URI就會被轉發到大型快取或壓縮引擎上去，以提高效能。

代理是如何獲取流量的？

有四種常見方式可以使客戶端流量流向代理：
1.修改客戶端：很多Web客戶端都支援手工和自動的代理配置。如果將客戶端配置為使用代理伺服器，客戶端就會將HTTP請求有意地直接傳送給代理，而不是原始伺服器。
2.修改網路：網路基礎設施可以通過若干種計數手段，在客戶端不知道，或沒有參與的情況下，攔截網路流量並將其匯入代理。這種攔截通常都依賴於監視HTTP流量的交換裝置及路由裝置，在客戶端毫不知情的情況下，對其進行攔截，並將流量匯入一個代理。這種代理被稱為攔截代理。
3.修改DNS的名稱空間：放在Web伺服器之前的代理伺服器——替代物，會直接假扮Web伺服器的名字和IP地址，這樣，所有的請求就會發送給這些替代物，而不是伺服器了。要實現這一點，可以手工編輯DNS名稱列表，或者用特殊的動態DNS伺服器根據需要來確定適當的代理或伺服器。有時在安裝過程中，真實伺服器的IP地址和名稱被修改了，替代物得到的會是之前的地址和名稱。
4.修改Web伺服器：也可以將某些伺服器配置為向客戶端傳送一條HTTP重定向命令，將客戶端請求重定向到一個代理上去。收到重定向命令後，客戶端會與代理進行通訊。

客戶端的代理設定？

很多瀏覽器都提供了多種配置代理的方式，包括：
1.手工配置：顯式地設定要使用的代理
2.預先配置瀏覽器：瀏覽器廠商或發行商會在瀏覽器傳送給其客戶之前預先對瀏覽器的代理設定進行手工設定
3.代理的自動配置：提供一個URI，指向一個用JavaScript語言編寫的代理自動配置檔案；客戶端會取回這個JavaScript檔案，並執行它以決定是否應該使用一個代理，如果是的話，應該使用哪個代理
4.WPAD的代理髮現：有些瀏覽器支援Web代理自動發現協議（WPAD），這個協議會自動檢測出瀏覽器可以從哪個“配置伺服器”下載到一個自動配置檔案

與代理請求有關的一些棘手問題？

代理URI和伺服器URI的不同？
客戶端向Web伺服器傳送請求時，請求行中只包含部分URI（沒有方案、主機或埠）如：
GET /index.html HTTP/1.0
但當客戶端向代理髮送請求時，請求行中則包含完整的URI。如：
GET http://www.marys-antiques.com/index.html HTTP/1.0

為什麼會有兩種不同的請求格式，一種用於代理，另一種用於伺服器？在原始的HTTP設計中，客戶端會直接與單個伺服器進行對話。不存在虛擬機器，也沒有為代理制定什麼規則。單個的伺服器都知道自己的主機名和埠。所以為了避免傳送冗餘資訊，客戶端只需傳送部分URI即可，無需傳送方案和主機以及埠。
代理出現之後，使用部分URI就有問題了。代理需要知道目標伺服器的名稱，這樣它們才能建立自己與伺服器的連線。基於代理的閘道器要知道URI的方案才能連線到FTP資源和其他方案上去。HTTP/1.0要求代理請求傳送完整的URI，解決了這個問題，但它為伺服器請求保留部分URI的形式（已經有相當多的伺服器都改為支援完整URI）
因此，我們要將部分URI傳送給伺服器，將完整的URI傳送給代理。

與虛擬主機一樣的問題？
虛擬主機Web伺服器會在很多Web站點間共享同一個物理Web伺服器。包含部分URI的請求到達時，虛擬主機Web伺服器需要知道目的Web站點的主機名。與上一個問題相似，但是解決方法不同：
1.顯式的代理要求在請求報文中使用完整的URI來解決這個問題
2.虛擬主機Web伺服器要求使用Host首部來承載主機和埠資訊。

攔截代理會收到部分URI？
客戶端並不總是知道它是在和代理對話，因為有些代理對客戶端是不可見的。客戶端的流量可能會經過替代物或攔截代理，在這兩種情況下，客戶端都會認為它在與Web伺服器進行對話，不會發送完整的URI。如：
如前所述，反向代理是一個用來取代原始伺服器的代理伺服器，它通常會通過假扮伺服器的主機名和IP地址來做到這一點。它會收到Web伺服器請求，可能會向真正的伺服器提供快取的響應或者代理請求。客戶端無法區別反向代理和Web伺服器，因此它會發送部分URI
攔截代理是網路流量中的代理伺服器，它會攔截從客戶端發往伺服器的請求，並提供一個快取響應，或對其進行轉發。由於攔截代理攔截了從客戶端到伺服器的流量，所以它會收到傳送給Web伺服器的部分URI

代理既可以處理代理請求，也可以處理伺服器請求？
由於將流量重定向到代理伺服器的方式有所不同，通用的代理伺服器既應該支援請求報文中的完整URI，也應該支援部分URI。規則如下：
1.如果提供的是完整的URI，代理就應該使用這個完整的URI
2.如果提供的是部分URI，而且有Host首部，就應該用Host首部來確定原始伺服器的名字和埠號。
3.如果提供的是部分URI，而且沒有Host首部，有三種方法：
（1）如果代理是代表原始伺服器的替代物，可以用真實伺服器的地址和埠號來配置代理
（2）如果流量被攔截了，而且攔截者也可以提供原始的IP地址和埠，代理就可以用攔截技術提供的IP地址和埠號。
（3）如果所有方法都失敗了，代理沒有足夠的資訊來確定原始伺服器，就必須返回一條錯誤報文

轉發過程中對URI的修改？
代理伺服器要在轉發報文時修改請求URI的話，需要特別小心，對URI的微小修改，甚至是看起來無害的修改，都可能給下游伺服器帶來一些互操作性的問題。

URI的客戶端自動擴充套件和主機名解析？
根據是否有代理，瀏覽器對請求URI的解析會有所不同。沒有代理時，瀏覽器如果沒有找到主機，很多瀏覽器都會嘗試提供某種主機名自動“擴充套件”機制。

代理時URI的解析？
使用顯式代理時，使用者的URI會直接傳送給代理，所以瀏覽器就不再執行所有便捷的擴充套件功能了。

有攔截代理時URI的解析？
使用不可見的攔截代理時，對主機名的解析會略有不同，因為對客戶端來說，是沒有代理的，這是瀏覽器會自動擴充套件主機名，直到DNS成功為止。

在第（1）步中，使用者瀏覽器的URI地址視窗輸入oreilly。
在第（2a）步中，瀏覽器通過DNS查詢主機oreilly，但DNS伺服器失敗了，並回送響應說明主機為止，如第（2b）步所示
在第（3a）步中，瀏覽器進行自動擴充套件，將oreilly轉換成www.oreilly.com。在第（3b）步中，DNS解析成功,將IP地址返回給了瀏覽器
在第（4a）步中，客戶端已經成功解析了主機名，並有了一張IP地址列表。有些IP地址可能已經停用了。所以通常客戶端會嘗試著連線每個IP地址，直到成功為止。但對攔截代理來說，第一次連線請求就會被代理伺服器攔截成功，不會連線到原始伺服器上去，客戶端認為它與Web伺服器進行成功的對話，但那個Web伺服器可能甚至都不處於活躍狀態
在第（5b）步，代理與真正原始伺服器進行互動時。可能會發現那個IP地址實際指向的是一個已停用的伺服器，為了提供與瀏覽器相同級別的容錯機制，代理可以通過解析Host首部的主機名，也可以通過對IP地址的方向DNS查詢來嘗試其他IP地址。對攔截和顯式代理實現來說，在DNS解析到已經停用的伺服器時，提供容錯機制很重要。

追蹤報文？

很多公司都會用快取代理伺服器來訪問因特網。

隨著代理的逐漸流行，我們要能夠追蹤經過代理的報文流，以檢測出各種問題，其重要性就跟追蹤經過不同交換機和路由器傳輸的IP分組流一樣。

Via首部？
Via首部欄位列出了與報文途徑的每個中間節點（代理或閘道器）有關的資訊。報文每經過一個節點，都必須將這個中間節點新增到Via列表的末尾。如：

說明第一個代理名proxy-62.irenes-isp.net實現了HTTP/1.1協議，另一個是實現了HTTP/1.0
代理也可以用Via首部來檢測網路中的路由迴圈。代理應該在傳送一條請求之前，在Via首部插入一個與其自身有關的獨特字串，並在輸入的請求中查詢這個字串，已檢測網路中是否存在路由迴圈。
每個Via路標中最多包含4個元件：一個可選的協議名（預設為HTTP）、一個必選的協議版本，一個必選的節點名和一個可選的描述性註釋

Via與閘道器？
有些代理會為使用非HTTP協議的伺服器提供閘道器的功能。Via首部記錄了這些協議的轉換。這樣HTTP應用程式就會了解代理鏈上各點的協議處理能力以及所做的協議轉換了。

Via的隱私和安全問題？
有時候我們並不希望在Via字串中使用確切的主機名。除非顯式地允許這種行為，否則當代理伺服器作為網路防火牆的一部分使用時，是不應該轉發防火牆後面那些主機名的名字和埠號的。
如果不允許進行Via節點名轉發，作為安全防線的一部分使用的代理就應該用適當的假名來取代那臺主機的名字。一般來說，即使隱藏了真實名稱，代理也應該嘗試著為每臺代理伺服器保留一個Via路標條目。

Trace方法？

通過HTTP/1.1的Trace方法，使用者可以跟蹤經代理鏈傳輸的請求報文，觀察報文。Trace對代理流的除錯非常有用。

其中有一個max-forwards首部來限制trace和options請求所經過的代理跳數。Max-Forwards請求首部欄位包含了一個整數，如果值為0，那麼即使接受者不是原始伺服器，它也必須將Trace報文回送給客戶端，而不應該繼續轉發，如果收到的值大於0，轉發的報文中就必須包含一個更新了的Max-Forwards欄位，其值會被減一。

代理認證？

代理可以作為訪問控制裝置使用。HTTP定義了一種名為代理認證的機制，這種機制可以組織對內容的請求，直到使用者向代理提供了有效的訪問許可權證書為止。

步驟如下:
1.對受限內容的請求到達一臺代理伺服器時，代理伺服器可以返回一個要求使用訪問證書的407Proxy Authorization Required狀態碼
2.客戶端收到407響應時，會嘗試著從本地資料庫或通過提示使用者來蒐集所需要的證書
3.只要獲得了證書，客戶端就會重新發送請求，在Proxy-Authorization首部欄位中提供所要求的證書。
4.如果證書有效，代理就會將原始請求沿著傳輸鏈路向下傳送，否則就傳送另一條407應答。
若傳輸鏈路中有多個代理，且每個代理都要進行認證時，代理認證通常無法很好的工作。人們建議，應該對HTTP進行升級，將認證證書與代理鏈中特定的路標聯絡起來，但這些升級措施並沒有得到廣泛實現。