今天主要總結關於閘道器、隧道及中繼的內容。

首先介紹一下閘道器是什麼？

閘道器可以作為某種翻譯器使用，它抽象出了一種能夠到達資源的方法。閘道器是應用程式和資源的粘合劑。

Web閘道器在一側使用HTTP協議，在另一側使用另一種協議。
<客戶端協議>/<伺服器端協議>
比如：
伺服器端閘道器通過HTTP與客戶端對話，通過其他協議與伺服器通訊（HTTP/*）
客戶端閘道器通過與其他協議與客戶端對話，通過HTTP與伺服器通訊（*/HTTP）

下面詳細介紹：
HTTP/*：服務端Web閘道器：
請求流入原始伺服器時，伺服器端與Web閘道器會將客戶端HTTP請求轉換為其他協議。

閘道器會開啟一條到原始伺服器FTP埠的FTP連線，通過FTP協議獲取物件。閘道器會做下列事情：
1.傳送USER和PASS命令登入到伺服器上去
2.釋出CWD命令，轉移到伺服器上合適的目錄中去
3.將下載型別設定為ASCII
4.用MDTM獲取文件的最後修改時間
5.PASV告訴伺服器將有被動資料獲取請求到達
6.用RETR請求進行物件獲取
7.開啟到FTP伺服器的資料連線，伺服器埠由控制通道返回，一旦資料通道打開了，就將物件內容回送給閘道器

HTTP/HTTPS：伺服器端安全閘道器：
一個組織可以通過閘道器對所有的輸入Web請求加密，以提高額外的隱私和安全性保護。客戶端可以用普通的HTTP瀏覽Web內容，但閘道器會自動加密使用者的對話。
HTTPS/HTTP客戶端安全加速器閘道器：
這些HTTPS/HTTP閘道器位於Web伺服器之前，通常作為不可見的攔截閘道器或反向代理使用，它們接收安全的HTTPS流量，對安全流量進行解密，並向Web伺服器傳送普通的HTTP請求。這些閘道器中通常都包含專用的解密硬體，以比原始伺服器有效的多的方式解密安全流量，以減輕原始伺服器的負荷。這些閘道器在閘道器和原始伺服器之間傳送的是未加密的流量，所以確保閘道器和原始伺服器之間的網路是安全的。

下面講資源閘道器？

最常見的閘道器，應用程式伺服器，會將目標伺服器與閘道器結合在一個伺服器中實現。應用程式伺服器是伺服器端閘道器，與客戶端通過HTTP進行通訊，並與伺服器端的應用程式相連。

1.收到客戶端A的請求，根據URI將其通過API傳送給一個數碼攝像機應用程式。將得到的圖片繫結到一條HTTP響應報文中，再回送給客戶端。在客戶端的瀏覽器中顯示。
2.客戶端B的URI請求的是一個電子商務應用程式。客戶端B的請求是通過伺服器閘道器API傳送給電子商務軟體的，結果會被回送給瀏覽器。電子商務軟體與客戶端進行互動，引導使用者通過一系列HTML頁面來完成購物。

第一個流行的應用程式閘道器API就是通過閘道器介面（CGI）。CGI是一個標準介面集，Web伺服器可以用它來裝載程式以響應對特定URL的HTTP請求，並收集程式的輸出資料，將其放在HTTP響應中回送。

下面將Web服務？

Web服務可以用XML通過SOAP來交換資訊。XML提供了一種建立資料物件的定製資訊，並對其進行解釋的方法。SOAP（簡單物件訪問協議）是向HTTP報文中新增XML資訊的標準方式。

隧道？

Web隧道可以通過HTTP應用程式訪問使用非HTTP協議的應用程式。Web隧道允許使用者通過HTTP連線傳送非HTTP流量，這樣就可以再HTTP上捎帶其他協議資料。

如何用CONNECT建立HTTP隧道？

CONNECT方法請求隧道閘道器建立一條到達任意目的伺服器和埠的TCP連線，並對客戶端和伺服器之間的後繼資料進行盲轉發。

1.CONNECT請求
除了起始行之外，CONNECT的語法跟其他HTTP方法類似。一個後面跟著冒號和埠號的主機名取代了請求URI。主機和埠都必須指定。
2.CONNECT響應
和普通HTTP報文一樣，響應碼200表示成功。響應中的原因短語通常被設定為“Connection Estabilished”。與普通HTTP響應不同，這個響應不需要包含Content-Type首部，此時連線只是對原始位元組進行轉接，不再是報文的承載者，所以不需要使用內容型別了。

接下來講資料隧道，定時及連線管理？

管道化資料對閘道器是不透明的，所以閘道器不能對分組的順序和分組流作任何假設。一旦隧道建立起來了，資料就可以在任意時間流向任意方向了。
作為一種效能優化方法，允許客戶端在傳送了CONNECT請求之後，接收響應之前，傳送隧道資料。尤其是，閘道器不能假設網路I/O請求只會返回首部資料，閘道器必須確保在連線準備就緒時，將與首部一同讀進來的資料傳送給伺服器。在請求之後以管道方式傳送資料的客戶端，如果發現回送的響應是認證請求，或者其他非200但不致命的錯誤狀態，就必須做好重發請求資料的準備。
如果在任意時刻，隧道的任意一個端點斷開了連線，那個端點發出的所有未傳輸資料都會被傳送給另一個端點，之後，到另一個端點的連線也會被代理終止。如果還有資料要傳輸給關閉連線的端點，資料會被丟棄。

SSL隧道？

最初開發Web隧道是為了通過防火牆來傳輸加密的SSL流量。很多組織都會將所有流量通過分組過濾路由器和代理伺服器以隧道方式傳輸，以提升安全性。但有些協議，比如加密SSL，其資訊是加密的，無法通過傳統的代理伺服器轉發。隧道會通過一條HTTP連線來傳輸SSL流量，以穿過埠80的HTTP防火牆。

SSL隧道與HTTP/HTTPS閘道器的對比？

可以像其他協議一樣，對HTTPS協議（SSL上的HTTP）進行閘道器操作：由閘道器（而不是客戶端）初始化與遠端HTTPS伺服器的SSL會話，然後代表客戶端執行HTTPS事務。響應會由代理接收並解密，然後通過（不安全的）HTTP傳送給客戶端，這是閘道器處理FTP的方式，但這種方式有幾種缺點：
1.客戶端到閘道器之間的連線時普通的非安全的HTTP
2.儘管代理是已認證主體，但客戶端無法對遠端伺服器執行SSL客戶端認證（基於X509證書的認證）

注意，對於SSL隧道機制來說，無需在代理中實現SSL。SSL會話是建立在產生請求的客戶端和目的（安全的）Web伺服器之間的，中間的代理伺服器只是將加密資料和經過隧道傳輸，並不會在安全事務中扮演其他的角色。

隧道認證：

隧道的安全性考慮：隧道閘道器無法驗證目前使用的協議是否就是它原本打算經過隧道傳輸的協議。因此，惡意使用者會通過隧道做些事。

中繼？

HTTP中繼是沒有完全遵循HTTP規範的簡單HTTP代理。中繼負責處理HTTP中建立連線的部分，然後對位元組進行盲轉發。
之前介紹過的盲中繼就是實現中存在的一個常見問題。