上一次我們知道了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已經收到數據，從而進行下一次的數據轉發。可想而知主機2就會收到很多的重複數據，但是重複的數據顯然是不需要的，那麼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協議保證可靠性的極大機制我們已經全部學習完成。
總結一下：
爲了確保可靠的數據傳輸，TCP協議通過連接管理機制，確認應答機制，流量控制以及擁塞控制這些方法讓可靠性得以很大程度上的保證，另外，序列號保證了數據的按序到達，就知道哪些數據已經收到，那些沒有收到需要重傳。而校驗和通過CRC校驗，如果接收端校驗不通過則認爲數據有問題，此舉也保證了數據的可靠性傳輸。
