Python介面自動化測試必備基礎之http協定詳解
- WBOY轉載
- 2022-05-31 11:39:582274瀏覽
本篇文章為大家帶來了關於python的相關知識，其中主要介紹了關於接口自動化測試必備基礎中http協議的相關問題，下面一起來看一下，希望對大家有幫助。
推薦學習：python視訊教學
# HTTP協定與特點
如果將HTTP協定當作一個人來比較的話，想要深入了解這個人的時候，一定會先去了解對方的性格特質等。那麼 HTTP協定 有什麼特徵呢？總的來說有以下幾個特點：
- 1、第一個特點：
HTTP協定支援客戶/服務端模式；因為HTTP 協定是TCP、IP 協定簇的一員，與其他成員一樣，用於客戶端與伺服器之間的通訊；而客戶/伺服器模式的工作方式是由客戶端向伺服器發出請求，伺服器端回應請求，並進行回應的服務；所有的HTTP請求都是從客戶端開始建立通信，伺服器端在沒有接收到任何的客戶端請求之前是不會發出回應的；這就是HTTP協定的特點之一。
- #2、第二個特點：
簡單快速；客戶端向伺服器請求服務的時候，只需要傳入請求的方法和路徑；常用的請求方法有GET、HEAD、POST（除了這三種之外，還有其他不那麼常用的方法，有興趣的夥伴可以在HTTP協定狀態及封包組成一文進行拓展）；由於HTTP協定簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快。
- 3、第三個特點：
靈活；之所以靈活是因為HTTP 允許傳輸任意類型的資料物件；傳輸的類型由Content-Type加以標記內容類型，支援多種內容格式的傳輸。 (相容性很強)
- 4、第四個特點：無連線；這裡的無連線可不是沒有連線的意思，而是限制每個連線只處理一個請求。伺服器處理完客戶端的請求並收到客戶端的應答之後，就中斷連線。採用如此的設計方式呢，能夠節省傳輸時間。
- 拓展：可能有同學認為一個頁面有很多個 HTTP 請求，來回這樣連接、斷開會效率很低。其實早期這麼做的原因是因為產生於互聯網，因此伺服器需要處理同時面向全世界 數十萬、上百萬 的網頁訪問。但是每個客戶端（或者說瀏覽器）與伺服器之間交換資料的間歇性特別大，所以HTTP 的傳輸是具備突發性與順時性的，大部分通道實際上會很空閒，無端的佔用資源比較浪費。因此呢， HTTP 的設計者有意使用這樣的特點將協定設計為
請求的時候建立連接，請求完就釋放連接。盡快的將資源釋放出來服務給其他的客戶端，無論怎樣，對於同一個客戶端來說，還是每一次只處理一個請求，所以我們也能看出來HTTP 協定的另外一個優點，它很專一。 (*^▽^*)
- 5、最後一個特點：無狀態；無狀態的意思是說
HTTP協定對於事務的處理沒有記憶能力；缺少狀態就意味著如果後續處理需要前面的信息，則必須要重傳，這就很可能會導致每次連接傳送的資料量增大。另一方面，在伺服器不需要先前的資訊時它的回應就比較快。
PS：所以 HTTP 的這些特性是既有優點也有缺點。
- 優點：優點在於解放伺服器，每次請求點到為止不會造成不必要的連線佔用。
- 缺點：缺點在於每一次請求都會傳送大量重複的內容訊息。
- 所以保持 HTTP 連線的兩種技術就應運而生了，那就是
cookie與session。
HTTP的請求與回應
現在我們知道HTTP協定是一種請求與回應的模式，那麼就來一起認識HTTP的請求與回應吧，先從HTTP協定的請求說起。
HTTP的請求
請求 是傳送給介面的資料對象，包含介面的位址（也就是常說的URL）、請求的方法（get、post…）、參數、請求頭（Headers）、Cookies、資料等等… 見下圖：
##
上圖中的封包內容就是典型的HTTP協定的post 與get 請求封包（忽略get請求訊息的請求體，那是我瞎編的 。）：
1、第一行就是請求行，包含有請求方法、請求URI、HTTP協定及版本（與第二行的host屬性結合形成了完整的請求URL ）
2、中間的部分就是封包頭，包含有若干個屬性；格式就是圖中的
屬性名:屬性值這樣的格式。服務端根據報文頭來取得客戶端的資訊。3、最下面的部分就是報文體，封包與封包頭之間必須有一個空行。在類似圖中這樣一個
post 請求裡面將頁面表單裡的元件值透過name=admin&passwd=123456這樣類似的鍵值對的格式編碼形成這樣的格式化串，承載多個請求參數的資料。 （不只是報文體可以傳輸數據，請求的URL 在get 請求方法的時候也是支援傳遞參數的。）
在這裡可以看出主要的訊息是透過請求的方法、url、與封包的主體來傳遞的。這也是 HTTP 的特徵之一，簡單快速，同時也會發現報文頭裡也包含有很多種信息，這些做一個了解即可。參考 HTTP協定狀態及封包組成 文末的請求頭報文。
HTTP的回應
熟悉了 HTTP 的請求，然後再來看一下回應。見下圖：
可以從回應封包的樣式看出，與請求的封包比較相像，他也分成三個部分：請求行對應回應行、請求頭對應回應頭、請求體對應回應體。
- 1、回應行分為兩部分：封包協定版本及回應狀態碼。
- 2、回應頭也分為伺服器類型、對應資料類型回應時間等多個參數。
- 3、回應體就是我們真正想要的乾貨，就是請求的最終回傳內容。主要針對這個內容進行解析，比如說請求的是一個頁面，這個時候請求的回傳就是一個比較大的
HTML。
HTTP請求方法剖析
更多內容參考 HTTP協定狀態及封包組成 一文的 HTTP請求方法 。
GET 方法
GET方法 用來要求存取已被URI 識別的資源，指定的資源經伺服器端解析後回傳回應內容。 （見下圖）
PSOT 方法
##POST方法 與GET方法 功能類似，一般用來傳輸實體的主體；主要的目的不是為了獲取回應主體的內容，是向WEB伺服器提供表單數據，尤其是大批量的數據 。
POST方法 其實是克服了GET方法 的一些缺點，透過POST 請求，資料就不是作為一個URL 請求的一部分了，而是作為標準資料的格式來傳遞給WEB伺服器 這也克服了GET方法 中資料無法保密且資料量有限制的缺點。
接下來就是一些不太常用的一些方法的介紹了。
PUT 方法
- 從客戶端傳送到伺服器的資料取代指定的文件的內容。
- PUT方法與POST方法最大的不同的是：PUT是冪等的，而POST是不冪等的。因此，更多的時候我們將
PUT方法用作傳輸資源。開啟 PUT方法 需要控制權限，否則會造成一定的安全性隱患，例如向伺服器傳輸帶有惡意 payload 的攻擊腳本。
HEAD 方法
#HEAD方法幾乎與GET方法相同，只不過HEAD方法只要求訊息封包頭，回傳的回應中沒有具體的內容，用來取得標頭。
DELETE 方法
- #請求伺服器刪除指定的資源，也就是刪除檔案。 （一般伺服器會控制此方法的權限，否則會造成重大的安全漏洞。）
#OPTIONS 方法
- 用來查詢針對請求的URI 指定的資源支援的方法，就是詢問
請求的URL能夠支援什麼方法。
該方法在實際工作中使用的是非常少的，在安全領域經常會被攻擊者、滲透測試工程師使用於資訊收集。
TRACE 方法
- 用於回顯伺服器收到的請求，主要用於測試或診斷。 （不常用）
- 在安全領域經常被用於跨站攻擊。
CONNECT 方法
- 開啟與客戶端所要求的資源之間的雙向溝通的通道，所以更多的時候是用它來建立隧道。 （使用代理程式的時候就是使用的這個方法）
HTTP狀態碼詳解
HTTP 狀態碼
在我們使用瀏覽覽器向WEB網頁所在伺服器發出請求時，當伺服器接收我們的請求並回應的情況下。瀏覽器會接收並顯示網頁，此網頁所在的伺服器會傳回一個包含HTTP狀態碼的資訊頭（server header）用來回應我們在瀏覽器中的請求。
HTTP狀態碼的英文為HTTP Status Code。
下面是常見的HTTP狀態碼
- 200 - 請求成功
- 301 - 資源（網頁等）被永久轉移到其它URL
- #404 -請求的資源（網頁等）不存在
- #500 - 內部伺服器錯誤
#HTTP狀態碼分類
| #分類 | 描述 |
| 1** | |
| 2** |
HTTP狀態碼表
狀態碼 |
英文名稱 | 中文描述 |
|---|---|---|
| #100 | #Continue | 繼續。客戶端應繼續其請求 |
| 101 | Switching Protocols | #切換協定。伺服器根據客戶端的請求切換協定。 只能切換到更進階的協議，例如，切換到HTTP的新版本協定 |
| #200 | OK | #請求成功。一般用於GET與POST請求 |
| 201 | Created | 已建立。成功請求並建立了新的資源 |
| 202 | Accepted | 已接受。已接受請求，但未處理完成 |
| 203 | Non-Authoritative Information | 非授權資訊。請求成功。但傳回的meta資訊不在原始的伺服器，而是副本 |
| 204 | No Content | 無內容。伺服器成功處理，但未傳回內容。在未更新網頁的情況下，可確保瀏覽器繼續顯示目前文件 |
| 205 | Reset Content | 重設內容。伺服器處理成功，使用者終端（例如：瀏覽器）應重設文件視圖。 可透過此回傳碼清除瀏覽器的表單域 |
| 206 | Partial Content | ##206 |
| ##部分內容。伺服器成功處理了部分GET請求 | 300 | Multiple Choices|
| 用於使用者終端（例如：瀏覽器）選擇 | 301 | Moved Permanently|
| 瀏覽器會自動定向到新URI。今後任何新的請求都應使用新的URI代替 | 302 | |
| 暫時移動。與301類似。但資源只是臨時被移動。用戶端應繼續使用原有URI | 303 | |
| 來檢視其它位址。與301類似。使用GET和POST請求查看 | 304 | Not Modified|
| 會快取存取過的資源，透過提供一個頭資訊指出客戶端希望只傳回指定日期之後修改的資源 | 305 | |
| 使用代理程式。所請求的資源必須透過代理程式存取 | 306 | |
| 已經被廢棄的HTTP狀態碼 | ||
| ##307 | Temporary Redirect | |
| 401 | Unauthorized | |
| ##402 | Payment Required ###保留，將來使用############403######Forbidden######伺服器理解請求客戶端的請求，但是拒絕執行此請求############404######Not Found######伺服器無法根據客戶端的請求找到資源（網頁）。透過此程式碼，網站設計人員可###設定"您所要求的資源無法找到"的個性頁面 |
|
| 405 | Method Not Allowed | 客戶端請求中的方法被禁止 |
| 406 | Not Acceptable | 伺服器無法根據客戶端請求的內容特性完成請求 |
| 407 | Proxy Authentication Required | 請求要求代理程式的身份認證，與401類似，但請求者應使用代理程式進行授權 |
| 408 | Request Time-out | 伺服器等待客戶端傳送的請求時間過長，逾時 |
| 409 | Conflict | |
| #伺服器完成客戶端的PUT請求是可能返回此程式碼，伺服器處理請求時發生了衝突 | ||
| Gone | 客戶端請求的資源已經不存在。 410不同於404，如果資源以前有現在被永久刪除了可使用410程式碼， | 網站設計人員可透過301程式碼指定資源的新位置 |
| 411 | Length Required | 伺服器無法處理客戶端發送的不含Content-Length的請求訊息 |
| Precondition Failed | 客戶端請求訊息的先決條件錯誤 | |
| Request Entity Too Large | 由於請求的實體過大，伺服器無法處理，因此拒絕請求。為防止客戶端的連續請求，伺服器可能會 | 關閉連線。如果只是伺服器暫時無法處理，則會包含一個Retry-After的回應訊息 |
| 414 | Request-URI Too Large | 請求的URI過長（URI通常為網址），伺服器無法處理 |
| 415 | Unsupported Media Typ | 伺服器無法處理請求附帶的媒體格式 |
| 416 | Requested range not satisfiabl | 客戶端請求的範圍無效 |
| 417 | Expectation Failed | 伺服器無法滿足Expect的請求頭資訊 |
| #500 | Internal Server Erro | #伺服器內部錯誤，無法完成請求 |
| 501 | Not Implemented | 伺服器不支援請求的功能，無法完成請求 |
| Bad Gateway | 充當網關或代理程式的伺服器，從遠端伺服器接收到了一個無效的請求 | |
| Service Unavailable | 由於超載或系統維護，伺服器暫時的無法處理客戶端的請求。延時的長度可包含在伺服器 | 的Retry-After頭資訊中 |
Gateway Time-out
充當網關或代理程式的伺服器，未及時從遠端伺服器取得請求
以上是Python介面自動化測試必備基礎之http協定詳解的詳細內容。更多資訊請關注PHP中文網其他相關文章！