整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
ttpbin：測試 HTTP 請求及響應的網站.http://httpbin.org
httpbin這個網站能測試 HTTP 請求和響應的各種信息，比如 cookie、ip、headers 和登錄驗證等，且支持
GET、POST 等多種方法，對 web 開發和測試很有幫助。
一個http請求包括三個部分，為別為請求行，請求報頭，消息主體，類似以下這樣：
請求行
請求報頭
消息主體
HTTP協議規定post提交的數據必須放在消息主體中，但是協議并沒有規定必須使用什么編碼方式。服務端通過是
根據請求頭中的Content-Type字段來獲知請求中的消息主體是用何種方式進行編碼，再對消息主體進行解析，也就
是說提交的數據格式要和Content-Type字段規定的一致。具體的編碼方式包括：
application/x-www-form-urlencoded
最常見post提交數據的方式，以form表單形式提交數據。
application/json
以json串提交數據。
multipart/form-data
一般使用來上傳文件。
以form形式發送post請求
Reqeusts支持以form表單形式發送post請求，只需要將請求的參數構造成一個字典，然后傳給requests.post( )的
data 參數即可。
可以看到，請求頭中的Content-Type字段已設置為application/x-www-form-urlencoded.
且 d = {'key1': 'value1', 'key2': 'value2'} 以form表單的形式提交到服務端，服務端返回的form字段即是
提交的數據。
以json形式發送post請求
可以將一json串傳給requests.post()的data參數
以multipart形式發送post請求
Requests也支持以multipart形式發送post請求，只需將一文件傳給requests.post()的 files 參數即可。
文本文件report.txt的內容只有一行：Hello world!，從請求的響應結果可以看到數據已上傳到服務端中。
boundary 用于分割不同的字段 類似于查詢字符串中的&。不是HTML產生的，可以自己指定。
對于學習python的學習路線，學習方法，系統學習規劃有任何問題，可以關注我的頭條號，私信給我”python“會自動回復python系統學習交流群，群里有學習路線以及詳細的規劃，我做web開發十年的時間，希望幫助新手少走彎路。
. 體系結構 萬維網（WWW）服務是分布式的客戶/服務器服務，客戶使用瀏覽器能夠得到服務器提供的服務，這種服務的提供是分布在許多網站中的，如下圖所示：
圖13-1 分布式的服務
每一個網站保存有一個或多個文檔，叫做萬維網頁面。在圖12-1所示的例子中，客戶需要查看網站A的某些信息。瀏覽器用來讀取萬維網上的文檔。它向網站A發送一個請求，這個請求包含了網站A和網站中萬維網頁面的地址，這個地址叫做統一資源定位符（URL）。網站A收到請求后，將指定的文檔發送給這個客戶。它用同樣的方法與網站B通信。1. 客戶（瀏覽器） 許多廠商提供商用瀏覽器，可以解釋和顯示萬維網頁面。每一個瀏覽器通常由3個部分組成：控制程序、客戶程序及解釋程序。控制程序從鍵盤或鼠標接收輸入，使用客戶程序訪問要瀏覽的文檔。在文檔找到后，控制程序就使用解釋程序（可以是HTML、Java或JavaScript等）中的一個，把文檔顯示在屏幕上。2. 服務器 萬維網頁面存儲在服務器上。每當有客戶請求到達時，對應的文檔就發送給客戶。為了提高效率，服務器通常在其高速緩存中存儲被請求過的文檔；對高速緩存進行訪問要比磁盤快得多。通過多線程或多進程可使服務器的效率更加提高，服務器在同一時間可回答多個請求。3. 統一資源定位符（URL） 客戶要訪問萬維網頁面就需要這個頁面地址。為了方便地訪問文檔，HTTP協議使用統一資源定位符（URL）。URL是Internet上指定信息的標準。URL由4部分組成：協議、主機、端口和路徑，如下圖所示：
圖13-2 URL
協議：協議指定了用這個URL的客戶/服務器程序。例如，HTTP協議、FTP協議和TELNET協議等。 主機：主機指明了信息所存放的地址，可以是邏輯地址也可以是相應的域名。存放萬維網頁面的計算機通常使用以字符"WWW"開始的域名，但這不是強制性的。 端口：端口指定了使用主機的某個端口，端口是可選的。如果包含了端口，那么端口就插入在主機和路徑之間，和主機用冒號分隔開。 路徑：路徑指定了文件存放的位置。路徑本身可以包含斜線，用于將目錄與子目錄和文件分隔開。二. 萬維網文檔 萬維網文檔可分為3類：靜態文檔、動態文檔和活動文檔。這種分類是基于文檔內容被確定的時間。1. 靜態文檔 靜態文檔是固定內容的文檔，它由服務器創建，并存儲在服務器中。客戶只能得到文檔的一個副本。換言之，文件的內容是在文件被創建時就確定的，而不是在它被使用時。當然，在服務器中的內容是可以改變的，但用戶不能改變它。當客戶訪問文檔時，文檔的一個副本就被發送出去。用戶可以使用瀏覽程序顯示這個文檔，如下圖所示：
圖13-3 靜態文檔
2. 動態文檔 動態文檔是在瀏覽器請求該文檔時才由萬維網服務器創建出來。當請求到達時，萬維網服務器就運行創建動態文檔的應用程序。服務器返回這個程序或腳本的輸出，把它作為對請求該文檔的瀏覽器的響應。因為對每一個請求都創建出新的文檔，因此每一個請求得到的動態文檔的內容就會不同。3. 活動文檔 對于許多應用，需要程序能夠在客戶端運行，這就叫做活動文檔。當瀏覽器請求活動文檔時，服務器就發送這個文檔的一個副本或腳本。然后這個文檔就在客戶（瀏覽器）端運行。
三. HTTP協議簡介四. HTTP報文格式
三. HTTP協議簡介 HTTP（超文本傳輸協議）主要用于訪問萬維網上的數據。協議以普通文本、超文本、音頻、視頻等格式傳輸數據。之所以稱為超文本協議，原因是在應用環境中，它可以快速的在文檔之間跳轉。HTTP在熟知端口80上使用TCP服務。四. HTTP報文格式 HTTP報文有兩種一般的類型：請求和響應。這兩種類型的報文格式幾乎是相同的。報文格式如下圖所示：
圖13-4 HTTP報文格式
五. HTTP方法
五. HTTP方法 HTTP報文中的方法是客戶端向服務器端發出的實際命令和請求。常用HTTP方法如下表所示：
表13-1 HTTP方法
六. HTTP狀態碼
六. HTTP狀態碼 在響應報文中，請求行被替換為狀態行，由3位數字組成，表示請求是否被理解或被滿足。HTTP協議的狀態碼如下表所示：
表13-2 HTTP狀態碼
七. 持久與非持久連接 1. 非持久連接 2. 持久連接
七. 持久與非持久連接 在版本1.1以前的HTTP協議默認是非持久連接的，而在版本1.1中，持久連接是默認的連接。1. 非持久連接 在非持久連接中，對每一個請求/響應都要建立一次TCP連接。非持久連接的步驟如下： ● 客戶打開TCP連接，并發送請求。 ● 服務器發送響應，并關閉連接。 ● 客戶讀取數據，直到它遇到文件結束標記；然后它關閉連接。 使用非持久連接時，對于在不同文件中的N個不同圖片的請求，連接必須打開和關閉N次。非持久連接策略給服務器造成了很大的開銷，因為服務器需要N個不同的緩存，而每次打開連接時都要使用慢開始過程。2. 持久連接 HTTP版本1.1指明持久連接是默認的策略。在使用持久連接時，服務器在發送響應后，讓連接繼續為一些請求打開。服務器可以在客戶發送關閉請求時等待或關閉這個連接。發送端通常在每一個響應中都發送數據長度。但是，有時發送端并不知道數據的長度（例如動態文檔或活動文檔），這時服務器就把長度不知道這件事通知客戶，并在發送數據后關閉這個連接，這樣客戶就知道數據結束的地方已經到了。
八. HTTP代理服務器
八. HTTP代理服務器 HTTP支持代理服務器（proxy server）。代理服務器保留對最近請求的響應的副本。在有代理服務器的情況下，HTTP客戶把請求發送給代理服務器。代理服務器檢查它的高速緩存。如果在高速緩存中有這個響應，代理服務器就直接應答客戶的請求；反之，如果在高速緩存中沒有這個響應，代理服務器就把請求發送給相應的HTTP服務器，當HTTP服務器的響應到達代理服務器時，代理服務器將該響應轉發給客戶，同時將該響應存儲到高速緩存中，以便以后為其它客戶的請求使用。 代理服務器減少了原始服務器的負荷，減小了通信量，也減小了延時。但是，由于使用了代理服務器，客戶必須配置成接入到代理服務器而不是那個目標服務器。
頁面訪問
各主機打開工具區的"拓撲驗證工具"，選擇相應的網絡結構，配置網卡后，進行拓撲驗證，如果通過拓撲驗證，關閉工具繼續進行實驗，如果沒有通過，請檢查網絡連接。 本練習一人一組，現僅以主機A為例，其它主機參考主機A的操作。1. 主機A清空IE緩存。2. 主機A啟動協議分析器開始捕獲數據，并設置過濾條件（提取HTTP協議）。3. 主機A啟動IE瀏覽器，在"地址"框中輸入http://服務器的ip/experiment，并連接，服務器IP默認為172.16.0.253。4. 主機A停止捕獲數據，分析捕獲到的數據，并回答以下問題： ● 本練習使用HTTP協議的哪種方法？簡述這種方法的作用。 ● 根據本練習的報文內容，填寫下表。
表13-3 實驗結果
● 參考"會話分析"視圖顯示結果，繪制此次訪問過程的報文交互圖（包括TCP協議）。 ● 簡述TCP協議和HTTP協議之間的關系。
頁面提交
本練習一人一組，現僅以主機A為例，其它主機參考主機A的操作。1. 主機A啟動協議分析器開始捕獲數據，并設置過濾條件（提取HTTP協議）。2. 主機A啟動IE瀏覽器，在"地址"框中輸入"http://服務器的ip/experiment/post.html"，并連接，服務器IP默認為172.16.0.253。在返回頁面中，填寫"用戶名"和"密碼"，點擊[確定]按鈕。3. 主機A停止捕獲數據，分析捕獲到的數據，并回答以下問題： ● 本練習的提交過程使用HTTP協議的哪種方法？簡述這種方法的作用。 ● 此次通信分幾個階段？每個階段完成什么工作？ ● 參考"會話分析"視圖顯示結果，繪制此次提交過程的報文交互圖（包括TCP協議）。
獲取頁面信息
本練習一人一組，現僅以主機A為例，其它主機參考主機A的操作。1. 主機A啟動實驗平臺工具欄中的"TCP工具"。2. 主機A啟動協議分析器開始捕獲數據，并設置過濾條件（提取HTTP協議）。3. 主機A在"TCP工具"上，選中"客戶端"單選框，設置"IP地址"為服務器IP（172.16.0.253）；設置"端口"為80；單擊[連接]按鈕來和服務器建立連接。4. 主機A在"TCP工具"上，設置"發送數據（文本）"為以下內容： HEAD /experiment/ HTTP/1.1<CRLF> Host: 172.16.0.253<CRLF> <CRLF> 點擊[發送]按鈕。 （注：<CRLF>是回車換行） 點擊[斷開]按鈕，斷開TCP連接（由于不同http版本所遵循的規范不同，有些HTTP服務器不需要斷開操作）。 5. 主機A在"TCP工具"上的"顯示數據（文本）"中察看服務器返回信息。6. 主機A停止捕獲數據，分析捕獲到的數據。
較復雜的頁面訪問
本練習一人一組，現僅以主機A為例，其它主機參考主機A的操作。1. 本練習中要求各主機設置DNS服務器地址（DNS服務器的IP地址即主控中心平臺的IP地址），其IP地址以172.16.0.253為例。2. 主機A使用"ipconfig /flushdns"命令清空DNS高速緩存。3. 主機A啟動協議分析器開始捕獲數據并設置過濾條件（提取DNS、HTTP協議）。4. 主機A啟動IE瀏覽器，在地址框中輸入http://JServer.NetLab/complexpage.htm。5. 主機A停止捕獲數據，察看相關會話，分析捕獲到的數據，并回答以下問題： ● 結合本次實驗結果，簡述瀏覽器是如何處理一個訪問請求的。6. 恢復網絡環境，將"首選DNS服務器"清空。
1. 一個主頁是否只有一個連接？
1. 同時打開多個瀏覽器窗口并訪問一個WEB站點的不同頁面時，系統是根據什么把返回的頁面正確地顯示到相應窗口的？
1. 為什么HTTP不保持與客戶端的TCP連接？
，一般現在流傳的HTTP請求：GET和POST的比較是這樣的：
GET和POST是HTTP的兩個常用方法。
什么是HTTP?
超文本傳輸協議(HyperText Transfer Protocol -- HTTP)是一個設計來使客戶端和服務器順利進行通訊的協議。
HTTP在客戶端和服務器之間以request-responseprotocol（請求-回復協議）工作。
GET- 從指定的服務器中獲取數據
POST- 提交數據給指定的服務器處理
GET方法：
使用GET方法時，查詢字符串（鍵值對）被附加在URL地址后面一起發送到服務器：
/test/demo_form.jsp?name1=value1&name2=value2
特點：
· GET請求能夠被緩存
· GET請求會保存在瀏覽器的瀏覽記錄中
· 以GET請求的URL能夠保存為瀏覽器書簽
· GET請求有長度限制
· GET請求主要用以獲取數據
POST方法：
使用POST方法時，查詢字符串在POST信息中單獨存在，和HTTP請求一起發送到服務器：
POST/test/demo_form.jsp HTTP/1.1
Host:w3schools.com
name1=value1&name2=value2
特點：
· POST請求不能被緩存下來
· POST請求不會保存在瀏覽器瀏覽記錄中
· 以POST請求的URL無法保存為瀏覽器書簽
· POST請求沒有長度限制
GET和POST的區別：
其他HTTP請求方式
二，本質上，這些并不是HTTP的GET和POST兩者請求的區別，這些區別是建立在HTML標準對于HTTP協議的用法的約定之上的。
1. GET和POST與數據如何傳遞沒有關系
GET和POST是由HTTP協議定義的。在HTTP協議中，Method和Data（URL， Body， Header）是正交的兩個概念，也就是說，使用哪個Method與應用層的數據如何傳輸是沒有相互關系的。
HTTP沒有要求，如果Method是POST數據就要放在BODY中。也沒有要求，如果Method是GET，數據（參數）就一定要放在URL中而不能放在BODY中。
那么，網上流傳甚廣的這個說法是從何而來的呢？我在HTML標準中，找到了相似的描述。這和網上流傳的說法一致。但是這只是HTML標準對HTTP協議的用法的約定。怎么能當成GET和POST的區別呢？
而且，現代的Web Server都是支持GET中包含BODY這樣的請求。雖然這種請求不可能從瀏覽器發出，但是現在的Web Server又不是只給瀏覽器用，已經完全地超出了HTML服務器的范疇了。
2. HTTP協議對GET和POST都沒有對長度的限制
HTTP協議明確地指出了，HTTP頭和Body都沒有長度的要求。而對于URL長度上的限制，有兩方面的原因造成：
1. 瀏覽器。據說早期的瀏覽器會對URL長度做限制。據說IE對URL長度會限制在2048個字符內（流傳很廣，而且無數同事都表示認同）。但我自己試了一下，我構造了90K的URL通過IE9訪問live.com，是正常的。網上的東西，哪怕是Wikipedia上的，也不能信。
2. 服務器。URL長了，對服務器處理也是一種負擔。原本一個會話就沒有多少數據，現在如果有人惡意地構造幾個幾M大小的URL，并不停地訪問你的服務器。服務器的最大并發數顯然會下降。另一種攻擊方式是，把告訴服務器Content-Length是一個很大的數，然后只給服務器發一點兒數據，嘿嘿，服務器你就傻等著去吧。哪怕你有超時設置，這種故意的次次訪問超時也能讓服務器吃不了兜著走。有鑒于此，多數服務器出于安全啦、穩定啦方面的考慮，會給URL長度加限制。但是這個限制是針對所有HTTP請求的，與GET、POST沒有關系。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
