上面是Wireshark用戶手冊的鏈接毕荐，整體情況請點擊。
一艳馒，準備工作
Wireshark提供Mac版本憎亚，可以從官網(wǎng)下載安裝，到這篇博客為止最新版本應該是2.2.1弄慰。安裝好之后打開的第一個界面如下：
Wireshark在第一個界面就把當前系統(tǒng)所包含的網(wǎng)卡列出來了第美，直接點擊任何一項就可以開始監(jiān)聽通過該網(wǎng)卡的所有網(wǎng)絡流量。
當我們把iPhone通過usb連接macbook時陆爽，Wireshark并不能直接監(jiān)聽通過iPhone的網(wǎng)絡流量什往，需要通過一個系統(tǒng)程序在我們的Mac系統(tǒng)上，建立一個映射到iPhone的虛擬網(wǎng)卡慌闭，在terminal中輸入如下命令即可：格式為：rvictl -s [UUID]
然后選擇下圖中藍色的網(wǎng)卡别威，既可抓當前的iPhone包；
Wireshare即進入如下界面開始監(jiān)聽iPhone設備上的所有流量驴剔。
此時省古，啟動iPhone上的任意App，只要有網(wǎng)絡流量產(chǎn)生丧失，對應的網(wǎng)絡包都會在Wireshark上述的列表中展示出來豺妓。
Wireshark的流量監(jiān)控界面主要分為四塊，由上至下布讹；
第一部分（標號為1）是工具欄琳拭，通過工具欄我們可以控制監(jiān)控的行為，比如開始抓包描验，停止抓包白嘁，重新開始抓包，以及在包之間跳轉等等挠乳。工具欄的底部有個輸入框权薯，可以讓我們手動輸入包的過濾條件，這部分對于熟練使用Wireshark抓包非常重要睡扬，后面會詳細的講解盟蚣。
第二部分（標號為2）是歷史流量包列表展示界面，這里展示的是從抓包開始卖怜，所有通過我們iPhone設備的流量屎开。列表界面不同的包有不同的顏色，Wireshark通過顏色來區(qū)分包的類型马靠，對于特定場景快速識別目標流量非常有用奄抽，后面也會專門講解蔼两。
第三部分（標號為3）是單個包的詳細信息展示面板，我們在第二部分選中的網(wǎng)絡包在這一部分會將其結構以可閱讀的文本形式展示出來逞度，要正確閱讀這一部分的信息需要對tcp/ip協(xié)議有一定的掌握额划。
第四部分（標號為4）是單個包的二進制流信息展示面板，這一部分展示的信息是包的原始數(shù)據(jù)档泽，也是一個網(wǎng)絡包所包含內容的真實展現(xiàn)俊戳，我們在第三部分多選中的協(xié)議頭，都會在這一部分以同步高亮的形式標記出來馆匿。這一部分的展示是為了讓我們對包的真實內容做直觀的判斷抑胎，能具體到單個byte。
二渐北，簡單的Filter過濾包
使用Wireshark和使用Charles最大的區(qū)別在于阿逃，Charles只捕獲HTTP流量，而Wireshark捕捉的是經(jīng)過目標網(wǎng)卡所有的流量赃蛛，流量包可以在幾秒內膨脹到難以閱讀的數(shù)量恃锉，所以此時我們需要使用Filter來做包的過濾，F(xiàn)ilter規(guī)則定的越細焊虏，剔除掉的干擾信息就越多淡喜，分析起來就越快。
Wireshark的Filter分為兩種诵闭，一種為Capture Filter炼团，另一種是Display Filter。
Capture Filter出現(xiàn)在初始界面疏尿，在網(wǎng)卡列表的上方有個輸入框瘟芝，允許我們輸入capture filter，一旦輸入了特定的capture規(guī)則褥琐，Wireshark就只捕獲符合該規(guī)則的流量包了锌俱。
Display Filter出現(xiàn)在流量監(jiān)控界面，在工具欄的下方有個輸入框敌呈，允許我們輸入display filter贸宏，display filter只是從界面上過濾掉不符合規(guī)則的包，Wireshark實際上還是監(jiān)聽了這些包磕洪，一旦去掉display filter吭练，所有的包又會出現(xiàn)在同一界面。
Capture Filter的規(guī)則和我們平常使用tcpdump的filter語法是一致的析显，比如為了只監(jiān)控http的流量鲫咽，我們可以先在初始化界面選中rvi0網(wǎng)卡，再在capture filter輸入框里輸入：
//只捕獲HTTP流量
port 80 or port 443
回車之后Wireshark就開始監(jiān)控我們iPhone上所有的http和https流量了 ，非常簡單分尸，我們還可以使用其他的capture filter來捕獲特定的流量锦聊，比如想分析DNS解析過程，可以使用：
//只捕獲DNS流量
port 53
比如只想捕獲和特定服務器相關的流量:
//只捕獲和特定主機的流量
host 171.10.191.10
Display Filter的語法是由Wireshark自定義的箩绍，和Capture filter的語法不能混用孔庭。比如我們只想看某個主機的流量，可以使用如下Display Filter：
ip.addr==171.10.191.10
如果只看http或者https的流量伶选，可以用：
tcp.port == 80 || tcp.port == 443
Wireshark實際上提供了便捷的UI操作幫助我們來書寫Display Filter史飞，在Display Filter輸入框的最右邊有個Expression按鈕尖昏，點擊之后可以彈出如下界面：
Display Filter的語法本質上是個等是關系描述仰税，我們可以在search當中輸入我們感興趣的協(xié)議比如http，再在展開的協(xié)議頭里選擇我們的條件比如http.host抽诉，最后設置Relation和Value就可以生成一個Display Filter條件了陨簇。
2.1 包顏色規(guī)則
Wireshark在大多數(shù)時候捕獲的包數(shù)量都遠超我們感興趣的數(shù)量，而且各個連接的包都混雜在一起迹淌，為了方便我們識別不同的連接會話河绽，Wireshark默認使用一種著色規(guī)則幫助我們來進行包類型區(qū)分。
具體的規(guī)則可以通過菜單View->Coloring Rules...查看唉窃，默認規(guī)則如下：
這里有個小技巧耙饰，如上圖所示，我只將我感興趣的協(xié)議包上了色纹份，集中在http苟跪，tcp，udp包蔓涧，這樣分析起來更加直觀件已。比如根據(jù)上圖的規(guī)則，tcp三次握手中的Sync包是使用灰色標記的元暴，這樣我就可以在下圖的包中迅速定位一次tcp連接的開始包位置：
當然篷扩，包的顏色也可以按照自己的視覺習慣進行定制，我個人習慣把Sync包和FIN包設置一個高亮的顏色茉盏，方便判斷一次HTTP會話的起始和結束鉴未。
2.2 流量跟蹤
Wireshark默認情況下將不同網(wǎng)絡連接的流量都混在一起展示，即使給不同協(xié)議的包上色之后鸠姨，要單獨查看某個特定連接的流量依然不怎么方便铜秆，我們可以通過Wireshark提供的兩種方式來實現(xiàn)這個目標。
方式一：Follow Stream
當我們選中某個包之后享怀，右鍵彈出的菜單里羽峰，有個選項允許我們將當前包所屬于的完整流量單獨列出來，如下圖：
Wireshark支持我們常見的四種Stream，TCP梅屉，UDP值纱，HTTP，SSL坯汤。比如我們選中Follow TCP Stream之后可以得到如下的詳細分析輸出（樣本為監(jiān)控iPhone手機的流量）：
上圖中將iPhone和Server之間某次的連接流量完整的呈現(xiàn)出來虐唠，包括iPhone發(fā)送了多少個包，Server回了多少個包惰聂，以及iPhone上行和下行的流量疆偿，還提供流量編解碼選擇，文本搜索功能等搓幌。
三杆故，Wireshark與http&https
HTTP的工作方式并不復雜，先由客戶端向服務端發(fā)起一個請求溉愁，再由服務器回復一個請求处铛。但是因為服務器與客戶端并不是物理上直接相連，而是通過DNS拐揭，NAT等等一系列網(wǎng)絡設備進行計算撤蟆，不可避免的需要先確定對方的存在與否。這個確定過程就是HTTP的三次握手堂污；
我再APP中使用WKWebView加載http://www.rfc-editor.org/info/rfc2616時候抓包如下家肯，探討HTTP的工作原理
3.1 三次握手
3.1.1，第一條protocol為DNS而且只有一個包盟猖，這是因為我的demo多次運行讨衣，DNS已經(jīng)4.31.198.49與http://www.rfc-editor.org/info/rfc2616的映射，所以客戶端下一步可以與4.31.198.49進行通訊扒披。
3.1.2值依，圖中第二條數(shù)據(jù)的protocol為TCP，由于HTTP協(xié)議基于TCP碟案，所以開始三次握手愿险，從上圖可以看出Src Port（客戶端）:55906，Dst Port（服務器）:8价说。TCP數(shù)據(jù)包中辆亏，seq表示這個包的序號，注意鳖目，這個序號不是按1遞增的扮叨，而是按tcp包內數(shù)據(jù)字節(jié)長度加上，如包內數(shù)據(jù)是21字節(jié)领迈，而當前IP1發(fā)到IP2的包的seq是10的話彻磁，那下個IP1發(fā)到IP2的包的seq就是10+21=31碍沐。
3.1.3,每個tcp包都帶有win、ack衷蜓，這些是告訴對方累提，我還可以接收數(shù)據(jù)的滑動窗口是多少，如果A發(fā)到B的包的win為0磁浇，就是A告訴B說我現(xiàn)在滑動窗口為0了斋陪，飽了，你不要再發(fā)給我了置吓，就說明A端環(huán)境有壓力（如帶寬滿了等）
3.1.4无虚，ack可以理解為應答。A發(fā)給B的ack是告訴B衍锚，我已收到你發(fā)的數(shù)據(jù)包友题，收到ack號這里了，你下次要發(fā)seq為ack號的給我
3.1.5构拳，在網(wǎng)絡不堵即滑動窗口一點都不堵的情況下咆爽，第一個包的ack號就是第二個包的seq號，如果堵了置森，由于是滑動窗口緩存處理隊列，所以這個值會錯開 （即擁塞避免符糊，快重傳凫海，慢啟動等一系列避免網(wǎng)絡擁塞的策略）
3.1.6，注意我們分析tcp包時男娄，要以一個會話做為一個完整對象行贪，即通訊只發(fā)生在兩個IP之間，兩個固定的端口之間模闲，如果端口變化了建瘫，那鏈接就不是同一條了，不同的鏈接之間的seq是沒有關聯(lián)的尸折。因為我之前已經(jīng)設置了Capture Filter為host 10.0.78.73(本機iPhone的ip)啰脚，所以在這里可以設置display filter的規(guī)則為ip.dst == 4.31.198.49 || ip.dst == 10.0.78.73，即我只顯示ip為4.31.198.49與10.0.78.73的數(shù)據(jù)包实夹。
3.2 HTTP包
3.2.1橄浓，上圖中灰色的數(shù)據(jù)包是客戶端向服務端發(fā)送的“GET /info/rfc2616 HTTP/1.1”請求，即通過1.1版的HTTP協(xié)議亮航，獲取/info目錄里的rfc2616文件荸实。說白了就是想下載頁面的內容。
3.2.2缴淋，圖中藍色行及其下方為一個HTTP請求的完整請求內容准给，即：請求行泄朴、請求頭(headerField)、請求體(body)露氮；同理叼旋，響應也有狀態(tài)行、響應頭沦辙、實體內容夫植。接下來我們逐個展開。
1油讯，請求行
包含請求方法(Method)详民、請求統(tǒng)一資源標識符(URI)、HTTP版本號陌兑，如圖：
請求方法就是我們所熟悉的POST沈跨、GET、HEAD兔综、PUT等
URI就是URL中排除掉Host剩下的部分饿凛，也就是資源在服務器本地上的路徑
HTTP版本號，目前主流的版本是1.1(1999年開始采用)软驰，最新的版本是2.0(2015年5月發(fā)布)涧窒。不同版本之間差異下面會再展開
2、請求頭
請求頭主要存放對客戶端想給服務端的附加信息锭亏，下圖框框的部分就是請求頭（上方圖的部分）：
HTTP請求在iOS中用NSURLRequest與NSMutableRequest表示纠吴；HTTP響應用NSHTTPURLResponse表示。
Host: 目標服務器的網(wǎng)絡地址
Accept: 讓服務端知道客戶端所能接收的數(shù)據(jù)類型慧瘤，如text/html */*
Content-Type: body中的數(shù)據(jù)類型戴已，如application/json; charset=UTF-8
Accept-Language: 客戶端的語言環(huán)境，如zh-cn
Accept-Encoding: 客戶端支持的數(shù)據(jù)壓縮格式锅减，如gzip
User-Agent:
客戶端的軟件環(huán)境糖儡，我們可以更改該字段為自己客戶端的名字，比如QQ music v1.11怔匣，比如瀏覽器Mozilla/5.0
(Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/600.8.9 (KHTML, like Gecko) Maxthon/4.5.2
Connection: keep-alive握联，該字段是從HTTP 1.1才開始有的，用來告訴服務端這是一個持久連接劫狠，“請服務端不要在發(fā)出響應后立即斷開TCP連接”拴疤。關于該字段的更多解釋將在后面的HTTP版本簡介中展開。
Content-Length: body的長度独泞，如果body為空則該字段值為0呐矾。該字段一般在POST請求中才會有。POST請求的body請求體也有可能是空的懦砂，因此POST中Content-Length也有可能為0
Cookie: 記錄者用戶信息的保存在本地的用戶數(shù)據(jù)蜒犯，如果有會被自動附上
值得一提的是组橄，在iOS中當你發(fā)送一個任意請求時，不管你愿不愿意罚随，NSURLRequest都會自動幫你記錄你所訪問的URL上設置的cookie玉工。在iOS中用NSHTTPCookieStorage表示，是一個單例淘菩。通過
NSHTTPCookieStorage?*cookieJar?=?[NSHTTPCookieStorage?sharedHTTPCookieStorage];
for(NSHTTPCookie?*cookiein[cookieJar?cookies])?{
NSLog(@"%@",?cookie);
}
可以獲取目前被自動保存的所有cookie遵班。
3、請求體
真正需要發(fā)給服務端的數(shù)據(jù)潮改，在使用POST-multipart上傳請求中請求體就是上傳文件的二進制NSData類型數(shù)據(jù)狭郑；在GET請求中請求體為空；在普通的POST請求中請求體就是一些表單數(shù)據(jù)汇在。在iOS中一般用NSURLRequest與NSMutableURLRequest的HTTPBody屬性表示翰萨，添加body用-[NSMutableURLRequest setHTTPBody:]。
4糕殉、響應狀態(tài)行
上圖是是服務端返回給客戶端的響應狀態(tài)行亩鬼，包含HTTP版本號、狀態(tài)碼阿蝶、狀態(tài)碼對應的英文名稱雳锋。
以下就是典型的正確狀態(tài)行：
HTTP/1.1 200 OK\r\n
這個部分需要講的是錯誤碼。事實上HTTP請求錯誤碼可以根據(jù)錯誤碼從左往右第一個數(shù)字大致分為以下幾類：
1XX：信息提示赡磅。不代表成功或者失敗魄缚，表示臨時響應，比如100表示繼續(xù)焚廊，101表示切換協(xié)議
2XX: 成功
3XX: 重定向
4XX:客戶端錯誤，很有可能是客戶端發(fā)生問題习劫，如親切可愛的404表示未找到文件咆瘟，說明你的URI是有問題的，服務器機子上該目錄是沒有該文件的诽里；414URI太長
5XX: 服務器錯誤袒餐，比如504網(wǎng)關超時
錯誤碼是不用去記的，出錯了再查對應的錯誤碼含義就行谤狡。但是知道上面的分類有助于第一時間做出大體的判斷灸眼，起碼你能清楚是服務端還是客戶端的原因。
5墓懂、響應頭與響應實體
這部分與請求部分差異不大焰宣，響應頭的字field會有稍許不同。
3.3 超時重傳
這是我再抓包過程中發(fā)現(xiàn)的丟包現(xiàn)象捕仔，如上面所說4.31.198.49為服務器的ip匕积，在上圖中服務器發(fā)送給客戶端的包丟了盈罐，丟了？闪唆？盅粪？服務器響應體丟了怎么辦呢？是否會開始下一輪的三次握手呢悄蕾？
1票顾，HTTP丟包后，客戶端會告訴服務器丟包了,當前Seq = 363帆调，下次請發(fā)送Ack = 1的序號包奠骄；服務器收到請求后，忽略之前的seq = 363的包贷帮，重新發(fā)送seq = 1的包戚揭。
2，服務器確定后說撵枢，“好的民晒，親〕荩”序號包為Seq = 1的包確定潜必，下次請請求Ack為363的包，我當前的窗口為（win = 131744），空閑的很，大膽請求吧皮卡丘祖秒；
上圖為客戶端確定收到的Seq = 363的包孟岛，目前可以確定收到Seq = 1449 的包，所以客戶端重新請求Ack = 1449的包揭保。
3.4 HTTPS怎么辦？？晒他？
HTTPS是個研究好幾天后，我還是確定沒有服務器的同學配合逸贾，客戶端用Wireshark無法抓到實際意義的包陨仅。
上圖是HTTPS的響應包，下方是抓包后顯示的數(shù)據(jù)铝侵，很明顯除了這條可以知道是HTTP數(shù)據(jù)外
灼伤，其他的完全看不懂，因為所有信息都被加密了咪鲜，這也反映蘋果規(guī)定所有請求必須是https請求的明智狐赡。
3.4 HTTPS解密
1，找服務器的基友表達善意嗜诀，將服務器的秘鑰導出猾警，例如key01.key文件
2孔祸，單擊Wireshark的Preferences(Mac版本為例)，
在彈出的Wireshark首選項設置中選擇Protocol的SSL（加密套接字協(xié)議）发皿，選擇RSA keys list的Edit按鈕崔慧，如下格式填好，單擊OK穴墅。接下來就可以見證奇跡的時刻惶室。
四，TCP玄货，HTTP皇钞，Socket
這三個概念經(jīng)常被談到，也是比較容易被混掉的概念松捉。在回顧之前我們先看一下這三者在TCP/IP協(xié)議族中的位置關系：
HTTP是應用層的協(xié)議夹界，更靠近用戶端；TCP是傳輸層的協(xié)議隘世；而socket是從傳輸層上抽象出來的一個抽象層可柿，本質是接口。所以本質上三種還是很好區(qū)分的丙者。盡管如此复斥，有時候你可能會懵逼，HTTP連接械媒、TCP連接目锭、socket連接有什么區(qū)別？好吧纷捞，如果上面的圖解釋的還是不夠清楚的話痢虹，我們繼續(xù)往下看。
4.1主儡，TCP連接與HTTP連接的區(qū)別
上文提過世分，HTTP是基于TCP的，客戶端往服務端發(fā)送一個HTTP請求時第一步就是要建立與服務端的TCP連接缀辩，也就是先三次握手，“你好踪央，你好臀玄，你好”。從HTTP 1.1開始支持持久連接畅蹂，也就是一次TCP連接可以發(fā)送多次的HTTP請求健无。
小總結：HTTP基于TCP
4.2，TCP連接與Socket連接的區(qū)別
在圖4.1中我們提到液斜，socket層只是在TCP/UDP傳輸層上做的一個抽象接口層累贤，因此一個socket連接可以基于連接叠穆，也有可能基于UDP【矢啵基于TCP協(xié)議的socket連接同樣需要通過三次握手建立連接硼被，是可靠的；基于UDP協(xié)議的socket連接不需要建立連接的過程渗磅，不過對方能不能收到都會發(fā)送過去嚷硫，是不可靠的，大多數(shù)的即時通訊IM都是后者始鱼。
小總結：Socket也基于TCP
4.3仔掸，HTTP連接與Socket連接的區(qū)別
區(qū)分這兩個概念是比較有意義的，畢竟TCP看不見摸不著医清，HTTP與Socket是實實在在能用到的起暮。
HTTP是短連接，Socket(基于TCP協(xié)議的)是長連接会烙。盡管HTTP1.1開始支持持久連接负懦，但仍無法保證始終連接。而Socket連接一旦建立TCP三次握手持搜，除非一方主動斷開密似，否則連接狀態(tài)一直保持。
HTTP連接服務端無法主動發(fā)消息葫盼，Socket連接雙方請求的發(fā)送先后限制残腌。這點就比較重要了，因為它將決定二者分別適合應用在什么場景下贫导。HTTP采用“請求-響應”機制抛猫，在客戶端還沒發(fā)送消息給服務端前，服務端無法推送消息給客戶端孩灯。必須滿足客戶端發(fā)送消息在前闺金，服務端回復在后。Socket連接雙方類似peer2peer的關系峰档，一方隨時可以向另一方喊話败匹。
4.4，問題來了：什么時候該用HTTP讥巡，什么時候該用socket
這個問題的提出是很自然而然的掀亩。當你接到一個與另一方的網(wǎng)絡通訊需求，自然會考慮用HTTP還是用Socket欢顷。
用HTTP的情況：雙方不需要時刻保持連接在線槽棍，比如客戶端資源的獲取、文件上傳等。
用Socket的情況：大部分即時通訊應用(QQ炼七、微信)缆巧、聊天室、蘋果APNs等
