看看共享鏈路上如何擠占帶寬：
如果 B 倔強(qiáng)地也要保住自己在 start 點(diǎn)的 bw 怎么辦？假設(shè) B 確實(shí)通過(guò) inflate inflight 保住了自己原來(lái)的 bw，A 又不服又要搶回來(lái)怎么辦？來(lái)看看這個(gè)過(guò)程：
多流均保帶寬的代價(jià)是高昂的。丟包導(dǎo)致每一個(gè)脈沖的能耗白白浪費(fèi)，而排隊(duì)延時(shí)則意味著存儲(chǔ)器的能耗。保帶寬的結(jié)果，損人不利己，這里就解釋了。
看個(gè)有趣的：Relentless Congestion Control
如果放寬算法的公平性約束，搶帶寬，讓帶寬就自然多了，非常像高速公路的場(chǎng)景了，你想快就快，不太過(guò)分且我也沒(méi)啥急事就讓讓你，當(dāng)然，我也一樣。算法的核心是：
instead of applying a multiplicative reduction to cwnd after a loss, cwnd is reduced by the number of lost segments.
完全基于范雅各布森報(bào)文守恒，精確填充管道：發(fā)出去 a，丟了 b，cwnd = a - b。relentless cc 承認(rèn)自己非標(biāo)：
Relentless Congestion Control conforms to neither the details nor the philosophy of current congestion control standards.
與其它 draft 幾乎無(wú)例外想轉(zhuǎn)正不同，relentless cc 甚至不以標(biāo)準(zhǔn)化為目標(biāo)，只記錄一種可能性：
We are not even planning to standardize it at this time. The goal of the document is to illustrate what new protocol features and properties might be possible if we relax the “TCP-friendly” mandate.
看一下 relentless cc 的工作圖示：
這方式是不是更溫柔呢。
如前述，執(zhí)意保固定帶寬有大代價(jià)，只要?jiǎng)e硬杠，一般不會(huì)有大沖突。流多了就都慢點(diǎn)，自己有需要，隨時(shí) probe，如果大家沒(méi)有特別要緊的事非要給你擠回去，一般都會(huì)默認(rèn)的。relentless cc 只是在不停地執(zhí)行 cwnd = cwnd - losses。
非要硬來(lái)的話(huà)，說(shuō)說(shuō) arq 和 fec，二者結(jié)合效果更好，比方說(shuō)尾部 fec，重傳 fec。fec 就是提前重傳。既然預(yù)測(cè)到丟包率，重傳就是必然的，等到后面實(shí)際丟包(這是必然的)再重傳，不如提前重傳，用 fec 的話(huà)講就是發(fā)送冗余。但由于擁塞丟包本身就是發(fā)送行為的函數(shù)，擁塞 fec 效果未必好(大概率很差)，無(wú)論任何時(shí)候擁塞都要謹(jǐn)慎對(duì)待。
總有人說(shuō)不受控的 udp 要比 tcp 快，其實(shí)一個(gè)優(yōu)秀的 udp-based 協(xié)議并不比 tcp 快，它至少把 tcp 那些東西重新在 udp 上實(shí)現(xiàn)了一遍，比如 quic，最后就成了 yat-yet another tcp 了。但凡為 udp 做加法，只能讓它更慢，但慢并不意味著不好，端到端傳輸協(xié)議要全局看。
作者：dog250
轉(zhuǎn)自：https://blog.csdn.net/dog250/article/details/134322441
該文章在 2024/1/27 16:00:42 編輯過(guò)
400 186 1886
