大家可能都聽(tīng)說(shuō)過(guò)擁塞控制和流量控制,想必也有一些人可能還分不清擁塞控制和流量控制,進(jìn)而把他們當(dāng)作一回事。擁塞控制和流量控制雖然采取的動(dòng)作很相似,但擁塞控制與網(wǎng)絡(luò)的擁堵情況相關(guān)聯(lián),而流量控制與接收方的緩存狀態(tài)相關(guān)聯(lián)。
也就是說(shuō),擁塞控制和流量控制是針對(duì)完全不同的問(wèn)題而采取的措施。今天這篇文章,我們先來(lái)講講擁塞控制。
一、為何要進(jìn)行擁塞控制?
為了方便,我們假設(shè)主機(jī)A給主機(jī)B傳輸數(shù)據(jù)。
我們知道,兩臺(tái)主機(jī)在傳輸數(shù)據(jù)包的時(shí)候,如果發(fā)送方遲遲沒(méi)有收到接收方反饋的ACK,那么發(fā)送方就會(huì)認(rèn)為它發(fā)送的數(shù)據(jù)包丟失了,進(jìn)而會(huì)重新傳輸這個(gè)丟失的數(shù)據(jù)包。
然而實(shí)際情況有可能此時(shí)有太多主機(jī)正在使用信道資源,導(dǎo)致網(wǎng)絡(luò)擁塞了,而A發(fā)送的數(shù)據(jù)包被堵在了半路,遲遲沒(méi)有到達(dá)B。這個(gè)時(shí)候A誤認(rèn)為是發(fā)生了丟包情況,會(huì)重新傳輸這個(gè)數(shù)據(jù)包。
結(jié)果就是不僅浪費(fèi)了信道資源,還會(huì)使網(wǎng)絡(luò)更加擁塞。因此,我們需要進(jìn)行擁塞控制。
二、如何知道網(wǎng)絡(luò)的擁塞情況?
A與B建立連接之后,就可以向B發(fā)送數(shù)據(jù)了,然而這個(gè)時(shí)候A并不知道此時(shí)的網(wǎng)絡(luò)擁塞情況如何,也就是說(shuō),A不知道一次性連續(xù)發(fā)送多少個(gè)數(shù)據(jù)包好,我們也把A一次性連續(xù)發(fā)送多少個(gè)數(shù)據(jù)包稱(chēng)之為擁塞窗口,用N代表此時(shí)擁塞窗口的大小吧。
為了探測(cè)網(wǎng)絡(luò)的擁塞情況,我們可以采取以下兩種策略:
1、先發(fā)送一個(gè)數(shù)據(jù)包試探下,如果該數(shù)據(jù)包沒(méi)有發(fā)生超時(shí)事件(也就是沒(méi)有丟包)。那么下次發(fā)送時(shí)就發(fā)送2個(gè),如果還是沒(méi)有發(fā)生超時(shí)事件,下次就發(fā)送3個(gè),以此類(lèi)推,即N = 1, 2, 3, 4, 5.....
(圖可能畫(huà)的不大形象,,,,)
2、一個(gè)一個(gè)增加實(shí)在是太慢了,所以可以剛開(kāi)始發(fā)送1個(gè),如果沒(méi)有發(fā)生超時(shí)時(shí)間,就發(fā)送2個(gè),如果還是沒(méi)有發(fā)送超時(shí)事件就發(fā)送4個(gè),接著8個(gè)...,用翻倍的速度類(lèi)推,即 N = 1, 2, 4, 8, 16...
無(wú)論是第一種方法還是第二種方法,最后都會(huì)出現(xiàn)瓶頸值。不過(guò)這里值得注意的是,第一種情況的增長(zhǎng)速率確實(shí)有點(diǎn)慢,但是第二種情況以指數(shù)增長(zhǎng),增長(zhǎng)速度有點(diǎn)太快了,可能一下子就到瓶頸值了。
為了解決這個(gè)過(guò)慢或過(guò)快的問(wèn)題,我們可以把第一種方法和第二種方法結(jié)合起來(lái)。也就是說(shuō),我們剛開(kāi)始可以以指數(shù)的速度增長(zhǎng),增長(zhǎng)到某一個(gè)值,我們把這個(gè)值稱(chēng)之為閾值吧,用變量ssthresh代替。當(dāng)增長(zhǎng)到閾值時(shí),我們就不在以指數(shù)增長(zhǎng)了,而是一個(gè)一個(gè)線性增長(zhǎng)。
所以最終的策略是:前期指數(shù)增長(zhǎng),到達(dá)閾值之后,就以一個(gè)一個(gè)線性的速度來(lái)增長(zhǎng)。
(注:8之后其實(shí)是直線的,那里只是彎曲了一下)
我們也把指數(shù)增長(zhǎng)階段稱(chēng)之為慢啟動(dòng),線性增長(zhǎng)階段稱(chēng)之為擁塞避免
三、到了瓶頸值之后怎么辦?
無(wú)論是指數(shù)增長(zhǎng)還是一個(gè)一個(gè)增長(zhǎng),最終肯定會(huì)出現(xiàn)超時(shí)事件,總不可能無(wú)限增長(zhǎng)吧。當(dāng)出現(xiàn)超時(shí)事件時(shí),我們就認(rèn)為此時(shí)網(wǎng)絡(luò)出現(xiàn)了擁塞了,不能再繼續(xù)增長(zhǎng)了。我們就把這個(gè)時(shí)候的N的值稱(chēng)之為瓶頸值吧,用MAX這個(gè)字母來(lái)代替吧,即最大值。
注:這里再次提醒閾值過(guò)后是一個(gè)一個(gè)線性增長(zhǎng),圖中之所以彎曲是因?yàn)槲耶?huà)圖原因?qū)е碌摹?/p>
當(dāng)達(dá)到最大值MAX之后,我們?cè)撛趺崔k呢?
當(dāng)?shù)竭_(dá)最大值之后我們采取的策略是這樣的:
我們就回到最初的最初的狀態(tài),也就是說(shuō)從1,2,4,8.....開(kāi)始,不過(guò)這個(gè)時(shí)候我們還會(huì)把ssthresh調(diào)小,調(diào)為MAX值的一半,即ssthresh = MAX / 2。
圖中閾值為8,瓶頸值是14;超時(shí)事件發(fā)生后,閾值為14 / 2 = 7。
四、超時(shí)事件就一定是網(wǎng)絡(luò)擁塞?
超時(shí)事件發(fā)送就一定是網(wǎng)絡(luò)出現(xiàn)了擁堵嗎?其實(shí)也有可能不是出現(xiàn)了網(wǎng)絡(luò)擁堵,有可能是因?yàn)槟硞€(gè)數(shù)據(jù)包出現(xiàn)了丟失或者損害了,導(dǎo)致了這個(gè)數(shù)據(jù)包超時(shí)事件發(fā)生了
為了防止這種情況,我們是通過(guò)冗余ACK來(lái)處理的。我們都知道,數(shù)據(jù)包是有序號(hào)的,如果A給B發(fā)送M1, M2, M3, M4, M5...N個(gè)數(shù)據(jù)包,如果B收到了M1, M2, M4....卻始終沒(méi)有收到M3,這個(gè)時(shí)候就會(huì)重復(fù)確認(rèn)M2,意在告訴A,M3還沒(méi)收到,可能是丟失了。
當(dāng)A連續(xù)收到了三個(gè)確認(rèn)M2的ACK,且M3超時(shí)事件還沒(méi)發(fā)生。A就知道M3可能丟失了,這個(gè)時(shí)候A就不必等待M3設(shè)置的計(jì)時(shí)器到期了,而是快速重傳M3。并且把ssthresh設(shè)置為MAX的一半,即ssthresh = MAX/2,但是這個(gè)時(shí)候并非把控制窗口N設(shè)置為1,而是讓N = ssthresh,N在一個(gè)一個(gè)增長(zhǎng)。
我們也把這種情況稱(chēng)之為快速恢復(fù)。而這種具有快速恢復(fù)的TCP版本稱(chēng)之為T(mén)CP Reno。
還有另外一種TCP版本,無(wú)論是收到三個(gè)相同的ACK還是發(fā)生超時(shí)事件,都把擁塞窗口的大小設(shè)為1,從最初狀態(tài)開(kāi)始,這種版本的TCP我們稱(chēng)之為T(mén)CP Tahoe。
編輯:hfy
-
緩存
+關(guān)注
關(guān)注
1文章
245瀏覽量
27048 -
擁塞控制
+關(guān)注
關(guān)注
0文章
14瀏覽量
8558 -
流量控制
+關(guān)注
關(guān)注
0文章
28瀏覽量
9774 -
通信網(wǎng)絡(luò)
+關(guān)注
關(guān)注
21文章
2074瀏覽量
52779
發(fā)布評(píng)論請(qǐng)先 登錄
如何利用先進(jìn)網(wǎng)絡(luò)技術(shù)實(shí)現(xiàn)可持續(xù)AI云服務(wù)

使用NXP 88W8801芯片組進(jìn)行iPerf3測(cè)試期間TCP中的周期性丟包現(xiàn)象,怎么解決?
適用于數(shù)據(jù)中心和AI時(shí)代的800G網(wǎng)絡(luò)
信而泰PFC/ECN流量測(cè)試方案:打造智能無(wú)損網(wǎng)絡(luò)的關(guān)鍵利器

評(píng)論