記錄 ---- 網關、隧道及中繼

網關、隧道及中繼

Web是一種強大的內容發佈工具。隨着時間的流逝，人們已經從只在網上發送靜態的在線文檔，發展到共享更復雜的資源，好比數據庫內容或動態生成的HTML頁面。Web瀏覽器這樣的HTTP應用程序爲用戶提供了一種統一的方式來訪問因特網上的內容。HTTP也已成爲應用程序開發者的一種基本構造模塊，開發者們能夠在HTTP上捎回其餘的協議內容(好比，能夠將其餘協議的流量包裹在HTTP中)。Web上全部的資源均可以使用HTTP協議，並且其餘應用程序和應用程序協議也能夠利用HTTP來完成它們的任務。

網關

HTTP擴展和接口的發展是由用戶需求驅動的。要在Web上發佈更復雜資源的需求出現時，人們很快就明確了單個應用程序沒法處理全部這些能想到的資源。爲了解決這個問題，開發者提出了網關(gateway)的概念，網關能夠做爲某種翻譯器使用，它抽象出了一種可以到達資源的方法。網關是資源和應用程序之間的粘合劑。應用程序能夠(經過HTTP或其餘已定義的接口)請求網關來處理某條請求，網關能夠提供一條響應。網關能夠向數據庫發送查詢語句，或者生成動態的內容，就像一個門同樣：進去一條請求，出來一個響應。有些網關會自動將HTTP流量轉換爲其餘協議，這樣HTTP客戶端無需瞭解其餘協議，就能夠與其餘應用程序進行交互了。

客戶端和服務器端網關：Web 網關在一側使用HTTP協議，在另外一側使用另外一種協議。所以，將 HTTP 客戶端鏈接到 NNTP 新聞服務器的網關就是一個 HTTP/NNTP 網關。咱們用術語服務器端網關和客戶端網關來講明對話是在網關的哪一側進行的。

• 服務端網關(server-side gateway)：經過HTTP與客戶端對話，經過其餘協議與服務器通訊(HTTP/*)。
• 客戶端網關(client-side gateway)：經過其餘協議與客戶端對話，經過HTTP與服務器通訊(*/HTTP)。

協議網關

將HTTP流量導向網關時所使用的方式與將流量導向代理的方式相同。最多見的方式是，顯式地配置瀏覽器使用網關，對流量進行透明的攔截，或者將網關配置爲替代者(反向代理)。

• 服務端Web網關(HTTP/*)：請求流入原始服務器時，服務器端Web網關會將客戶端HTTP請求轉換爲其餘協議。
• 服務器端安全網關(HTTP/HTTPS)：一個組織能夠經過網關對全部的輸入Web請求加密，以提供額外的隱私和安全性保護。客戶端能夠用普通的HTTP瀏覽Web內容，但網關會自動加密用戶的對話。
• 客戶端安全加速器網關(HTTPS/HTTP)：這些HTTPS/HTTP網關位於Web服務器以前，一般做爲不可見的攔截網關或反向代理使用。它們接收安全的HTTPS流量，對安全流量進行解密，並向Web服務器發送普通的HTTP請求。這些網關中一般都包含專用的解密硬件，以比原始服務器有效得多的方式來解密安全流量，以減輕原始服務器的負荷。這些網關在網關和原始服務器之間發送的是未加密的流量，因此，要謹慎使用，確保網關和原始服務器之間的網絡是安全的。

資源網關

最多見的網關，應用程序服務器，會將目標服務器與網關結合在一個服務器中實現。應用程序服務器是服務器端網關，與客戶端經過HTTP進行通訊，並與服務器端的應用程序相連。客戶端是經過HTTP鏈接到應用程序服務器的。但應用程序服務器並無回送文件，而是將請求經過一個網關應用編程接口(Application Programming Interface，API)發送給運行在服務器上的應用程序。第一個流行的應用程序網關API就是通用網關接口(Common Gateway Interface， CGI)。CGI是一個標準接口集，Web服務器能夠用它來裝載程序以響應對特定URL的HTTP請求，並收集程序的輸出數據，將其放在HTTP響應中回送。在過去的幾年中，商業Web服務器提供了一些更復雜的接口，以便將Web服務器鏈接到應用程序上去。早期的Web服務器是至關簡單的，在網關接口的實現過程當中採用的簡單方式一直持續到了如今。

請求須要使用網關的資源時，服務器會請輔助應用程序來處理請求。服務器會將輔助應用程序所需的數據傳送給它。一般就是整條請求，或者用戶想在數據庫上運行的請求(來自 URL 的請求字符串)之類的東西。而後，它會向服務器返回一條響應或響應數據，服務器則會將其轉發給客戶端。服務器和網關是相互獨立的應用程序，所以，它們的責任是分得很清楚的。這個簡單的協議(輸入請求，轉交，響應)就是最古老，也最經常使用的服務器擴展接口CGI的本質。

CGI

CGI是第一個，可能仍然是獲得最普遍使用的服務器擴展。在Web上普遍用於動態HTML、數據庫查詢以及信用卡處理等任務。CGI應用程序是獨立於服務器的，因此，幾乎能夠用任意語言來實現。CGI很簡單，幾乎全部的HTTP服務器都支持它。CGI的處理對用戶來講是不可見的。從客戶端的角度來看，就像發起一個普通請求同樣。它徹底不清楚服務器和CGI應用程序之間的轉接過程。URL中出現字符cgi和可能出現的"?"是客戶端發現使用了CGI應用程序的惟一線索。CGI在服務器和衆多的資源類型之間提供了一種簡單的、函數形式的粘合方式，用來處理各類須要的轉換。這個接口還能很好地保護服務器，防止一些糟糕的擴展對它形成的破壞(若是這些擴展直接與服務器相連，形成的錯誤可能會引起服務器崩潰)。可是，這種分離會形成性能的耗費。爲每條CGI請求引起一個新進程的開銷是很高的，會限制那些使用CGI的服務器的性能，而且會加劇服務端機器資源的負擔。爲了解決這個問題，開發了一種新型CGI——並將其恰當地稱爲快速CGI。這個接口模擬了CGI，但它是做爲持久守護進程運行的，消除了爲每一個請求創建或拆除新進程所帶來的性能損耗。

服務器擴展API

CGI協議爲外部翻譯器與現有的HTTP服務器提供了一種簡潔的接口方式，但若是想要改變服務器自身的行爲，或者只是想盡量地提高能從服務器上得到的性能呢？服務器開發者爲這兩種需求提供了幾種服務器擴展API，爲Web開發者提供了強大的接口，以便他們將本身的模塊與HTTP服務器直接相連。擴展API容許程序員將本身的代碼嫁接到服務器上，或者用本身的代碼將服務器的一個組件完整地替換出來。大多數流行的服務器都會爲開發者提供一個或多個擴展API。這些擴展一般都會綁定在服務器自身的結構上，因此，大多數都是某種服務器類型特有的。Web服務器都提供了一些API接口，容許開發者經過這些接口改變服務器的行爲，或者爲不一樣的資源提供一些定製的接口。這些定製接口爲開發者提供了強大的接口方式。

應用程序接口

隨着Web應用程序提供的服務類型愈來愈多，有一點變得愈來愈清晰了：HTTP能夠做爲一種鏈接應用程序的基礎軟件來使用。在將應用程序鏈接起來的過程當中，一個更爲棘手的問題是在兩個應用程序之間進行協議接口的協商，以便這些應用程序能夠進行數據的交換——這一般都是針對具體應用程序的個案進行的。應用程序之間要配合工做，所要交互的信息比HTTP首部所能表達的信息要複雜得多。因特網委員會開發了一組容許Web應用程序之間相互通訊的標準和協議。儘管Web服務能夠用來表示獨立的Web應用程序(構造模塊)，這裏咱們仍是寬鬆地用這個術語來表示這些標準。Web服務的引入並不新鮮，但這是應用程序共享信息的一種新機制。Web服務是構建在標準的Web技術(好比HTTP)之上的。

隧道

Web隧道(Web tunnel)容許用戶經過HTTP鏈接發送非HTTP流量，這樣就能夠在HTTP上捎帶其餘協議數據了。使用Web隧道最多見的緣由就是要在HTTP鏈接中嵌入非HTTP流量，這樣，這類流量就能夠穿過只容許Web流量經過的防火牆了。

用CONNECT創建HTTP隧道

Web隧道是用HTTP的CONNECT方法創建起來的。CONNECT方法並非"HTTP/1.1"核心規範的一部分，但倒是一種獲得普遍應用的擴展。CONNECT方法請求隧道網關建立一條到達任意目的服務器和端口的TCP鏈接，並對客戶端和服務器之間的後繼數據進行盲轉發。

CONNECT 方法如何創建起一條到達網關的隧道：

• 客戶端發送一條CONNECT請求給隧道網關，客戶端的CONNECT方法請求隧道網關打開一條TCP鏈接；
• 建立了TCP鏈接；
• 一旦創建了TCP鏈接，網關就會發送一條"HTTP 200 Connection Established"響應來通知客戶端；
• 此時，隧道就創建起來了，客戶端經過HTTP隧道發送的全部數據都會被直接轉發給輸出TCP鏈接，服務器發送的全部數據都會經過HTTP隧道轉發給客戶端。

CONNECT請求：除了起始行以外，CONNECT的語法與其餘HTTP方法相似。一個後面跟着冒號和端口號的主機名取代了請求URI。主機和端口都必須指定(CONNECT home.netscape.com:443 HTTP/1.0)。和其餘HTTP報文同樣，起始行以後，有零個或多個HTTP請求首部字段。這些行照例以CRLF結尾，首部列表以一個僅有CRLF的空行結束。

CONNECT響應：發送了請求以後，客戶端會等待來自網關的響應。和普通HTTP報文同樣，響應碼200表示成功。按照慣例，響應中的緣由短語一般被設置爲"Connection Established"(HTTP/1.0 200 Connection Established)。與普通 HTTP 響應不一樣，這個響應並不須要包含Content-Type首部。此時鏈接只是對原始字節進行轉接，再也不是報文的承載者，因此不須要使用內容類型了。

數據隧道、定時及鏈接管理

管道化數據對網關是不透明的，因此網關不能對分組的順序和分組流做任何假設。一旦隧道創建起來了，數據就能夠在任意時間流向任意方向了。做爲一種性能優化方法，容許客戶端在發送了CONNECT請求以後，接收響應以前，發送隧道數據。這樣能夠更快地將數據發送給服務器，但這就意味着網關必須可以正確處理跟在請求以後的數據。尤爲是，網關不能假設網絡I/O請求只會返回首部數據，網關必須確保在鏈接準備就緒時，將與首部一同讀進來的數據發送給服務器。在請求以後以管道方式發送數據的客戶端，若是發現回送的響應是認證請求，或者其餘非200但不致命的錯誤狀態，就必須作好重發請求數據的準備。若是在任意時刻，隧道的任意一個端點斷開了鏈接，那個端點發出的全部未傳輸數據都會被傳送給另外一個端點，以後，到另外一個端點的鏈接也會被代理終止。若是還有數據要傳輸給關閉鏈接的端點，數據會被丟棄。

SSL隧道

最初開發Web隧道是爲了經過防火牆來傳輸加密的SSL流量。不少組織都會將全部流量經過分組過濾路由器和代理服務器以隧道方式傳輸，以提高安全性。但有些協議，好比加密SSL，其信息是加密的，沒法經過傳統的代理服務器轉發。隧道會經過一條HTTP鏈接來傳輸SSL流量，以穿過端口80的HTTP防火牆。爲了讓SSL流量經現存的代理防火牆進行傳輸，HTTP中添加了一項隧道特性，在此特性中，能夠將原始的加密數據放在HTTP報文中，經過普通的HTTP信道傳送。一般會用隧道將非HTTP流量傳過端口過濾防火牆。這一點能夠獲得很好的利用，好比，經過防火牆傳輸安全SSL流量。可是，這項特性可能會被濫用，使得惡意協議經過HTTP隧道流入某個組織內部。

SSL隧道與HTTP/HTTPS網關的對比

能夠像其餘協議同樣，對HTTPS協議(SSL上的HTTP)進行網關操做：由網關(而不是客戶端)初始化與遠端HTTPS服務器的SSL會話，而後表明客戶端執行HTTPS事務。響應會由代理接收並解密，而後經過(不安全的)HTTP傳送給客戶端。注意，對於SSL隧道機制來講，無需在代理中實現SSL。SSL會話是創建在產生請求的客戶端和目的(安全的)Web服務器之間的，中間的代理服務器只是將加密數據通過隧道傳輸，並不會在安全事務中扮演其餘的角色。

這是網關處理FTP的方式。但這種方式有幾個缺點：

• 客戶端到網關之間的鏈接是普通的非安全HTTP；
• 儘管代理是已認證主體，但客戶端沒法對遠端服務器執行SSL客戶端認證；
• 網關要支持完整的SSL實現。

隧道認證

在適當的狀況下，也能夠將HTTP的其餘特性與隧道配合使用。尤爲是，能夠將代理的認證支持與隧道配合使用，對客戶端使用隧道的權利進行認證。

隧道的安全性考慮

隧道網關沒法驗證目前使用的協議是否就是它本來打算通過隧道傳輸的協議。爲了下降對隧道的濫用，網關應該只爲特定的知名端口，好比HTTPS的端口443，打開隧道。

中繼

HTTP中繼(relay)是沒有徹底遵循HTTP規範的簡單HTTP代理。中繼負責處理HTTP中創建鏈接的部分，而後對字節進行盲轉發。HTTP很複雜，因此實現基本的代理功能並對流量進行盲轉發，並且不執行任何首部和方法邏輯，有時是頗有用的。盲中繼很容易實現，因此有時會提供簡單的過濾、診斷或內容轉換功能。但這種方式可能潛在嚴重的互操做問題，因此部署的時候要特別當心。有一些方法可使中繼稍微智能一些，以消除這些風險，但全部簡化的代理都存在着出現互操做性問題的風險。要爲某個特定目標構建簡單的HTTP中繼，必定要特別注意其使用方法。對任何大規模部署來講，都要很是認真地考慮使用真正的、徹底遵循HTTP的代理服務器。

某些簡單盲中繼實現中存在的一個更常見(也更聲名狼藉的)問題是，因爲它們沒法正確處理Connection首部，因此有潛在的掛起keep-alive鏈接的可能。

• Web客戶端向中繼發送了一條包含"Connection: Keep-Alive"首部的報文，若是可能的話要求創建一條keep-alive鏈接。客戶端等待響應，以肯定它要求創建keep-alive信道的請求是否被承認了。
• 中繼收到了這條HTTP請求，但它並不理解Connection首部，所以會將報文一字不漏地沿着鏈路傳遞給服務器。但Connection首部是個逐跳首部；只適用於單條傳輸鏈路，是不該該沿着鏈路傳送下去的。要有很差的事情發生了！
• 通過中繼轉發的HTTP請求抵達Web服務器。當Web服務器收到通過代理轉發的"Connection: Keep-Alive"首部時，會錯誤地認爲中繼(對服務器來講，它看起來就和其餘客戶端同樣)要求進行keep-alive的對話！這對Web服務器來講沒什麼問題——它贊成進行keep-alive對話，並回送了一個"Connection: Keep-Alive"響應首部。那麼，此時，Web服務器就認爲它是在與中繼進行keep-alive對話，會遵循keep-alive對話的規則。但中繼對keep-alive會話根本就一無所知。
• 中繼將Web服務器的響應報文，以及來自Web服務器的"Connection: Keep-Alive"首部一塊兒發回給客戶端。客戶端看到這個首部，認爲中繼贊成進行keep-alive對話。此時，客戶端和服務器都認爲它們是在進行keep-alive對話，但與它們進行對話的中繼卻根本不知道什麼keep-alive對話。
• 中繼對持久對話一無所知，因此它會將收到的全部數據都轉發給客戶端，等待原始服務器關閉鏈接。但原始服務器認爲中繼要求服務器將鏈接保持在活躍狀態，因此是不會關閉鏈接的！這樣，中繼就會掛起，等待鏈接的關閉。
• 當客戶端收到回送的響應報文時，它會直接轉向第二條請求，在keep-alive鏈接上向中繼發送另外一條請求。簡單中繼一般不會期待同一條鏈接上還會有另外一條請求到達。瀏覽器上的圈會不停地轉，但沒有任何進展。