chinese直男口爆体育生外卖, 99久久er热在这里只有精品99, 又色又爽又黄18禁美女裸身无遮挡, gogogo高清免费观看日本电视,私密按摩师高清版在线,人妻视频毛茸茸,91论坛 兴趣闲谈,欧美 亚洲 精品 8区,国产精品久久久久精品免费

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

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

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

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

454398 ? 來(lái)源:博客園 ? 作者:帥地玩編程 ? 2020-11-03 11:02 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

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

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

一、為何要進(jìn)行擁塞控制?

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

我們知道,兩臺(tái)主機(jī)在傳輸數(shù)據(jù)包的時(shí)候,如果發(fā)送方遲遲沒有收到接收方反饋的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ù)包被堵在了半路,遲遲沒有到達(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ù)包稱之為擁塞窗口,用N代表此時(shí)擁塞窗口的大小吧。

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

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

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

2、一個(gè)一個(gè)增加實(shí)在是太慢了,所以可以剛開始發(fā)送1個(gè),如果沒有發(fā)生超時(shí)時(shí)間,就發(fā)送2個(gè),如果還是沒有發(fā)送超時(shí)事件就發(fā)送4個(gè),接著8個(gè)...,用翻倍的速度類推,即 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ò)快的問題,我們可以把第一種方法和第二種方法結(jié)合起來(lái)。也就是說(shuō),我們剛開始可以以指數(shù)的速度增長(zhǎng),增長(zhǎng)到某一個(gè)值,我們把這個(gè)值稱之為閾值吧,用變量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)階段稱之為慢啟動(dòng),線性增長(zhǎ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的值稱之為瓶頸值吧,用MAX這個(gè)字母來(lái)代替吧,即最大值。

注:這里再次提醒閾值過(guò)后是一個(gè)一個(gè)線性增長(zhǎng),圖中之所以彎曲是因?yàn)槲耶媹D原因?qū)е碌摹?/p>

當(dāng)達(dá)到最大值MAX之后,我們?cè)撛趺崔k呢?

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

我們就回到最初的最初的狀態(tài),也就是說(shuō)從1,2,4,8.....開始,不過(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....卻始終沒有收到M3,這個(gè)時(shí)候就會(huì)重復(fù)確認(rèn)M2,意在告訴A,M3還沒收到,可能是丟失了。

當(dāng)A連續(xù)收到了三個(gè)確認(rèn)M2的ACK,且M3超時(shí)事件還沒發(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)。

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

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

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

    關(guān)注

    1

    文章

    246

    瀏覽量

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

    關(guān)注

    0

    文章

    14

    瀏覽量

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

    關(guān)注

    0

    文章

    28

    瀏覽量

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

    關(guān)注

    22

    文章

    2077

    瀏覽量

    53013
收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評(píng)論

    相關(guān)推薦
    熱點(diǎn)推薦

    AI網(wǎng)絡(luò)管理新范式:精要解讀超以太網(wǎng)聯(lián)盟(UEC)1.0 規(guī)范(2025Q2)

    隨著AI與高性能計(jì)算(HPC)集群對(duì)網(wǎng)絡(luò)帶寬、時(shí)延和擁塞管理的要求日益嚴(yán)苛,傳統(tǒng)以太網(wǎng)在超大規(guī)模場(chǎng)景下面臨瓶頸。為此,超以太網(wǎng)聯(lián)盟(UEC) 在Linux聯(lián)合開發(fā)基金會(huì)(JDF)下成立,致力于構(gòu)建新一代高性能以太網(wǎng)標(biāo)準(zhǔn)。
    的頭像 發(fā)表于 07-11 18:41 ?486次閱讀
    AI<b class='flag-5'>網(wǎng)絡(luò)</b>管理新范式:精要解讀超以太網(wǎng)聯(lián)盟(UEC)1.0 規(guī)范(2025Q2)

    如何用AI負(fù)載為SONiC交換機(jī)調(diào)整ECN水線

    顯式擁塞通知(ECN)是計(jì)算機(jī)網(wǎng)絡(luò)中的一種機(jī)制,它允許發(fā)送設(shè)備明確地通知接收設(shè)備網(wǎng)絡(luò)擁塞,而不是依賴于傳統(tǒng)的“丟包”方法。在傳統(tǒng)的TCP/IP網(wǎng)絡(luò)
    的頭像 發(fā)表于 07-11 14:12 ?1161次閱讀
    如何用AI負(fù)載為SONiC交換機(jī)調(diào)整ECN水線

    RDMA簡(jiǎn)介7之可靠傳輸

    網(wǎng)絡(luò)無(wú)損,需要進(jìn)行嚴(yán)格的流量控制擁塞管理。流量控制指通過(guò)調(diào)整發(fā)送端的發(fā)送速率,確保接收端能夠處理并接收所有數(shù)據(jù)包。RoCE v2使用了IE
    發(fā)表于 06-13 10:01

    如何利用先進(jìn)網(wǎng)絡(luò)技術(shù)實(shí)現(xiàn)可持續(xù)AI云服務(wù)

    隨著 AI 技術(shù)的飛速發(fā)展,企業(yè)對(duì)云網(wǎng)絡(luò)的高性能、低延遲和高可擴(kuò)展性提出了更高的要求。AI 應(yīng)用通常需要兼顧訓(xùn)練與推理,在處理海量數(shù)據(jù)和復(fù)雜的計(jì)算任務(wù)的同時(shí),應(yīng)對(duì)不可預(yù)測(cè)的突發(fā)和局部擁塞,這不僅對(duì)計(jì)算資源提出了挑戰(zhàn),也對(duì)網(wǎng)絡(luò)基礎(chǔ)
    的頭像 發(fā)表于 05-16 10:41 ?469次閱讀
    如何利用先進(jìn)<b class='flag-5'>網(wǎng)絡(luò)</b>技術(shù)實(shí)現(xiàn)可持續(xù)AI云服務(wù)

    使用NXP 88W8801芯片組進(jìn)行iPerf3測(cè)試期間TCP中的周期性丟包現(xiàn)象,怎么解決?

    /secreceiver 帶寬波動(dòng)很大,并且在測(cè)試期間觀察到頻繁的重傳 (Retr)。擁塞窗口 (Cwnd) 也變化很大,表明連接中可能存在不穩(wěn)定。 主要觀察: 帶寬在 ~6.56 Mb/秒和 ~32.3
    發(fā)表于 04-02 06:53

    適用于數(shù)據(jù)中心和AI時(shí)代的800G網(wǎng)絡(luò)

    提出了三大核心需求: 超低延遲和高帶寬:確保大規(guī)模數(shù)據(jù)傳輸高效進(jìn)行。 智能流量調(diào)度:采用自適應(yīng)路由和負(fù)載均衡技術(shù),減少網(wǎng)絡(luò)擁塞。 性能隔離與穩(wěn)定性:在多租戶環(huán)境下保障帶寬分配,防止性能
    發(fā)表于 03-25 17:35

    信而泰PFC/ECN流量測(cè)試方案:打造智能無(wú)損網(wǎng)絡(luò)的關(guān)鍵利器

    導(dǎo)語(yǔ):AI算力爆發(fā)的背后,如何保障網(wǎng)絡(luò)“零丟包”? 在當(dāng)今數(shù)據(jù)中心網(wǎng)絡(luò)中,隨著AI、高性能計(jì)算(HPC)和分布式存儲(chǔ)等應(yīng)用的飛速發(fā)展,網(wǎng)絡(luò)的無(wú)損傳輸能力變得至關(guān)重要。PFC(基于優(yōu)先級(jí)的流量
    的頭像 發(fā)表于 03-13 09:53 ?508次閱讀
    信而泰PFC/ECN流量測(cè)試方案:打造智能無(wú)損<b class='flag-5'>網(wǎng)絡(luò)</b>的關(guān)鍵利器

    STM32F429以太網(wǎng)外設(shè)數(shù)據(jù)處理上限是多少?

    背景:以429作為控制器的板卡處于網(wǎng)絡(luò)交換機(jī)的一個(gè)節(jié)點(diǎn)處,同網(wǎng)段有其他網(wǎng)絡(luò)節(jié)點(diǎn),其他節(jié)點(diǎn)控制器芯片種類為,A核ARM、CPU,因此429是處理性能最差的節(jié)點(diǎn)。 現(xiàn)有方案: 429只與某
    發(fā)表于 03-13 06:52

    TCP協(xié)議的安全性分析

    使用確認(rèn)機(jī)制來(lái)確保數(shù)據(jù)段被正確接收。如果一個(gè)段丟失,發(fā)送方將重新發(fā)送該段。 流量控制 :TCP使用窗口大小來(lái)控制發(fā)送方發(fā)送數(shù)據(jù)的速率,以避免接收方被過(guò)多的數(shù)據(jù)淹沒。 擁塞控制 :TCP
    的頭像 發(fā)表于 01-22 09:48 ?694次閱讀

    百問FB網(wǎng)絡(luò)編程 - 網(wǎng)絡(luò)編程簡(jiǎn)介

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

    VLAN 實(shí)施對(duì)網(wǎng)絡(luò)性能的影響

    的廣播域和沖突域。這樣,網(wǎng)絡(luò)中的廣播流量和沖突就被限制在每個(gè)VLAN內(nèi)部,減少了網(wǎng)絡(luò)擁塞,提高了網(wǎng)絡(luò)的整體性能。 優(yōu)化網(wǎng)絡(luò)流量 VLAN允許
    的頭像 發(fā)表于 11-19 09:35 ?1643次閱讀

    嵌入式學(xué)習(xí)-飛凌嵌入式ElfBoard ELF 1板卡-

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

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

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

    SD-WAN技術(shù)在直播網(wǎng)絡(luò)中如何實(shí)現(xiàn)智能路徑選擇?

    :系統(tǒng)根據(jù)監(jiān)控得到的數(shù)據(jù),評(píng)估每條路徑的質(zhì)量和性能。這些評(píng)估標(biāo)準(zhǔn)可能包括路徑的穩(wěn)定性、歷史性能數(shù)據(jù)以及當(dāng)前的網(wǎng)絡(luò)擁塞情況。 3、策略定義:管理員可以定義網(wǎng)絡(luò)流量的傳輸策略,比如哪些類型
    的頭像 發(fā)表于 09-09 14:39 ?672次閱讀

    INA188為何會(huì)有壓降的情況產(chǎn)生 ?

    我目前使用感測(cè)器的 0~5V 輸出連接到 INA188 的輸入端時(shí)會(huì)有 15mV 的壓降,即全幅輸出 5.000V 會(huì)變成 4.985V,在不接 INA188 時(shí)直接測(cè)量則無(wú) 15mV 的壓降,RG 為 50K 0.1% (放大2倍,使用正負(fù)12V雙電源),請(qǐng)問為何會(huì)有壓降的情況
    發(fā)表于 08-14 07:22