本文來探討一下TCP協議方面的一些認識及實踐

一、簡介

引用《TCP/IP詳解-卷1》中的介紹，TCP與UDP使用相同的網絡層(IP層)，TCP卻向應用層提供了與UDP完全不同的服務。TCP提供一種面向連接的、可靠的字節流服務。

所謂面向連接的，是指在彼此通信前要先建立連接。同時這種點對點的連接表明了TCP不支持多播和廣播。

所謂可靠的，是指TCP有一堆保證數據傳輸準確的機制。

所謂字節流，是指TCP接收端并不知道發送端每次向該連接寫入了多少數據，只關心通過限制能從連接中最大字節數。

二、協議格式

圖：TCP數據包結構

圖：TCP包首部結構

字段說明：

16位源端口號：指建立連接(或發送數據)的端口號

16位目的端口號：指連接另一端(或接受數據)的端口號

32位序號：發送的字節序號，如果是新建立的連接，則第一個包的seq為0，否則為上一個數據包的確認序號。同一個包中的序號和確認序號是不同的。

32位確認序號：等于接收到數據包的序號seq+數據包的長度len。同時告訴對端，下一個數據包的開頭字節序號。

4位首部長度：tcp包首部的長度。

URG：緊急指針有效。它使一端可以告訴另一端有些具有某種方式的“緊急數據”已經放置在普通的數據流中。另一端被通知這個緊急數據已被放置在普通數據流

中，由接收方決定如何處理。URG比特被置1，并且一個16bit的緊急指針被置為一個正的偏移量，該偏移量必須與TCP首部中的序號字段相加，以便得出緊急數據的最后一個字節的序號。注意：TCP的緊急方式不是帶外數據(out-of-band data)。緊急方式有什么作用呢?兩個最常見的例子是Telnet和Rlogin。當交互用戶鍵入中斷鍵時，另一個例子是FTP，當交互用戶放棄一個文件的傳輸時。如果在接收方處理第一個緊急指針之前，發送方多次進入緊急方式會發生什么情況呢?在數據流中的緊急指針會向前移動，而其在接收方的前一個位置將丟失。接收方只有一個緊急指針，每當對方有新的值到達時它將被覆蓋。這意味著如果發送方進入緊急方式時所寫的內容對接收方非常重要，那么這些字節數據必須被發送方用某種方式特別標記。我們將看到Telnet通過在數據流中加入一個值為255的字節作為前綴來標記它所有的命令。

ACK：確認序號有效

PSH：接收方應盡快將這個報文段交給應用層。發送方使用PUSH標志通知接收方將所收到的數據全部提交給接收進程。這里的數據包括與PUSH一起傳送的數據以及接收方TCP已經為接收進程收到的其他數據(還在TCP的緩沖區中)。

RST：重置連接

SYN：同步信號，用于發起一個連接

FIN：發端完成發送任務，關閉連接

16位窗口大?。篢CP的流量控制由連接的每一端通過聲明的窗口大小來提供。窗口大小為字節數，起始于確認序號字段指明的值，這個值是接收端正期望接收的字節。窗口大小是一個16 bit字段，因而窗口大小最大為65535字節。

16位校驗和：檢驗和覆蓋了整個的TCP報文段：TCP首部和TCP數據。

16位緊急指針：只有當URG標志置1時緊急指針才有效。緊急指針是一個正的偏移量，和序號字段中的值相加表示緊急數據最后一個字節的序號。TCP的緊急方式是發送端向另一端發送緊急數據的一種方式。

選項：部分可選配置，主要有以下幾種：

每個選項的開始是1字節kind字段，說明選項的類型。kind字段為0和1的選項僅占1個字節。其他的選項在kind字節后還有len字節。它說明的長度是指總長度，包括kind字節和len字節。

三、TCP各種狀態

1. 狀態轉移

A主動建立連接

圖：主動建立連接

B被動建立連接

圖：被動建立連接

C主動關閉連接

圖：主動關閉連接

D被動關閉連接

圖：被動關閉連接

2. 建立連接

圖：TCP建立連接

3. 關閉連接

圖：TCP關閉連接

4. 半連接

TCP連接是個全雙工通道，所以可以同時支持發送和接收?？梢哉J為將一個通道分成兩部分，就像高速公路一樣，一條大路中間分隔，兩邊的方向完全相反。

半連接是指連接的一端發送完本地數據后，將發送的那半個連接關閉，告訴對端不用再等待接收數據，而對端照樣可以發送數據，本端可以讀取數據。

再舉高速公路的例子，假如連接是北京到天津的高速公路，如果某一天，北京到天津方向的沒有車輛，則該方向高速公路可以封閉，北京這邊的入口將關閉，同時告知天津出口不會有車輛通行，天津出口也沒必要有人值班了。但是，有不少車輛要從天津開往北京方向，這樣天津的入口沒有關閉，北京的出口則需要有人收費抬桿。

5. 復位報文

無論何時一個報文段發往基準的連接(referenced connection)出現錯誤，TCP都會發出一個復位報文段(這里提到的“基準的連接”是指由目的I P地址和目的端口號以及源I P地址和源端口號指明的連接。)

產生復位的一種常見情況是當連接請求到達時，目的端口沒有進程正在聽。對于UDP，當一個數據報到達目的端口時，該端口沒在使用，它將產生一個ICMP端口不可達的信息。而TCP則使用復位。

發送一個復位報文段而不是FIN來中途釋放一個連接，這稱為異常釋放。異常終止一個連接對應用程序來說有兩個優點：(1)丟棄任何待發數據并立即發送復位報文段;(2)RST的接收方會區分另一端執行的是異常關閉還是正常關閉。應用程序使用的API必須提供產生異常關閉而不是正常關閉的手段。Socket API通過“linger on close”選項(SO_LINGER)提供了這種異常關閉的能力。我們加上-L選項并將停留時間設為0。這將導致連接關閉時進行復位而不是正常的FIN。

四、TCP數據傳輸

1. 正常傳輸

圖：正常的數據傳輸

2. 快發慢接

圖：快發到慢收的數據傳輸

上圖說明，在慢收設備接收數據時，由于沒有及時的將TCP緩沖區的數據讀到應用層而會返回給發送端一個通告窗口為0的ACK。

五、超時和重傳機制

1. 往返時間RTT及重傳超時間RTO(Retransmission TimeOut)

RTT估計器：R←aR+ ( 1-a )M

這里的a是一個推薦值為0.9的平滑因子。每次進行新測量的時候，這個被平滑的RTT將得到更新。每個新估計的90%來自前一個估計，而10 %則取自新的測量。

RTO公式：

E rr= M-A

A←A+ g E rr

D←D+ h( | E rr |-D)

RTO= A+ 4D

這里的A是被平滑的RTT(均值的估計器)而D則是被平滑的均值偏差。Err是剛得到的測量結果與當前的RTT估計器之差。A和D均被用于計算下一個重傳時間(RTO)。增量g起平均作用，取為1/8(0.125)。偏差的增益是h，取值為0.25。當RTT變化時，較大的偏差增益將使RTO快速上升。

一個TCP連接只有一個RTT計時器，如果一個請求發送時計時器已經開始計時，則該請求不進行RTT計算。

圖：RTT計時

上圖中，第4個數據包在發送時因為RTT計時器已經開始計時(第3個數據包)而沒有再次啟動計時器。

2. 擁塞避免算法

有兩種分組丟失的指示：發生超時和接收到重復的確認。

擁塞避免算法和慢啟動算法是兩個目的不同、獨立的算法。但是當擁塞發生時，我們希望降低分組進入網絡的傳輸速率，于是可以調用慢啟動來作到這一點。

擁塞避免算法和慢啟動算法需要對每個連接維持兩個變量：一個擁塞窗口cwnd和一個慢啟動門限ssthresh。算法如下：

1) 對一個給定的連接，初始化cwnd為1個報文段，ssthresh為65535個字節。

2) TCP輸出例程的輸出不能超過cwnd和接收方通告窗口的大小。擁塞避免是發送方使用的流量控制，而通告窗口則是接收方進行的流量控制。前者是發送方感受到的網絡擁塞的估計，而后者則與接收方在該連接上的可用緩存大小有關。

3) 當擁塞發生時(超時或收到重復確認)，ssthresh被設置為當前窗口大小的一半(cwnd和接收方通告窗口大小的最小值，但最少為2個報文段)。此外，如果是超時引起了擁塞，則cwnd被設置為1個報文段(這就是慢啟動)。

4) 當新的數據被對方確認時，就增加cwnd，但增加的方法依賴于我們是否正在進行慢啟動或擁塞避免。如果cwnd小于或等于ssthresh，則正在進行慢啟動，否則正在進行擁塞避免。慢啟動一直持續到我們回到當擁塞發生時所處位置的半時候才停止(因為我們記錄了在步驟2中給我們制造麻煩的窗口大小的一半)，然后轉為執行擁塞避免。

慢啟動算法初始設置cwnd為1個報文段，此后每收到一個確認就加1。

擁塞避免算法要求每次收到一個確認時將cwnd增加1/cwnd。與慢啟動的指數增加比起來，這是一種加性增長(additive increase)。我們希望在一個往返時間內最多為cwnd增加1個報文段(不管在這個RTT中收到了多少個ACK)，然而慢啟動將根據這個往返時間中所收到的確認的個數增加cwnd。

圖：慢啟動和擁塞避免的可視化描述

3. 快速重傳與快速恢復算法

在收到一個失序的報文之后，TCP需要立即產生一個ACK(一個重復的ACK)。這個ACK不應該被延遲。該重復的ACK是為了讓對方知道收到一個失序的報文段，并告訴對方自己希望收到的報文序號。

問題出現了，有兩種可能我們會收到重復的ACK：丟包和報文段失序。如果是報文段失序了，那么在發送一兩個重復的ACK之后，基本上都能接收到失序的幾個報文，然后在TCP緩沖區中重新排序，然后返回另一個ACK(希望收到的下一個報文的序號);而如果有三個或三個以上的重復ACK，那么認為該ACK對應的數據已經丟失，需要立即進行重傳，無需等待超時定時器溢出。這就是快速重傳算法。

圖：TCP超時重傳

上圖可以看出，發送端在連續收到了3個重復的ACK報文后，并沒有進入慢啟動，而是執行了擁塞避免算法，這就是快速回復算法。之所以沒有執行慢啟動算法是因為，發送端收到了連續的重復的ACK報文段后，不僅判斷出這個報文已經丟失，還能判斷到接收端收到了后面的幾個報文段(只有這樣，接收端才連續的返回重復ACK報文)，表明這時候的網絡仍然可以傳輸報文，沒有必要執行慢啟動影響傳輸性能，所以，在接收到重傳報文段的ACK之前，又發出了三個報文段67、69和71。

這個算法通常按如下過程進行實現：

1) 當收到第3個重復的ACK時，將ssthresh設置為當前擁塞窗口cwnd的一半。重傳丟失的報文段。設置cwnd為ssthresh加上3倍的報文段大小。

2) 每次收到另一個重復的ACK時，cwnd增加1個報文段大小并發送1個分組(如果新的cwnd允許發送)。

3) 當下一個確認新數據的A C K到達時，設置cwnd為ssthresh(在第1步中設置的值)。這個ACK應該是在進行重傳后的一個往返時間內對步驟1中重傳的確認。另外，這個ACK也應該是對丟失的分組和收到的第1個重復的ACK之間的所有中間報文段的確認。這一步采用的是擁塞避免，因為當分組丟失時我們將當前的速率減半。

4. 擁塞算法例子

1) 初始SYN有一個超時重傳的例子

圖：SYN超時重傳-擁塞避免例子

當SYN的超時發生時，sstresh被置為其最小取值(512字節，表示2個報文段)。為進入慢啟動階段，cwnd被置為1個報文段(256字節)

當收到SYN和ACK時，沒有對這兩個變量做任何修改，因為新的數據還沒有被確認。

當ACK 257到達時，因為cwnd小于等于ssthresh，因此仍然處于慢啟動階段，于是將cwnd增加256字節。當收到ACK 513時，進行同樣的處理。

當ACK 769到達時，我們不再處于慢啟動狀態，而是進入了擁塞避免狀態。新的cwnd值按以下方法計算：

通過上面公式計算獲得當前cwnd的大小為885字節：

當下一個ACK 1025到達時，我們計算cwnd為991字節：

2) 報文段丟失重傳

圖：報文段丟失重傳-擁塞避免例子

當第3個重復的ACK到達時，ssthresh被置為cwnd的一半(四舍五入到報文段大小的下一個倍數)，而cwnd被置為ssthresh加上所收到的重復的ACK數乘以報文段大小(也即1024加上3倍的256)，然后發送重傳數據。

又有5個重復的ACK到達(報文段64~66, 68和70)，每次cwnd增加1個報文段長度。最后一個新的ACK(報文段72段)到達時，cwnd被置為ssthresh(1024)并進入正常的擁塞避免過程。由于cwnd小于等于ssthresh(現在相等)，因此報文段的大小增加到cwnd，取值為1280。

當下一個新的ACK到達(沒有在圖中表示出來)時，cwnd大于ssthresh，取值為1363：

在快速重傳和快速恢復階段，我們收到報文段66、68和70中的重復的ACK后才發送新的數據，而不是在接收到報文段64和65中重復的ACK之后就發送。這是cwnd的取值與未被確認的數據大小比較的結果。當報文段65到達時，cwnd為2048，但未被確認的數據有2304字節(9個報文段：46, 48, 50, 52, 54, 55, 57, 59和63)，因此不能發送任何數據。當報文段65到達后，cwnd被置為2304，此時我們仍不能進行發送。但是當報文段66到達時，cwnd為2560，所以我們可以發送1個新的數據報文段。類似地，當報文段68到達時，cwnd等于2816，該數值大于未被確認的2560字節的數據大小，因此我們可以發送另1個新的數據報文段。報文段70到達時也進行了類似的處理。

5. 重新分組

當TCP超時并重傳時，它不一定要重傳同樣的報文段。相反，TCP允許進行重新分組而發送一個較大的報文段，這將有助于提高性能(當然，這個較大的報文段不能夠超過接收方聲明的MSS)。在協議中這是允許的，因為TCP是使用字節序號而不是報文段序號來進行識別它所要發送的數據和進行確認。

來源 http://www.cnblogs.com/geekma/archive/2012/10/23/2735944.html