07- HTTP協議詳解及Fiddler抓包

HTTP協議簡介-超文本傳輸協議

 HTTP協議是請求/響應協議：客戶端發送請求到服務器，服務器響應該請求。當前版本爲1.1版本。

 

 

 

HTTP協議特色

 

1.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET  POST 。

2. 靈活：HTTP容許傳輸任意類型的數據對象。傳輸的類型由content-type加以標記。

3.無鏈接：無鏈接的含義就是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應道後，即斷開連接。

4.無狀態：HTTP協議是無狀態協議。無狀態是指協議對與事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則他必須重傳，這樣可能致使每次連接傳送的數據量增大。

 

HTTP消息

 HTTP消息由從客戶端到服務器的請求消息和服務器到客戶端的響應消息組成。

 

HTTP請求消息實例

 

客戶端發送一個HTTP請求到服務器的請求消息包括如下格式：請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成，下圖給出了請求報文的通常格式。

 

實例：

GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi

 

HTTP請求方法

 

 

http經常使用請求-get請求方法

get請求通常用於獲取/查詢資源信息，格式爲：

 

GET /books/?sex=man&name=Professional HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive

 

HTTP經常使用請求--post請求方法

post請求通常用於提交表單，格式爲：

 

POST / HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alive
（----此處空一行----）
name=Professional%20Ajax&publisher=Wiley

 

 

 

 

URL

URL = http://主機名：端口/l路徑？查詢

若是沒有指定端口，那麼默認使用80端口

例子：

http://www.baidu.com/

https://www.baidu.com/baidu?wd=w3school

 

常見的請求頭

請求頭，用來講明服務器要使用的附加信息，比較重要的信息有 Cookie、Referer、User-Agent 等，下面將一些經常使用的頭信息說明以下：
    Accept，請求報頭域，用於指定客戶端可接受哪些類型的信息。
    Accept-Language，指定客戶端可接受的語言類型。
    Accept-Encoding，指定客戶端可接受的內容編碼。
    Host，用於指定請求資源的主機 IP 和端口號，其內容爲請求 URL 的原始服務器或網關的位置。從 HTTP 1.1 版本開始，Request 必須包含此內容。
    Cookie，也經常使用複數形式 Cookies，是網站爲了辨別用戶進行 Session 跟蹤而儲存在用戶本地的數據。Cookies 的主要功能就是維持當前訪問會話，例如咱們輸入用戶名密碼登陸了某個網站，登陸成功以後服務器會用 Session 保存咱們的登陸狀態信息，後面咱們每次刷新或請求該站點的其餘頁面時會發現都是保持着登陸狀態的，在這裏就是 Cookies 的功勞，Cookies 裏有信息標識了咱們所對應的服務器的 Session 會話，每次瀏覽器在請求該站點的頁面時都會在請求頭中加上 Cookies 並將其發送給服務器，服務器經過 Cookies 識別出是咱們本身，而且查出當前狀態是登陸的狀態，因此返回的結果就是登陸以後才能看到的網頁內容。
    Referer，此內容用來標識這個請求是從哪一個頁面發過來的，服務器能夠拿到這一信息並作相應的處理，如作來源統計、作防盜鏈處理等。
    User-Agent，簡稱 UA，它是一個特殊字符串頭，使得服務器可以識別客戶使用的操做系統及版本、瀏覽器及版本等信息。在作爬蟲時加上此信息能夠假裝爲瀏覽器，若是不加極可能會被識別出爲爬蟲。
    Content-Type，即 Internet Media Type，互聯網媒體類型，也叫作 MIME 類型，在 HTTP 協議消息頭中，使用它來表示具體請求中的媒體類型信息。例如 text/html 表明 HTML 格式，image/gif 表明 GIF 圖片，application/json 表明 Json 類型，更多對應關係能夠查看此對照表：http://tool.oschina.net/commons。

請求體

　　即請求體，通常承載的內容是 POST 請求中的 Form Data，即表單數據，而對於 GET 請求 Request Body 則爲空。

  　例如在這裏我登陸 GitHub 時捕獲到的 Request 和 Response 如圖

 

 

在登陸以前咱們填寫了用戶名和密碼信息，提交時就這些內容就會以 Form Data 的形式提交給服務器，此時注意 Request Headers 中指定了 Content-Type 爲 application/x-www-form-urlencoded，只有設置 Content-Type 爲 application/x-www-form-urlencoded 纔會以 Form Data 形式提交，另外咱們也能夠將 Content-Type 設置爲 application/json 來提交 Json 數據，或者設置爲 multipart/form-data 來上傳文件。

下面列出了 Content-Type 和 POST 提交數據方式的關係：

 

 

HTTP響應

　　客戶端向服務器發送一個請求，服務器返回響應，HTTP協議也有四部分組成。分別是：狀態行，消息報頭（響應頭），空行和響應正文。

　　根據響應的類別，服務器響應裏能夠含有響應正文，但並無全部的響應都有響應正文。

 

HTTP響應實例

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

 

常見的HTTP響應頭

響應頭，其中包含了服務器對請求的應答信息，如 Content-Type、Server、Set-Cookie 等，下面將一些經常使用的頭信息說明以下：

    Date，標識 Response 產生的時間。
    Last-Modified，指定資源的最後修改時間。
    Content-Encoding，指定 Response 內容的編碼。
    Server，包含了服務器的信息，名稱，版本號等。
    Content-Type，文檔類型，指定了返回的數據類型是什麼，如text/html 則表明返回 HTML 文檔，application/x-javascript 則表明返回 JavaScript 文件，image/jpeg 則表明返回了圖片。
    Set-Cookie，設置Cookie，Response Headers 中的 Set-Cookie即告訴瀏覽器須要將此內容放在 Cookies 中，下次請求攜帶 Cookies 請求。
    Expires，指定 Response 的過時時間，使用它能夠控制代理服務器或瀏覽器將內容更新到緩存中，若是再次訪問時，直接從緩存中加載，下降服務器負載，縮短加載時間。

 

HTTP響應狀態碼

 

Response 消息中的第一行叫作狀態行，由HTTP協議版本號， 狀態碼， 狀態消息 三部分組成。

狀態碼用來告訴HTTP客戶端,HTTP服務器是否產生了預期的Response.

HTTP/1.1中定義了5類狀態碼， 狀態碼由三位數字組成，第一個數字定義了響應的類別

1XX  提示信息 - 表示請求已被成功接收，繼續處理

2XX  成功 - 表示請求已被成功接收，理解，接受

3XX  重定向 - 要完成請求必須進行更進一步的處理

4XX  客戶端錯誤 -  請求有語法錯誤或請求沒法實現

5XX  服務器端錯誤 -   服務器未能實現合法的請求

 

HTTP響應狀態碼-典型

 

GET請求與post請求區別

get請求方法:

請求資源

請求數據在URL中，只能提交字符串類型的數據，長度有限制，少於255字符。

get方法速度快

安全性低，數據置於請求行，客戶端地址可見。

post請求方法：

提交數據

請求數據在請求主體中傳遞

安全性高，數據置於消息主題內，客戶端不可見。

請求數據類型不受限制，長度不受限制。

速度慢

 

 http協議是無狀態的

 http協議是無狀態的，同一個客戶端的此次請求和上次請求是沒有對應關係，對http服務器來講，它並不知道這兩個請求來自同一個客戶端。 爲了解決這個問題， Web程序引入了Cookie機制來維護狀態。

 

fiddler抓包工具簡介

 fiddler是經過改寫HTTP代理，讓全部客戶端和服務器的http和https請求從fiddle那經過，容許你監視，設置斷點，甚至修改輸入輸出數據。

在打開fiddle他的那一瞬間，他就已經設置好了瀏覽器的代理了。當你關閉的時候它又幫你把代理還原了，一切不須要手動設置。

fiddler抓包原理

 

fiddler抓包工具

火狐瀏覽器須要本身設置代理，谷歌瀏覽器自動設置代理

 

 

請求過濾

 

 

https安裝證書

 

移動端APP抓包

 

 

接口定義

 

接口是個比較泛義上的概念，主要表示系統對外交互的部分，好比電源插座是電器和電能之間的接口，圖形界面是應用軟件和用戶的接口，醫院掛號大廳是醫生和病人之間的接口

 

 

 

 

 

webAPI

 

咱們要學習的接口概念縮小到web系統提供的對外消息交互接口，經過發送對應的請求給服務器，服務器會返回相應的結果，由於其調用模式很是像編程語言中的API，因此web消息交互接口又叫webapi。 

 

 

 

 

 

 

 

Web服務接口

 

目前web服務接口都是基於http協議傳遞消息

 

一般你們所說的，web服務接口，websevice ,webapi其實表示的都是一個意思

 

主流的http消息體類型主要分爲兩種

 

SOAP UI: 使用XML格式傳輸消息體，因爲閱讀性差，同等信息量傳輸耗費的資源多，由於標籤

 

 

 

REST: 定義了一種消息傳輸的風格，規定了消息體和URL的請求格式，同時也規定服務端的開發設計架構。本質上仍是用http協議傳輸消息，至於這種風格具體是什麼，怎麼就肯定我開發的系統符合REST定義的風格規範，不少作了不少年服務端開發的人員也不必定能說清楚，因爲沒有強制的要求，即便開發的服務沒有徹底符合REST風格規範，也可使用

 

 

 

因此咱們也不須要了解到底REST風格是什麼樣子的，可能大家有疑惑，這個也不瞭解那麼咱們怎麼測試webapi呢

 

 

 

其實咱們只要知道，無論系統處於那種設計風格，只要是基於HTTP協議，咱們就能對他進行測試

 

只要是發送數據交互過程有來有往，咱們就能夠用通用的方法來測試這個系統

 

 

 

 

 

 

 

 

 

 

 

 

 

webAPI 測試特色

 

一般系統內部的接口是不須要QA測試的，若是測試須要提供API文檔，由於這是一個判斷api是否符合需求的標準。

 

即便要測試內部接口，多數也不是從功能的角度來測試，而是以安全的角度。

 

 

 

對外暴露的接口必需要對其進行測試，若是提供API文檔，那麼測試人員須要本身準備文檔，而後提交給開發進行評審。

 

 

 

 

 

HTTP協議基礎

 

http與html的關係

 

新學習web的人常常混淆的兩個名詞就是HTTP和HTML，

 

都是姓H的，都是互聯網領域的名詞。很容易混淆。

 

 

 

HTML是一種用來定義網頁的文本語言，

 

會HTML，就能夠編寫網頁；

 

咱們訪問百度獲得的內容是html，你們能夠打開瀏覽器查看源碼看到HTML

 

 

 

HTTP是在網絡上傳輸信息（固然也包括HTML）的協議，一般用於瀏覽器和服務器的通訊。

 

 

 

二者的關係作個類比，一個比如快遞的商品（HTML），一個比如運輸商品的方式（http）

 

 

 

快遞盒子既能夠包裝手機也能夠包裝其餘商品，什麼類型的信息都是不限制的

 

 

 

 

 

 

 

http請求

 

http請求消息包含以下內容

 

 

 

l 請求行（必須包含）

 

是http請求的第一行的內容，表示操做什麼資源，經過什麼http協議版本去獲取

 

例如GET /images/logo.gif HTTP/1.1，

 

表示從/images目錄下請求獲取logo.gif這個文件。

 

再好比

 

POST / HTTP/1.1

 

表示向這個url地址 / 提交信息。

 

GET POST是請求的方法，咱們後面會進一步講解

 

 

 

l 請求頭（必須包含）

 

例如Accept-Language: en

 

能夠有好多個，好比

 

 

 

 

 

接下來http請求消息裏面可能還有

 

l 空行（非必須）

 

l 消息體（非必須）

 

空行的主要目的是隔開消息頭和消息體的

 

 

 

因此：

 

請求行和請求頭是必須有的。

 

空行和消息體可能有也可能沒有。

 

 

 

一個GET請求消息的例子以下

 

GET/index.htmlHTTP/1.1

 

Host: www.example.com

 

 

 

這個例子裏面包括請求行和一個請求頭，沒有消息體。

 

 

 

 

 

一個POST請求消息的例子以下（注意請求頭和消息體之間的空行）

 

 

 

POST / HTTP/1.1

 

Host: foo.com

 

Content-Type: application/x-www-form-urlencoded

 

Content-Length: 13

 

 

 

say=Hi&to=Mom

 

 

 

請求行

 

請求行在第一行，包含

 

l 請求的方法

 

請求的方法，表示請求的動做是獲取信息、仍是提交信息，仍是修改信息、仍是刪除信息等。。

 

 

 

常見的有 GET，POST，PUT，DELETE

 

GET：

 

請求獲取Request-URI所標識的資源

 

就是向uri指定的資源發出「獲取」請求。使用GET方法通常用在讀取數據，

 

這應該是一種最多見的請求了。

 

 

 

POST：

 

表示在Request-URI所標識的資源後附加新的數據

 

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

 

數據被包含在請求消息中。這個請求可能會建立新的資源或修改現有資源。

 

 

 

PUT：

 

向指定資源位置上傳其最新內容。一般用於更新修改部分資源信息。

 

 

 

DELETE：

 

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

 

 

 

 

 

 

 

請求頭字段 (request headers)

 

http的請求頭用來表示請求的其它信息。

 

格式是：大小寫不敏感的名字+冒號+空格+值

 

就像鍵值對，一個名字一個值，一個名字一個值

 

 

 

不少標準的請求頭字段是由國際標準化組織制定的

 

https://tools.ietf.org/html/rfc4229

 

 

 

常見的請求頭字段

 

Accept-Encoding:

 

例：

 

Accept-Encoding:gzip, deflate, br

 

表示客戶端所支持的解碼（解壓縮）格式。

 

 

 

網路數據的傳輸都是佔據帶寬的，而將文件數據壓縮可以下降數據量，減小傳輸時間。因此服務器在返回數據給客戶端時，經常對數據進行壓縮（對用戶透明，一般由服務器或代理來作），而壓縮的方式有多種，到底採用哪種則須要看客戶端支持哪一種解碼方式，這時候就能夠根據header中Accept-Encoding的值。

 

 

 

文件或數據的壓縮，由服務器或代理來作，通常不須要程序員干預；客戶端接收到數據時解壓縮，一般由瀏覽器自動完成，對用戶透明。

 

對於咱們主動發起的ajax請求，通常數據量較少，不須要設置該字段。

 

 

 

Accept-Language:

 

例

 

Accept-Language:zh-CN,zh;q=0.9

 

表示客戶端支持的語言格式（不是編碼格式），如中文/英文，一般瀏覽器直接發起請求時，瀏覽器會根據被設置的語言環境（默認語言），來附加上該字段。

 

 

 

通常咱們服務器解析報文時，是不理會該字段的。

 

他的使用場景能夠是這樣的，假若有個文件，有各類語言的版本，這樣當不一樣請求發來時，咱們能夠根據Accept-Language的值來判斷到底返回哪一種語言版本給客戶端。

 

（其實這種應用場景也通常不採用判斷Accept-Language字段的方法，不靠譜，還不如直接在url中體現語言版本呢）

 

 

 

Accept-Charset：

 

例：

 

Accept-Charset:gbk,utf-8;q=0.8

 

表示客戶端支持編碼格式。服務器在返回報文時，須要將字符按照必定的編碼格式轉換爲字節序列發送給客戶端，那麼該採用哪一種編碼格式呢？

 

固然做爲服務器端，他能夠採用任何一種編碼方式，客戶端都得完完整整的接收響應報文。由於目前客戶端幾乎都支持常見編碼類型，因此服務器在返回數據時，只須要按照既定的編碼方式編碼，而後在響應報文中告知客戶端所使用的編碼方式。這樣客戶端在接收到報文後按照該方式進行解碼，就就不會出現亂碼問題。

 

 

 

可是，若是客戶端已經定了就使用某種解碼方式，那麼這時候服務器端就不能那麼任性了，他就須要解析Accept-Charset字段，根據這個值，來設定採用的編碼方式。

 

如上例中，以逗號分隔，客戶端支持兩種編碼方式，gbk和utf-8（gbk優先級高於utf8），其中utf-8後的q值，表示utf-8佔的「權重」。

 

---------------------

 

User-Agent:

 

例：

 

User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36

 

表示客戶端的軟件環境。如上能夠看出使用的是Window10 64位操做系統，Chrome瀏覽器等信息。服務器能夠根據該字段評估客戶端的環境從而給出不一樣的響應。（好比根據請求是從手機端或是電腦端發起的，返回不一樣版本的頁面）

 

 

 

Host：

 

例：

 

Host:localhost:8080

 

表示請求者的主機地址（IP地址）和端口號。

 

服務器端能夠根據該字段進行ip過濾等操做。

 

 

 

Content-Type

 

例子：

 

Content-Type :application/x-www-form-urlencoded

 

表示請求體的消息類型 （用於POST和PUT請求中）

 

常見的有x-www-form-urlencoded格式json格式還有xml格式

 

 

 

請求消息體

 

不少時候，http請求是須要請求消息體的，好比POST、PUT等請求。

 

Get一般是不須要消息體的。

 

 

 

post、put提交信息，會把消息內容翻到請求體裏面。

 

 

 

請求消息體中保存了要提交給服務端的數據信息。

 

常見的消息體格式就三種，json，xml，www- form-urlencoded

 

其中最多見的就是json是後面課程的重點

 

 

 

json用來傳遞稍微複雜的數據

 

傳遞簡單的用 www-form-urlencode

 

 

 

http響應

 

 

 

HTTP響應消息包含以下內容

 

 

 

l 狀態行

 

l 響應頭

 

l 空行

 

l 消息體

 

 

 

狀態行和響應頭是必須有的。

 

空行和消息體可能有也可能沒有。

 

狀態行

 

狀態行在第一行，包含協議版本狀態碼和描述狀態的短語

 

好比

 

HTTP/1.1 200OK

 

咱們重點來看一下狀態碼，它表示客戶端的的請求結果如何

 

• 1xx消息——請求已被服務器接收，繼續處理

 

（這類不常見，先忽略過去）

 

• 2xx成功——請求已成功被服務器接收、理解、並處理

 

（最常見的就是200，抓包給你們看看）

 

• 3xx重定向——須要後續操做才能完成這一請求

 

（在webapi中不常見）

 

就像店面移到新的地址，會貼一個告示，小王理髮店已經移到。。

 

301 Moved Permanently永久性移動到新地址，再訪問這個資源，就直接用新地址。好比小王理髮店永久性移動到西街。。

 

若是下次訪問，能夠直接去西街

 

302 Moved Temporarily這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求

 

小王理髮店，只是暫時的裝修，臨時移到西街，之後還會移回來，下次應該仍是先去東街看看。

 

 

 

304 Not Modified

 

表示資源未被修改，由於請求頭指定的版本If-Modified-Since或If-None-Match。在這種狀況下，因爲客戶端仍然具備之前下載的副本，所以不須要從新傳輸資源

 

現代的瀏覽器常常緩存資源數據，若是資源未被修改，一般不須要服務端傳回所有的資源信息。節省效率和帶寬。

 

其它的 30x不是特別常見，感興趣的能夠本身去學習。。

 

 

 

轉發與重定向區別

 

https://www.cnblogs.com/ChrisMurphy/p/5059940.html

 

 

 

4xx請求錯誤——

 

這類的狀態碼錶明瞭客戶端看起來可能發生了錯誤，妨礙了服務器的處理。

 

400 Bad Request

 

401 Unauthorized未認證

 

403 Forbidden認證了，可是沒有相應的權限

 

404 Not Found，訪問http://ci.ytesting.com/portal/home33.html

 

常見錯誤，你們訪問博客的時候，有時候遇到帖子被刪了，或者文章的url發生了變化，用原來的地址訪問就會出現這種狀況

 

 

 

• 5xx服務器錯誤——服務器在處理某個正確請求時發生錯誤

 

 

 

表示服務器沒法完成明顯有效的請求。這類狀態碼錶明瞭服務器在處理請求的過程當中有錯誤或者異常狀態發生，也有多是服務器意識到以當前的軟硬件資源沒法完成對請求的處理。

 

 

 

500 Internal Server Error服務端的代碼錯誤致使，一般是一個異常拋出了

 

 

 

503 Service Unavailable

 

因爲臨時的服務器維護或者過載（好比被攻擊致使服務端的防護措施），服務器當前沒法處理請求。這個情況是暫時的，而且將在一段時間之後恢復。

 

 

 

 

 

 

 

響應頭字段 (response headers)

 

http的響應頭用來表示響應的其它信息。

 

格式和請求頭相似，有不少能夠共用的字段。

 

Content-Type:text/html;charset=utf-8

 

消息體的數據格式，這個是常用的， 

 

 

 

Content-Length表示請求消息體的長度

 

Date:Sun, 30 Jul 2017 08:25:37 GMT表示響應消息發送的日期時間

 

 

 

其餘經常使用的響應頭感興趣的能夠參考網上的信息，後面的課程會一一說到

 

 

 

 

 

響應消息體

 

不少時候，http響應是須要消息體的。好比請求一個網頁的內容，那麼咱們網頁的html內容就在響應的消息體中給出。

 

 

 

 

 

fiddler抓包工具

 

百度搜索 fiddler，https://www.telerik.com/fiddler

 

安裝下載

 

 

 

 

 

隨便填寫

 

 

 

 

 

安裝後打開，界面以下：

 

 

 

 

 

 

 

左邊是抓到的http請求和響應，右邊能夠顯示其具體信息。

 

 

 

 

 

fiddler抓包原理是做爲代理監聽了瀏覽器到web服務器之間的http通訊請求

 

如圖：

 

 

 

 

 

上面瀏覽器和服務器之間沒有代理，抓不到包

 

下面瀏覽器和服務器之間加了代理，能夠抓包

 

 

 

fiddler做爲代理的 ip和端口是

 

tools-> options

 

 

 

 

 

動的時候，會修改系統代理設置，把本身設置爲系統代理

 

 

 

 

 

若是咱們要使用fiddler抓 web網站先後端的包，就要保證瀏覽器會使用 fiddler做爲 proxy

 

有的瀏覽器好比火狐，不必定使用系統代理，能夠手動設置瀏覽器代理爲Fiddler的代理

 

抓個包看看。

 

 

 

這個inspector是查看內容

 

 

 

 

 

看raw部分

 

 

 

若是這樣，不少包都抓了，有些包不是咱們關心的。

 

咱們能夠設置過濾條件，根據host過濾

 

 

 

locahost; httpbin.com

 

 

 

 

 

甚至根據url路徑過濾