TCP的可靠性傳輸是如何保證的
系統總結TCP連接中，它是如何保證數據的傳輸
01 前言
我們之前介紹過TCP的連接比UDP連接複雜，也比較安全，但是我們想知道它是如何保證這些數據的安全的？數據的發送先後有什麼祕訣呢？接下來我就一一去總結這些細節性的問題。
02 保證數據安全的方法
TCP主要提供了檢驗和、序列號/確認應答、超時重傳、最大消息長度、滑動窗口控制等方法實現了可靠性傳輸。
檢驗和
通過檢驗和的方式，接收端可以檢測出來數據是否有差錯和異常，假如有差錯就會直接丟棄TCP段，重新發送。TCP在計算檢驗和時，會在TCP首部加上一個12字節的僞首部。檢驗和總共計算3部分：TCP首部、TCP數據、TCP僞首部
序列號/確認應答
這個機制類似於問答的形式。比如在課堂上老師會問你“明白了嗎？”，假如你沒有隔一段時間沒有迴應或者你說不明白，那麼老師就會重新講一遍。其實計算機的確認應答機制也是一樣的，發送端發送信息給接收端，接收端會迴應一個包，這個包就是應答包。
上述過程中，只要發送端有一個包傳輸，接收端沒有迴應確認包（ACK包），都會重發。或者接收端的應答包，發送端沒有收到也會重發數據。這就可以保證數據的完整性。
超時重傳
超時重傳是指發送出去的數據包到接收到確認包之間的時間，如果超過了這個時間會被認爲是丟包了，需要重傳。那麼我們該如何確認這個時間值呢？
我們知道，一來一回的時間總是差不多的，都會有一個類似於平均值的概念。比如發送一個包到接收端收到這個包一共是0.5s，然後接收端回發一個確認包給發送端也要0.5s，這樣的兩個時間就是RTT（往返時間）。然後可能由於網絡原因的問題，時間會有偏差，稱爲抖動（方差）。
從上面的介紹來看，超時重傳的時間大概是比往返時間+抖動值還要稍大的時間。
但是在重發的過程中，假如一個包經過多次的重發也沒有收到對端的確認包，那麼就會認爲接收端異常，強制關閉連接。並且通知應用通信異常強行終止。
最大消息長度
在建立TCP連接的時候，雙方約定一個最大的長度（MSS）作爲發送的單位，重傳的時候也是以這個單位來進行重傳。理想的情況下是該長度的數據剛好不被網絡層分塊。
滑動窗口控制
我們上面提到的超時重傳的機制存在效率低下的問題，發送一個包到發送下一個包要經過一段時間纔可以。所以我們就想着能不能不用等待確認包就發送下一個數據包呢？這就提出了一個滑動窗口的概念。
窗口的大小就是在無需等待確認包的情況下，發送端還能發送的最大數據量。這個機制的實現就是使用了大量的緩衝區，通過對多個段進行確認應答的功能。通過下一次的確認包可以判斷接收端是否已經接收到了數據，如果已經接收了就從緩衝區裏面刪除數據。
在窗口之外的數據就是還未發送的和對端已經收到的數據。那麼發送端是怎麼樣判斷接收端有沒有接收到數據呢？或者怎麼知道需要重發的數據有哪些呢？通過下面這個圖就知道了。
如上圖，接收端在沒有收到自己所期望的序列號數據之前，會對之前的數據進行重複確認。發送端在收到某個應答包之後，又連續3次收到同樣的應答包，則數據已經丟失了，需要重發。
擁塞控制
窗口控制解決了 兩臺主機之間因傳送速率而可能引起的丟包問題，在一方面保證了TCP數據傳送的可靠性。然而如果網絡非常擁堵，此時再發送數據就會加重網絡負擔，那麼發送的數據段很可能超過了最大生存時間也沒有到達接收方，就會產生丟包問題。爲此TCP引入慢啓動機制，先發出少量數據，就像探路一樣，先摸清當前的網絡擁堵狀態後，再決定按照多大的速度傳送數據。
此處引入一個擁塞窗口：
發送開始時定義擁塞窗口大小爲1；每次收到一個ACK應答，擁塞窗口加1；而在每次發送數據時，發送窗口取擁塞窗口與接送段接收窗口最小者。
慢啓動：在啓動初期以指數增長方式增長；設置一個慢啓動的閾值，當以指數增長達到閾值時就停止指數增長，按照線性增長方式增加至擁塞窗口；線性增長達到網絡擁塞時立即把擁塞窗口置回1，進行新一輪的“慢啓動”，同時新一輪的閾值變爲原來的一半。
03 小結
其實上面所說的知識在學校也學過，但是重來不會認真對待這些看似沒有用的知識，所以現在就好好總結一下了。對於網絡優化的部分可以參照上面的方法來進行優化，可以利用這些方法提供高速、可靠的通信服務。
參考文章
- 圖解TCP/IP
- TCP是如何保證數據的傳輸
