Http與HTTP隧道技術

saucej發表於2015-03-12

HTTP是一個客戶端和服務端請求和應答的標準(TCP)客戶端是終端使用者,伺服器端是網站。通過使用Web瀏覽器網路爬蟲或者其它的工具,客戶端發起一個到伺服器上指定埠(預設為80)的HTTP請求。(我們稱這個客戶端)叫使用者代理(user agent)。應答的伺服器上儲存著(一些)資源,比如HTML檔案和影象。(我們稱)這個應答伺服器為源伺服器(origin server)。在使用者代理和源伺服器中間可能存在

多箇中間層,比如代理,閘道器,或者隧道(tunnels)。儘管TCP/IP協議是網際網路上最流行的應用,HTTP協議並沒有規定必須使用它和(基於)它支援的層。 事實上,HTTP可以在任何其他網際網路協議上,或者在其他網路上實現。HTTP只假定(其下層協議提供)可靠的傳輸,任何能夠提供這種保證的協議都可以被其使用。

通常,由HTTP客戶端發起一個請求,建立一個到伺服器指定埠(預設是80埠)的TCP連線。HTTP伺服器則在那個埠監聽客戶端傳送過來的請求。一旦收到請求,伺服器(向客戶端)發回一個狀態行,比如"HTTP/1.1 200 OK",和(響應的)訊息,訊息的訊息體可能是請求的檔案、錯誤訊息、或者其它一些資訊。

HTTP使用TCP而不是UDP的原因在於(開啟)一個網頁必須傳送很多資料,而TCP協議提供傳輸控制,按順序組織資料,和錯誤糾正。

-------------

Keep-Alive功能使客戶端到伺服器端的連線持續有效,當出現對伺服器的後繼請求時,Keep-Alive功能避免了建立或者重新建立連線。市場上的大部分Web伺服器,包括iPlanet、IIS和Apache,都支援HTTP Keep-Alive。對於提供靜態內容的網站來說,這個功能通常很有用。但是,對於負擔較重的網站來說,這裡存在另外一個問題:雖然為客戶保留開啟的連線有一定的好處,但它同樣影響了效能,因為在處理暫停期間,本來可以釋放的資源仍舊被佔用。當Web伺服器和應用伺服器在同一臺機器上執行時,Keep- Alive功能對資源利用的影響尤其突出。

KeepAliveTime 值控制 TCP/IP 嘗試驗證空閒連線是否完好的頻率。如果這段時間內沒有活動,則會傳送保持活動訊號。如果網路工作正常,而且接收方是活動的,它就會響應。如果需要對丟失接收方敏感,換句話說,需要更快地發現丟失了接收方,請考慮減小這個值。如果長期不活動的空閒連線出現次數較多,而丟失接收方的情況出現較少,您可能會要提高該值以減少開銷。預設情況下,如果空閒連線 7200000 毫秒(2 小時)內沒有活動,Windows 就傳送保持活動的訊息。通常,1800000 毫秒是首選值,從而一半的已關閉連線會在 30 分鐘內被檢測到。 

響應訊息

 

HTTP-Version表示支援的HTTP版本,例如為HTTP/1.1。Status-Code是一個三個數字的結果程式碼。Reason-Phrase給Status-Code提供一個簡單的文字描述。Status-Code主要用於機器自動識別,Reason-Phrase主要用於幫助使用者理解。Status-Code的第一個數字定義響應的類別,後兩個數字沒有分類的作用。第一個數字可能取5個不同的值:
1xx:資訊響應類,表示接收到請求並且繼續處理
2xx:處理成功響應類,表示動作被成功接收、理解和接受
3xx:重定向響應類,為了完成指定的動作,必須接受進一步處理
4xx:客戶端錯誤,客戶請求包含語法錯誤或者是不能正確執行
5xx:服務端錯誤,伺服器不能正確執行一個正確的請求
典型的響應訊息:
HTTP/1.0200OK
Date:Mon,31Dec200104:25:57GMT
Server:Apache/1.3.14(Unix)
Content-type:text/html
Last-modified:Tue,17Apr200106:46:28GMT
Etag:"a030f020ac7c01:1e9f"
Content-length:39725426
Content-range:bytes55******/40279980

運作方式:基於HTTP協議的客戶/伺服器模式的資訊交換過程,它分四個過程:建立連線、傳送請求資訊、傳送響應資訊、關閉連線。

HTTP協議是基於請求/響應正規化的。一個客戶機與伺服器建立連線後,傳送一個請求給伺服器,請求方式的格式為,統一資源識別符號、協議版本號,後邊是MIME資訊包括請求修飾符、客戶機資訊和可能的內容。伺服器接到請求後,給予相應的響應資訊,其格式為一個狀態行包括資訊的協議版本號、一個成功或錯誤的程式碼,後邊是MIME資訊包括伺服器資訊、實體資訊和可能的內容。

 

簡單地說就是任何伺服器除了包括HTML檔案外,還有一個HTTP駐留程式,用於響應使用者請求。你的瀏覽器是HTTP客戶,第一次向伺服器傳送請求,當瀏覽器中輸入了一個開始檔案或者點選了一個超級連結時,瀏覽器就向伺服器傳送了HTTP請求。駐留程式收到請求,在進行必要操作後回送所要求的檔案。

 

報文格式:

HTTP報文由從客戶機到伺服器的請求和從伺服器到客戶機的響應構成。請求報文格式如下:
請求行 - 通用資訊頭 - 請求頭 - 實體頭 - 報文主體
請求行以方法欄位開始,後面分別是 URL 欄位和 HTTP 協議版本欄位,並以 CRLF 結尾。SP 是分隔符。除了在最後的 CRLF 序列中 CF 和 LF 是必需的之外,其他都可以不要。有關通用資訊頭,請求頭和實體頭方面的具體內容可以參照相關檔案。
應答報文格式如下:
狀態行 - 通用資訊頭 - 響應頭 - 實體頭 - 報文主體
狀態碼元由3位數字組成,表示請求是否被理解或被滿足。原因分析是對原文的狀態碼作簡短的描述,狀態碼用來支援自動操作,而原因分析用來供使用者使用。客戶機無需用來檢查或顯示語法。有關通用資訊頭,響應頭和實體頭方面的具體內容可以參照相關檔案。

-----------------------

HTTP隧道技術

應用場景:

防火牆(只開放80)內的機器A
防火牆外部的機器B  (http隧道伺服器)
防火牆外部的機器C
如果A要通過某種非http協議訪問C 應該不能訪問

--

http隧道流程是

A上的軟體需要用到非http協議訪問外部機器時候 把本來的資料(包括資料、最終IP地址、原始協議等)打包放在一個http包中然後發給B, 這時候防火牆是可以通過的 .B上接收到資料包之後 分解資料形成原始的資料包 按照原協議傳送給最終的IP,返回資料之後 打包成http 傳送給A。A解釋這個http包並且處理.

利用HTTP協議的缺陷來實現對防火牆的滲透,或者說現有的一些HTTP隧道技術的實現,是基於防火牆在對HTTP協議的報文進行識別與過濾時,往往只對其諸如POST、GET等命令的頭進行識別,而放行其後的所有報文。
所以,只要具備了對HTTP的基本認識與基本的C語言或者Perl等程式語言的常識,就可以從事HTTP方面的學習與研究了。
這是C版本的:
http://www.nocrew.org/software/httptunnel.html
雖然是在UNIX下的原始碼,但對於瞭解基本原理與基本實現技術是很好的。
如果需要JAVA和PHP版本的可以到
http://www.ohardt.com/mailbridge/
這裡下載,這是一個利用HTTP隧道技術來收發EAMIL的實現。

 

 

 

相關文章