创建网站目录时我们应该烟台做网站优化哪家好

创建网站目录时我们应该,烟台做网站优化哪家好,广州哪里能做英文版核酸,软件开发费用计算方法TCP 拥塞控制算法详解#xff1a;CUBIC、BBR 及传统算法 目录 CUBIC 拥塞控制算法BBR 拥塞控制算法CUBIC 与 BBR 对比总结传统算法#xff1a;TCP Tahoe传统算法#xff1a;TCP Reno传统算法#xff1a;TCP NewReno传统算法#xff1a;TCP SACK传统算法总结对比从传统到…TCP 拥塞控制算法详解CUBIC、BBR 及传统算法目录CUBIC 拥塞控制算法BBR 拥塞控制算法CUBIC 与 BBR 对比总结传统算法TCP Tahoe传统算法TCP Reno传统算法TCP NewReno传统算法TCP SACK传统算法总结对比从传统到现代的演进一、CUBIC 拥塞控制算法1.1 背景CUBIC 是一种基于窗口的拥塞控制算法是对传统BICBinary Increase Congestion Control的改进。在 Linux 内核中被广泛采用自 Linux 2.6.19 引入尤其在**高带宽、高延迟长肥网络LFN**环境中表现良好是许多现代操作系统的默认 TCP 拥塞控制算法。1.2 特点以时间为基准的窗口增长使用立方函数调整拥塞窗口cwnd而非线性或指数增长。对高 BDP 网络友好适合高速、长距离网络。窗口增长与丢包相关但不完全依赖丢包作为拥塞的唯一信号。1.3 工作原理发生丢包时CUBIC 将拥塞窗口降至W_max × ββ 一般约 0.7。之后不再线性增加 cwnd而是按三次函数关于时间差 t快速增长较快接近上次最大窗口W_max再缓慢逼近新平衡点。公式简化W(t) C(t − K)³ W_max其中W(t)为 t 时刻的拥塞窗口C为缩放常数K为达到 W_max 所需时间t为自上次丢包以来的时间。1.4 优点在高带宽延迟网络中性能优于传统算法。可扩展性好适合数据中心和互联网骨干网。1.5 缺点仍主要依赖丢包作为拥塞信号难以区分排队延迟与真正拥塞。在存在较大缓冲队列的网络中可能引起较高延迟bufferbloat。二、BBR 拥塞控制算法2.1 背景BBRBottleneck Bandwidth and RTT由 Google 提出2016 年旨在解决传统基于丢包的算法如 CUBIC在高延迟、高带宽环境下效率低下的问题并改善bufferbloat。2.2 特点不依赖丢包作为拥塞判断而是基于**瓶颈带宽BtlBw和往返时延RTprop**动态调整发送速率。主动探测网络带宽和最小 RTT通过建模网络状态实现高效传输。显著减少排队延迟提高响应速度和吞吐量。2.3 工作原理BBR 周期性地在两种模式之间切换PROBE_BW带宽探测逐步增加发送速率以探测可用带宽。PROBE_RTT最小 RTT 探测定期降低发送速率以测量最小 RTT反映无排队时的网络延迟。BBR 控制两个关键参数BtlBw当前路径所能承载的最大数据传输率瓶颈带宽估计。RTprop路径上的最短往返时间最小 RTT。拥塞窗口的调整不直接依据丢包而是使发送速率尽量匹配估计的瓶颈带宽同时避免过多排队延迟。2.4 优点在高带宽、高延迟、高缓冲网络中性能优越。降低网络延迟和抖动提升用户体验。减少因拥塞窗口过大造成的 bufferbloat。特别适用于视频流、大文件传输等对带宽敏感的场景。2.5 缺点多 BBR 流竞争时可能存在公平性问题。部署需要操作系统支持Linux kernel ≥ 4.9 支持较好。部分网络设备对非传统拥塞控制算法支持不佳。三、CUBIC 与 BBR 对比总结特性CUBICBBR拥塞判断依据丢包带宽 延迟不依赖丢包拥塞窗口增长方式基于时间的立方函数基于带宽/延迟模型的速率控制对延迟的敏感性较低易受 bufferbloat 影响高能显著降低延迟适用场景高带宽延迟网络、通用场景高速网络、实时业务、视频流、云应用公平性较好多 BBR 流间可能存在竞争问题默认支持Linux 默认老版本需手动开启Linux 4.9 支持四、传统算法TCP Tahoe4.1 背景Tahoe 是最早的 TCP 拥塞控制算法之一约 1988 年是 TCP Reno 的前身首次引入拥塞控制的基本思想。4.2 核心机制慢启动Slow Start初始 cwnd 较小每经过一个 RTTcwnd 翻倍指数增长直到达到慢启动阈值ssthresh。拥塞避免Congestion Avoidance当 cwnd ≥ ssthresh 后改为线性增长每 RTT 加 1。快速重传Fast Retransmit收到3 个重复 ACK时立即重传丢失的数据包无需等待超时。发生丢包时将ssthresh 减半将cwnd 设为 1重新进入慢启动。4.3 缺点一旦检测到丢包就回到慢启动性能急剧下降。没有「快速恢复」机制带宽利用率不高。五、传统算法TCP Reno5.1 背景Reno 在 Tahoe 基础上加入快速恢复约 1990 年前后提出广泛用于早期 Internet。5.2 核心机制继承 Tahoe 的慢启动、拥塞避免和快速重传并新增快速恢复Fast Recovery当收到 3 个重复 ACK 时设置ssthresh max(cwnd/2, 2)设置cwnd ssthresh每收到一个重复 ACKcwnd 增加 1有上限重传丢失报文当收到新 ACK确认新数据时退出快速恢复cwnd 设为 ssthresh进入拥塞避免。超时处理若发生超时重传ssthresh 设为 cwnd/2cwnd 重置为 1重新进入慢启动。5.3 优点与缺点优点相比 Tahoe丢包恢复更快网络利用率更高。缺点对同一窗口内多个包丢失处理有限在高 BDP 网络中扩展性不足仍基于「丢包拥塞」模型。六、传统算法TCP NewReno6.1 背景NewReno 改进 Reno 在同一窗口内多包丢失时的表现RFC 2582。6.2 核心机制Reno 在快速恢复过程中只能恢复一个丢包若有多个丢包会多次触发快速重传和窗口重置。NewReno 修改快速恢复逻辑使发送方在一次fast recovery 中可连续重传所有丢失的包直到全部被确认才退出恢复状态。6.3 优点与缺点优点多包丢失场景下吞吐量更高向后兼容 Reno。缺点实现更复杂仍受限于丢包检测难以很好适应高带宽、低丢包率网络。七、传统算法TCP SACK7.1 背景SACKSelective Acknowledgment不是完整的拥塞控制算法而是配合 Reno/NewReno 的增强机制RFC 2018、RFC 2883。7.2 工作机制接收方通过 TCP 选项中的SACK字段报告已收到的非连续数据块。发送方据此只重传真正丢失的段而不是从最近确认点之后的所有数据。7.3 优点与缺点优点大幅改善多包丢失的恢复效率与 NewReno 结合形成「NewReno SACK」效果更好。缺点协议更复杂并非所有设备都支持 SACK。八、传统算法总结对比算法拥塞控制机制多包丢失处理快速恢复是否考虑延迟出现年代Tahoe慢启动 拥塞避免 快速重传差❌❌1988Reno 快速恢复一般✅❌~1990NewReno改进快速恢复支持多包丢失好✅❌1999 (RFC)SACK提供细粒度重传信息更好配合✅❌1996传统算法的总体评价优点简单、易实现、广泛部署在低带宽、低延迟、丢包频繁的网络中有效奠定了后续发展基础。缺点基于「丢包拥塞」的保守模型cwnd 调整反应较慢吞吐量易剧烈波动忽略延迟变化易导致 bufferbloat难以应对数据中心、视频流、云服务等高要求场景。九、从传统到现代的演进Tahoe → Reno → NewReno (SACK) → CUBIC → BBR ↑ ↑ 传统丢包驱动模型 现代模型驱动/测量驱动CUBIC 和 BBR 代表了两种不同理念前者仍以丢包驱动为主后者采用测量驱动带宽与 RTT的模型。随着对实时性和高带宽需求的增长BBR 等新一代算法得到越来越广泛的应用。实际部署中应根据网络特点和业务需求选择合适的拥塞控制策略。