HTTP隧道用於在被限制的網絡連接(包括防火牆NATACL)以及其他限制的情況下在兩台計算機之間建立網絡鏈接。該隧道通常由位於DMZ中的代理服務器中介創建。

隧道還可以使用受限網絡通常不支持的協議進行通信。

HTTP CONNECT方式

HTTP隧道的常見形式是標準HTTP CONNECT方式。[1][2][3]在這種機制下,客戶端要求HTTP代理服務器將TCP連接轉發到所需的目的地。然後服務器繼續代表客戶端進行連接。服務器建立連接後,代理服務器將繼續代理與客戶端之間的TCP流。只有初始連接請求是HTTP,之後服務器將僅代理建立的TCP連接。

正是這種機制讓使用HTTP代理的客戶端可以訪問TLS網站(即HTTPS)。

建立隧道示例

客戶端連接到代理服務器,並通過指定端口和要連接的主機建立隧道。 該端口用於指示請求的協議。[4]

CONNECT streamline.t-mobile.com:22 HTTP/1.1
Proxy-Authorization: Basic encoded-credentials

如果代理允許連接,並且代理已連接到指定的主機,則代理將返回2XX成功響應。[4]

HTTP/1.1 200 OK

現在客戶端將通過代理訪問遠程主機。 發送到代理服務器的所有數據都將原樣轉發到遠程主機[4],並且客戶端可以使用遠程主機支持的任何協議進行通信。

在下面的示例中,客戶端在初始CONNECT請求中通過端口號開始SSH通信。

SSH-2.0-OpenSSH_4.3\r\n
... ggg

不使用CONNECT的HTTP隧道

HTTP隧道也可以僅使用常用的HTTP請求方法(如POST,GET,PUT和DELETE)來實現。這類似於同步HTTP上的雙向流(BOSH)中使用的方法。

示例程序,特殊的HTTP服務器在受保護的網絡外部運行,而客戶端程序在受保護的網絡內部的計算機上運行。

當客戶端發送任何網絡流量時,客戶端都會將流量數據重新打包為HTTP請求,並將數據發送到外部服務器,該外部服務器會提取並執行客戶端的原始網絡請求。

外部服務器收到此請求的響應後,將其重新打包為HTTP響應,並發送回客戶端。

由於所有流量都封裝在常規的GET和POST請求和響應中,因此該方法適用於大多數代理、防火牆及內網。

另見

參考文獻

  1. ^ Hypertext Transfer Protocol -- HTTP/1.1 [2010-07-09]. RFC 2616. 
  2. ^ Upgrading to TLS Within HTTP/1.1 (RFC 2817). [3 July 2011]. (原始內容存檔於2015-10-08). 
  3. ^ Fielding, Roy. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. tools.ietf.org. [2014-06-01]. (原始內容存檔於2014-07-14) (英語). 
  4. ^ 4.0 4.1 4.2 CONNECT. HTTP/1.1 Semantics and Content. IETF. June 2014: p. 30. sec. 4.3.6 [4 November 2017]. RFC 7231.