TCP序列號和確認號詳解

TCP序列號和確認號詳解

在網絡分析中，讀懂TCP序列號和確認號在的變化趨勢，能夠幫助咱們學習TCP協議以及排查通信故障，如經過查看序列號和確認號能夠肯定數據傳輸是否亂序。但我在查閱了當前不少資料後發現，它們大多隻簡單介紹了TCP通信的過程，並無對序列號和確認號進行詳細介紹，結合實例的講解就更沒有了。近段時間因爲工做的緣由，須要對TCP的序列號和確認號進行深刻學習，下面即是我學習後的一些知識點總結，但願對TCP序列號和確認號感興趣的朋友有必定幫助。

1.  序列號和確認號的簡介及做用

TCP 協議工做在OSI的傳輸層，是一種可靠的面向鏈接的數據流協議，TCP之因此可靠，是由於它保證了傳送數據包的順序。順序是用一個序列號來保證的。響應包內也包括一個序列號，表示接收方準備好這個序列號的包。在TCP傳送一個數據包時，它會把這個數據包放入重發隊列中，同時啓動計時器，若是收到了關於這個包的確認信息，便將此數據包從隊列中刪除，若是在計時器超時的時候仍然沒有收到確認信息，則須要從新發送該數據包。另外，TCP經過數據分段中的序列號來保證全部傳輸的數據能夠按照正常的順序進行重組，從而保障數據傳輸的完整。

2.  TCP的通信過程

在TCP通信中主要有鏈接的創建、數據的傳輸、鏈接的關閉三個過程！每一個過程完成不一樣的工做，並且序列號和確認號在每一個過程當中的變化都是不一樣的。

2.1 TCP創建鏈接

TCP創建鏈接，也就是咱們常說的三次握手，它須要三步完成。在TCP的三次握手中，發送第一個SYN的一端執行的是主動打開。而接收這個SYN併發回下一個SYN的另外一端執行的是被動打開。

這裏以客戶端向服務器發起鏈接來講明。

1)  第1步 ：客戶端向服務器發送一個同步數據包請求創建鏈接，該數據包中，初始序列號（ISN）是客戶端隨機產生的一個值，確認號是0；

2)  第2步 ：服務器收到這個同步請求數據包後，會對客戶端進行一個同步確認。這個數據包中，序列號（ISN）是服務器隨機產生的一個值，確認號是客戶端的初始序列號+1；

3)  第3步 ：客戶端收到這個同步確認數據包後，再對服務器進行一個確認。該數據包中，序列號是上一個同步請求數據包中的確認號值，確認號是服務器的初始序列號+1。

注意 ：由於一個SYN將佔用一個序號，因此要加1。

初始序列號（ISN）隨時間而變化的，並且不一樣的操做系統也會有不一樣的實現方式，因此每一個鏈接的初始序列號是不一樣的。TCP鏈接兩端會在創建鏈接時，交互一些信息，如窗口大小、MSS等，以便爲接着的數據傳輸作準備。

RFC793指出ISN能夠看做是一個32bit的計數器，每4ms加1，這樣選擇序號的目的在於防止在網絡中被延遲的分組在之後被重複傳輸，而致使某個鏈接的一端對它做錯誤的判斷。

2.2 TCP傳輸數據

在TCP創建鏈接後，就能夠開始傳輸數據了。TCP工做在全雙工模式，它能夠同時進行雙向數據傳輸。這裏爲了簡化，咱們只談服務器向客戶端發送數據的狀況，而客戶端向服務器發送數據的原理和它是相似的，這裏便不重複說明。
服務器向客戶端發送一個數據包後，客戶端收到這個數據包後，會向服務器發送一個確認數據包。

傳輸數據的簡要過程以下：

1)  發送數據 ：服務器向客戶端發送一個帶有數據的數據包，該數據包中的序列號和確認號與創建鏈接第三步的數據包中的序列號和確認號相同；

2)  確認收到 ：客戶端收到該數據包，向服務器發送一個確認數據包，該數據包中，序列號是爲上一個數據包中的確認號值，而確認號爲服務器發送的上一個數據包中的序列號+所該數據包中所帶數據的大小。
數據分段中的序列號能夠保證全部傳輸的數據按照正常的次序進行重組，並且經過確認保證數據傳輸的完整性。

2.3 TCP關閉鏈接

前面咱們提到，創建一個鏈接須要3個步驟，可是關閉一個鏈接須要通過4個步驟。由於TCP鏈接是全雙工的工做模式，因此每一個方向上須要單獨關閉。在TCP關閉鏈接時，首先關閉的一方（即發送第一個終止數據包的）將執行主動關閉，而另外一方（收到這個終止數據包的）再執行被動關閉。

關閉鏈接的4個步驟以下：

1)  第1步 ：服務器完成它的數據發送任務後，會主動向客戶端發送一個終止數據包，以關閉在這個方向上的TCP鏈接。該數據包中，序列號爲客戶端發送的上一個數據包中的確認號值，而確認號爲服務器發送的上一個數據包中的序列號+該數據包所帶的數據的大小；

2)  第2步 ：客戶端收到服務器發送的終止數據包後，將對服務器發送確認信息，以關閉該方向上的TCP鏈接。這時的數據包中，序列號爲第1步中的確認號值，而確認號爲第1步的數據包中的序列號+1；

3)  第3步 ：同理，客戶端完成它的數據發送任務後，就也會向服務器發送一個終止數據包，以關閉在這個方向上的TCP鏈接，該數據包中，序列號爲服務器發送的上一個數據包中的確認號值，而確認號爲客戶端發送的上一個數據包中的序列號+該數據包所帶數據的大小；

4)  第4步 ：服務器收到客戶端發送的終止數據包後，將對客戶端發送確認信息，以關閉該方向上的TCP鏈接。這時在數據包中，序列號爲第3步中的確認號值，而確認號爲第3步數據包中的序列號+1；

注意 ：由於FIN和SYN同樣，也要佔一個序號。理論上服務器在TCP鏈接關閉時發送的終止數據包中，只有終止位是置1，而後客戶端進行確認。可是在實際的 TCP實現中，在終止數據包中，確認位和終止位是同時置爲1的，確認位置爲1表示對最後一次傳輸的數據進行確認，終止位置爲1表示關閉該方向的TCP鏈接。

3.  實際數據包分析

結合上面的理論，下面咱們訪問網頁來捕獲數據包，經過實際的數據包來驗證序列號和確認號在TCP鏈接創建、傳輸數據以及關閉鏈接時的變化。

打開科來網絡分析系統，首先爲減小數據干擾，在過濾器中設置只捕獲TCP協議的數據，而後開始捕獲，同時，訪問www.csna.cn ，待頁面下載完成後，中止捕獲。

這次環境中，客戶端爲192.168.0.92，服務器爲：222.77.187.23。

3.1 TCP創建鏈接

在捕獲的數據包中，首先咱們來查看創建鏈接的三次握手信息，而且觀察數據包中序列號和確認號的變化。爲了讓你們看的更加明白，我在這裏使用了「添加數據包註釋」的功能。
咱們先來查看創建鏈接的第一步，如圖1所示。





（圖1  創建鏈接第一步）

圖1中，客戶端向服務器發起一個同步請求數據包，請求鏈接服務器的80端口，客戶端隨機產生一個初始序列號（ISN）爲2712239078，確認號爲0。

注意 ：在實際狀況中，咱們訪問網站首先進行的是域名解析，這裏咱們設置了過濾器因此沒有捕獲到DNS數據包。
接下來咱們再看創建鏈接的第二步。如圖2。



（圖2  創建鏈接第二步）

圖2 中，服務器收到客戶的同步請求數據包後，並向客戶端發送一個同步確認數據。這個數據包中，服務器隨機產生一個初始序列號（1288781508），同時，將客戶端發送的初始序列號（ISN）加1（2712239078+1=2712239079）以做爲確認號發回給客戶段進行確認。
咱們再來查看創建鏈接的第三步，以下圖3。



（圖3  創建鏈接第三步）

圖3 中，客戶端收到這個同步確認數據包後，再次對服務器進行一次確認。在這個數據包中，序列號爲上一個數據包的確認號（2712239079），確認號爲服務器的初始序列號（ISN）加1（1288781508+1=1288781509），以對服務器的同步確認數據包進行確認，這樣TCP鏈接就創建了。

3.2 TCP傳輸數據

TCP鏈接創建後，立刻就開始傳輸數據，這裏客戶端主動向服務器發送一個GET請求，來提交本身的請求信息。
下面咱們就來看客戶端發送給服務器的GET請求數據包，如圖4所示，



（圖4  傳輸數據）

圖4中的是客戶端向服務器發送的GET請求據數據包，咱們注意看序列號和確認號的值！該數據包中，序列號爲2712239079，確認號爲1288781509，這和三次握手的第三步的數據包中的序列號和確認號相同。
從圖4中看出這個數據包的大小爲1018字節，其中減去14字節Ethernet報頭，20字節的IP報頭，20字節的TCP報頭和4字節的FCS （1018-14-20-20-4=960），獲得傳輸的數據大小爲1432。咱們將該數據包中的序列號加上該數據大小（即2712239079+960 =2712240039），發現與「下一個序列號」的值徹底吻合，也就是下一個數據包中服務器發送給客戶端的數據包中的確認號，如圖5所示。



（圖5 確認收到）

注意 ：「下一個序列號」是科來網絡分析系統爲了方便用戶查找下一個連續數據包，而根據數據包序列號和確認號自動計算得出，該字段在實際數據包中是不存在的。

3.3 TCP關閉鏈接

在傳輸數據完成以後，TCP會關閉鏈接，這裏是服務器主動關閉該方向上的TCP鏈接。咱們繼續來觀察捕獲的數據包，先來看關閉鏈接的第一步，這裏是服務器主動發起關閉，如圖6。



（圖6  關閉鏈接第一步）

圖6 中，服務器向客戶端主動發起確認位和終止位同時置爲1的數據包，確認位置1表示對最後一次傳輸的數據進行確認，終止位置1表示關閉該方向的TCP鏈接，關閉服務器和客戶端的TCP鏈接。在這個數據包中，序列號爲客戶端發送的上一個數據包中所帶的確認號值（1288781777），而確認號爲服務器發送的上一個數據包中的序列號+該數據包所帶的數據的大小（2712238597+1432=2712240039）；

而後客戶端收到該終止數據包，會對服務器發送一個確認數據包，該數據包中，序列號爲第1步中的確認號值（2712240039），而確認號爲第1步的數據包中的序列號+1（1288781777+1=1288781778）；
咱們注意觀察序列號和確認號的變化狀況，如圖7所示。



（圖7  關閉鏈接第二步）

隨後，就是來自客戶端被動發起的關閉，它與服務器主動發起的關閉同理，只不過此次是被動關閉客戶端方向上的TCP鏈接，咱們就不重複說明，如圖8和圖9所示。



（圖8  關閉鏈接第三步）



（圖9  關閉鏈接第四步）

咱們根據以上對TCP的創建鏈接、傳輸數據和關閉鏈接三個過程的抓包分析，成功的驗證了前面所說的理論。