QUIC with CUBIC or BBR

最新推荐文章于 2024-07-02 16:48:22 发布
最新推荐文章于 2024-07-02 16:48:22 发布
阅读量1.8k 收藏 21
点赞数 21
文章标签： 智能路由器
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Xuesengxinyi/article/details/135980307
版权

拥塞控制

拥塞控制算法是 TCP/QUIC 协议的一个基础部分，多年来经过一个个版本的迭代（如 Tahoe、Reno、Vegas 等），拥塞控制算法得到了持续的提升。由于篇幅有限，本文就目前比较流行的两种拥塞控制算法（CUBIC，BBR)，也是 MSQUIC 目前支持的拥塞控制算法进行介绍。

太多太快的分组（包含着 TCP 段以及 UDP 数据报等) 需要网络传输，超过网络 (具体来可能是部分节点、链路) 的处理能力，网络中的某个(某些)路由器队列溢出，开始丢弃分组。 从源端的角度来看:

  • 分组丢失，源端超时了
  • 在源端，收到某 TCP 段的多个冗余ACK
  • 延迟增加
  • 拥塞情况加速变坏
  • 不加控制网络将无法使用

CUBIC 拥塞控制思路

CUBIC 是一种拥塞控制协议。TCP CUBIC 版本目前已经作为默认的拥塞控制算法被应用在 linux/unix 系统中，微软在 Win10/Windows Server 2019 系统也对 CUBIC 做了支持。CUBIC 的提出得益于当今通信链路往往具有越来越高的带宽水平这一事实。在由高带宽链路组成的网络中，缓慢增加传输速率的拥塞控制算法可能最终会浪费链路的容量。CUBIC 改变了现有 TCP 标准中的线性拥塞窗口增长函数为三次函数，以提高 TCP 在快速和长距离网络上的可扩展性。它还通过使窗口增长独立

最低0.47元/天 解锁文章
Thiac
关注
Facebook：对比COPA 与CUBIC，BBR v1在拥塞控制及视频质量的表现
LiveVideoStack
11-26 1605
Facebook的测试结果显示，COPA较于常用算法CUBIC及BBR v1存在一定优势，来看看具体表现。文 / Nitin Garg译 / Adrian Ng原文 ht...
BBR算法原理与实现深度解析
最新发布
程序猿老樊的博客
03-31 1193
BBR算法通过重新定义拥塞控制的基本范式，为现代网络应用提供了突破性的解决方案。随着QUIC协议的普及和智能网卡技术的发展，BBR类算法将在边缘计算、云游戏、工业物联网等领域发挥更重要的作用。
TCP拥塞控制
qq_35293054的博客
07-31 178
如果收到三次重复确认，Reno算法则进入快速重传，只将拥塞窗口减半来跳过慢启动阶段，将慢启动阈值设为当前新的拥塞窗口值，进入一个称为“快速恢复”的新设计阶段。发出的数据包得不到确认，可能是延时也可能是丢包，因此等待一段（RTO）时间开始重传数据包，这种重传我们称为超时重传。当接收方发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速地重传，不必等待超时再重传。但是并能避免网络的中发生拥塞。拥塞窗口 cwnd是发送方维护的一个 的状态变量，它会根据网络的拥塞程度动态变化。
1、Ubuntu22.04开启BBR拥塞控制算法
m0_63008237的博客
02-09 8475
1、Ubuntu22.04开启BBR拥塞控制算法
TCP cubic算法和bbr算法
sinat_32152141的博客
03-25 2010
前段时间调试网络相关的功能时发现，在一定的丢包率情况下，使用tcp bbr算法比cubic算法有更好的网络传输表现（拉流更顺畅）。本文仅仅记录一次网络调试经验以及网上查找的一些结论性的内容。对于两种tcp拥塞控制算法的具体实现不做深究，更多的是了解两种算法的表现情况及使用场景。
CUBIC与BBR在广域网中间的竞争
weixin_41820355的博客
09-13 1303
这篇文章主要了描述BBR和CUBIC竞争时会出现的状况的仿真情况，以及会出现这种状况的原因。 首先这里看到仿真的结论：当缓冲区很小时，bbr能够占据优势；而当缓冲区很大时，cubic能占据优势。也就是说，当bbr与cubic发生竞争，能够决定哪一种拥塞控制能够占据优势的因素是缓冲区的大小。 深究为什么会出现这种情况，应该从BBR和CUBIC的原理讲起。 先看到CUBIC。 CUBIC的核心思想是对对窗口可能的最大值进行二分查找。当前链路在网络上因为排队而发生丢包时，链路的当前最佳拥塞窗口肯定是小于丢包时的
cubic与bbr性能实测
大厂经验交流地
04-04 6090
自1988年第一代TCP算法Tahoe诞生依赖，相继出现了reno、new reno、sacks、cubic、bbr等多种拥塞控制算法，在较常见的有reno、cubic以及linux 4.9以上内核搭载的bbr算法，在ubuntu 16.04包括之前的系统版本之前，默认使用cubic算法，在19.04之后的版本已经切换为默认bbr算法了，以这两大经典算法为例，分析一下优劣。 1.cubic 谈到c...
cubic 相比 bbr 并非很糟糕
TCP/IP
05-11 3万+
” 来优化吞吐，另一方面，丢包恢复后，cwnd 起点低，不要试图加速 ai 过程来优化吞吐，因为这同样破坏了 aimd 内核。如果你想提高上限，就要减小 a，但 a 是针对 tcp 的，所以，若要提高上限，必须往协议头里加东西，至于下限，无底线，有空比试比试看谁的吞吐低，但稳定。如果只 mark lost 了一个报文，prr 只将 cwnd 拉低一点点，如果继续 mark lost，则继续 prr 降 cwnd，这样就将丢包数量和丢包频度和 prr 过程关联起来，至于 ‘足够’ 是多少，调参。
CUBIC与BBR拥塞算法的仿真对比
weixin_41820355的博客
11-23 3953
写在前面 之前其实写过一篇类似文章，也是有关于CUBIC与BBR算法的比较。但是那一篇文章大多是比较感性的探讨，并没有仿真数据作为支撑。所以这里我将会结合数据对CUBIC与BBR的公平性进行探讨。 （万分感谢@Soonyang Zhang学长的ns3相关源码） 公平性探究 在点对点通信的情况下，我将公平性探究分为三个部分。第一种是所有流都为CUBIC流，第二种是所有的流都为BBR流，第三种是CUBIC流与BBR流混合。 仅CUBIC 在所有的流都为CUBIC流的情况下，公平性如图所示： CUBIC的收敛性
如何在ns中基于quic协议构建一套模拟不同拥塞控制算法（如BBR\CUBIC等）加持下多流竞争的通信系统
10-11
在Node.js (Node.js) 中，利用QUIC协议（Quick UDP Internet Connections）构建一个支持多种拥塞控制算法（比如BBR（Bottleneck Bandwidth and Round Trip Time）、CUBIC（Congestion Control Based on ...
深入解析QUIC协议
Pano2019的博客
01-06 1879
QUIC(Quick UDP Internet Connection)是Google提出的一个基于UDP的传输协议，因其高效的传输效率和多路并发的能力，已经成为下一代互联网协议HTTP/3的底层传输协议。除了应用于Web领域，它的优势同样适用于一些通用的需要低延迟、高吞吐特性的传输场景。本文从QUIC的由来和优势出发，分享实际项目中需要考虑的问题和解决思路，通过测试对比QUIC和TCP的实际传输能力，希望有助于大家理解和实践QUIC协议。 PART 01 为什么需要QUIC？ 众所周知，HTTP从最初的H
QUIC BBR Cubic 效果对比【有线场景】
chuanglan的专栏
06-18 2549
TCP 在较高丢包率场景不能较好的工作，因此对比试验不包含 TCP，只对比 QUIC-cubic 和 QUIC BBR 在 不同丢包率、延时场景下的上传时长（单位：秒），上传文件大小为 7.6M，网络环境为北京7层办公室有线网络。 实验数据分析： 1、根据实验 1，未设置丢包模拟时，quic bbr 的稳定性和上传速度均好于 quic cubic； 2、根据实验 2，在丢包率和延时均增大时，quic bbr 和 quic cubic 表现均变差，但前者的稳定性和速度仍优于后者 3、对比实验 2 和实验 4
流媒体弱网优化之路(BBR算法应用)——QUIC-BBR算法代码分析
qw225967的博客
08-16 1256
本文简单介绍了quiche中，BBR-V1的实现主流程，还有很多细节没有详细介绍。在quic的BBR算法中，思想主要集中在对整个传输链路承载能力的检测，重点是采样检测而非GCC逻辑中的预估。这两种思想的不同也造就了BBR算法相比GCC算法更主动，在带宽抢占中更有野性。同时，BBR中比较关键的点是保证采样的可靠性，因此使用什么类型的滤波、回归算法也是BBR可靠性很重要的一部分。后续我们将会对这些算法进行更深入的了解。
bbr 和 cubic 的共存
TCP/IP
07-02 2万+
bbr 流多，虽可从持续减少的 cubic 方 probe 一些带宽，但所有 bbr 的同步 probertt 及自己的 cwnd gain(量多，值就小了，很容易被限制在很小的buffer)会限制甚至反制 in-flight，如果相反，bbr 少，cubic 多就不同，大量异步 aimd 造成统计波动平稳(平方反比律还记得吗)，minrtt 不会减少，而 maxbw 在 mi probe 中纯增加，bbr 带宽持续攀爬向上。时间长河中，一切现状都是历史在叠加，这就是卷积，而另一方面，如本文所描述的模型。
BBR 会取代 CUBIC 吗?
TCP/IP
08-27 1万+
CUBIC 收敛成本随着数量的降低而降低，打个比方，Buffer 大小为 b，N 条 CUBIC 流时，每条流在平均占据 b/N Buffer 时便会收敛，随着 N 的减少，收敛时 Buffer 占据变多了。但 BBR 不同，BBR 是另一回事，所以事情就不会那么简单。BBR 那边的收益在不断减少，CUBIC 这边反而逐渐扳回，总能达到一个平衡点，CUBIC 不再切 BBR，BBR 也不会回退到 CUBIC。跟同事聊到一个 issue，看了篇论文，周末了，开始写点东西，本文形而上，不过也是经过了些思考。..
TCP BBR算法与Reno/CUBIC的对比
热门推荐
TCP/IP
10-29 4万+
我一再强调，BBR算法是个分界点，所有的TCP拥塞控制算法，被分为BBR之前和BBR之后的(其实发现，这并不是我个人的观点，很多人都这么认为，所有想写本文探个究竟)。当然这里的”所有“并不包括封闭的那些算法，比如垃圾公司Appex的算法，或者伟大的垃圾微软的算法。任何的算法都内含了一个进化的过程，CUBIC和Reno看起来非常不同，但是却属于同一个思想，因此可以说，CUBIC是Reno的高级版本，
QUIC BBR Cubic 效果对比【无线场景】
chuanglan的专栏
06-18 2680
【兄弟篇：有线场景下的对比】 TCP 在较高丢包率场景不能较好的工作，因此对比试验不包含 TCP，只对比 QUIC-cubic 和 QUIC BBR 在不同丢包率、延时场景下的上传时长（单位：秒），上传文件大小为 7.6M，网络环境为办公室无线网络，测试机器为 17 款 MacBook pro 13-inch。 实验数据分析： 1、在无丢包且延时小于 10ms 场景下，bbr 相比 cubic 并不占优势； 2、根据实验 3，在无丢包、高延时场景下，bbr 与 cubic 都变得较差，但 bbr 较好于 c
从CUBIC/BBR的TCP ACK失速说起
TCP/IP
04-29 7521
上周有同事问，延迟ACK到底对应用层会产生什么后果，我也不知道该如何作答，于是丢了一个链接： TCP之Delay ACK在Linux和Windows上实现的异同-Linux的自适应ACK：https://blog.csdn.net/dog250/article/details/52664508 是的，这是我几年前关于Delay ACK的分析，如今看来有些许不足，有些空洞，有些学院派，所以本文试...
test quic bbr on ns3
u010643777的专栏
06-03 1855
You can’t have your cake and eat it.  The network congestion control mechanism is the most important component in computer network. Ever since the Internet has experienced collapse[1], to work out s...
ns3中quic-bbr怎么配置
10-10
NS-3是一个广泛使用的网络模拟器，而QUIC-BBR（Quick UDP Internet Connections with BBR）是一种基于Google的BBR算法的QUIC实现。要在NS-3中配置QUIC-BBR，你需要安装相关的模块并设置适当的参数。以下是基本步骤： 1. **安装QUIC支持**：首先，确保你的NS-3版本包含了QUIC的支持，你可以从NS-3官方GitHub仓库获取最新版本，并启用相应的模块。通常，`ns3-quic`模块包含QUIC的相关功能。 2. **配置应用层协议**：在你的NS-3场景文件（`.cc`或`.xml`）中，创建一个QUIC的应用层协议实例，比如`QuicApplication`，并指定你想要使用的BBR算法作为拥塞控制器： ```cpp QuicApplication quicApp("quic-bbr"); ``` 3. **创建QUIC会话**：创建一个QUIC会话并连接到网络接口： ```cpp QuicSession session(sessionHandler); session.AddApplicationProtocol(&quicApp); session.SetQuicConfig(quicConfig); // 配置QUIC参数 session.ConnectTo(remoteEndpoint); ``` 4. **配置BBR参数**：通过`QuicCongestionController`的API，如`SetMaxStreamData Burstiness`，可以调整BBR的具体参数。例如，设置最大数据突发窗口： ```cpp uint32_t maxBurst = ...; // 根据需求设定值 quicApp.GetCongestionController().SetMaxStreamDataBurst(maxBurst); ``` 5. **运行模拟**：最后，在你的模拟环境中启动并运行模型。 注意：具体的配置细节可能会因NS-3版本的不同而有所变化，建议查阅最新的NS-3文档或者参考示例代码。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值