ttpbin：測試 HTTP 請求及響應(yīng)的網(wǎng)站.http://httpbin.org

httpbin這個網(wǎng)站能測試 HTTP 請求和響應(yīng)的各種信息，比如 cookie、ip、headers 和登錄驗證等，且支持

GET、POST 等多種方法，對 web 開發(fā)和測試很有幫助。

一個http請求包括三個部分，為別為請求行，請求報頭，消息主體，類似以下這樣：

請求行

請求報頭

消息主體

HTTP協(xié)議規(guī)定post提交的數(shù)據(jù)必須放在消息主體中，但是協(xié)議并沒有規(guī)定必須使用什么編碼方式。服務(wù)端通過是

根據(jù)請求頭中的Content-Type字段來獲知請求中的消息主體是用何種方式進行編碼，再對消息主體進行解析，也就

是說提交的數(shù)據(jù)格式要和Content-Type字段規(guī)定的一致。具體的編碼方式包括：

application/x-www-form-urlencoded

最常見post提交數(shù)據(jù)的方式，以form表單形式提交數(shù)據(jù)。

application/json

以json串提交數(shù)據(jù)。

multipart/form-data

一般使用來上傳文件。

以form形式發(fā)送post請求

Reqeusts支持以form表單形式發(fā)送post請求，只需要將請求的參數(shù)構(gòu)造成一個字典，然后傳給requests.post( )的

data 參數(shù)即可。

可以看到，請求頭中的Content-Type字段已設(shè)置為application/x-www-form-urlencoded.

且 d = {'key1': 'value1', 'key2': 'value2'} 以form表單的形式提交到服務(wù)端，服務(wù)端返回的form字段即是

提交的數(shù)據(jù)。

以json形式發(fā)送post請求

可以將一json串傳給requests.post()的data參數(shù)

以multipart形式發(fā)送post請求

Requests也支持以multipart形式發(fā)送post請求，只需將一文件傳給requests.post()的 files 參數(shù)即可。

文本文件report.txt的內(nèi)容只有一行：Hello world!，從請求的響應(yīng)結(jié)果可以看到數(shù)據(jù)已上傳到服務(wù)端中。

boundary 用于分割不同的字段 類似于查詢字符串中的&。不是HTML產(chǎn)生的，可以自己指定。

對于學(xué)習(xí)python的學(xué)習(xí)路線，學(xué)習(xí)方法，系統(tǒng)學(xué)習(xí)規(guī)劃有任何問題，可以關(guān)注我的頭條號，私信給我”python“會自動回復(fù)python系統(tǒng)學(xué)習(xí)交流群，群里有學(xué)習(xí)路線以及詳細的規(guī)劃，我做web開發(fā)十年的時間，希望幫助新手少走彎路。

. 體系結(jié)構(gòu) 萬維網(wǎng)（WWW）服務(wù)是分布式的客戶/服務(wù)器服務(wù)，客戶使用瀏覽器能夠得到服務(wù)器提供的服務(wù)，這種服務(wù)的提供是分布在許多網(wǎng)站中的，如下圖所示：

圖13-1 分布式的服務(wù)

每一個網(wǎng)站保存有一個或多個文檔，叫做萬維網(wǎng)頁面。在圖12-1所示的例子中，客戶需要查看網(wǎng)站A的某些信息。瀏覽器用來讀取萬維網(wǎng)上的文檔。它向網(wǎng)站A發(fā)送一個請求，這個請求包含了網(wǎng)站A和網(wǎng)站中萬維網(wǎng)頁面的地址，這個地址叫做統(tǒng)一資源定位符（URL）。網(wǎng)站A收到請求后，將指定的文檔發(fā)送給這個客戶。它用同樣的方法與網(wǎng)站B通信。1. 客戶（瀏覽器） 許多廠商提供商用瀏覽器，可以解釋和顯示萬維網(wǎng)頁面。每一個瀏覽器通常由3個部分組成：控制程序、客戶程序及解釋程序。控制程序從鍵盤或鼠標(biāo)接收輸入，使用客戶程序訪問要瀏覽的文檔。在文檔找到后，控制程序就使用解釋程序（可以是HTML、Java或JavaScript等）中的一個，把文檔顯示在屏幕上。2. 服務(wù)器 萬維網(wǎng)頁面存儲在服務(wù)器上。每當(dāng)有客戶請求到達時，對應(yīng)的文檔就發(fā)送給客戶。為了提高效率，服務(wù)器通常在其高速緩存中存儲被請求過的文檔；對高速緩存進行訪問要比磁盤快得多。通過多線程或多進程可使服務(wù)器的效率更加提高，服務(wù)器在同一時間可回答多個請求。3. 統(tǒng)一資源定位符（URL） 客戶要訪問萬維網(wǎng)頁面就需要這個頁面地址。為了方便地訪問文檔，HTTP協(xié)議使用統(tǒng)一資源定位符（URL）。URL是Internet上指定信息的標(biāo)準(zhǔn)。URL由4部分組成：協(xié)議、主機、端口和路徑，如下圖所示：

圖13-2 URL

協(xié)議：協(xié)議指定了用這個URL的客戶/服務(wù)器程序。例如，HTTP協(xié)議、FTP協(xié)議和TELNET協(xié)議等。 主機：主機指明了信息所存放的地址，可以是邏輯地址也可以是相應(yīng)的域名。存放萬維網(wǎng)頁面的計算機通常使用以字符"WWW"開始的域名，但這不是強制性的。 端口：端口指定了使用主機的某個端口，端口是可選的。如果包含了端口，那么端口就插入在主機和路徑之間，和主機用冒號分隔開。 路徑：路徑指定了文件存放的位置。路徑本身可以包含斜線，用于將目錄與子目錄和文件分隔開。二. 萬維網(wǎng)文檔 萬維網(wǎng)文檔可分為3類：靜態(tài)文檔、動態(tài)文檔和活動文檔。這種分類是基于文檔內(nèi)容被確定的時間。1. 靜態(tài)文檔 靜態(tài)文檔是固定內(nèi)容的文檔，它由服務(wù)器創(chuàng)建，并存儲在服務(wù)器中。客戶只能得到文檔的一個副本。換言之，文件的內(nèi)容是在文件被創(chuàng)建時就確定的，而不是在它被使用時。當(dāng)然，在服務(wù)器中的內(nèi)容是可以改變的，但用戶不能改變它。當(dāng)客戶訪問文檔時，文檔的一個副本就被發(fā)送出去。用戶可以使用瀏覽程序顯示這個文檔，如下圖所示：

圖13-3 靜態(tài)文檔

2. 動態(tài)文檔 動態(tài)文檔是在瀏覽器請求該文檔時才由萬維網(wǎng)服務(wù)器創(chuàng)建出來。當(dāng)請求到達時，萬維網(wǎng)服務(wù)器就運行創(chuàng)建動態(tài)文檔的應(yīng)用程序。服務(wù)器返回這個程序或腳本的輸出，把它作為對請求該文檔的瀏覽器的響應(yīng)。因為對每一個請求都創(chuàng)建出新的文檔，因此每一個請求得到的動態(tài)文檔的內(nèi)容就會不同。3. 活動文檔 對于許多應(yīng)用，需要程序能夠在客戶端運行，這就叫做活動文檔。當(dāng)瀏覽器請求活動文檔時，服務(wù)器就發(fā)送這個文檔的一個副本或腳本。然后這個文檔就在客戶（瀏覽器）端運行。

三. HTTP協(xié)議簡介四. HTTP報文格式

三. HTTP協(xié)議簡介 HTTP（超文本傳輸協(xié)議）主要用于訪問萬維網(wǎng)上的數(shù)據(jù)。協(xié)議以普通文本、超文本、音頻、視頻等格式傳輸數(shù)據(jù)。之所以稱為超文本協(xié)議，原因是在應(yīng)用環(huán)境中，它可以快速的在文檔之間跳轉(zhuǎn)。HTTP在熟知端口80上使用TCP服務(wù)。四. HTTP報文格式 HTTP報文有兩種一般的類型：請求和響應(yīng)。這兩種類型的報文格式幾乎是相同的。報文格式如下圖所示：

圖13-4 HTTP報文格式

五. HTTP方法

五. HTTP方法 HTTP報文中的方法是客戶端向服務(wù)器端發(fā)出的實際命令和請求。常用HTTP方法如下表所示：

表13-1 HTTP方法

六. HTTP狀態(tài)碼

六. HTTP狀態(tài)碼 在響應(yīng)報文中，請求行被替換為狀態(tài)行，由3位數(shù)字組成，表示請求是否被理解或被滿足。HTTP協(xié)議的狀態(tài)碼如下表所示：

表13-2 HTTP狀態(tài)碼

七. 持久與非持久連接 1. 非持久連接 2. 持久連接

七. 持久與非持久連接 在版本1.1以前的HTTP協(xié)議默認是非持久連接的，而在版本1.1中，持久連接是默認的連接。1. 非持久連接 在非持久連接中，對每一個請求/響應(yīng)都要建立一次TCP連接。非持久連接的步驟如下： ● 客戶打開TCP連接，并發(fā)送請求。 ● 服務(wù)器發(fā)送響應(yīng)，并關(guān)閉連接。 ● 客戶讀取數(shù)據(jù)，直到它遇到文件結(jié)束標(biāo)記；然后它關(guān)閉連接。 使用非持久連接時，對于在不同文件中的N個不同圖片的請求，連接必須打開和關(guān)閉N次。非持久連接策略給服務(wù)器造成了很大的開銷，因為服務(wù)器需要N個不同的緩存，而每次打開連接時都要使用慢開始過程。2. 持久連接 HTTP版本1.1指明持久連接是默認的策略。在使用持久連接時，服務(wù)器在發(fā)送響應(yīng)后，讓連接繼續(xù)為一些請求打開。服務(wù)器可以在客戶發(fā)送關(guān)閉請求時等待或關(guān)閉這個連接。發(fā)送端通常在每一個響應(yīng)中都發(fā)送數(shù)據(jù)長度。但是，有時發(fā)送端并不知道數(shù)據(jù)的長度（例如動態(tài)文檔或活動文檔），這時服務(wù)器就把長度不知道這件事通知客戶，并在發(fā)送數(shù)據(jù)后關(guān)閉這個連接，這樣客戶就知道數(shù)據(jù)結(jié)束的地方已經(jīng)到了。

八. HTTP代理服務(wù)器

八. HTTP代理服務(wù)器 HTTP支持代理服務(wù)器（proxy server）。代理服務(wù)器保留對最近請求的響應(yīng)的副本。在有代理服務(wù)器的情況下，HTTP客戶把請求發(fā)送給代理服務(wù)器。代理服務(wù)器檢查它的高速緩存。如果在高速緩存中有這個響應(yīng)，代理服務(wù)器就直接應(yīng)答客戶的請求；反之，如果在高速緩存中沒有這個響應(yīng)，代理服務(wù)器就把請求發(fā)送給相應(yīng)的HTTP服務(wù)器，當(dāng)HTTP服務(wù)器的響應(yīng)到達代理服務(wù)器時，代理服務(wù)器將該響應(yīng)轉(zhuǎn)發(fā)給客戶，同時將該響應(yīng)存儲到高速緩存中，以便以后為其它客戶的請求使用。 代理服務(wù)器減少了原始服務(wù)器的負荷，減小了通信量，也減小了延時。但是，由于使用了代理服務(wù)器，客戶必須配置成接入到代理服務(wù)器而不是那個目標(biāo)服務(wù)器。

頁面訪問

各主機打開工具區(qū)的"拓撲驗證工具"，選擇相應(yīng)的網(wǎng)絡(luò)結(jié)構(gòu)，配置網(wǎng)卡后，進行拓撲驗證，如果通過拓撲驗證，關(guān)閉工具繼續(xù)進行實驗，如果沒有通過，請檢查網(wǎng)絡(luò)連接。 本練習(xí)一人一組，現(xiàn)僅以主機A為例，其它主機參考主機A的操作。1. 主機A清空IE緩存。2. 主機A啟動協(xié)議分析器開始捕獲數(shù)據(jù)，并設(shè)置過濾條件（提取HTTP協(xié)議）。3. 主機A啟動IE瀏覽器，在"地址"框中輸入http://服務(wù)器的ip/experiment，并連接，服務(wù)器IP默認為172.16.0.253。4. 主機A停止捕獲數(shù)據(jù)，分析捕獲到的數(shù)據(jù)，并回答以下問題： ● 本練習(xí)使用HTTP協(xié)議的哪種方法？簡述這種方法的作用。 ● 根據(jù)本練習(xí)的報文內(nèi)容，填寫下表。

表13-3 實驗結(jié)果

● 參考"會話分析"視圖顯示結(jié)果，繪制此次訪問過程的報文交互圖（包括TCP協(xié)議）。 ● 簡述TCP協(xié)議和HTTP協(xié)議之間的關(guān)系。

頁面提交

本練習(xí)一人一組，現(xiàn)僅以主機A為例，其它主機參考主機A的操作。1. 主機A啟動協(xié)議分析器開始捕獲數(shù)據(jù)，并設(shè)置過濾條件（提取HTTP協(xié)議）。2. 主機A啟動IE瀏覽器，在"地址"框中輸入"http://服務(wù)器的ip/experiment/post.html"，并連接，服務(wù)器IP默認為172.16.0.253。在返回頁面中，填寫"用戶名"和"密碼"，點擊[確定]按鈕。3. 主機A停止捕獲數(shù)據(jù)，分析捕獲到的數(shù)據(jù)，并回答以下問題： ● 本練習(xí)的提交過程使用HTTP協(xié)議的哪種方法？簡述這種方法的作用。 ● 此次通信分幾個階段？每個階段完成什么工作？ ● 參考"會話分析"視圖顯示結(jié)果，繪制此次提交過程的報文交互圖（包括TCP協(xié)議）。

獲取頁面信息

本練習(xí)一人一組，現(xiàn)僅以主機A為例，其它主機參考主機A的操作。1. 主機A啟動實驗平臺工具欄中的"TCP工具"。2. 主機A啟動協(xié)議分析器開始捕獲數(shù)據(jù)，并設(shè)置過濾條件（提取HTTP協(xié)議）。3. 主機A在"TCP工具"上，選中"客戶端"單選框，設(shè)置"IP地址"為服務(wù)器IP（172.16.0.253）；設(shè)置"端口"為80；單擊[連接]按鈕來和服務(wù)器建立連接。4. 主機A在"TCP工具"上，設(shè)置"發(fā)送數(shù)據(jù)（文本）"為以下內(nèi)容： HEAD /experiment/ HTTP/1.1<CRLF> Host: 172.16.0.253<CRLF> <CRLF> 點擊[發(fā)送]按鈕。 （注：<CRLF>是回車換行） 點擊[斷開]按鈕，斷開TCP連接（由于不同http版本所遵循的規(guī)范不同，有些HTTP服務(wù)器不需要斷開操作）。 5. 主機A在"TCP工具"上的"顯示數(shù)據(jù)（文本）"中察看服務(wù)器返回信息。6. 主機A停止捕獲數(shù)據(jù)，分析捕獲到的數(shù)據(jù)。

較復(fù)雜的頁面訪問

本練習(xí)一人一組，現(xiàn)僅以主機A為例，其它主機參考主機A的操作。1. 本練習(xí)中要求各主機設(shè)置DNS服務(wù)器地址（DNS服務(wù)器的IP地址即主控中心平臺的IP地址），其IP地址以172.16.0.253為例。2. 主機A使用"ipconfig /flushdns"命令清空DNS高速緩存。3. 主機A啟動協(xié)議分析器開始捕獲數(shù)據(jù)并設(shè)置過濾條件（提取DNS、HTTP協(xié)議）。4. 主機A啟動IE瀏覽器，在地址框中輸入http://JServer.NetLab/complexpage.htm。5. 主機A停止捕獲數(shù)據(jù)，察看相關(guān)會話，分析捕獲到的數(shù)據(jù)，并回答以下問題： ● 結(jié)合本次實驗結(jié)果，簡述瀏覽器是如何處理一個訪問請求的。6. 恢復(fù)網(wǎng)絡(luò)環(huán)境，將"首選DNS服務(wù)器"清空。

1. 一個主頁是否只有一個連接？

1. 同時打開多個瀏覽器窗口并訪問一個WEB站點的不同頁面時，系統(tǒng)是根據(jù)什么把返回的頁面正確地顯示到相應(yīng)窗口的？

1. 為什么HTTP不保持與客戶端的TCP連接？

，一般現(xiàn)在流傳的HTTP請求：GET和POST的比較是這樣的：

GET和POST是HTTP的兩個常用方法。

什么是HTTP?

超文本傳輸協(xié)議(HyperText Transfer Protocol -- HTTP)是一個設(shè)計來使客戶端和服務(wù)器順利進行通訊的協(xié)議。

HTTP在客戶端和服務(wù)器之間以request-responseprotocol（請求-回復(fù)協(xié)議）工作。

GET- 從指定的服務(wù)器中獲取數(shù)據(jù)

POST- 提交數(shù)據(jù)給指定的服務(wù)器處理

GET方法：

使用GET方法時，查詢字符串（鍵值對）被附加在URL地址后面一起發(fā)送到服務(wù)器：

/test/demo_form.jsp?name1=value1&name2=value2

特點：

· GET請求能夠被緩存

· GET請求會保存在瀏覽器的瀏覽記錄中

· 以GET請求的URL能夠保存為瀏覽器書簽

· GET請求有長度限制

· GET請求主要用以獲取數(shù)據(jù)

POST方法：

使用POST方法時，查詢字符串在POST信息中單獨存在，和HTTP請求一起發(fā)送到服務(wù)器：

POST/test/demo_form.jsp HTTP/1.1

Host:w3schools.com

name1=value1&name2=value2

特點：

· POST請求不能被緩存下來

· POST請求不會保存在瀏覽器瀏覽記錄中

· 以POST請求的URL無法保存為瀏覽器書簽

· POST請求沒有長度限制

GET和POST的區(qū)別：

其他HTTP請求方式

二，本質(zhì)上，這些并不是HTTP的GET和POST兩者請求的區(qū)別，這些區(qū)別是建立在HTML標(biāo)準(zhǔn)對于HTTP協(xié)議的用法的約定之上的。

1. GET和POST與數(shù)據(jù)如何傳遞沒有關(guān)系

GET和POST是由HTTP協(xié)議定義的。在HTTP協(xié)議中，Method和Data（URL， Body， Header）是正交的兩個概念，也就是說，使用哪個Method與應(yīng)用層的數(shù)據(jù)如何傳輸是沒有相互關(guān)系的。

HTTP沒有要求，如果Method是POST數(shù)據(jù)就要放在BODY中。也沒有要求，如果Method是GET，數(shù)據(jù)（參數(shù)）就一定要放在URL中而不能放在BODY中。

那么，網(wǎng)上流傳甚廣的這個說法是從何而來的呢？我在HTML標(biāo)準(zhǔn)中，找到了相似的描述。這和網(wǎng)上流傳的說法一致。但是這只是HTML標(biāo)準(zhǔn)對HTTP協(xié)議的用法的約定。怎么能當(dāng)成GET和POST的區(qū)別呢？

而且，現(xiàn)代的Web Server都是支持GET中包含BODY這樣的請求。雖然這種請求不可能從瀏覽器發(fā)出，但是現(xiàn)在的Web Server又不是只給瀏覽器用，已經(jīng)完全地超出了HTML服務(wù)器的范疇了。

2. HTTP協(xié)議對GET和POST都沒有對長度的限制

HTTP協(xié)議明確地指出了，HTTP頭和Body都沒有長度的要求。而對于URL長度上的限制，有兩方面的原因造成：

1. 瀏覽器。據(jù)說早期的瀏覽器會對URL長度做限制。據(jù)說IE對URL長度會限制在2048個字符內(nèi)（流傳很廣，而且無數(shù)同事都表示認同）。但我自己試了一下，我構(gòu)造了90K的URL通過IE9訪問live.com，是正常的。網(wǎng)上的東西，哪怕是Wikipedia上的，也不能信。

2. 服務(wù)器。URL長了，對服務(wù)器處理也是一種負擔(dān)。原本一個會話就沒有多少數(shù)據(jù)，現(xiàn)在如果有人惡意地構(gòu)造幾個幾M大小的URL，并不停地訪問你的服務(wù)器。服務(wù)器的最大并發(fā)數(shù)顯然會下降。另一種攻擊方式是，把告訴服務(wù)器Content-Length是一個很大的數(shù)，然后只給服務(wù)器發(fā)一點兒數(shù)據(jù)，嘿嘿，服務(wù)器你就傻等著去吧。哪怕你有超時設(shè)置，這種故意的次次訪問超時也能讓服務(wù)器吃不了兜著走。有鑒于此，多數(shù)服務(wù)器出于安全啦、穩(wěn)定啦方面的考慮，會給URL長度加限制。但是這個限制是針對所有HTTP請求的，與GET、POST沒有關(guān)系。