一、 tcpdump與Wireshark介紹
在網(wǎng)絡(luò)問題的調(diào)試中，tcpdump應(yīng)該說是一個必不可少的工具，和大部分linux下優(yōu)秀工具一樣，它的特點就是簡單而強大。它是基于Unix系統(tǒng)的命令行式的數(shù)據(jù)包嗅探工具，可以抓取流動在網(wǎng)卡上的數(shù)據(jù)包。
默認情況下，tcpdump不會抓取本機內(nèi)部通訊的報文。根據(jù)網(wǎng)絡(luò)協(xié)議棧的規(guī)定，對于報文，即使是目的地是本機，也需要經(jīng)過本機的網(wǎng)絡(luò)協(xié)議層，所以本機通訊肯定是通過API進入了內(nèi)核，并且完成了路由選擇。【比如本機的TCP通信，也必須要socket通信的基本要素：src ip port dst ip port】
如果要使用tcpdump抓取其他主機mac地址的數(shù)據(jù)包，必須開啟網(wǎng)卡混雜模式，所謂混雜模式，用最簡單的語言就是讓網(wǎng)卡抓取任何經(jīng)過它的數(shù)據(jù)包，不管這個數(shù)據(jù)包是不是發(fā)給它或者是它發(fā)出的。一般而言，Unix不會讓普通用戶設(shè)置混雜模式，因為這樣可以看到別人的信息，比如telnet的用戶名和密碼，這樣會引起一些安全上的問題，所以只有root用戶可以開啟混雜模式，開啟混雜模式的命令是：ifconfig en0 promisc, en0是你要打開混雜模式的網(wǎng)卡。
Linux抓包原理：
Linux抓包是通過注冊一種虛擬的底層網(wǎng)絡(luò)協(xié)議來完成對網(wǎng)絡(luò)報文(準(zhǔn)確的說是網(wǎng)絡(luò)設(shè)備)消息的處理權(quán)。當(dāng)網(wǎng)卡接收到一個網(wǎng)絡(luò)報文之后，它會遍歷系統(tǒng)中所有已經(jīng)注冊的網(wǎng)絡(luò)協(xié)議，例如以太網(wǎng)協(xié)議、x25協(xié)議處理模塊來嘗試進行報文的解析處理，這一點和一些文件系統(tǒng)的掛載相似，就是讓系統(tǒng)中所有的已經(jīng)注冊的文件系統(tǒng)來進行嘗試掛載，如果哪一個認為自己可以處理，那么就完成掛載。
當(dāng)抓包模塊把自己偽裝成一個網(wǎng)絡(luò)協(xié)議的時候，系統(tǒng)在收到報文的時候就會給這個偽協(xié)議一次機會，讓它來對網(wǎng)卡收到的報文進行一次處理，此時該模塊就會趁機對報文進行窺探，也就是把這個報文完完整整的復(fù)制一份，假裝是自己接收到的報文，匯報給抓包模塊。
Wireshark是一個網(wǎng)絡(luò)協(xié)議檢測工具，支持windows平臺、Unix平臺、Mac平臺，一般只在圖形界面平臺下使用Wireshark，如果是Linux的話，直接使用tcpdump了，因為一般而言Linux都自帶的tcpdump，或者用tcpdump抓包以后用Wireshark打開分析。
在Mac平臺下，Wireshark通過WinPcap進行抓包，封裝的很好，使用起來很方便，可以很容易的制定抓包過濾器或者顯示過濾器。Wireshark是一個免費的工具，只要google一下就能很容易找到下載的地方。
所以，tcpdump是用來抓取數(shù)據(jù)非常方便，Wireshark則是用于分析抓取到的數(shù)據(jù)比較方便。
二、tcpdump抓取TCP包分析
TCP傳輸控制協(xié)議是面向連接的可靠的傳輸層協(xié)議，在進行數(shù)據(jù)傳輸之前，需要在傳輸數(shù)據(jù)的兩端（客戶端和服務(wù)器端）創(chuàng)建一個連接，這個連接由一對插口地址唯一標(biāo)識，即是在IP報文首部的源IP地址、目的IP地址，以及TCP數(shù)據(jù)報首部的源端口地址和目的端口地址。TCP首部結(jié)構(gòu)如下：
注意：通常情況下，一個正常的TCP連接，都會有三個階段:1、TCP三次握手;2、數(shù)據(jù)傳送;3、TCP四次揮手
其中在TCP連接和斷開連接過程中的關(guān)鍵部分如下：
源端口號：即發(fā)送方的端口號，在TCP連接過程中，對于客戶端，端口號往往由內(nèi)核分配，無需進程指定；
目的端口號：即發(fā)送目的的端口號；
序號：即為發(fā)送的數(shù)據(jù)段首個字節(jié)的序號；
確認序號：在收到對方發(fā)來的數(shù)據(jù)報，發(fā)送確認時期待對方下一次發(fā)送的數(shù)據(jù)序號；
SYN：同步序列編號，Synchronize Sequence Numbers；
ACK：確認編號，Acknowledgement Number；
FIN：結(jié)束標(biāo)志，F(xiàn)INish；
1、三次握手，過程如下：
step1. 由客戶端向服務(wù)器端發(fā)起TCP連接請求。Client發(fā)送：同步序列編號SYN置為1，發(fā)送序號Seq為一個隨機數(shù)，這里假設(shè)為X，確認序號ACK置為0；
step2. 服務(wù)器端接收到連接請求。Server響應(yīng)：同步序列編號SYN置為1，并將確認序號ACK置為X+1，然后生成一個隨機數(shù)Y作為發(fā)送序號Seq（因為所確認的數(shù)據(jù)報的確認序號未初始化）；
step3. 客戶端對接收到的確認進行確認。Client發(fā)送：將確認序號ACK置為Y+1，然后將發(fā)送序號Seq置為X+1（即為接收到的數(shù)據(jù)報的確認序號）；
為什么是三次握手而不是兩次對于step3的作用，假設(shè)一種情況，客戶端A向服務(wù)器B發(fā)送一個連接請求數(shù)據(jù)報，然后這個數(shù)據(jù)報在網(wǎng)絡(luò)中滯留導(dǎo)致其遲到了，雖然遲到了，但是服務(wù)器仍然會接收并發(fā)回一個確認數(shù)據(jù)報。但是A卻因為久久收不到B的確認而將發(fā)送的請求連接置為失效，等到一段時間后，接到B發(fā)送過來的確認，A認為自己現(xiàn)在沒有發(fā)送連接，而B卻一直以為連接成功了，于是一直在等待A的動作，而A將不會有任何的動作了。這會導(dǎo)致服務(wù)器資源白白浪費掉了，因此，兩次握手是不行的，因此需要再加上一次，對B發(fā)過來的確認再進行一次確認，即確認這次連接是有效的，從而建立連接。
對于雙方，發(fā)送序號的初始化為何值有的系統(tǒng)中是顯式的初始化序號是0，但是這種已知的初始化值是非常危險的，因為這會使得一些黑客鉆漏洞，發(fā)送一些數(shù)據(jù)報來破壞連接。因此，初始化序號因為取隨機數(shù)會更好一些，并且是越隨機越安全。
tcpdump抓TCP三次握手抓包分析：
sudotcpdump-n-S-ilo0host10.37.63.3andtcpport8080
# 接著再運行：
curlhttp://10.37.63.3:8080/atbg/doc
控制臺輸出：
每一行中間都有這個包所攜帶的標(biāo)志：
S=SYN，發(fā)起連接標(biāo)志。
P=PUSH，傳送數(shù)據(jù)標(biāo)志。
F=FIN，關(guān)閉連接標(biāo)志。
ack，表示確認包。
RST=RESET，異常關(guān)閉連接。
.，表示沒有任何標(biāo)志。
第1行：16:00:13.486776，從10.37.63.3（client）的臨時端口61725向10.37.63.3（server）的8080監(jiān)聽端口發(fā)起連接，client初始包序號seq為1944916150，滑動窗口大小為65535字節(jié)（滑動窗口即tcp接收緩沖區(qū)的大小，用于tcp擁塞控制），mss大小為16344（即可接收的最大包長度，通常為MTU減40字節(jié)，IP頭和TCP頭各20字節(jié)）。【seq=1944916150，ack=0，syn=1】
第2行：16:00:13.486850，server響應(yīng)連接，同時帶上第一個包的ack信息，為client端的初始包序號seq加1，即1944916151，即server端下次等待接受這個包序號的包，用于tcp字節(jié)流的順序控制。Server端的初始包序號seq為1119565918，mss也是16344?！緎eq=1119565918，ack=1944916151，syn=1】
第3行：15:46:13.084161，client再次發(fā)送確認連接，tcp連接三次握手完成，等待傳輸數(shù)據(jù)包?！綼ck=1119565919，seq=1944916151】
2、四次揮手
連接雙方在完成數(shù)據(jù)傳輸之后就需要斷開連接。由于TCP連接是屬于全雙工的，即連接雙方可以在一條TCP連接上互相傳輸數(shù)據(jù)，因此在斷開時存在一個半關(guān)閉狀態(tài)，即有有一方失去發(fā)送數(shù)據(jù)的能力，卻還能接收數(shù)據(jù)。因此，斷開連接需要分為四次。主要過程如下：
step1. 主機A向主機B發(fā)起斷開連接請求，之后主機A進入FIN-WAIT-1狀態(tài)；
step2. 主機B收到主機A的請求后，向主機A發(fā)回確認，然后進入CLOSE-WAIT狀態(tài)；
step3. 主機A收到B的確認之后，進入FIN-WAIT-2狀態(tài)，此時便是半關(guān)閉狀態(tài)，即主機A失去發(fā)送能力，但是主機B卻還能向A發(fā)送數(shù)據(jù)，并且A可以接收數(shù)據(jù)。此時主機B占主導(dǎo)位置了，如果需要繼續(xù)關(guān)閉則需要主機B來操作了；
step4. 主機B向A發(fā)出斷開連接請求，然后進入LAST-ACK狀態(tài)；
step5. 主機A接收到請求后發(fā)送確認，進入TIME-WAIT狀態(tài)，等待2MSL之后進入CLOSED狀態(tài)，而主機B則在接受到確認后進入CLOSED狀態(tài)；
為何主機A在發(fā)送了最后的確認后沒有進入CLOSED狀態(tài)，反而進入了一個等待2MSL的TIME-WAIT主要作用有兩個：
第一，確保主機A最后發(fā)送的確認能夠到達主機B。如果處于LAST-ACK狀態(tài)的主機B一直收不到來自主機A的確認，它會重傳斷開連接請求，然后主機A就可以有足夠的時間去再次發(fā)送確認。但是這也只能盡最大力量來確保能夠正常斷開，如果主機A的確認總是在網(wǎng)絡(luò)中滯留失效，從而超過了2MSL，最后也無法正常斷開；
第二，如果主機A在發(fā)送了確認之后立即進入CLOSED狀態(tài)。假設(shè)之后主機A再次向主機B發(fā)送一條連接請求，而這條連接請求比之前的確認報文更早地到達主機B，則會使得主機B以為這條連接請求是在舊的連接中A發(fā)出的報文，并不看成是一條新的連接請求了，即使得這個連接請求失效了，增加2MSL的時間可以使得這個失效的連接請求報文作廢，這樣才不影響下次新的連接請求中出現(xiàn)失效的連接請求。
為什么斷開連接請求報文只有三個，而不是四個因為在TCP連接過程中，確認的發(fā)送有一個延時（即經(jīng)受延時的確認），一端在發(fā)送確認的時候?qū)⒌却欢螘r間，如果自己在這段事件內(nèi)也有數(shù)據(jù)要發(fā)送，就跟確認一起發(fā)送，如果沒有，則確認單獨發(fā)送。而我們的抓包實驗中，由服務(wù)器端先斷開連接，之后客戶端在確認的延遲時間內(nèi)，也有請求斷開連接需要發(fā)送，于是就與上次確認一起發(fā)送，因此就只有三個數(shù)據(jù)報了。
三、 Wireshark分析tcpdump抓包結(jié)果
1、啟動8080端口，tcpdump抓包命令如下：
tcpdump-ilo0-s0-n-Shost10.37.63.3andport8080-w./Desktop/tcpdump_10.37.63.3_8080_20160525.cap
# 然后再執(zhí)行curl
curlhttp://10.37.63.3:8080/atbg/doc
2、使用Wireshark打開tcpdump_10.37.63.3_8080_20160525.cap文件
No. 1-4 行：TCP三次握手環(huán)節(jié)；
No. 5-8 行：TCP傳輸數(shù)據(jù)環(huán)節(jié)；
No. 9-13 行：TCP四次揮手環(huán)節(jié)；
