TCP協(xié)議傳輸?shù)奶攸c主要就是面向字節(jié)流、傳輸可靠、面向連接。這篇博客，我們就重點討論一下TCP協(xié)議如何確保傳輸?shù)目煽啃缘摹?/p>

確保傳輸可靠性的方式

TCP協(xié)議保證數(shù)據(jù)傳輸可靠性的方式主要有：

-校驗和
-序列號
-確認(rèn)應(yīng)答
-超時重傳
-連接管理
-流量控制
-擁塞控制

校驗和

計算方式：在數(shù)據(jù)傳輸?shù)倪^程中，將發(fā)送的數(shù)據(jù)段都當(dāng)做一個16位的整數(shù)。將這些整數(shù)加起來。并且前面的進(jìn)位不能丟棄，補在后面，最后取反，得到校驗和。
發(fā)送方：在發(fā)送數(shù)據(jù)之前計算檢驗和，并進(jìn)行校驗和的填充。
接收方：收到數(shù)據(jù)后，對數(shù)據(jù)以同樣的方式進(jìn)行計算，求出校驗和，與發(fā)送方的進(jìn)行比對。

image.png

注意：如果接收方比對校驗和與發(fā)送方不一致，那么數(shù)據(jù)一定傳輸有誤。但是如果接收方比對校驗和與發(fā)送方一致，數(shù)據(jù)不一定傳輸成功。

確認(rèn)應(yīng)答與序列號

序列號：TCP傳輸時將每個字節(jié)的數(shù)據(jù)都進(jìn)行了編號，這就是序列號。
確認(rèn)應(yīng)答：TCP傳輸?shù)倪^程中，每次接收方收到數(shù)據(jù)后，都會對傳輸方進(jìn)行確認(rèn)應(yīng)答。也就是發(fā)送ACK報文。這個ACK報文當(dāng)中帶有對應(yīng)的確認(rèn)序列號，告訴發(fā)送方，接收到了哪些數(shù)據(jù)，下一次的數(shù)據(jù)從哪里發(fā)。

image.png

序列號的作用不僅僅是應(yīng)答的作用，有了序列號能夠?qū)⒔邮盏降臄?shù)據(jù)根據(jù)序列號排序，并且去掉重復(fù)序列號的數(shù)據(jù)。這也是TCP傳輸可靠性的保證之一。

超時重傳

在進(jìn)行TCP傳輸時，由于確認(rèn)應(yīng)答與序列號機制，也就是說發(fā)送方發(fā)送一部分?jǐn)?shù)據(jù)后，都會等待接收方發(fā)送的ACK報文，并解析ACK報文，判斷數(shù)據(jù)是否傳輸成功。如果發(fā)送方發(fā)送完數(shù)據(jù)后，遲遲沒有等到接收方的ACK報文，這該怎么辦呢？而沒有收到ACK報文的原因可能是什么呢？

首先，發(fā)送方?jīng)]有介紹到響應(yīng)的ACK報文原因可能有兩點：

數(shù)據(jù)在傳輸過程中由于網(wǎng)絡(luò)原因等直接全體丟包，接收方根本沒有接收到。
接收方接收到了響應(yīng)的數(shù)據(jù)，但是發(fā)送的ACK報文響應(yīng)卻由于網(wǎng)絡(luò)原因丟包了。
TCP在解決這個問題的時候引入了一個新的機制，叫做超時重傳機制。簡單理解就是發(fā)送方在發(fā)送完數(shù)據(jù)后等待一個時間，時間到達(dá)沒有接收到ACK報文，那么對剛才發(fā)送的數(shù)據(jù)進(jìn)行重新發(fā)送。如果是剛才第一個原因，接收方收到二次重發(fā)的數(shù)據(jù)后，便進(jìn)行ACK應(yīng)答。如果是第二個原因，接收方發(fā)現(xiàn)接收的數(shù)據(jù)已存在（判斷存在的根據(jù)就是序列號，所以上面說序列號還有去除重復(fù)數(shù)據(jù)的作用），那么直接丟棄，仍舊發(fā)送ACK應(yīng)答。

那么發(fā)送方發(fā)送完畢后等待的時間是多少呢？如果這個等待的時間過長，那么會影響TCP傳輸?shù)恼w效率，如果等待時間過短，又會導(dǎo)致頻繁的發(fā)送重復(fù)的包。如何權(quán)衡？

由于TCP傳輸時保證能夠在任何環(huán)境下都有一個高性能的通信，因此這個最大超時時間（也就是等待的時間）是動態(tài)計算的。

在Linux中（BSD Unix和Windows下也是這樣）超時以500ms為一個單位進(jìn)行控制，每次判定超時重發(fā)的超時時間都是500ms的整數(shù)倍。重發(fā)一次后，仍未響應(yīng)，那么等待2500ms的時間后，再次重傳。等待4500ms的時間繼續(xù)重傳。以一個指數(shù)的形式增長。累計到一定的重傳次數(shù)，TCP就認(rèn)為網(wǎng)絡(luò)或者對端出現(xiàn)異常，強制關(guān)閉連接。
連接管理

連接管理就是三次握手與四次揮手的過程，在前面詳細(xì)講過這個過程，這里不再贅述。保證可靠的連接，是保證可靠性的前提。

流量控制

接收端在接收到數(shù)據(jù)后，對其進(jìn)行處理。如果發(fā)送端的發(fā)送速度太快，導(dǎo)致接收端的結(jié)束緩沖區(qū)很快的填充滿了。此時如果發(fā)送端仍舊發(fā)送數(shù)據(jù)，那么接下來發(fā)送的數(shù)據(jù)都會丟包，繼而導(dǎo)致丟包的一系列連鎖反應(yīng)，超時重傳呀什么的。而TCP根據(jù)接收端對數(shù)據(jù)的處理能力，決定發(fā)送端的發(fā)送速度，這個機制就是流量控制。

在TCP協(xié)議的報頭信息當(dāng)中，有一個16位字段的窗口大小。在介紹這個窗口大小時我們知道，窗口大小的內(nèi)容實際上是接收端接收數(shù)據(jù)緩沖區(qū)的剩余大小。這個數(shù)字越大，證明接收端接收緩沖區(qū)的剩余空間越大，網(wǎng)絡(luò)的吞吐量越大。接收端會在確認(rèn)應(yīng)答發(fā)送ACK報文時，將自己的即時窗口大小填入，并跟隨ACK報文一起發(fā)送過去。而發(fā)送方根據(jù)ACK報文里的窗口大小的值的改變進(jìn)而改變自己的發(fā)送速度。如果接收到窗口大小的值為0，那么發(fā)送方將停止發(fā)送數(shù)據(jù)。并定期的向接收端發(fā)送窗口探測數(shù)據(jù)段，讓接收端把窗口大小告訴發(fā)送端。

image.png

注：16位的窗口大小最大能表示65535個字節(jié)（64K），但是TCP的窗口大小最大并不是64K。在TCP首部中40個字節(jié)的選項中還包含了一個窗口擴(kuò)大因子M，實際的窗口大小就是16為窗口字段的值左移M位。每移一位，擴(kuò)大兩倍。

擁塞控制

TCP傳輸?shù)倪^程中，發(fā)送端開始發(fā)送數(shù)據(jù)的時候，如果剛開始就發(fā)送大量的數(shù)據(jù)，那么就可能造成一些問題。網(wǎng)絡(luò)可能在開始的時候就很擁堵，如果給網(wǎng)絡(luò)中在扔出大量數(shù)據(jù)，那么這個擁堵就會加劇。擁堵的加劇就會產(chǎn)生大量的丟包，就對大量的超時重傳，嚴(yán)重影響傳輸。

所以TCP引入了慢啟動的機制，在開始發(fā)送數(shù)據(jù)時，先發(fā)送少量的數(shù)據(jù)探路。探清當(dāng)前的網(wǎng)絡(luò)狀態(tài)如何，再決定多大的速度進(jìn)行傳輸。這時候就引入一個叫做擁塞窗口的概念。發(fā)送剛開始定義擁塞窗口為 1，每次收到ACK應(yīng)答，擁塞窗口加 1。在發(fā)送數(shù)據(jù)之前，首先將擁塞窗口與接收端反饋的窗口大小比對，取較小的值作為實際發(fā)送的窗口。

擁塞窗口的增長是指數(shù)級別的。慢啟動的機制只是說明在開始的時候發(fā)送的少，發(fā)送的慢，但是增長的速度是非常快的。為了控制擁塞窗口的增長，不能使擁塞窗口單純的加倍，設(shè)置一個擁塞窗口的閾值，當(dāng)擁塞窗口大小超過閾值時，不能再按照指數(shù)來增長，而是線性的增長。在慢啟動開始的時候，慢啟動的閾值等于窗口的最大值，一旦造成網(wǎng)絡(luò)擁塞，發(fā)生超時重傳時，慢啟動的閾值會為原來的一半（這里的原來指的是發(fā)生網(wǎng)絡(luò)擁塞時擁塞窗口的大?。?，同時擁塞窗口重置為 1。

image.png

擁塞控制是TCP在傳輸時盡可能快的將數(shù)據(jù)傳輸，并且避免擁塞造成的一系列問題。是可靠性的保證，同時也是維護(hù)了傳輸?shù)母咝浴?/p>

————————————————

原文鏈接：https://blog.csdn.net/liuchenxia8/article/details/80428157