HTTP协议及其POST与GET操作差异Word文档格式.docx

HTTP协议及其POST与GET操作差异Word文档格式.docx

《HTTP协议及其POST与GET操作差异Word文档格式.docx》由会员分享，可在线阅读，更多相关《HTTP协议及其POST与GET操作差异Word文档格式.docx（9页珍藏版）》请在冰豆网上搜索。

∙2、抓包分析

∙3、POST與GET的差異

1、HTTP概述

為了喚醒你對HTTP協議的記憶或使你能夠對HTTP協議有所瞭解，首先簡單一下HTTP協議。

超文本傳輸協議（HTTP，HyperTextTransferProtocol）是互聯網上應用最為廣泛的一種網絡協議。

所有的WWW文件都必須遵守這個標準。

設計HTTP最初的目的是為了提供一種發布和接收HTML頁面的方法。

HTTP的發展是萬維網協會（WorldWideWebConsortium）和Internet工作小組（InternetEngineeringTaskForce）合作的結果，（他們）最終發佈了一系列的RFC，其中最著名的就是RFC2616。

RFC2616定義了HTTP協議中一個現今被廣泛使用的版本——HTTP1.1。

1.1、HTTP協議的客戶端與服務器的交互

HTTP是一個客戶端和服務器端請求和應答的標準（TCP）。

客戶端是終端用戶，服務器端是網站。

通過使用Web瀏覽器、網絡爬蟲或者其它的工具，客戶端發起一個到服務器上指定端口（默認端口為80）的HTTP請求。

（我們稱這個客戶端）調用戶代理（useragent）。

應答的服務器上存儲著（一些）資源，比如HTML文件和圖像。

（我們稱）這個應答服務器為源服務器（originserver）。

在用戶代理和源服務器中間可能存在多個中間層，比如代理，網關，或者隧道（tunnel）。

儘管TCP/IP協議是互聯網上最流行的應用，HTTP協議並沒有規定必須使用它和（基於）它支持的層。

事實上，HTTP可以在任何其他互聯網協議上，或者在其他網絡上實現。

HTTP只假定（其下層協議提供）可靠的傳輸，任何能夠提供這種保證的協議都可以被其使用。

通常，由HTTP客戶端發起一個請求，建立一個到服務器指定端口（默認是80端口）的TCP連接。

HTTP服務器則在那個端口監聽客戶端發送過來的請求。

一旦收到請求，服務器（向客戶端）發回一個狀態行，比如"

HTTP/1.1200OK"

，和（響應的）消息，消息的消息體可能是請求的文件、錯誤消息、或者其它一些信息。

HTTP使用TCP而不是UDP的原因在於（打開一個）一個網頁必須傳送很多數據，而TCP協議提供傳輸控制，按順序組織數據，和錯誤糾正。

通過HTTP或者HTTPS協議請求的資源由統一資源標識符（UniformResourceIdentifiers，或者，更準確一些，URI）來標識。

客戶端與服務器端的結構與交互過程可以表示為下面2張圖：

圖1、Web客戶端-服務器端結構（其中web服務器的超文本鏈接，即通過網站上的一個鏈接跳轉到了其他服務器上）

圖2、Web客戶端與服務器端的交互

1.2、HTTP消息

客戶端與服務器之間的交互用到了兩種類型的消息：

請求（Request）和響應（Response）。

HTTP請求的格式為：

圖3、HTTP請求的格式

HTTP響應的格式為：

圖4、HTTP響應的格式

從上面可以看出HTTP的請求和響應消息的首部均包含可變數量的字段，用一個空行（blankline）將所有首部字段（header）與消息主體（body）分隔開來。

一個首部字段由字段名和隨後的冒號、一個空格和字段值組成，字段名不區分大小寫。

報文頭可分為三類：

一類應用於請求，一類應用於響應，還有一類描述主體。

有一些報文頭（例如：

Date）既可用於請求又可用於響應。

描述主體的報文頭可以出現在POST請求和所有響應報文中。

HTTP的首部字段如下圖所示：

圖5、HTTP首部字段

1.3、HTTP請求的方法

HTTP/1.1協議中共定義了八種方法（有時也叫「動作」）來表明Request-URI指定的資源的不同操作方式：

∙OPTIONS

返回服務器針對特定資源所支持的HTTP請求方法。

也可以利用向Web服務器發送'

*'

的請求來測試服務器的功能性。

∙HEAD

向服務器索要與GET請求相一致的響應，只不過響應體將不會被返回。

這一方法可以在不必傳輸整個響應內容的情況下，就可以獲取包含在響應消息頭中的元信息。

∙GET

向特定的資源發出請求。

注意：

GET方法不應當被用於產生「副作用」的操作中，例如在WebApplication中。

其中一個原因是GET可能會被網絡蜘蛛等隨意訪問。

∙POST

向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。

數據被包含在請求體中。

POST請求可能會導致新的資源的建立和/或已有資源的修改。

∙PUT

向指定資源位置上傳其最新內容。

∙DELETE

請求服務器刪除Request-URI所標識的資源。

∙TRACE

回顯服務器收到的請求，主要用於測試或診斷。

∙CONNECT

HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。

方法名稱是區分大小寫的。

當某個請求所針對的資源不支持對應的請求方法的時候，服務器應當返回狀態碼405（MethodNotAllowed）；

當服務器不認識或者不支持對應的請求方法的時候，應當返回狀態碼501（NotImplemented）。

HTTP服務器至少應該實現GET和HEAD方法，其他方法都是可選的。

此外，除了上述方法，特定的HTTP服務器還能夠擴展自定義的方法。

安全方法

開發者應當意識到他們的軟件代表了用戶在因特網上進行交互，並且應當告知用戶，他們正在進行的操作可能對他們自身或者其他人有未曾預料的重要影響。

特別地，對於GET和HEAD方法而言，除了進行獲取資源信息外，這些請求不應當再有任何其他意義。

也就是說，這些方法應當被認為是「安全的」，即所謂安全的意味著該操作用於獲取信息而非修改信息。

客戶端應當使用其他「非安全」方法，例如POST、PUT及DELETE來以特殊的方式（通常是按鈕而不是超鏈接）使得客戶能夠意識到可能要負的責任（例如一個按鈕帶來的資金交易）或者被告知正在請求的操作可能是不安全的（例如某個文件將被上傳或刪除）。

但是，不能想當然地認為服務器不會在處理某個GET請求時不會產生任何副作用。

事實上，很多動態資源會把這作為其特性。

這裡重要的區別在於用戶並沒有請求這一副作用，因此不應由用戶為這些副作用承擔責任。

冪等方法

假如在不考慮諸如錯誤或者過期等問題的情況下，若干次請求的副作用與單次請求相同或者根本沒有副作用，那麼這些請求方法就能夠被視作「冪等」的。

GET，HEAD，PUT和DELETE方法都有這樣的冪等屬性，同樣由於根據協議，OPTIONS，TRACE都不應有副作用，因此也理所當然也是冪等的。

假如某個由若干個請求做成的請求串行產生的結果在重複執行這個請求串行或者其中任何一個或多個請求後仍沒有發生變化，則這個請求串行便是「冪等」的。

但是，可能出現若干個請求做成的請求串行是「非冪等」的，即使這個請求串行中所有執行的請求方法都是冪等的。

例如，這個請求串行的結果依賴於某個會在下次執行這個串行的過程中被修改的變量。

1.4、HTTP響應的代碼

服務器程序響應的第一行叫狀態行。

狀態行以HTTP版本號開始，後面跟著3位數字表示響應代碼，最後是易讀的響應短語。

根據第一位可以把響應分成5類：

圖6、HTTP響應代碼

2、抓包分析

現在我們對HTTP基本上算是瞭解了，下面我用wireshark抓取打開博客園首頁時，我的電腦與博客園服務器的交互過程的HTTP數據包。

做好準備工作，關閉一些可能干擾我們抓取打開博客園的相關程序。

如下圖，我們在瀏覽器中輸入並確定時，首先抓到如下包：

圖7、打開博客園抓取的包

從圖中可以看出，我們在瀏覽器中輸入並確定時是向服務器發送了一個HTTP請求消息：

GET 

/ 

HTTP/1.1。

根據1.2中介紹的HTTP消息的格式，我們知道GET對應request、/對應request-line、HTTP/1.1對應版本號。

除了請求行之外，發送了一些首部字段，如：

Accept、Accept-Language、User-Agent、Accept-Encoding、Host、Connection等。

而且可以看出他們的格式就是：

首部字段名:

字段值，注意冒號後面有個空格。

接下來我們看一下GET 

HTTP/1.1請求的響應消息是怎樣的：

圖8、GET 

HTTP/1.1請求的響應消息

響應消息的狀態行是：

HTTP/1.1 

200 

OK，其中HTTP/1.1對應版本號、200對應response-code、OK對應response-phrase。

除了狀態行，還返回了一些首部字段，如：

Cache-Control、Content-Type、Content-Encoding、Expires、Last-Modified、Vary、Server等等。

（通過上圖我們可以看出，博客用的是IIS7.0）

上面抓的是GET的數據包，現在我來看一個POST的數據包——打開博客園首頁過程中獲取左邊的分類信息就是通過POST請求返回的。

圖9、POST數據包

我們可以看到，POST/ws/PublicUserService.asmx/GetLoginInfoHTTP/1.1。

除了把GET換成了POST之外，其它信息差不多。

下面我們放大看下發送的首部字段：

圖10、POST/ws/PublicUserService.asmx/GetLoginInfoHTTP/1.1的首部字段

NOTE：

本節涉及的一些首部字段我就不在這裡解釋了。

我想，到了這裡大家對HTTP的認識應該更深入了一步。

3、POST與GET的差異

1.3中介紹了8種方法，其中GET與POST最基本和常用了。

表單提交中get和post方式的區別歸納如下幾點：

∙GET是從服務器上獲取數據，POST是向服務器傳送數據。

∙GET是把參數數據隊列加到提交表單的ACTION屬性所指的URL中，值和表單內各個字段一一對應，在URL中可以看到。

POST是通過HTTPPOST機制，將表單內各個字段與其內容放置在HTMLHEADER內一起傳送到ACTION屬性所指的URL地址。

用戶看不到這個過程。

∙對於GET方式，服務器端用Request.QueryString獲取變量的值，對於POST方式，服務器端用Request.Form獲取提交的數據。

∙GET傳送的數據量較小，不能大於2KB（這主要是因為受URL長度限制）。

POST傳送的數據量較大，一般被默認為不受限制。

但理論上，限制取決於服務器的處理能力。

∙GET安全性較低，POST安全性較高。

因為GET在傳輸過程，數據被放在請求的URL中，而如今現有的很多服務器、代理服務器或者用戶代理都會將請求URL記錄到日誌文件中，然後放在某個地方，這樣就可能會有一些隱私的信息被第三方看到。

另外，用戶也可以在瀏覽器上直接看到提交的數據，一些系統內部消息將會一同顯示在用戶面前。

POST的所有操作對用戶來說都是不可見的。

在FORM提交的時候，如果不指定Method，則默認為GET請求（