上一次我們知道了TCP協議通過連接管理機制保證可靠性，今天我們繼續來看一看TCP協議中其他幾種保證可靠性的方法。

· 確認應答機制?
· 超時重傳機制?
· 流量控制?
· 擁塞窗口

確認應答機制?
在將這部分的內容之前我們應該首先知道的一點就是，在TCP中，TCP將每個字節的數據都進行了編號，即為序列號（對每一個數據的編號）。?
?
?
由圖分析：當主機1給主機2發送了1~1000這么多數據時，主機2如果收到了就會給主機1應答（ACK報文段，每一個ACK都帶有對應的確認序列號），表示你給我發的1~1000的數據我已經全部收到了（收到哪些數據），下次你再給我發就給我從1001數據開始發（下次從哪里開始發）。那么主機1收到應答之后就知道對方已經收到了1~1000的全部數據，所以再一次發送數據的時候他就會從1001開始發，后面都是依此類推的情況。

當然了，當我們的主機1給主機2發送了數據之后，經過一端時間主機1并沒有收到主機2的應答的情況也是有的，所以這個時候為了確保數據的準確到達，TCP就有了超時重傳機制。?
超時重傳機制?
主機1沒有收到主機2的確認應答有以下兩種情況：?
1、數據根本就沒有傳送到達主機2，因此主機2就不會回傳一個確認應答的報文。?
?
由圖分析：主機1給主機2發送了數據，可能因為其他的原因數據無法到達主機2.（比如網絡擁堵）。這個時候主機1等待了一個特定的時間間隔之后發現主機2還沒有確認應答，于是就再一次將上一次的數據重新發送過去。

2、主機2收到了數據，也回傳了確認應答報文，但是該報文丟失了。?
?
由圖分析：主機2收到了主機1發來的數據，但是發給主機1的確認應答并沒有準時到達主機1，所以主機1也會因為沒有收到確認應答而再次重新將數據發送過去。但實際情況卻是我們的主機2第一次就已經收到了主機1的數據。但是主機1依舊會重發數據已確保主機2已經收到數據，從而進行下一次的數據轉發?？上攵鳈C2就會收到很多的重復數據，但是重復的數據顯然是不需要的，那么TCP協議就需要能夠識別那些重復的數據并且要將沖符的數據丟棄掉，這個時候序列號就發揮他的一項作用了——去重。每一個數據都有自己的序列號，如果主機2收到重復的數據那么必然機會產生多個序列號相同的數據，那么序列號相同的數據就必然是重復的數據。

我們提到一個特定的時間間隔，這個時間又是如何規定的？

最理想的情況下，找到一個最小的時間保證確認應答一定能在這時間內返回?
但是這個時間的長短，隨著網絡環境的不同，也是有差異的。?
如果超時時間設得太長，會影響整體的重傳效率?
如果超時時間設的太短，有可能平凡的發送沖符的數據包。?
TCP為了抱枕個無論在何種環境下都能比較高性能的通信，因此會動態計算這個最大超時時間：?
Linux中，超時以500ms為一個單位進行控制，每次判定超時重發的超時時間都是500ms的整數倍。?
如果重發一次，任然得不到應答，就等待2*500ms后在進行重傳?
如果還得不到應答，等待4*500ms再重傳，一次類推，以指數形式遞增。?
累積到一定的重傳次數，TCP認為網絡或者對端主機出現異常，就會強制關閉連接。

流量控制?
接收端處理數據的速度是優先的，如果發送端發的太快，導致接收端的緩沖區被打滿，這個時候如果發送端繼續發送就會造成丟包，繼而引起丟包重傳等一系列連鎖反應。因此TCP支持根據接收端的處理能力，來決定發送端的發送速度，這個機制就叫做流量控制。

接收端將自己可以接受的緩沖區大小放入TCP首部中的“窗口大小”字段，通過ACK段通知發送端；?
窗口大小字段越大，說明網絡的吞吐量越高?
接收端一旦發現自己的緩沖區快滿了就會將窗口大小設置成一個更小的值通知發送端。?
發送端接收到窗口大小以后，就會減慢自己的發送速度。?
如果接收緩沖區滿了，就會將窗口置為0，這時發送方不再發送數據。?
但是需要定期的發送一個試探窗口，，目的是為了取探測數據段，是接收端把窗口大小告訴發送端。

接收端是如何把窗口大小告訴發送端的呢？現在，我們回過頭去看一看，在上一篇博客中我們給出了TCP的報頭格式，在TCP的首部中有一個16位的窗口大小的字段，就是存放的窗口大小的信息。另外在TCP的首部中的40字節選項中還包含了一個窗口擴大因子M，實際的窗口大小是窗口字段的值左移M位。

擁塞窗口?
在后面會講到TCP提高性能的滑動窗口，滑動窗口能夠高效可靠的發送大量的數據，但是如果在一開始就發送大量的數據任然可能引發問題。要知道在網絡上有很多的計算機，有可能當前的網絡狀態已經很擁堵，在不清楚當前的網絡狀態下，貿然發送大量的數據，這樣對于已經很擁堵的網絡來說無疑是雪上加霜。?
由此，TCP引入了慢啟動機制：先發送少量的數據，由此取探測當前的網絡的擁堵狀態，在決定按照多大的速度傳輸數據。?

擁塞窗口：?
發送開始的時候定義擁塞窗口大小為1?
每當收到一個ACK應答以后擁塞窗口加1?
每次發送數據包的時候，將擁塞窗口和接收端主機反饋的窗口大小作比較，取較小值作為實際發送的窗口。?
如圖，擁塞窗口的增長速度呈指數形式增長，我們提到說慢啟動，只是說出事的時候慢而已，但是增長速度非常的快。為了增長的不呢么快，因此我們不能讓擁塞窗口單純的加倍，這里引入一個慢啟動的閾值，當同色窗口超過這個閾值的時候，不再按照指數方式增長，而是改為按照線性的方式增長。?
當TCP開始啟動的時候，慢啟動閾值等于窗口最大值，在每次超時重發的時候，慢啟動閾值會變成原來的一半，同時擁塞窗口置為1。

少量的丟包，僅僅只會觸發超時重傳，而大量的丟包就認為是網絡擁堵，當TCP通信開始后，網絡吞吐量會逐漸的上升，隨著網絡發生擁堵，吞吐量會立刻下降，擁塞控制說到底就是TCP協議想盡可能快的將數據傳輸給對方，但又要避免給網絡造成太大的壓力的折中解決辦法。

至此，TCP協議保證可靠性的極大機制我們已經全部學習完成。?
總結一下：?
為了確?？煽康臄祿鬏?#xff0c;TCP協議通過連接管理機制，確認應答機制，流量控制以及擁塞控制這些方法讓可靠性得以很大程度上的保證，另外，序列號保證了數據的按序到達，就知道哪些數據已經收到，那些沒有收到需要重傳。而校驗和通過CRC校驗，如果接收端校驗不通過則認為數據有問題，此舉也保證了數據的可靠性傳輸。

總結

以上是生活随笔為你收集整理的TCP协议可靠性保证（确认应答机制，超时重传机制，流量控制，拥塞窗口）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。