接口自動化測試之HTTP協議詳解

協議

簡單理解，計算機與計算機之間的通信語言就叫作協議，不一樣的計算機之間只有使用相同的協議才能通訊。因此網絡協議就是爲計算機網絡中進行數據交換而創建的規則，標準或約定的集合。

OSI模型

1978年國際化標準組織提出了「開放系統互聯網參考模型」，即著名的OSI模型。它將計算機網絡體系結構的通訊協議劃分爲7層，自上而下分別是：物理層，數據鏈路層，網絡層，傳輸層，會話層，表示層，應用層。(7層網絡默認具體是什麼自行百度)

那麼們的今天的主題HTTP協議就在應用層，也是應用層使用最多的協議

HTTP

超文本傳輸協議，是一種分佈式，協做式的，面向應用層的超媒體信息系統。它是一種通用的，無狀態的協議。

原理

HTTP協議工做於客戶端與服務器的架構上，客戶端經過URL向服務器發送全部的請求。服務器根據接收到的請求，向客戶端發送響應信息。HTTP協議定義客戶端如何向服務器發送請求，以及服務器如何將響應請求傳送給客戶端，因此HTTP請求協議採用了請求/響應模型

 

客戶端

客戶端主要有兩個職能

1.向服務器發送請求

2.接收服務器返回的報文並解釋成友善的信息供咱們閱讀

客戶端大概有：瀏覽器，應用程序等

現在時代咱們可能使用最多的就是瀏覽器， 當用戶在地址欄輸入網址回車時，瀏覽器會爲何作以下處理：

1.解析協議和域名

2.使用HTTP協議並建立請求報文向服務端發送請求

3.接收服務器返回的內容並展現給客戶

服務端

服務器端在接收到客戶端發送的請求後會開始處理請求

服務器處理過程以下

服務器軟件一直在監聽端口是否有新的請求達到，如iis或者tomcat在創建web站點後，默認會一直監聽80端口等待HTTP請求到達服務器。

1.創建鏈接：若是客戶端已經打開一條道服務器的持久鏈接，則能夠直接使用，不然客戶端須要在服務器打開一條新的鏈接

2.接收請求報文：鏈接上有數據到時，web服務器會從網絡鏈接中讀取數據，並將請求報文中的內容解析出來

3.處理請求：當請求被接收後，服務器即可以根據請求報文進行處理了。例如post方法中提出報文主體的數據並插入到數據庫中

4.訪問資源：請求處理完後，好比web會根據數據生成一系列的HTML頁面或圖片等信息，此步驟將訪問這些存儲在服務器上的物理文件

5.構建響應：web服務器在識別資源後，構造響應報文，響應報文包括：狀態碼，響應頭，響應主體等內容

6.發送響應：服務器將響應的數據發送給客戶端機器

7.記錄日誌：請求結束，服務器會在日誌文件中記錄一條請求日誌

你們都知道瀏覽器想客戶端發送請求是經過URL地址傳遞的，那麼接下來咱們看一下URL的組成

URL

實例URL：https://i.cnblogs.com/EditPosts.aspx?postid=10913098&update=1#name

組成

URL主要有如下幾個部分組成

1.協議部分

該URL的協議爲HTTP

2.域名部分

該URL的域名部分爲/www.kath2.com， URL中也可使用ip地址做爲域名

3.端口部分

端口部分跟在域名：後面，若是沒有，那麼說明URL使用的是默認端口80，端口不是URL的必須組成部分

4.虛擬目錄部分

從域名後的第一個/到最後一個/之間的部分，虛擬目錄也不是URL的必須組成部分

5.文件名部分

最後一個/到？號爲止，是文件名部分。若是沒有？號，則到#號爲止，若是沒有？和#號，則從域名最後/開始到結束都是文件名部分，示例中的文件名部分爲EditPosts.aspx

6.錨部分

從#號到最後

7.參數部分

從？號開始到#號結束， 多個參數使用&號分割

報文

客戶端與服務器之間的信息傳遞使用的載體叫作報文，報文分爲請求和響應兩個部分

請求報文

客戶端發送數據給服務器的過程叫作請求

組成

請求報文分爲4個部分

1.請求首行

包含請求方法，要訪問的資源以及所舒勇的HTTP版本

2.請求頭部

說明服務器要使用的附加信息

3.空行

請求報文頭部後的空行是必須的

4.請求體

get每每不存在請求體，post請求體包含請求的參數

格式

實例

get請求實例

 

post請求實例

請求方法

主要請求方法有get，post，put，delete等

get請求

1.從服務器獲取數據，返回響應的實體部分，能夠類比數據庫的select操做，不會影響數據庫自己

2.沒有請求體

3.請求參數附在URL後，以？號開始，多個參數使用&分割

4.一般對數據不敏感的請求使用get請求，由於參數跟在URL後不安全

5.傳輸的參數長度是有限制的

post請求

1.向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的創建和/或已有資源的修改。

2.一般post請求含有請求體

3.請求參數存放在請求體中，能夠是任意格式

4.相對來講數據比較安全

5.請求數據無大小限制，能夠認爲是無限制

其餘請求不作介紹

響應報文

客戶端發送請求到服務器，服務器處理以後返回數據給客戶端的過程叫作響應

組成

響應報文一樣包含了4個部分

1.響應首行

協議版本，狀態碼，成功與失敗的狀態信息

2.響應頭部

用來講明客戶端要使用的一些附加信息

3.空行

響應報文頭部後的空行是必須的

4.響應數據

返回給客戶端的數據等信息

格式

實例

get響應實例

 post響應實例

響應狀態碼

HTTP擴展

Cookie機制

Cookie是什麼？

你們都知道咱們登陸一個網站的時候，在輸入賬號和密碼的時候下面常常會看到一個「記住我」的選項，那麼只要咱們勾選了這個選項，再次登陸的時候就無需再輸入賬號和密碼便可登陸網站，那麼這種方法就是經過Cookie機制實現的。用來記錄用戶的狀態和用戶的身份

Cookie是由服務器發給客戶端的特殊信息，而這些信息，以文本文件的方式存在客戶端，而後客戶端每次向服務器發送請求的時候就會帶上這些特殊信息，以便服務器作身份識別

Cookie處理過程

當用戶第一次請求服務器時，請求報文中並不會包含Cookie信息，當服務器接收到客戶端的請求時，會響應信息給客戶端，這時候響應報文的頭部會包含一個set-Cookie的字段信息，幷包含了用戶的身份信息。當客戶端收到set-Cookie時，會把Cookie保存在本地（內存或者硬盤中）

當客戶端再次發送請求報文給服務器時，請求報文頭部會攜帶Cookie信息併發送給服務器，服務器經過Cookie自帶的信息分析，動態生成與該客戶端相對應的數據。

實例

第一次訪問

http://120.78.128.25:8765網站，咱們使用Fiddler抓取請求此網站首頁的請求報文和響應報文

能夠看到第一次請求次網站時，請求報文是不含有Cookie信息的，而響應報文返回一個set-Cookie給客戶端

第二次訪問

第二次請求的報文和響應報文，咱們能夠看到已經發生了變化

請求報文已經攜帶了Cookie信息， 而響應報文再也不攜帶set-Cookie信息

因此說只要咱們不清楚cookie信息，那麼之後有效時間內，咱們均可以直接訪問這個網站

Session機制

Session是什麼？

Session是另一種記錄客戶狀態和身份的機制，不一樣的是Cookie保存在客戶端本地中， 而Session保存在服務器中

與Cookie機制做用相同，只不過Cookie是經過檢查客戶身上的通行證肯定客戶身份，而Session則是經過服務器上的客戶明細表來確認客戶身份

Session處理過程

當客戶端第一次請求服務器時，服務器會建立一個Session併爲該Session分配惟一標識Session id，並向Session中添加內容，服務器收到客戶的請求後，會返回給客戶端響應的信息，那麼響應報文頭部會攜帶Session id返回給客戶端

當客戶端再次請求服務器時，請求報文頭部會攜帶以前的Session id(session id 是須要經過cookie傳遞)， 服務器收到請求後根據Session id查找對應的session內容， 並分析對比是否爲同一個客戶端發來的請求，接着返回相應的數據給客戶端

區別

最後咱們經過一個生活中的實例來深刻理解兩者的區別

筆者曾常常去的一家咖啡店有喝5杯咖啡免費贈一杯咖啡的優惠，然而一次性消費5杯咖啡的機會微乎其微，這時就須要某種方式來紀錄某位顧客的消費數量。想象一下其實也無外乎下面的幾種方案： 

    一、該店的店員很厲害，能記住每位顧客的消費數量，只要顧客一走進咖啡店，店員就知道該怎麼對待了。這種作法就是協議自己支持狀態。 

    二、發給顧客一張卡片，上面記錄着消費的數量，通常還有個有效期限。每次消費時，若是顧客出示這張卡片，則這次消費就會與之前或之後的消費相聯繫起來。這種作法就是在客戶端保持狀態。 

    三、發給顧客一張會員卡，除了卡號以外什麼信息也不紀錄，每次消費時，若是顧客出示該卡片，則店員在店裏的紀錄本上找到這個卡號對應的紀錄添加一些消費信息。這種作法就是在服務器端保持狀態。

因爲HTTP協議是無狀態的，而出於種種考慮也不但願使之成爲有狀態的，所以，後面兩種方案就成爲現實的選擇。具體來講cookie機制採用的是在客戶端保持狀態的方案，而session機制採用的是在服務器端保持狀態的方案。同時咱們也看到，因爲採用服務器端保持狀態的方案在客戶端也須要保存一個標識，因此session機制可能須要藉助於cookie機制來達到保存標識的目的，但實際上它還有其餘選擇

原文出處：https://www.cnblogs.com/linuxchao/p/linuxchao-http.html