利用wireShark抓取iphone手機上的網絡通訊包

說明

之前利用工具抓取網絡請求時都是使用Charles，而後愈來愈以爲Charles有些卡，而且只能過濾HTTP協議。可是Charles過濾的網絡請求數據顯示的很是清晰。 後來就換着使用WireShark來抓取手機上的網絡請求。

WireShark功能很是強大，它能過濾幾乎全部的協議，而且也不多出現卡頓的狀況，體驗起來確實比Charles要好。在介紹使用WireShark以前，咱們首先要了解一些常見的協議：HTTP,TCP,UDP等。

HTTP協議

概念

HTTP協議，即超文本傳輸協議(Hypertext transfer protocol)。是一種詳細規定了瀏覽器和萬維網(WWW = World Wide Web)服務器之間互相通訊的規則，經過因特網傳送萬維網文檔的數據傳送協議。

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

在Internet中全部的傳輸都是經過TCP/IP進行的。HTTP協議做爲TCP/IP模型中應用層的協議也不例外。HTTP協議一般承載於TCP協議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了咱們常說的HTTPS。

HTTP默認的端口號爲80，HTTPS的端口號爲443。

URL

URL(Uniform Resource Locator) 地址用於描述一個網絡上的資源, 基本格式以下：

schema://host[:port#]/path/.../[?query-string][#anchor]
複製代碼

scheme 指定低層使用的協議(例如：http, https, ftp)

host HTTP服務器的IP地址或者域名

port# HTTP服務器的默認端口是80，這種狀況下端口號能夠省略。若是使用了別的端口，必須指明，例如 http://www.hao2you.com:8080/

path 訪問資源的路徑

query-string 發送給http服務器的數據

anchor- 錨

打開一個網頁須要瀏覽器發送不少次Request:

1. 當你在瀏覽器輸入URL http://www.baidu.com 的時候，瀏覽器發送一個Request去獲取 http://www.baidu.com 的html. 服務器把Response發送回給瀏覽器.
2. 瀏覽器分析Response中的 HTML，發現其中引用了不少其餘文件，好比圖片，CSS文件，JS文件。
3. 瀏覽器會自動再次發送Request去獲取圖片，CSS文件，或者JS文件.
4. 等全部的文件都下載成功後。 網頁就被顯示出來了。

HTTP消息結構

HTTP消息分爲請求和響應消息。

HTTP請求消息

在請求消息的結構中，包括三部分：請求行、請求頭、請求體。

請求行的格式爲： METHOD /path HTTP/version-number

• METHOD:表示請求方式，常見的有POST,GET等。
• path : 表示請求的資源
• HTTP/version-number : 表示HTTP協議的版本號

請求頭內包含不少的鍵值對。

請求體就是咱們要往服務器發送的內容。在GET方式下的請求體是空的。

HTTP響應消息

響應消息的結構和請求消息的結構答題相同，一樣也分爲三部分：響應行、響應頭、響應體。

響應行的格式爲：HTTP/version-number status-code message

• status-code 表示狀態碼

GET請求與POST請求的區別

Http協議定義了不少與服務器交互的方法，最基本的有4種，分別是GET,POST,PUT,DELETE. 一個URL地址用於描述一個網絡上的資源，而HTTP中的GET, POST, PUT, DELETE就對應着對這個資源的查，改，增，刪4個操做。 咱們最多見的就是GET和POST了。GET通常用於獲取/查詢資源信息，而POST通常用於更新資源信息。

GET和POST的區別：

1. GET提交的數據會放在URL以後，以?分割URL和傳輸數據，參數之間以&相連，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數據放在HTTP包的Body中.
2. GET提交的數據大小有限制（由於瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制.
3. GET方式須要使用Request.QueryString來取得變量的值，而POST方式經過Request.Form來獲取變量的值。
4. GET方式提交數據，會帶來安全問題，好比一個登陸頁面，經過GET方式提交數據時，用戶名和密碼將出如今URL上，若是頁面能夠被緩存或者其餘人能夠訪問這臺機器，就能夠從歷史記錄得到該用戶的帳號和密碼.

狀態碼

Response 消息中的第一行叫作狀態行，由HTTP協議版本號、狀態碼、狀態消息 ，三部分組成。狀態碼用來告訴HTTP客戶端,HTTP服務器是否產生了預期的Response.

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

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

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

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

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

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

下面是一些常見的狀態碼：

• 200 OK 代表該請求被成功地完成，所請求的資源發送回客戶端
• 302 Found 重定向，新的URL會在response 中的Location中返回，瀏覽器將會自動使用新的URL發出新的Request
• 304 Not Modified 表明上次的文檔已經被緩存了， 還能夠繼續使用
• 400 Bad Request 客戶端請求與語法錯誤，不能被服務器所理解
• 403 Forbidden 服務器收到請求，可是拒絕提供服務
• 404 Not Found 請求資源不存在（輸錯了URL）
• 500 Internal Server Error 服務器發生了不可預期的錯誤
• 503 Server Unavailable 服務器當前不能處理客戶端的請求，一段時間後可能恢復正常

請求頭

request header 中的內容大體如圖：

catch頭域

catch中包含的內容不只僅是上圖中顯示的內容，可能還有其它類型的內容。如下是常見的catch中的內容：

If-Modified-Since ： 把瀏覽器端緩存頁面的最後修改時間發送到服務器去，服務器會把這個時間與服務器上實際文件的最後修改時間進行對比。若是時間一致，那麼返回304，客戶端就直接使用本地緩存文件。若是時間不一致，就會返回200和新的文件內容。客戶端接到以後，會丟棄舊文件，把新文件緩存起來，並顯示在瀏覽器中.

If-None-Match : If-None-Match和ETag一塊兒工做，工做原理是在HTTP Response中添加ETag信息。 當用戶再次請求該資源時，將在HTTP Request 中加入If-None-Match信息(ETag的值)。若是服務器驗證資源的ETag沒有改變（該資源沒有更新），將返回一個304狀態告訴客戶端使用本地緩存文件。不然將返回200狀態和新的資源和Etag. 使用這樣的機制將提升網站的性能

Pragma : 防止頁面被緩存， 在HTTP/1.1版本中，它和Cache-Control:no-cache做用如出一轍,Pargma只有一個用法， 例如： Pragma: no-cache

注意: 在HTTP/1.0版本中，只實現了Pragema:no-cache, 沒有實現Cache-Control
複製代碼

Cache-Control:這個是很是重要的規則。 這個用來指定Response-Request遵循的緩存機制。各個指令含義以下:

• Cache-Control:Public 能夠被任何緩存所緩存（）
• Cache-Control:Private 內容只緩存到私有緩存中
• Cache-Control:no-cache 全部內容都不會被緩存

Client頭域

Accept : 瀏覽器端能夠接受的媒體類型。

例如： Accept: text/html 表明瀏覽器能夠接受服務器回發的類型爲 text/html 也就是咱們常說的html文檔,

若是服務器沒法返回text/html類型的數據,服務器應該返回一個406錯誤(non acceptable)

通配符 * 表明任意類型

例如 Accept: */* 表明瀏覽器能夠處理全部類型,(通常瀏覽器發給服務器都是發這個)

Accept-Encoding: 瀏覽器申明本身接收的編碼方法，一般指定壓縮方法，是否支持壓縮，支持什麼壓縮方法（gzip，deflate），（注意：這不是指字符編碼）;

例如： Accept-Encoding: gzip, deflate

Accept-Language : 瀏覽器申明本身接收的語言。

語言跟字符集的區別：中文是語言，中文有多種字符集，好比big5，gb2312，gbk等等；

例如： Accept-Language: en-us

User-Agent : 告訴HTTP服務器， 客戶端使用的操做系統和瀏覽器的名稱和版本.

咱們上網登錄論壇的時候，每每會看到一些歡迎信息，其中列出了你的操做系統的名稱和版本，你所使用的瀏覽器的名稱和版本，這每每讓不少人感到很神奇，實際上，服務器應用程序就是從User-Agent這個請求報頭域中獲取到這些信息User-Agent請求報頭域容許客戶端將它的操做系統、瀏覽器和其它屬性告訴服務器。

例如： User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; CIBA; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; InfoPath.2; .NET4.0E)

Accept-Charset : 瀏覽器申明本身接收的字符集，這就是本文前面介紹的各類字符集和字符編碼，如gb2312，utf-8（一般咱們說Charset包括了相應的字符編碼方案）；

Cookies/Login頭域

Cookie : 最重要的header, 將cookie的值發送給HTTP 服務器

Miscellaneous頭域

Referer: 提供了Request的上下文信息的服務器，告訴服務器我是從哪一個連接過來的，好比從我主頁上連接到一個朋友那裏，他的服務器就可以從HTTP Referer中統計出天天有多少用戶點擊我主頁上的連接訪問他的網站。

例如: Referer:http://translate.google.cn/?hl=zh-cn&tab=wT

Transport頭域

Connection ： Connection: keep-alive 當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接不會關閉，若是客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經創建的鏈接； Connection: close 表明一個Request完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接會關閉， 當客戶端再次發送Request，須要從新創建TCP鏈接。

Host : （發送請求時，該報頭域是必需的）,請求報頭域主要用於指定被請求資源的Internet主機和端口號，它一般從HTTP URL中提取出來的。

例如: 咱們在瀏覽器中輸入：http://www.guet.edu.cn/index.html

瀏覽器發送的請求消息中，就會包含Host請求報頭域，以下：

Host：http://www.guet.edu.cn

此處使用缺省端口號80，若指定了端口號，則變成：Host：指定端口號 。

響應頭

response header 中的內容大體如圖：

Catch頭域

Date : 生成消息的具體時間和日期。

Expires : 瀏覽器會在指定過時時間內使用本地緩存。

例如: Expires: Tue, 08 Feb 2022 11:35:14 GMT

Vary :

例如: Vary: Accept-Encoding

Cookies/Login頭域

P3P : 用於跨域設置Cookie, 這樣能夠解決iframe跨域訪問cookie的問題

例如: P3P: CP=CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR

Set-Cookie : 很是重要的header, 用於把cookie 發送到客戶端瀏覽器， 每個寫入cookie都會生成一個Set-Cookie.

例如: Set-Cookie: sc=4c31523a; path=/; domain=.acookie.taobao.com

Entity頭域

ETag : 和If-None-Match 配合使用。實例請看上節中If-None-Match的實例）

Last-Modified : 用於指示資源的最後修改日期和時間。（實例請看上節的If-Modified-Since的實例）

Content-Type : WEB服務器告訴瀏覽器本身響應的對象的類型和字符集。 例如：

Content-Type: text/html; charset=utf-8
Content-Type:text/html;charset=GB2312
Content-Type: image/jpeg
複製代碼

Content-Length : 指明實體正文的長度，以字節方式存儲的十進制數字來表示。在數據下行的過程當中，Content-Length的方式要預先在服務器中緩存全部數據，而後全部數據再一古腦兒地發給客戶端。

Content-Encoding : WEB服務器代表本身使用了什麼壓縮方法（gzip，deflate）壓縮響應中的對象。

Content-Language : WEB服務器告訴瀏覽器本身響應的對象的語言者

Miscellaneous頭域

Server : 指明HTTP服務器的軟件信息

X-AspNet-Version: 若是網站是用ASP.NET開發的，這個header用來表示ASP.NET的版本

X-Powered-By:表示網站是用什麼技術開發的

Transport頭域

Connection : Connection: keep-alive 當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接不會關閉，若是客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經創建的鏈接;Connection: close 表明一個Request完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接會關閉， 當客戶端再次發送Request，須要從新創建TCP鏈接。

Location頭域

Location : 用於重定向一個新的位置, 包含新的URL地址

HTTP協議是無狀態的和Connection: keep-alive的區別

無狀態是指協議對於事務處理沒有記憶能力，服務器不知道客戶端是什麼狀態。從另外一方面講，打開一個服務器上的網頁和你以前打開這個服務器上的網頁之間沒有任何聯繫

HTTP是一個無狀態的面向鏈接的協議，無狀態不表明HTTP不能保持TCP鏈接，更不能表明HTTP使用的是UDP協議（無鏈接）

從HTTP/1.1起，默認都開啓了Keep-Alive，保持鏈接特性，簡單地說，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接不會關閉，若是客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經創建的鏈接

Keep-Alive不會永久保持鏈接，它有一個保持時間，能夠在不一樣的服務器軟件（如Apache）中設定這個時間。

TCP協議

WireShark抓包

方法

手機鏈接上電腦，而後在命令行中輸入如下命令來建立一個網絡監聽接口：

rvictl -s uuid
複製代碼

• uuid是設備的惟一識別號。

eg: 建立一個rvi0監聽手機的網絡活動

qis-Mac-mini:Desktop qi$ rvictl -s 6f2eb102cd69721a1456d0bca56ad0d0a23b6e89

Starting device 6f2eb102cd69721a1456d0bca56ad0d0a23b6e89 [SUCCEEDED] with interface rvi0
複製代碼

抓取HTTP包

抓取post請求方式的包：

抓取get請求方式的包:

HTTPS

概念

HTTPS(全稱：Hypertext Transfer Protocol over Secure Socket Layer)安全套接字層超文本傳輸協議HTTPS,爲了數據傳輸的安全，HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠證書來驗證服務器的身份，併爲瀏覽器和服務器之間的通訊加密。HTTPS所用的端口號是443 。

爲了能更好的理解HTTPS，首先須要瞭解一些概念。

對稱加密

加密和解密使用的祕鑰是相同的祕鑰。所以對稱加密要保證安全性的話，祕鑰要作好保密，只能讓使用的人知道，不能夠公開。

非對稱加密(RSA)

RSA是一種公鑰密碼體制，如今使用的很普遍。公鑰公開，私鑰保密，他的加密解密算法是公開的。由公鑰加密的內容能夠而且只能有私鑰解密，而且由私鑰加密的內容能夠而且只能由公鑰解密。也就是說，RSA的這一對公鑰、私鑰均可以用來加密和解密，而且一方加密的內容能夠由而且只能由對方進行解密。可用於驗證HTTPS各類祕鑰的加密。

簽名(數字簽名)

簽名就是在信息的後面再加上一段內容，能夠證實信息沒有被修改過，怎麼樣能夠達到這個效果呢？通常是對信息作一個hash計算獲得一個hash值，注意，這個過程是不可逆的，也就是說沒法經過hash值得出原來的信息內容。在把信息發送出去時，把這個hash值加密後作爲一個簽名和信息一塊兒發出去。 接收方在收到信息後，會從新計算信息的hash值，並和信息所附帶的hash值(解密後)進行對比，若是一致，就說明信息的內容沒有被修改過，由於這裏hash計算能夠保證不一樣的內容必定會獲得不一樣的hash值，因此只要內容一被修改，根據信息內容計算的hash值就會變化。固然，不懷好意的人也能夠修改信息內容的同時也修改hash值，從而讓它們能夠相匹配，爲了防止這種狀況，hash值通常都會加密後(也就是簽名)再和信息一塊兒發送，以保證這個hash值不被修改。可是客戶端如何解密呢？這就涉及到數字證書了。

證書

證書中包含我的基本信息，以及最重要的公鑰。

數字證書CA

若是證書在傳輸的過程當中被篡改了呢？因此後來又出現了數字簽名。

CA就是用它的私鑰對消息摘要加密，造成簽名，並把原始信息和數據簽名進行合併，即所謂的數字證書。這樣，當別人把他的證書發過來的時候，我再用一樣的Hash算法，再次生成消息摘要。而後用CA的公鑰對數字簽名解密，獲得CA建立的消息摘要，二者一比較，就知道中間有沒有被人篡改了。

HTTPS通訊過程

下圖是HTTPS的通訊過程：

[圖片上傳失敗...(image-a96c81-1551686316747)]

1. 客戶端向服務器發送https請求
2. 服務器端返回數字證書(CA)
3. 客戶端利用本身的CA[主流的CA機構證書通常都內置在各個主流瀏覽器中]公鑰去解密證書,若是證書有問題會提示風險
4. 若是證書沒問題客戶端會生成一個對稱加密的隨機祕鑰而後再和剛剛解密的服務器端的公鑰對數據進行加密，而後發送給服務器端。
5. 服務器收到之後會用本身的私鑰對客戶端發來的對稱密鑰進行解密
6. 以後雙方就拿這個對稱加密祕鑰來進行正常通訊。

參考

• HTTP協議
• iOS中的Socket編程
• 深刻理解 https 通訊加密過程