利用tcpdump抓包工具監控TCP鏈接的三次握手和斷開鏈接的四次揮手

TCP傳輸控制協議是面向鏈接的可靠的傳輸層協議，在進行數據傳輸以前，須要在傳輸數據的兩端（客戶端和服務器端）建立一個鏈接，這個鏈接由一對插口地址惟一標識，便是在IP報文首部的源IP地址、目的IP地址，以及TCP數據報首部的源端口地址和目的端口地址。TCP首部結構以下：

 

 

其中在TCP鏈接和斷開鏈接過程當中的關鍵部分以下：

 

1.源端口號：即發送方的端口號，在TCP鏈接過程當中，對於客戶端，端口號每每由內核分配，無需進程指定；

2.目的端口號：即發送目的的端口號；

3.序號：即爲發送的數據段首個字節的序號；

3.確認序號：在收到對方發來的數據報，發送確認時期待對方下一次發送的數據序號；

4.SYN：用於發送鏈接請求；

5.ACK：確認序號有效；

6.FIN：斷開鏈接。

 

三次握手

三次握手的過程以下：

 

step1.  由客戶端向服務器端發起鏈接請求。發送請求標識位SYN置爲1，發送序號爲一個隨機數，這裏假設爲X；

step2.  服務器端接收到鏈接請求，將標識位ACK置爲1，並將確認序號置爲X+1，而後生成一個隨機數Y做爲發送序號（由於所確認的數據報的確認序號未初始化）；

step3:  客戶端對接收到的確認進行確認，將確認序號置爲Y+1，而後將發送序號置爲X+1（即爲接收到的數據報的確認序號）；

 

這裏有幾點須要說明一下：

 

1.爲何是三次握手而不是兩次。對於step3的做用，假設一種狀況，客戶端A想服務器B發送一個鏈接請求數據報，而後這個數據報在網絡中滯留致使其遲到了，雖然遲到了，可是服務器仍然會接收併發回一個確認數據報。可是A卻由於久久收不到B的確認而將發送的請求鏈接失效，等到一段時間後，接到B發送過來的確認，A認爲本身如今沒有發送鏈接，而B卻一直覺得鏈接成功了，因而一直在等待A的動做，而A將不會有任何的動做了。這會致使服務器資源白白浪費掉了，所以，兩次握手是不行的，所以須要再加上一次，對B發過來的確認再進行一次確認，即確認此次鏈接是有效的，從而創建鏈接。

2.對於雙方，發送序號的初始化爲什麼值。有的系統中是顯式的初始化序號是0，可是這種已知的初始化值是很是危險的，由於這會使得一些黑客鑽漏洞，發送一些數據報來破壞鏈接。所以，初始化序號由於取隨機數會更好一些，而且是越隨機越安全。

 

下面是一個簡單的客戶端/服務器端鏈接程序，在Linux環境下，開啓三個終端，在第一個終端輸入命令

 

 

而後在第二個終端運行服務器端程序：

 

 

最後在第三個終端運行客戶端程序：

 

 

完了以後，咱們能夠在第一個終端看到抓包的結果，以下：

 

前三個數據包就是三次握手的三個數據報了。咱們逐個分析一下，第一個數據報是由客戶端發送到服務器端，隨機產生一個序號seq = 830831828。而後第二個數據報是由服務器端發回的確認，隨機產生一個序號seq = 2690963443，而後根據接收到的請求數據報將確認序號設置爲830831829。而後第三個數據報是有客戶端對服務器端確認數據報的確認，能夠看出確認序號爲2690963444

 

四次揮手

鏈接雙方在完成數據傳輸以後就須要斷開鏈接。因爲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鏈接過程當中，確認的發送有一個延時（即經受延時的確認），一端在發送確認的時候將等待一段時間，若是本身在這段事件內也有數據要發送，就跟確認一塊兒發送，若是沒有，則確認單獨發送。而咱們的抓包實驗中，由服務器端先斷開鏈接，以後客戶端在確認的延遲時間內，也有請求斷開鏈接須要發送，因而就與上次確認一塊兒發送，所以就只有三個數據報了。

 

http://blog.csdn.net/hulifangjiayou/article/details/47283387