網絡學習筆記（二）：TCP可靠傳輸原理

時間 2020-06-18

原文原文鏈接

TCP數據段做爲IP數據報的數據部分來傳輸的，IP層提供盡最大努力服務，卻不保證數據可靠傳輸。TCP想要提供可靠傳輸，須要採起必定的措施來讓不可靠的傳輸信道提供可靠傳輸服務。好比：出現差錯時，讓發送方重傳數據；接收方來不及處理數據時，讓發送方下降傳輸速度。 html

1、數據流傳輸方式

TCP傳輸的數據通常分爲兩類：交互數據、成塊數據。交互數據通常較小，好比發送1個字節的交互數據，加上TCP數據段首部以及IP數據報首部，至少須要41個字節。在廣域網，數量衆多的交互數據會增長擁塞出現的可能。而成塊數據的報文段基本上都是滿長度的。 根據不一樣狀況，兩種數據流採用不一樣的傳輸方式。 算法

一、交互數據流傳輸

在互聯網早期，通訊鏈路並不可靠，所以在鏈路層傳輸數據時要採用可靠的傳輸協議，其中最簡答的協議叫「中止等待協議」。在運輸層並不使用中止等待協議，只是傳輸交互數據流傳輸時採用的nagle算法和該協議的原理很相似。 數組

（一）、中止等待ARQ協議

「中止等待」是指每發送完一個分組就中止發送，等待對方確認，在收到對方確認後再發送下一個分組。發送方在必定時間沒有收到確認，則會重傳分組。 如上圖所示，發送方發送數據分組A，接收方接收到A後，向發送方發送確認數據；發送方在收到A的確認後，繼續發送數據分組B。 數組分組在傳輸過程當中發生錯誤時有兩種狀況：緩存

一、當接收方收到錯誤數據分組時，會直接丟棄分組。 二、若是數組分組在傳輸的過程當中丟失。 網絡

在這兩種狀況下，接收方都不會發送任何信息。發送方在必定時間內沒有收到確認，就認爲分組丟失，而後重傳該數據分組，這就叫超時重傳。 中止等待ARQ協議就是經過這種確認和重傳的機制，在不可靠的網絡上實現可靠通訊。 ide

（二）、nagle算法

在傳輸交互數據流時，通常採用nagle算法。nagle算法要求在一個TCP鏈接上最多隻能有一個未被確認的小分組，在該分組的確認到達以前不能發送其餘分組。值得注意的是：並非在收到確認以後馬上發送其餘分組，TCP鏈接上容許不存在數據分組。具體的nagle算法發送分組的規則以下： spa

一、緩存中的數據長度達到最大報文長度時，則容許發送。 二、緩存中的數據長度達到發送窗口大小的一半時，則容許發送。 三、報文段首部FIN標誌位置爲1，則容許發送。 四、報文段首部設置了TCP_NODELAY選項，則容許發送； 五、發生了超時（通常爲200ms），則當即發送。 3d

TCP在未收到確認時收集這些零散的數據，當確認到達的時候，能夠以一個報文段發送出去。確認到達的越快，數據發送的也就越快。 nagle算法可以有效解決交互類的小數據過多的問題，下降網絡擁塞出現的可能。可是因爲不是將緩存中收到的數據馬上發送出去，所以會產生必定的時延。另外，接收方通常會延遲確認，以便將確認報文與要送的數據相結合起來，通常延遲時間爲200ms。 對於一些實時應用程序來講，nagle算法帶來的延遲是不可以接受的。TCP標準規定，必須實現nagle算法，但也必須提供一種能夠關閉nagle算法的方法。上述nagle算法規則中第四條說的TCP_NODELAY選項就是nagle算法被關閉的標誌。 htm

二、成塊數據流傳輸

成塊數據每每超過最大報文長度，要進行拆分以後再發送，交互數據碎片化的問題不會出現。成塊數據是經過基於滑動窗口協議來的連續ARQ協議完成的。 blog

（一）、滑動窗口協議

使用基於中止等待協議的nagle算法的缺點是信道利用率過低。以下圖所示： 若是使用流水線傳輸，那麼信道利用率會大幅提高。TCP採用滑動窗口協議來實現流水線傳輸。 滑動窗戶協議是指數據發送方有一個發送窗口，發送窗口範圍內的數據容許發送，隨着接收方傳來的確認信息以及通知的接收窗口的大小來動態調整發送窗口的起始位置以及大小。 如圖所示：序號1-4的數據是已經發送過而且被確認的數據，TCP能夠將這些數據清出緩存；序號5-11是在窗口範圍內的數據，容許發送；序號12-16的數據在緩存中不容許發送。 窗口後沿是由接收方發送的確認序號決定的，窗口前沿是由確認序號與發送窗口大小共同決定的。而發送窗口大小並必定等於接收方提供的接收窗口的大小，發送方會根據網絡擁塞狀況來動態調整發送窗口大小，前提是發送方發送窗口大小必定不大於接收方接收窗口大小。 窗口的滑動有三種狀況：

一、前沿向右移動，這種狀況發生在數據發送並被確認時。 二、後沿向右移動，容許發送更多數據。這種狀況發生在接收窗口增大或者網絡擁塞狀況緩解時。 三、後沿向左移動，這種狀況發生在接收方但願發送窗口縮小時，TCP標準強烈不建議出現這種狀況。由於發送方在收到縮小窗口的通知時，可能已經發送了一些縮小部分的數據，容易形成錯誤。

窗口前沿沒法向左移動，由於TCP會將窗口以外已經收到確認的數據清除出緩存。 TCP要求接收方有累計確認功能，接收方沒必要馬上對收到的數據進行確認，這樣能夠減小傳輸開銷。另外，在發送確認時也能夠捎帶上接收方要發送的數據。TCP標準規定確認推遲的時間不能超過0.5秒，若是收到一個具備最大報文長度的報文段，則必須隔一個報文段就發送一個確認。 累積確認功能使得接收方只對按序到達的最後一個分組發送確認，表示這個分組以前的分組已經所有到達。接收方不可以準確的通知發送方已經發送到接收方的數據分組。 例如，上圖中序號五、六、七、九、10分組到達接收方，接收方發送的確認序號是8，即接收方沒有收到序號8的分組，但願下次收到序號8的分組。而序號九、10分組雖然已經到達的事實，發送方並不知曉。 這會致使一個問題：一旦發生超時重傳的狀況，發送方是否須要再次發送已經到達的數據？若是不須要，又該如何獲知具體哪些數據已經到達？ 滑動窗口協議 與 自動重傳請求技術結合造成連續ARQ協議。連續ARQ協議根據超時重發數據方式的不一樣分爲後退N幀ARQ協議和選擇重發ARQ協議。

（二）、後退N幀ARQ協議

在發生超時重傳時，後退N幀ARQ協議不考慮確認序號以後的分組是否已經發送到接收方，直接從確認序號開始重傳以後的數據。 如上圖所示：序號五、六、七、九、10分組到達接收方，確認序號爲8。假如窗口大小不變，則窗口向右滑動，序號8-14在發送窗口中。超時重傳時不考慮序號九、10是否到達接收方，重傳序號8以後的所有在發送窗口的數據。

（三）、選擇重傳ARQ協議

選擇重傳ARQ協議是指在接收方收到未按序排列的數據流時，通知發送方重傳缺失的數據，而不是重傳所有數據。TCP數據段首部中添加選擇確認選項SACK能夠實現該目的。 如圖所示，假設上述分組都在發送窗口中，收到三個不連續的分組。三個分組的邊界分別爲：[4000,5001]、[6000,7001]、[8000,9001]。在創建TCP鏈接時，鏈接雙方先商定好，在首部選項中加入「容許SACK」的選項。在以後的TCP報文段中增長SACk選項，以便接收方向發送方報告不連續的字節塊的邊界。 由於序號是32位，所以指明一個邊界須要4個字節，說明一個字節塊的邊界須要8個字節。另外須要一個字節指明是SACK選項，一個字節指明這個選項的大小。TCP報文段首部選項最大爲40個字節，所以最多指明4個字節塊的邊界信息。 TCP標準並未指明發送方應該如何響應SACK，所以大多數實現仍是重傳全部未被確認的數據分組。

2、超時重傳時間

對於每個鏈接，TCP管理這4個不一樣的定時器：

一、重傳定時器：決定什麼時候重傳未被確認的數據分組。 二、堅持定時器：使窗口大小信息保持不斷流動。 三、保活定時器：檢測空閒鏈接的另外一端是否崩潰或重啓。 四、2MSL定時器：測量一個鏈接處於TIME_WAIT狀態的時間。

在超時重傳的狀況下，若是將超時重傳的時間設置的過短，會出現不少沒必要要的重傳，增大網絡負荷；若是設置的時間太長，則使網絡的空閒時間增大，下降傳輸效率。TCP採用一種自適應的算法來動態計算超時重傳的時間。

一、報文段往返時間

一個報文段發出的時間與收到確認的時間只差就是報文段的往返時間RTT。平滑的往返時間RTT_S是RTT的加權平均值。第一次測量時，RTT_S等於RTT的值，以後測量到新的RTT值時按如下公式計算：

新的RTT_S = （1 - α）×（舊的RTT_S）+ α ×（新的RTT樣本）

TCP標準推薦α的值爲0.125。 RTT誤差的加權平均值RTT_D，與RTT_S和新的RTT樣本之差有關。第一次測量時，RTT_D的值取RTT的一半，以後的測量中採用以下公式：

新的RTT_D = （1 - β）×（舊的RTT_D）+ β × |RTT_S - 新的RTT樣本|

TCP標準推薦β的值爲0.25。 超時計時器設置的超時重傳時間RTO由以下公式求得：

RTO = RTT_S + 4 × RTT_D

二、Karn算法

在實際測量報文段往返時間RTT時會遇到一些問題，以下圖所示： 發送報文段後，在必定時間內沒有收到確認。重傳該報文段，以後收到確認報文。那麼怎麼肯定確認報文是對哪一個報文的確認？由於重傳的報文和原報文徹底相同，收到的確認報文也相同。那麼報文段往返時間RTT是A仍是B呢？ 在上述狀況下，Karn提出一個算法：在計算加權平均RTT_S時，只要報文段重傳了，就不採用其往返時間樣本。這樣的到的加權平均RTT_S和RTO就比較準確。 Karn算法也存在問題：當報文段的時延忽然增大不少時，在原重傳時間內不會收到確認報文，因而重傳該報文段。根據Karn算法，重傳的報文段往返時間不會被採用，所以超時重傳時間就沒法更新。 所以要對Karn算法進行修正：報文重傳時，就把超時重傳時間RTO增大一些。典型的作法是重傳時間變成原來的兩倍。當再也不發生重傳時，再根據計算公式算出超時重傳時間。

3、流量控制

經過TCP鏈接發送數據，若是發送方發送數據很慢，容易形成資源浪費；若是發送方發送數據過快，接收方來不及接收會形成數據丟失。流量控制就是指在接收方可以接收的範圍內，合理而又快速的發送數據。

一、基於滑動窗口的流量控制

利用滑動窗口機制能夠實現對發送方的流量控制。在TCP鏈接創建時，接收方會在確認報文段中給出本身接收窗口的大小。在每次發送確認報文時可以根據狀況動態調整接收窗口的大小，並將告知發送方。以下圖所示： 發送方發送序號從1開始的100字節的數據，接收方在確認報文中聲明自身的接收窗口大小爲300字節。以後發送方發送300字節數據，接收方在確認報文中聲明自身接收窗口大小調整爲50字節。發送方再發送50字節數據以後，收到接收方傳來的確認報文，在該報文中聲明接收窗口爲0。 在接收方接收窗口爲0時，發送方再也不發送數據，直到接收方發送確認報文代表窗口大小發生改變。但是這個確認報文不必定可以被髮送方接收到，若是一旦該確認報文丟失，雙方都將處於等待中，造成死鎖。爲防止這種狀況出現，TCP規定在收到對方接受窗口爲0時，啓動一個堅持定時器週期性的發送探測報文，以肯定對方接收窗口爲0的狀態是否改變。 另外，TCP標準規定：接收方接收窗口爲0時，再也不接收正常數據，可是能夠接收零窗口探測報文段、確認報文段、攜帶緊急數據的報文段。

二、糊塗窗口綜合症

糊塗窗口綜合症是指僅僅有少許數據經過鏈接進行交換，而不是滿長度的報文段。這樣會致使網絡傳輸的效率很低。 若是接收緩存已經存滿，此時接收方的應用程序每次只從接收緩存中讀取少許數據，則接收方的接收窗口會一直保持在一個較低的值，致使發送方每次只能發送少許數據，會致使糊塗窗口綜合症。 若是發送方應用程序每次向發送緩存中寫入少許數據，TCP選擇每次收到數據以後當即發送，也會致使糊塗窗口綜合症。 避免糊塗窗口綜合症能夠從兩端採起解決措施：

一、接收方不通告小窗口。一般的算法是接收方不通告一個比當前窗口大的窗口（能夠爲0），除非窗口能夠增長一個報文段大小（也就是將要接收的MSS）或者能夠增長接收方緩存空間的一半，不論實際有多少。 二、發送方在存在滿長度的報文段或者接收方通告窗口大小一半報文時才發送。

4、MSS

最大報文段長度MSS是指每個TCP報文段中數據字段的最大長度。數據字段長度加上首部長度就等於TCP報文段的長度。 MSS是在創建TCP鏈接時通訊雙方協商肯定的。第一次握手時，發送方能夠在首部中增長MSS選項，若是沒有MSS選項，則MSS默認爲1460字節。第二次握手時，接收方也能夠在選項中增長MSS選項，最終MSS的值取鏈接雙方聲明的MSS中最小值。 若是數據鏈路層使用以太網的話，最大傳輸單元MTU爲1500字節，IP數據報首部最少爲20字節，TCP數據段首部至少爲20字節，那麼MSS最大爲1460字節。若是數據鏈路層使用互聯網，那麼MTU=576字節，MSS最大爲536字節。 在網絡層，若是傳輸的數據大於MTU，則會在發送端進行數據分片，而後再接收端的網絡層進行組合。若是其中任何一個分片產生錯誤，都會致使整個TCP報文段重傳。所以TCP會對數據進行分段，分段以後的數據往下交付不會超過MTU，能夠避免網絡層對數據進行分片。在傳輸層，UDP不像TCP那樣進行數據分段，UDP會將應用程序交付下來的整個數據封成一個數據報，若是數據報大小超過MTU，則由網絡層進行分片。

5、擁塞控制

擁塞控制是指防止過多的數據注入網絡中，這樣可使網絡中路由器或者鏈路不致過載。如今通訊線路的傳輸質量通常都很好，因傳輸出現差錯丟棄分組的機率很小。所以，判斷網絡擁塞的依據就是出現了超時。 TCP進行擁塞控制經常使用的算法有四種：慢啓動、擁塞避免、快重傳、快恢復。

一、慢啓動

TCP爲發送方維持一個擁塞窗口，記爲cwnd。擁塞窗口是發送方使用的流量控制，接收方聲明的接收窗口是接收方使用的流量控制。發送方的發送窗口大小等於這兩個窗口中的最小值。 擁塞窗口的值跟SMSS有關，SMSS爲發送的最大報文段長度。舊的規定是擁塞窗口的初始值爲1至2個SMSS，RFC 5681規定擁塞窗口的初始值不超過2至4個SMSS。具體規定以下：

一、若SMSS>2190字節，則cwnd=2×SMSS字節，且不得超過2個報文段。 二、若2190≥SMSS>1095字節，則cwnd=3×SMSS字節，且不得超過3個報文段。 三、若SMSS≥1095字節，則cwnd=4×SMSS字節，且不得超過4個報文段。

慢啓動算法規定：擁塞窗口初始化後，每收到一個對新報文的確認，擁塞窗口就加一個SMSS的大小。擁塞窗口以字節爲單位，可是慢啓動以SMSS大小爲單位增長。按照慢啓動算法，通過一輪傳輸，擁塞窗口就增大一倍，這是一種指數增加的關係。

二、擁塞避免

慢啓動算法除了維持擁塞窗口cwnd變量以外，還維持另外一個變量慢啓動門限ssthresh。當cwnd以指數增加的形式增加到大於或等於ssthresh時，就再也不採用慢啓動算法，而是採用擁塞避免算法來進行擁塞控制。 擁塞避免算法規定：每次收到一個確認時將cwnd增長1/cwnd個SMSS。即再也不是像慢啓動算法那樣通過一輪傳輸cwnd翻倍了，而是通過一輪傳輸增長一個SMSS。這是一種加性增加的關係。 當擁塞發生時（超時或收到重複確認），cwnd被設置爲1個SMSS。ssthresh被設置爲當前窗口大小的一半，但最少爲 2個報文段。 例如：假設TCP的ssthresh的初始值爲 8 SMSS。當擁塞窗口上升到 12 SMSS時網絡發生了超時，TCP使用慢開始和擁塞避免。擁塞窗口大小以下圖所示：

三、快重傳

若是個別報文段在網絡中丟失，網絡並無發生擁塞，這種狀況下發送方收不到確認報文，在超時以後會重傳該報文。發送方誤覺得網絡發生擁塞，錯誤的啓動慢開始算法，下降了傳輸效率。 採用快重傳算法可讓發送方儘早知道個別報文段的丟失。快重傳算法要求接收方不要延時發送確認，即便收到失序的報文段也要馬上發送對已收到報文的重複確認。以下圖所示： 接收方收到M1以後發送對M1的確認報文，M2報文丟失，以後接收方收到M三、M四、M5時每次都發送對M1報文的重複確認。快重傳算法規定當收到三次重複確認後，發送方就認爲M2報文段丟失，當即重傳M2報文段，而不用等待超時時再重傳，這樣能夠避免發送方誤認爲網絡發生擁塞。使用快重傳可使整個網絡的吞吐量提升約20%。

四、快恢復

在快重傳算法執行後，發送方知道只是丟失個別報文，而不是網絡發生擁塞。以後並不會執行慢啓動算法，而是執行快恢復算法：調整門限值ssthresh = cwnd/2，同時設置cwnd = ssthresh + 3 SMSS。這種設置門限值爲當前擁塞窗口的通常，同時根據門限值調整擁塞窗口的形式稱爲乘法減少。 爲何要設置擁塞窗口的值爲門限值加3個報文段，而不是直接等於門限值？這是由於發送方收到三個確認報文，就認爲有三個分組已經離開網絡到達接收方的緩存，這三個確認報文再也不佔用網絡資源，能夠適當增大擁塞窗口的大小。

6、總結

TCP數據流傳輸方式分爲：交互數據流、成塊數據流。交互數據流採用nagle算法來控制流量，成塊數據流經過基於滑動窗口協議的連續ARQ協議完成的。連續ARQ協議根據超時重傳時是重傳所有數據仍是選擇性的重傳而分爲：後退N幀ARQ協議、選擇重傳ARQ協議。 超時重傳的時間是動態肯定的，根據報文段往返時間通過改進後的Karn算法來計算的。 流量控制就是指在接收方可以接收的範圍內，合理而又快速的發送數據。發送方與接收方都要採起措施來防止糊塗窗口綜合症狀況的發生。 最大報文段長度MSS是在創建鏈接時由雙方協商肯定的，TCP數據報的MSS受限於網絡層的最大傳輸單元MTU。TCP會將應用程序交付的數據進行分段，每一個報文段加上TCP報文段首部以及IP數據報首部不會超過MTU，這樣網絡層就不會對TCP數據段進行分片。UDP會將應用程序交付的數據打包成一個UDP數據報，分片任務由網絡層來完成。 TCP進行擁塞控制經常使用的算法有四種：慢啓動、擁塞避免、快重傳、快恢復。這四種算法通常都不是孤立使用的，慢啓動和擁塞避免之間會根據擁塞窗口是否達到ssthresh以及是否發生重傳來切換；快重傳算法以後緊跟着使用快恢復算法。 如需轉載，煩請註明出處：https://www.cnblogs.com/lidengfeng/p/10538536.html