1 起因

前段時間，一直在調線上的一個問題：線上應用接受POST請求，請求body中的引數獲取不全，存在丟失的狀況。這個問題是偶發性的，大概發生的機率為5%-10%左右，這個概率已經相當高了。在排查問題的過程中使用到了tcpdump和Wireshark進行抓包分析。感覺這兩個工具搭配起來幹活，非常完美。所有的網路傳輸在這兩個工具搭配下，都無處遁形。

為了更好、更順手地能夠用好這兩個工具，特整理本篇文章，希望也能給大家帶來收穫。為大家之後排查問題，添一利器。

2 tcpdump與Wireshark介紹

在網路問題的除錯中，tcpdump應該說是一個必不可少的工具，和大部分linux下優秀工具一樣，它的特點就是簡單而強大。它是基於Unix系統的命令列式的資料包嗅探工具，可以抓取流動在網絡卡上的資料包。

預設情況下，tcpdump不會抓取本機內部通訊的報文。根據網路協議棧的規定，對於報文，即使是目的地是本機，也需要經過本機的網路協議層，所以本機通訊肯定是通過API進入了核心，並且完成了路由選擇。【比如本機的TCP通訊，也必須要socket通訊的基本要素：src ip port dst ip port】

如果要使用tcpdump抓取其他主機MAC地址的資料包，必須開啟網絡卡混雜模式，所謂混雜模式，用最簡單的語言就是讓網絡卡抓取任何經過它的資料包，不管這個資料包是不是發給它或者是它發出的。一般而言，Unix不會讓普通使用者設定混雜模式，因為這樣可以看到別人的資訊，比如telnet的使用者名稱和密碼，這樣會引起一些安全上的問題，所以只有root使用者可以開啟混雜模式，開啟混雜模式的命令是：ifconfig en0 promisc, en0是你要開啟混雜模式的網絡卡。

Linux抓包原理：

Linux抓包是通過註冊一種虛擬的底層網路協議來完成對網路報文(準確的說是網路裝置)訊息的處理權。當網絡卡接收到一個網路報文之後，它會遍歷系統中所有已經註冊的網路協議，例如乙太網協議、x25協議處理模組來嘗試進行報文的解析處理，這一點和一些檔案系統的掛載相似，就是讓系統中所有的已經註冊的檔案系統來進行嘗試掛載，如果哪一個認為自己可以處理，那麼就完成掛載。

當抓包模組把自己偽裝成一個網路協議的時候，系統在收到報文的時候就會給這個偽協議一次機會，讓它來對網絡卡收到的報文進行一次處理，此時該模組就會趁機對報文進行窺探，也就是把這個報文完完整整的複製一份，假裝是自己接收到的報文，彙報給抓包模組。

Wireshark是一個網路協議檢測工具，支援Windows平臺、Unix平臺、Mac平臺，一般只在圖形介面平臺下使用Wireshark，如果是Linux的話，直接使用tcpdump了，因為一般而言Linux都自帶的tcpdump，或者用tcpdump抓包以後用Wireshark開啟分析。

在Mac平臺下，Wireshark通過WinPcap進行抓包，封裝的很好，使用起來很方便，可以很容易的制定抓包過濾器或者顯示過濾器，具體簡單使用下面會介紹。Wireshark是一個免費的工具，只要google一下就能很容易找到下載的地方。

所以，tcpdump是用來抓取資料非常方便，Wireshark則是用於分析抓取到的資料比較方便。

3 tcpdump使用

3.1 語法

1. 型別的關鍵字

   host(預設型別): 指明一臺主機，如：host 210.27.48.2

   net: 指明一個網路地址，如：net 202.0.0.0

   port: 指明埠號，如：port 23

2. 確定方向的關鍵字

   src: src 210.27.48.2, IP包源地址是210.27.48.2

   dst: dst net 202.0.0.0, 目標網路地址是202.0.0.0

   dst or src(預設值)

   dst and src

3. 協議的關鍵字：預設值是監聽所有協議的資訊包

   fddi

   ip

   arp

   rarp

   tcp

   udp

4. 其他關鍵字

   gateway

   broadcast

   less

   greater

5. 常用表示式：多條件時可以用括號，但是要用轉義

   非 : ! or “not” (去掉雙引號)

   且 : && or “and”

   或 : || or “or”

3.2 選項

3.3 命令實踐

1、直接啟動tcpdump，將抓取所有經過第一個網路介面上的資料包

2、抓取所有經過指定網路介面上的資料包

3、抓取所有經過 en0，目的或源地址是 10.37.63.255 的網路資料：

4、抓取主機10.37.63.255和主機10.37.63.61或10.37.63.95的通訊：

5、抓取主機192.168.13.210除了和主機10.37.63.61之外所有主機通訊的資料包：

6、抓取主機10.37.63.255除了和主機10.37.63.61之外所有主機通訊的ip包

7、抓取主機10.37.63.3傳送的所有資料：

8、抓取主機10.37.63.3接收的所有資料：

9、抓取主機10.37.63.3所有在TCP 80埠的資料包：

10、抓取HTTP主機10.37.63.3在80埠接收到的資料包：

11、抓取所有經過 en0，目的或源埠是 25 的網路資料

12、抓取所有經過 en0，網路是 192.168上的資料包

13、協議過濾

14、抓取所有經過 en0，目的地址是 192.168.1.254 或 192.168.1.200 埠是 80 的 TCP 資料

15、抓取所有經過 en0，目標 MAC 地址是 00:01:02:03:04:05 的 ICMP 資料

16、抓取所有經過 en0，目的網路是 192.168，但目的主機不是 192.168.1.200 的 TCP 資料

17、只抓 SYN 包

18、抓 SYN, ACK

19、抓 SMTP 資料，抓取資料區開始為”MAIL”的包，”MAIL”的十六進位制為 0x4d41494c

20、抓 HTTP GET 資料，”GET “的十六進位制是 0x47455420

21、抓 SSH 返回，”SSH-“的十六進位制是 0x5353482D

22、高階包頭過濾如前兩個的包頭過濾，首先了解如何從包頭過濾資訊：

23、抓 DNS 請求資料

24、其他-c 引數對於運維人員來說也比較常用，因為流量比較大的伺服器，靠人工 CTRL+C 還是抓的太多，於是可以用-c 引數指定抓多少個包。

3.4 抓個網站練練

想抓取訪問某個網站時的網路資料。比如網站 http://www.baidu.com/ 怎麼做？

1、通過tcpdump截獲主機www.baidu.com傳送與接收所有的資料包

2、訪問這個網站

3、想要看到詳細的http報文。怎麼做？

4、分析抓取到的報文

4 tcpdump抓取TCP包分析

TCP傳輸控制協議是面向連線的可靠的傳輸層協議，在進行資料傳輸之前，需要在傳輸資料的兩端（客戶端和伺服器端）建立一個連線，這個連線由一對插口地址唯一標識，即是在IP報文首部的源IP地址、目的IP地址，以及TCP資料報首部的源埠地址和目的埠地址。TCP首部結構如下：

注意：通常情況下，一個正常的TCP連線，都會有三個階段:1、TCP三次握手;2、資料傳送;3、TCP四次揮手

其中在TCP連線和斷開連線過程中的關鍵部分如下：

1. 源埠號：即傳送方的埠號，在TCP連線過程中，對於客戶端，埠號往往由核心分配，無需程序指定；

2. 目的埠號：即傳送目的的埠號；

3. 序號：即為傳送的資料段首個位元組的序號；

4. 確認序號：在收到對方發來的資料報，傳送確認時期待對方下一次傳送的資料序號；

5. SYN：同步序列編號，Synchronize Sequence Numbers；

6. ACK：確認編號，Acknowledgement Number；

7. FIN：結束標誌，FINish；

4.1 TCP三次握手

三次握手的過程如下：

step1. 由客戶端向伺服器端發起TCP連線請求。Client傳送：同步序列編號SYN置為1，傳送序號Seq為一個隨機數，這裡假設為X，確認序號ACK置為0；

step2. 伺服器端接收到連線請求。Server響應：同步序列編號SYN置為1，並將確認序號ACK置為X+1，然後生成一個隨機數Y作為傳送序號Seq（因為所確認的資料報的確認序號未初始化）；

step3. 客戶端對接收到的確認進行確認。Client傳送：將確認序號ACK置為Y+1，然後將傳送序號Seq置為X+1（即為接收到的資料報的確認序號）；

1. 為什麼是三次握手而不是兩次對於step3的作用，假設一種情況，客戶端A向伺服器B傳送一個連線請求資料報，然後這個資料報在網路中滯留導致其遲到了，雖然遲到了，但是伺服器仍然會接收併發回一個確認資料報。但是A卻因為久久收不到B的確認而將傳送的請求連線置為失效，等到一段時間後，接到B傳送過來的確認，A認為自己現在沒有傳送連線，而B卻一直以為連線成功了，於是一直在等待A的動作，而A將不會有任何的動作了。這會導致伺服器資源白白浪費掉了，因此，兩次握手是不行的，因此需要再加上一次，對B發過來的確認再進行一次確認，即確認這次連線是有效的，從而建立連線。

2. 對於雙方，傳送序號的初始化為何值有的系統中是顯式的初始化序號是0，但是這種已知的初始化值是非常危險的，因為這會使得一些黑客鑽漏洞，傳送一些資料報來破壞連線。因此，初始化序號因為取隨機數會更好一些，並且是越隨機越安全。

tcpdump抓TCP三次握手抓包分析：

sudo tcpdump -n -S -ilo0 host10.37.63.3andtcp port8080

# 接著再執行：

curl http://10.37.63.3:8080/atbg/doc

控制檯輸出：

每一行中間都有這個包所攜帶的標誌：

S=SYN，發起連線標誌。

P=PUSH，傳送資料標誌。

F=FIN，關閉連線標誌。

ack，表示確認包。

RST=RESET，異常關閉連線。

.，表示沒有任何標誌。

第1行：16:00:13.486776，從10.37.63.3（client）的臨時埠61725向10.37.63.3（server）的8080監聽埠發起連線，client初始包序號seq為1944916150，滑動視窗大小為65535位元組（滑動視窗即tcp接收緩衝區的大小，用於tcp擁塞控制），mss大小為16344（即可接收的最大包長度，通常為MTU減40位元組，IP頭和TCP頭各20位元組）。【seq=1944916150，ack=0，syn=1】

第2行：16:00:13.486850，server響應連線，同時帶上第一個包的ack資訊，為client端的初始包序號seq加1，即1944916151，即server端下次等待接受這個包序號的包，用於tcp位元組流的順序控制。Server端的初始包序號seq為1119565918，mss也是16344。【seq=1119565918，ack=1944916151，syn=1】

第3行：15:46:13.084161，client再次傳送確認連線，tcp連線三次握手完成，等待傳輸資料包。【ack=1119565919，seq=1944916151】

4.2 TCP四次揮手

連線雙方在完成資料傳輸之後就需要斷開連線。由於TCP連線是屬於全雙工的，即連線雙方可以在一條TCP連線上互相傳輸資料，因此在斷開時存在一個半關閉狀態，即有有一方失去傳送資料的能力，卻還能接收資料。因此，斷開連線需要分為四次。主要過程如下：

step1. 主機A向主機B發起斷開連線請求，之後主機A進入FIN-WAIT-1狀態；

step2. 主機B收到主機A的請求後，向主機A發回確認，然後進入CLOSE-WAIT狀態；

step3. 主機A收到B的確認之後，進入FIN-WAIT-2狀態，此時便是半關閉狀態，即主機A失去傳送能力，但是主機B卻還能向A傳送資料，並且A可以接收資料。此時主機B佔主導位置了，如果需要繼續關閉則需要主機B來操作了；

step4. 主機B向A發出斷開連線請求，然後進入LAST-ACK狀態；

step5. 主機A接收到請求後傳送確認，進入TIME-WAIT狀態，等待2MSL之後進入CLOSED狀態，而主機B則在接受到確認後進入CLOSED狀態；

1. 為何主機A在傳送了最後的確認後沒有進入CLOSED狀態，反而進入了一個等待2MSL的TIME-WAIT主要作用有兩個：

   第一，確保主機A最後傳送的確認能夠到達主機B。如果處於LAST-ACK狀態的主機B一直收不到來自主機A的確認，它會重傳斷開連線請求，然後主機A就可以有足夠的時間去再次傳送確認。但是這也只能盡最大力量來確保能夠正常斷開，如果主機A的確認總是在網路中滯留失效，從而超過了2MSL，最後也無法正常斷開；

   第二，如果主機A在傳送了確認之後立即進入CLOSED狀態。假設之後主機A再次向主機B傳送一條連線請求，而這條連線請求比之前的確認報文更早地到達主機B，則會使得主機B以為這條連線請求是在舊的連線中A發出的報文，並不看成是一條新的連線請求了，即使得這個連線請求失效了，增加2MSL的時間可以使得這個失效的連線請求報文作廢，這樣才不影響下次新的連線請求中出現失效的連線請求。

2. 為什麼斷開連線請求報文只有三個，而不是四個因為在TCP連線過程中，確認的傳送有一個延時（即經受延時的確認），一端在傳送確認的時候將等待一段時間，如果自己在這段事件內也有資料要傳送，就跟確認一起傳送，如果沒有，則確認單獨傳送。而我們的抓包實驗中，由伺服器端先斷開連線，之後客戶端在確認的延遲時間內，也有請求斷開連線需要傳送，於是就與上次確認一起傳送，因此就只有三個資料報了。

5 Wireshark分析tcpdump抓包結果

1、啟動8080埠，tcpdump抓包命令如下：

tcpdump -ilo0 -s0 -n -Shost10.37.63.3andport8080 -w./Desktop/tcpdump_10.37.63.3_8080_20160525.cap

# 然後再執行curl

curl http://10.37.63.3:8080/atbg/doc

2、使用Wireshark開啟tcpdump_10.37.63.3_8080_20160525.cap檔案

No. 1-4 行：TCP三次握手環節；

No. 5-8 行：TCP傳輸資料環節；

No. 9-13 行：TCP四次揮手環節；

3、順便說一個檢視 http 請求和響應的方法：

彈窗如下圖所示，上面紅色部分為請求資訊，下面藍色部分為響應資訊：

以上是Wireshark分析tcpdump的簡單使用，Wireshark更強大的是過濾器工具，大家可以自行去多研究學習Wireshark，用起來還是比較爽的。