在线观看www成人影院-在线观看www日本免费网站-在线观看www视频-在线观看操-欧美18在线-欧美1级

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內(nèi)不再提示

為何要進行擁塞控制?如何知道網(wǎng)絡的擁塞情況?

454398 ? 來源:博客園 ? 作者:帥地玩編程 ? 2020-11-03 11:02 ? 次閱讀

大家可能都聽說過擁塞控制和流量控制,想必也有一些人可能還分不清擁塞控制和流量控制,進而把他們當作一回事。擁塞控制和流量控制雖然采取的動作很相似,但擁塞控制與網(wǎng)絡的擁堵情況相關(guān)聯(lián),而流量控制與接收方的緩存狀態(tài)相關(guān)聯(lián)。

也就是說,擁塞控制和流量控制是針對完全不同的問題而采取的措施。今天這篇文章,我們先來講講擁塞控制。

一、為何要進行擁塞控制?

為了方便,我們假設主機A給主機B傳輸數(shù)據(jù)。

我們知道,兩臺主機在傳輸數(shù)據(jù)包的時候,如果發(fā)送方遲遲沒有收到接收方反饋的ACK,那么發(fā)送方就會認為它發(fā)送的數(shù)據(jù)包丟失了,進而會重新傳輸這個丟失的數(shù)據(jù)包。

然而實際情況有可能此時有太多主機正在使用信道資源,導致網(wǎng)絡擁塞了,而A發(fā)送的數(shù)據(jù)包被堵在了半路,遲遲沒有到達B。這個時候A誤認為是發(fā)生了丟包情況,會重新傳輸這個數(shù)據(jù)包。

結(jié)果就是不僅浪費了信道資源,還會使網(wǎng)絡更加擁塞。因此,我們需要進行擁塞控制。

二、如何知道網(wǎng)絡的擁塞情況?

A與B建立連接之后,就可以向B發(fā)送數(shù)據(jù)了,然而這個時候A并不知道此時的網(wǎng)絡擁塞情況如何,也就是說,A不知道一次性連續(xù)發(fā)送多少個數(shù)據(jù)包好,我們也把A一次性連續(xù)發(fā)送多少個數(shù)據(jù)包稱之為擁塞窗口,用N代表此時擁塞窗口的大小吧。

為了探測網(wǎng)絡的擁塞情況,我們可以采取以下兩種策略:

1、先發(fā)送一個數(shù)據(jù)包試探下,如果該數(shù)據(jù)包沒有發(fā)生超時事件(也就是沒有丟包)。那么下次發(fā)送時就發(fā)送2個,如果還是沒有發(fā)生超時事件,下次就發(fā)送3個,以此類推,即N = 1, 2, 3, 4, 5.....

(圖可能畫的不大形象,,,,)

2、一個一個增加實在是太慢了,所以可以剛開始發(fā)送1個,如果沒有發(fā)生超時時間,就發(fā)送2個,如果還是沒有發(fā)送超時事件就發(fā)送4個,接著8個...,用翻倍的速度類推,即 N = 1, 2, 4, 8, 16...

無論是第一種方法還是第二種方法,最后都會出現(xiàn)瓶頸值。不過這里值得注意的是,第一種情況的增長速率確實有點慢,但是第二種情況以指數(shù)增長,增長速度有點太快了,可能一下子就到瓶頸值了。

為了解決這個過慢或過快的問題,我們可以把第一種方法和第二種方法結(jié)合起來。也就是說,我們剛開始可以以指數(shù)的速度增長,增長到某一個值,我們把這個值稱之為閾值吧,用變量ssthresh代替。當增長到閾值時,我們就不在以指數(shù)增長了,而是一個一個線性增長。

所以最終的策略是:前期指數(shù)增長,到達閾值之后,就以一個一個線性的速度來增長。

(注:8之后其實是直線的,那里只是彎曲了一下)

我們也把指數(shù)增長階段稱之為慢啟動,線性增長階段稱之為擁塞避免

三、到了瓶頸值之后怎么辦?

無論是指數(shù)增長還是一個一個增長,最終肯定會出現(xiàn)超時事件,總不可能無限增長吧。當出現(xiàn)超時事件時,我們就認為此時網(wǎng)絡出現(xiàn)了擁塞了,不能再繼續(xù)增長了。我們就把這個時候的N的值稱之為瓶頸值吧,用MAX這個字母來代替吧,即最大值。

注:這里再次提醒閾值過后是一個一個線性增長,圖中之所以彎曲是因為我畫圖原因?qū)е碌摹?/p>

當達到最大值MAX之后,我們該怎么辦呢?

當?shù)竭_最大值之后我們采取的策略是這樣的:

我們就回到最初的最初的狀態(tài),也就是說從1,2,4,8.....開始,不過這個時候我們還會把ssthresh調(diào)小,調(diào)為MAX值的一半,即ssthresh = MAX / 2。

圖中閾值為8,瓶頸值是14;超時事件發(fā)生后,閾值為14 / 2 = 7。

四、超時事件就一定是網(wǎng)絡擁塞?

超時事件發(fā)送就一定是網(wǎng)絡出現(xiàn)了擁堵嗎?其實也有可能不是出現(xiàn)了網(wǎng)絡擁堵,有可能是因為某個數(shù)據(jù)包出現(xiàn)了丟失或者損害了,導致了這個數(shù)據(jù)包超時事件發(fā)生了

為了防止這種情況,我們是通過冗余ACK來處理的。我們都知道,數(shù)據(jù)包是有序號的,如果A給B發(fā)送M1, M2, M3, M4, M5...N個數(shù)據(jù)包,如果B收到了M1, M2, M4....卻始終沒有收到M3,這個時候就會重復確認M2,意在告訴A,M3還沒收到,可能是丟失了。

當A連續(xù)收到了三個確認M2的ACK,且M3超時事件還沒發(fā)生。A就知道M3可能丟失了,這個時候A就不必等待M3設置的計時器到期了,而是快速重傳M3。并且把ssthresh設置為MAX的一半,即ssthresh = MAX/2,但是這個時候并非把控制窗口N設置為1,而是讓N = ssthresh,N在一個一個增長。

我們也把這種情況稱之為快速恢復。而這種具有快速恢復的TCP版本稱之為TCP Reno。

還有另外一種TCP版本,無論是收到三個相同的ACK還是發(fā)生超時事件,都把擁塞窗口的大小設為1,從最初狀態(tài)開始,這種版本的TCP我們稱之為TCP Tahoe。
編輯:hfy

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 緩存
    +關(guān)注

    關(guān)注

    1

    文章

    240

    瀏覽量

    26713
  • 擁塞控制
    +關(guān)注

    關(guān)注

    0

    文章

    14

    瀏覽量

    8498
  • 流量控制
    +關(guān)注

    關(guān)注

    0

    文章

    27

    瀏覽量

    9667
  • 通信網(wǎng)絡
    +關(guān)注

    關(guān)注

    21

    文章

    2043

    瀏覽量

    52110
收藏 人收藏

    評論

    相關(guān)推薦

    百問FB網(wǎng)絡編程 - 網(wǎng)絡編程簡介

    包括了應用層報文劃分為短報文,并提供擁塞控制機制,因此當網(wǎng)絡擁塞時源抑制其傳輸速率。 ?UDP協(xié)議向它的應用程序提供無連接服務。這是一種不提供不必要服務的服務,沒有可靠性,沒有流量
    發(fā)表于 12-04 09:46

    飛凌嵌入式ElfBoard ELF 1板卡-網(wǎng)絡編程示例之網(wǎng)絡基礎知識

    進行流量控制等避免網(wǎng)絡擁塞行為。(3)此外,傳輸途中出現(xiàn)丟包,UDP 也不負責重發(fā)。(4)甚至當包的到達順序出現(xiàn)亂序時也沒有糾正的功能。(5)如果需要以上的細節(jié)
    發(fā)表于 11-09 14:37

    網(wǎng)絡也會堵車?!3大法寶可以搞定它!

    。如果把網(wǎng)絡比作高速公路,數(shù)據(jù)流量比作車流量,那么網(wǎng)絡帶寬等資源和存儲、處理數(shù)據(jù)的能力有限,在出現(xiàn)突發(fā)流量時也會造成網(wǎng)絡擁塞網(wǎng)絡
    的頭像 發(fā)表于 05-21 08:05 ?445次閱讀
    <b class='flag-5'>網(wǎng)絡</b>也會堵車?!3大法寶可以搞定它!

    論TCP協(xié)議中的擁塞控制機制與網(wǎng)絡穩(wěn)定性

    過多的數(shù)據(jù)注入網(wǎng)絡,從而避免網(wǎng)絡擁塞。然而,盡管擁塞控制機制在很大程度上能夠減少網(wǎng)絡
    的頭像 發(fā)表于 04-19 16:42 ?453次閱讀

    星脈網(wǎng)絡深度解析:GOR全鏈路流量規(guī)劃與擁塞控制機制

    AI網(wǎng)絡中的數(shù)據(jù)流就好像拉力賽道上飛馳的賽車,在賽道上高速前進。但是由于賽道的寬度有限,如果一條賽道上同時有多輛賽車,那么賽車就需要降低速度來避免碰撞。
    的頭像 發(fā)表于 04-06 04:44 ?1695次閱讀
    星脈<b class='flag-5'>網(wǎng)絡</b>深度解析:GOR全鏈路流量規(guī)劃與<b class='flag-5'>擁塞</b><b class='flag-5'>控制</b>機制

    以太網(wǎng)存儲網(wǎng)絡擁塞管理連載案例(七)

    學習連接到遠程 VTEP 的設備的 MAC 地址有兩種常見方法。第一種方法使用基于組播的泛洪學習機制。
    的頭像 發(fā)表于 03-08 09:29 ?890次閱讀
    以太網(wǎng)存儲<b class='flag-5'>網(wǎng)絡</b>的<b class='flag-5'>擁塞</b>管理連載案例(七)

    以太網(wǎng)存儲網(wǎng)絡擁塞管理連載案例(六)

    消除或減少無損以太網(wǎng)網(wǎng)絡擁塞的高級方法與光纖通道結(jié)構(gòu)相同。幾十年來,不同的傳輸類型都采用了類似的方法,只是略有不同。
    的頭像 發(fā)表于 03-06 16:35 ?1011次閱讀
    以太網(wǎng)存儲<b class='flag-5'>網(wǎng)絡</b>的<b class='flag-5'>擁塞</b>管理連載案例(六)

    以太網(wǎng)存儲網(wǎng)絡擁塞管理連載案例(五)

    解決無損以太網(wǎng)網(wǎng)絡擁塞問題的方法與光纖通道結(jié)構(gòu)相同。兩者都使用逐跳流量控制機制,只是實現(xiàn)方式不同而已。
    的頭像 發(fā)表于 03-04 11:17 ?899次閱讀
    以太網(wǎng)存儲<b class='flag-5'>網(wǎng)絡</b>的<b class='flag-5'>擁塞</b>管理連載案例(五)

    以太網(wǎng)存儲網(wǎng)絡中的擁塞控制與管理策略

    當出口隊列利用率超過上升閾值時,Cisco Nexus 9000 交換機可檢測到微突發(fā)。當隊列利用率低于下降閾值時,微突發(fā)結(jié)束。根據(jù)交換機型號的不同,本文撰寫時的最小微突發(fā)粒度為 0.64 微秒,持續(xù)時間為 73 微秒。
    發(fā)表于 02-29 09:09 ?737次閱讀
    以太網(wǎng)存儲<b class='flag-5'>網(wǎng)絡</b>中的<b class='flag-5'>擁塞</b><b class='flag-5'>控制</b>與管理策略

    以太網(wǎng)存儲網(wǎng)絡擁塞管理連載方案(二)

    本節(jié)將從學術(shù)角度解釋如何計算無損以太網(wǎng)鏈路的headroom大小。該解釋基于 IEEE 802.1Qbb 優(yōu)先級流量控制標準。
    的頭像 發(fā)表于 02-27 09:12 ?1251次閱讀
    以太網(wǎng)存儲<b class='flag-5'>網(wǎng)絡</b>的<b class='flag-5'>擁塞</b>管理連載方案(二)

    以太網(wǎng)存儲網(wǎng)絡擁塞管理連載方案(一)

    鏈路級流量控制(LLFC):LLFC 可在直接連接的設備之間對鏈路上的所有流量進行流量控制。LLFC 是一項 IEEE 標準(IEEE 802.3x)。
    的頭像 發(fā)表于 02-26 10:52 ?1389次閱讀
    以太網(wǎng)存儲<b class='flag-5'>網(wǎng)絡</b>的<b class='flag-5'>擁塞</b>管理連載方案(一)

    TCP協(xié)議技術(shù)之擁塞控制算法

    擁塞控制是在網(wǎng)絡層和傳輸層進行的功能。在網(wǎng)絡層,擁塞控制
    的頭像 發(fā)表于 02-03 17:06 ?2329次閱讀
    TCP協(xié)議技術(shù)之<b class='flag-5'>擁塞</b><b class='flag-5'>控制</b>算法

    TCP協(xié)議技術(shù)之自適應重傳

    自適應重傳是TCP協(xié)議中的一種擁塞控制機制,旨在通過智能的方式處理網(wǎng)絡擁塞,并進行相應的數(shù)據(jù)重傳,以提高
    的頭像 發(fā)表于 02-03 17:03 ?1576次閱讀
    TCP協(xié)議技術(shù)之自適應重傳

    一文詳解DCQCN擁塞控制算法

    DCQCN 是一種基于速率的端到端擁塞協(xié)議,它建立在 QCN 和 DCTCP 之上。DCQCN 的大部分功能是現(xiàn)在網(wǎng)卡上(而不是交換機上,或者操作系統(tǒng)上)。
    發(fā)表于 01-23 10:48 ?6822次閱讀
    一文詳解DCQCN<b class='flag-5'>擁塞</b><b class='flag-5'>控制</b>算法

    請問TCP擁塞控制對數(shù)據(jù)延遲有何影響?

    今天分享一篇文章,是關(guān)于 TCP 擁塞控制對數(shù)據(jù)延遲產(chǎn)生的影響的。作者在服務延遲變高之后進行抓包分析,結(jié)果發(fā)現(xiàn)時間花在了 TCP 本身的機制上面:客戶端并不是將請求一股腦發(fā)送給服務端,而是只發(fā)送
    的頭像 發(fā)表于 01-19 09:44 ?631次閱讀
    請問TCP<b class='flag-5'>擁塞</b><b class='flag-5'>控制</b>對數(shù)據(jù)延遲有何影響?
    主站蜘蛛池模板: 视频在线视频免费观看| 777色淫网站女女免费| 一级黄色免费毛片| 九九热在线视频观看| 超级黄色毛片| 精品一区二区三区自拍图片区| 午夜色福利| 久久精品第一页| 视频在线视频免费观看| 黄色在线视频网| 操天天| 日日夜夜狠狠| 国内精品网站| 人人干国产| 手机在线看片国产日韩生活片| 成年人看的毛片| 午夜视频在线播放| 米奇精品一区二区三区| 日本xxxxxx69| 精品热99| 男女交性永久免费视频播放| 3344成年在线视频免费播放男男| 欧美经典三级春潮烂漫海棠红| 13日本xxxxxxxxx18| 男女互插小说| 四虎影午夜成年免费精品| 午夜女上男下xx00xx00动态| 日韩黄色免费| 国产欧美色图| 末满18以下勿进色禁网站| 男人女人真曰批视频播放| 狠狠色噜噜狠狠狠狠888奇米| 手机在线黄色| 九九色网站| 天天色天天操综合网| 日本女人啪啪| 伊人久久大香线蕉影院95| 伊人网色| 日本午夜大片a在线观看| 日本网站免费| 丁香婷婷视频|