6、擁塞控制
6.1、擁塞控制概述
擁塞:當對網(wǎng)絡(luò)資源的需求超過了現(xiàn)有的資源的可用部分。
擁塞出現(xiàn)的原因:
1.鏈路容量不夠大,在鏈路上形成堆積,路由器一直是高負荷運轉(zhuǎn)。
2.路由器緩存不夠大,交來的數(shù)據(jù)太多遠遠超過了處理的速度就會在路由器緩存形成堆積,堆不下的就丟失了。
3.處理機太慢了。
網(wǎng)絡(luò)擁塞往往是多種原因的,僅僅增加網(wǎng)絡(luò)資源有可能適得其反。比如說增大路由器的緩存但并未增加鏈路帶寬和處理機速度會導致排隊時間更長一旦用TCP報文傳輸那么大量的超時重傳會引發(fā)更嚴重的問題。提高處理機的速度也不行因為你會把巨大的壓力施加給下一跳。需要耗費大量的資源。
6.2、擁塞控制與流量控制
1.流量控制是點到點的,擁塞控制是全局性網(wǎng)絡(luò)的。
2.擁塞控制是防止過多數(shù)據(jù)注入到網(wǎng)絡(luò),控制發(fā)送速率這又與流量控制有些相似。
3.流量控制是發(fā)送緩存與接收緩存的問題,擁塞控制是網(wǎng)絡(luò)的問題。
6.3、擁塞控制的原理
1.開環(huán)控制方法:在設(shè)計網(wǎng)絡(luò)時考慮發(fā)生擁塞的因素,力求網(wǎng)絡(luò)不發(fā)生擁塞。
2.閉環(huán)控制方法:
基于反饋環(huán)路的概念:
?檢測網(wǎng)絡(luò)系統(tǒng)以便檢測到擁塞在何時何地發(fā)生;
?將擁塞發(fā)生的信息傳送到可采取行動的地方;
?調(diào)整網(wǎng)絡(luò)系統(tǒng)的運行已解決出現(xiàn)的問題。
6.4、擁塞出現(xiàn)的指標
1.由于緩沖區(qū)不夠而造成的分組丟失的百分數(shù)。
2.平均隊列長度。
3.超時重傳的分組數(shù)。
4.平均分組時延。
5.平均分組時延標準差。
一旦檢測到了擁塞會向源站發(fā)送擁塞信息。
6.5、擁塞通知的傳遞
IP中tos字段00表示不支持ECN傳輸,01或10表示支持ECN傳輸,11表示產(chǎn)生擁塞。接收端知道產(chǎn)生擁塞后將TCP報文首部中的ECE置為1告訴源端減小發(fā)送速率,源端降低速率后下一次發(fā)送報文TCP中的CWR置為1降低擁塞窗口(發(fā)送窗口是受對方接收窗口和擁塞窗口控制的)。
6.6、TCP擁塞控制方法
TCP采用基于窗口的方法進行擁塞控制,該方法屬于閉環(huán)控制方法。TCP發(fā)送方維持一個擁塞窗口,擁塞窗口根據(jù)網(wǎng)絡(luò)的擁塞程度動態(tài)的變化。發(fā)送端利用擁塞窗口根據(jù)擁塞情況調(diào)整發(fā)送的數(shù)據(jù)量若網(wǎng)絡(luò)沒有擁塞則增大窗口讓他多發(fā)數(shù)據(jù)提高網(wǎng)絡(luò)利用率。所以真正發(fā)送窗口的值為接收窗口值和擁塞窗口值的最小值。
現(xiàn)在我們假設(shè)對方接收緩存無限大僅考慮網(wǎng)絡(luò)問題探討一下TCP的擁塞控制算法。
6.6.1、慢開始算法
目的:用來探測網(wǎng)絡(luò)的負載或者承受能力。
算法思路:由小到大逐漸增大擁塞窗口,當自己主機剛連進網(wǎng)絡(luò)時如果一下注入太多資源可能造成網(wǎng)絡(luò)擁塞,因此循序漸進的探測網(wǎng)絡(luò)的擁塞程度。每收到一個確認報文擁塞窗口就增加一個報文段。
發(fā)送方每接收到一個確認報文就將擁塞窗口增加一個報文段。如圖所示我們可以看出發(fā)送一個收到一個確認下次發(fā)兩個,收到兩個確認下次發(fā)2+2=4個收到4個確認下次發(fā)4+4等于8個由此可見慢開始算法并不慢。
慢開始門限ssthresh(狀態(tài)變量)防止擁塞窗口cwnd增長過大引起網(wǎng)絡(luò)擁塞。
?當cwnd ?當cwnd>sshresh,停止使用慢開始算法而使用擁塞避免方法。 ?當cwnd = sshresh時既可以使用慢開始算法也可以使用擁塞避免算法。 擁塞避免算法:每經(jīng)過一個RTT,cwnd = cwnd + 1,他的增長是線性的。 當出現(xiàn)網(wǎng)絡(luò)擁塞時,ssthresh = max(cwnd/2,2);cwnd = 1;執(zhí)行慢開始算法。 目的:迅速減少網(wǎng)絡(luò)中的分組數(shù),有利于路由器將積壓的分組處理完。 6.6.2、擁塞控制流程 ?0~1執(zhí)行慢開始算法擁塞窗口呈指數(shù)級增大。 ?1~2達到慢開始門限時執(zhí)行擁塞避免算法擁塞窗口呈線性增大。 ?2~3超時重傳可能出現(xiàn)網(wǎng)絡(luò)擁塞執(zhí)行將擁塞窗口置1重新執(zhí)行慢開始算法。 ?34同12 ?4~5中間出現(xiàn)報文丟失收到3個確認報文執(zhí)行快重傳 6.6.3、快重傳 快重傳算法要求接收方不要等待自己發(fā)送數(shù)據(jù)時才進行捎帶確認,而是要立即發(fā)送確認,即使收到了失序的報文也要立即發(fā)出對已收到的報文段的重復確認。發(fā)送方只需要一連收到3個重復確認就立即重傳這樣就不會出現(xiàn)超時。 當我發(fā)送M3時發(fā)生了報文丟失按理說我應(yīng)該等超時之后再重新發(fā)送。但是這樣做有可能導致誤會這時候網(wǎng)絡(luò)可能沒有發(fā)生擁塞。當M3丟失后接收方發(fā)送已接收報文的重復確認即M2當M2重復確認3次M3立即重傳??熘貍魉惴梢宰尠l(fā)送方盡早知道報文發(fā)生了丟失。這樣就不會超時,就不會讓對方誤以為發(fā)生了擁塞。 6.6.4、快恢復算法 ?當發(fā)送端收到連續(xù)3個重復確認時,發(fā)送方認為網(wǎng)絡(luò)很可能沒有發(fā)生阻塞,因此不執(zhí)行慢開始算法,而是執(zhí)行快恢復算法; ?ssthresh = cwnd/2; ?新?lián)砣翱赾wnd = ssthresh; ?開始執(zhí)行擁塞避免算法,使擁塞窗口緩慢地線性增大。
-
緩沖區(qū)
+關(guān)注
關(guān)注
0文章
36瀏覽量
9362 -
TCP
+關(guān)注
關(guān)注
8文章
1402瀏覽量
80918 -
UDP
+關(guān)注
關(guān)注
0文章
330瀏覽量
34607
發(fā)布評論請先 登錄
第16章 UDP用戶數(shù)據(jù)報協(xié)議基礎(chǔ)知識
tcp和udp協(xié)議的異同

TCP/UDP網(wǎng)絡(luò)編程的基礎(chǔ)知識合集1
TCP/UDP網(wǎng)絡(luò)編程的基礎(chǔ)知識合集2
TCP/UDP網(wǎng)絡(luò)編程的基礎(chǔ)知識合集3

評論