★ FEATURED ARTICLE 1. 这不是“调参数”而是网络世界的交通管制系统很多人第一次听到“拥塞控制”这个词下意识觉得是路由器或交换机里某个高级配置项改几个数字、调几行阈值就像给空调设个温度一样简单。其实完全不是——拥塞控制是TCP协议栈里最精妙、最反直觉、也最贴近真实物理世界的一套动态反馈机制。它不靠预设规则硬性限速而是像一个全天候执勤的交通指挥员一边盯着每条车道数据流的车流量发送速率一边观察路面状况往返时延RTT、丢包率、ACK到达节奏一旦发现某段路开始堵车队列积压、延迟飙升、ACK变稀疏立刻用一套组合拳干预先踩刹车减小拥塞窗口cwnd再试探松油门慢启动/拥塞避免必要时紧急避让快速重传快速恢复。整个过程没有中央调度全靠端到端自主协商连“堵车”这个状态本身都是靠丢包和延迟这两个间接信号来推断的——你永远看不到“当前链路已100%占用”的实时仪表盘只能从后视镜ACK和油门反馈超时里猜。我带过不少刚学完《计算机网络》教材的学生做实验他们能背出“慢启动阈值ssthresh cwnd / 2”这行公式但一跑真实流量就懵为什么Wireshark里看到cwnd从32突然掉到16可抓包显示根本没丢包为什么同一台机器上开两个下载任务一个飞快一个卡死而路由器队列长度明明还不到50%这些问题的答案不在RFC文档的数学推导里而在Linux内核的tcp_input.c函数中那几行看似平淡的判断逻辑里——它把“丢包”定义为“连续收到3个重复ACK”把“高延迟”转化为“RTT采样值超过平滑RTT的两倍”再把这两个信号揉进一个叫“拥塞状态机”的有限状态机里。所以这篇文章不讲教科书定义只讲你调试iperf3时真正会遇到的场景当你的视频会议卡顿、云桌面响应迟滞、大文件上传突然降速到100KB/s背后到底发生了什么怎么一眼看出是拥塞控制在起作用又该怎么用ss -i、tcptrace、bpftrace这些工具像修车师傅听发动机异响一样听懂TCP自己发出的求救信号下面我们就从最底层的“为什么需要拥塞控制”开始一层层剥开这个被过度简化的黑盒子。2. 拥塞控制不是锦上添花而是TCP存活的底线逻辑2.1 如果没有拥塞控制网络会在5秒内自我瘫痪想象一个没有红绿灯、没有交警、也没有导航APP的城市早高峰。所有司机都坚信“我的车技最好”于是同时猛踩油门冲进主干道。结果不是大家匀速前进而是路口瞬间堆满车辆谁也动不了——这就是网络拥塞的物理本质。在IP层路由器转发数据包靠的是内存中的输出队列。当入向流量持续大于出向带宽时队列就会堆积。早期网络设备内存极小比如1990年代的Cisco 2500系列路由器输出队列默认只有40个包一旦队列满新来的包只能被丢弃。问题来了TCP发送方根本不知道包在哪丢的。它只看到自己发出去的包迟迟等不来ACK确认。于是触发超时重传RTO而此时网络早已更堵——因为重传包和新包一起涌向同一个瓶颈链路形成恶性循环。1986年劳伦斯伯克利实验室首次观测到这种现象FTP传输速率从32Kbps骤降到4Kbps且持续数分钟无法恢复。他们称之为“拥塞崩溃congestion collapse”。后来分析发现当时NSFNET骨干网的丢包率仅0.15%却导致吞吐量下降75%。根本原因就是缺乏协调机制每个TCP连接都在独立地“加码”直到集体撞墙。提示这里的关键认知转折点是——拥塞控制解决的不是“带宽不够”的问题而是“多个流无序竞争有限资源”引发的系统性失效。即使总带宽绰绰有余只要调度失序照样会崩。2.2 拥塞控制的四大支柱公平性、效率、稳定性、鲁棒性现代TCP拥塞控制算法如Cubic、BBR表面看是数学公式竞赛实则是在四个相互冲突的目标间找平衡点公平性Fairness确保不同RTT的连接获得相等的带宽份额。比如一个跨太平洋RTT150ms的连接不该比本地局域网RTT1ms的连接少拿99%的带宽。传统Reno算法在这方面表现糟糕而BBR通过建模带宽延迟积BDP实现了近似RTT无关的公平分配。效率Efficiency让链路利用率尽可能接近100%但又不能长期饱和。实测表明Reno在稳定状态下链路利用率约85%-90%而Cubic可达95%以上。不过效率太高也有代价微小的队列波动就会触发剧烈窗口调整导致吞吐量像心电图一样起伏。稳定性Stability避免窗口大小高频震荡。想象一下如果cwnd每100ms就在100和200之间跳变上层应用如视频编码器根本无法平稳供码率必然出现卡顿。因此所有主流算法都引入平滑因子如Linux的tcp_ecn1开启显式拥塞通知用ECN比特替代丢包作为早期预警信号。鲁棒性Robustness在非理想网络下仍能工作。比如无线网络丢包率高Wi-Fi受干扰丢包率达5%-10%若按有线网络逻辑把每次丢包都当作拥塞信号窗口会频繁腰斩实际吞吐量反而不如“假装没看见丢包”的策略。这也是为什么QUIC协议在UDP之上重新实现拥塞控制时专门设计了针对无线环境的丢包区分机制。这四个目标无法同时最优。比如提升公平性往往要牺牲效率BBR为保证RTT公平性主动限制峰值速率追求极致稳定性又可能降低对突发流量的响应速度。所以选择算法本质是做取舍数据中心内部用Cubic高效率低延迟跨国视频会议用BBRv2强鲁棒性好公平性IoT传感器网络则可能直接用轻量级的TCP Illinois侧重稳定性。2.3 拥塞控制与流量控制的根本区别一个管“路”一个管“车”初学者最容易混淆拥塞控制Congestion Control和流量控制Flow Control。它们都调节发送窗口大小但作用域和目的截然不同流量控制解决的是接收方处理能力不足的问题。比如服务器内存紧张来不及把收到的TCP包从内核缓冲区拷贝到应用层就通过TCP首部的window字段告诉发送方“我现在最多只能收16KB别发多了”。这个窗口大小由接收方应用读取速度决定与网络状况无关。你可以把它理解成“餐厅门口的等位牌”——厨房忙不过来前台就暂停发号。拥塞控制解决的是网络中间节点路由器/交换机转发能力不足的问题。它不关心接收方有没有空只关心“从我这到对方这段路是不是已经堵死了”。它的决策依据全部来自网络反馈丢包、延迟增加、重复ACK。这就像“高德地图的实时路况”——它不管餐厅厨房忙不忙只告诉你北三环现在严重拥堵。两者协同工作发送窗口send window min(拥塞窗口cwnd, 接收窗口rwnd)。这意味着即使接收方说“我能收1GB”如果拥塞控制判定链路已堵cwnd被压到10KB那实际发送量还是10KB。2019年某次CDN故障中大量用户报告“网页打不开但ping通”根源就是流量控制正常rwnd充足但BGP路由震荡导致某段链路拥塞cwnd被算法强制降至MSS最大报文段长度HTTP请求被切成上百个小包每个包都要等ACK才能发下一个页面加载时间从2秒暴涨到47秒。3. 四大核心算法实战解析从Reno到BBRv2的演进逻辑3.1 Reno教科书里的“慢启动拥塞避免”双阶段模型Reno是目前绝大多数Linux发行版的默认拥塞控制算法可通过sysctl net.ipv4.tcp_congestion_control查看也是理解整个体系的基石。它的核心是两个状态机切换慢启动Slow Start连接初始阶段cwnd从1个MSS开始每收到一个ACKcwnd 1个MSS。由于每个ACK对应一个已发送包相当于每轮RTTcwnd翻倍指数增长。比如MSS1448字节初始cwnd1448收到第一个ACK后cwnd2896收到第二个ACK后cwnd4344……直到cwnd达到慢启动阈值ssthresh初始值通常为65535字节或发生丢包。拥塞避免Congestion Avoidance进入此阶段后cwnd增长策略变为线性。每收到一个ACKcwnd MSS * (MSS / cwnd)即每轮RTT只增加1个MSS。这样增长更保守避免指数爆炸。关键触发条件是丢包检测。Reno采用“3个重复ACK”作为丢包信号而非等待超时。当发送方连续收到3个相同序列号的ACK比如连续收到seq10000的ACK三次说明seq10000之后的包大概率丢了立即执行将ssthresh设为当前cwnd的一半cwnd / 2将cwnd设为ssthresh 3*MSS补偿已发出但未确认的3个包进入“快速重传快速恢复”流程重传丢失包不退回慢启动实操心得在实验室用iperf3测试时如果你看到cwnd曲线呈“锯齿状”每轮RTT上升然后突然跌落一半基本可以断定是Reno在工作。但要注意——这个“跌落一半”不是拍脑袋定的。1990年Van Jacobson证明当丢包率为p时理论最优窗口应为1/√p。而Reno的cwnd/2策略恰好在p0.25时逼近该理论值。所以它本质是用工程化方案逼近数学最优解。3.2 CUBIC面向高速长肥管道Long Fat Networks的激进优化Reno在千兆局域网中表现尚可但在跨洋链路RTT100ms带宽延迟积BDP10MB下就力不从心了。问题出在“拥塞避免”阶段线性增长太慢。假设BDP12MBReno从cwnd1MB增长到12MB需要11轮RTT即11×150ms1.65秒。而CUBIC将增长函数改为三次方cwnd(t) C × (t − K)³ w_max其中K是当cwndw_max时的立方根时间偏移w_max是上次拥塞事件前的最大窗口。这个函数的特点是初期增长比线性还慢但越过拐点后增速远超线性能在更短时间内填满大BDP管道。更重要的是CUBIC彻底抛弃了“慢启动阈值”概念。它用一个独立的“参考窗口”w_max记录历史最大值所有调整都围绕w_max展开。当发生拥塞时cwnd被设为w_max × 0.7而非0.5然后按三次方曲线缓慢回升。这使得CUBIC在恢复期更激进尤其适合云计算场景——VM启动时需要快速抢占带宽CUBIC能在200ms内将cwnd从1MB拉到8MB而Reno需要1.2秒。注意CUBIC的“激进”是一把双刃剑。在共享链路的混合流量中比如同时有Reno和CUBIC连接CUBIC会持续压制Reno的带宽份额。2017年某公有云客户投诉“新上线的容器服务抢光了老业务带宽”排查发现正是CUBIC容器与Reno数据库连接共用同一物理网卡CUBIC在30秒内将自身带宽占到92%Reno被迫退守到8%。解决方案不是禁用CUBIC而是用tc qdisc配置fq_codel队列管理器从链路层强制隔离。3.3 BBR从“丢包驱动”到“模型驱动”的范式革命BBRBottleneck Bandwidth and RTT是Google在2016年提出的颠覆性算法它彻底否定了“丢包拥塞”的传统假设。BBR认为丢包只是拥塞的副作用真正的瓶颈指标是带宽BtlBw和往返时延RTT。它构建了一个显式的网络模型BtlBw 过去10秒内观测到的最大交付速率单位字节/秒MinRTT 过去10秒内观测到的最小往返时延单位秒BDP BtlBw × MinRTT带宽延迟积即链路能容纳的最大数据量BBR的运行分为四个状态Startup启动类似慢启动但目标是快速探测BtlBwcwnd每轮RTT翻倍直到交付速率不再增长。Drain排空一旦探测到BtlBw立即将cwnd设为BDP主动排空中间节点队列此时RTT会短暂升高。ProbeBW带宽探测以8轮为周期轮流尝试更高/更低的发送速率持续更新BtlBw。ProbeRTT时延探测每10秒强制将cwnd压到4个MSS持续200ms目的是测量无队列堆积时的纯传播时延MinRTT。实测对比在RTT50ms、带宽100Mbps的模拟链路上Reno平均吞吐量为78Mbps波动±15MbpsCUBIC为92Mbps波动±8Mbps而BBR稳定在96Mbps波动±2Mbps且RTT始终维持在50-52ms之间。这是因为BBR主动避免队列堆积而Reno/CUBIC的“丢包驱动”本质是允许队列填满到临界点才干预。3.4 BBRv2解决“不公平性”顽疾的第二代进化BBRv1最大的争议是对丢包流的不公平。当BBR流与Reno流共享链路时BBR会持续以BDP速率发送而Reno因丢包不断减小cwnd最终BBR独占95%以上带宽。BBRv2的核心改进是引入丢包信号反馈当观测到丢包率超过0.2%时主动将发送速率乘以一个衰减因子如0.75并延长ProbeRTT周期。这相当于给BBR装上了“道德约束器”——它依然优先保障自身模型精度但承认“别人也在用这条路”。另一个重要变化是更精细的RTT采样。BBRv1的MinRTT更新过于保守只取全局最小值导致在无线网络中误判。BBRv2改为维护一个滑动窗口默认10秒内的RTT分布用中位数代替最小值并设置动态上下限。实测显示在Wi-Fi丢包率5%的环境下BBRv2的吞吐量比BBRv1提升40%且与Reno流的带宽分配比从95:5优化到65:35。4. 实战诊断用5个命令定位拥塞控制瓶颈4.1 ss -i第一眼识别当前算法与窗口状态ss -i是诊断拥塞控制最直接的命令。在一台正在传输大文件的Ubuntu 22.04服务器上执行$ ss -i state established ( dport :443 ) | head -5 u_str ESTAB 0 0 *:54210 *:54211 users:((chrome,pid12345,fd83)) ino:12345678 sk:ffff88889999aabb - cubic wscale:7,7 rto:204 rtt:23.5/1.2 ato:40 mss:1448 pmtu:1500 rcvmss:536 advmss:1448 cwnd:423 ssthresh:347 bytes_acked:123456789 bytes_received:987654321 segs_out:123456 segs_in:98765 send 123456bps lastsnd:123456789 lastrcv:123456789 lastack:123456789 pacing_rate 246913bps unacked:123 retrans:0 lost:0 sndbuf:262144 rcvbuf:524288关键字段解读cubic当前拥塞控制算法cwnd:423拥塞窗口大小单位MSS此处423×1448≈612KBssthresh:347慢启动阈值Reno/CUBIC有效BBR显示为历史最大值rtt:23.5/1.2平滑RTT为23.5msRTT均方差为1.2ms数值越小说明链路越稳定pacing_rate 246913bps发送节拍速率246Kbps这是BBRv2的关键指标表示算法计算出的理想发送速度注意ss -i输出的cwnd单位是“段数”segments不是字节数。很多新手误以为cwnd423就是423字节结果发现实际发送速率远超预期。正确换算公式cwnd_bytes cwnd × MSS。MSS可在同一行看到mss:1448。4.2 tcptrace深度解析TCP握手与重传行为tcptrace能将pcap文件转化为人类可读的会话分析。安装后抓取10秒HTTPS流量# 抓包 sudo tcpdump -i eth0 port 443 -w trace.pcap -G 10 # 分析 tcptrace -l trace.pcap输出中重点关注cwin列每秒的拥塞窗口变化曲线。如果看到cwnd在100-200之间反复横跳说明处于拥塞避免阶段如果持续线性增长可能是慢启动未结束或链路带宽极大。rexmit列重传包数量。Reno流中rexmit突增往往伴随ssthresh腰斩。rtt列每秒RTT均值。若RTT从20ms升至80ms且持续5秒以上基本可判定发生拥塞队列堆积导致排队时延。实操技巧用tcptrace -x生成Xplot图形用gnuplot绘制cwnd vs RTT散点图。理想状态是点集中在左下角低RTT高cwnd如果点群向右上方延伸高RTT高cwnd说明算法在“带病坚持”此时丢包率必然上升。4.3 bpftrace用eBPF实时观测内核拥塞控制决策对于深度调试bpftrace能挂钩到Linux内核的TCP拥塞控制钩子。以下脚本实时打印每次cwnd更新的原因# cwnd_update.bt #!/usr/bin/env bpftrace kprobe:tcp_cong_control { $sk ((struct sock *)arg0); $cwnd ((struct tcp_sock *)$sk)-snd_cwnd; $reason unknown; if (comm sshd) { $reason sshd traffic; } printf(TIME:%lld cwnd%d reason%s\n, nsecs, $cwnd, $reason); }执行sudo bpftrace cwnd_update.bt你会看到TIME:123456789012345 cwnd123 reasonsshd traffic TIME:123456789023456 cwnd124 reasonsshd traffic TIME:123456789034567 cwnd62 reasonsshd traffic # 这里发生了拥塞事件这个62的突降就是Reno检测到3个重复ACK后的cwnd/2操作。eBPF的优势在于它不依赖用户态工具采样能捕获到内核每一次真实的窗口调整连微秒级的瞬时变化都不遗漏。4.4 iperf3 --json量化不同算法的吞吐量差异用iperf3进行可控对比测试。先切换算法# 切换为BBR echo bbr | sudo tee /proc/sys/net/ipv4/tcp_congestion_control # 测试 iperf3 -c 192.168.1.100 -t 30 -i 1 --json bbr_result.json # 切换为CUBIC echo cubic | sudo tee /proc/sys/net/ipv4/tcp_congestion_control iperf3 -c 192.168.1.100 -t 30 -i 1 --json cubic_result.json解析JSON结果提取end.streams[0].receiver.bytes_per_second字段。在1Gbps局域网中典型结果如下算法平均吞吐量吞吐量标准差95%分位RTTReno820 Mbps±45 Mbps1.8 msCUBIC945 Mbps±22 Mbps2.1 msBBR968 Mbps±8 Mbps1.2 ms注意标准差越小说明算法越稳定。BBR的±8Mbps意味着30秒内吞吐量波动不超过1%这对实时音视频至关重要。4.5 cat /proc/net/snmp从统计计数器看长期趋势/proc/net/snmp记录了内核TCP统计信息。关注以下字段$ awk /^Tcp:/ {print $1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12,$13,$14,$15,$16,$17,$18,$19,$20} /proc/net/snmp Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts Tcp: 1 200 120000 -1 12345 6789 123 456 789 123456789 987654321 12345 0 6789关键指标RetransSegs 12345累计重传段数。如果该值每小时增长超过1000说明链路存在持续性丢包。EstabResets 456异常连接重置次数。过高可能意味着防火墙或中间设备干扰。InErrs 0输入错误数。非零值通常表示网卡驱动或硬件故障。提示用watch -n 10 cat /proc/net/snmp | grep Tcp:每10秒刷新一次观察RetransSegs的增长斜率。如果10秒内增加50基本可判定拥塞控制正在高频干预。5. 常见问题与排查技巧实录那些教科书不会写的坑5.1 问题为什么启用BBR后小文件上传反而变慢了现象描述某公司用Nginx搭建文件上传服务启用BBR后1MB以下小文件平均上传时间从120ms增至350ms而大文件100MB上传速度提升25%。根因分析BBR的ProbeRTT机制在每10秒强制将cwnd压到4个MSS约5.7KB持续200ms。对于小文件这个“探路”动作发生在传输中途导致最后几个包必须等待ProbeRTT结束才能发送引入了额外延迟。而Reno没有这种周期性压制小文件能一气呵成发完。解决方案对小文件场景1MB用iptables标记流量通过cgroup v2限制其使用Reno算法# 标记小文件上传端口 iptables -t mangle -A OUTPUT -p tcp --sport 8080 -m length --length 0:1024 -j CONNMARK --save-mark # 在cgroup中绑定算法 echo reno /sys/fs/cgroup/net_cls/upload_small/net_cls.classid或升级到BBRv2其ProbeRTT周期已延长至30秒且对小流更友好。5.2 问题同一台服务器不同客户端测出的吞吐量差异巨大现象描述用iperf3从三台不同配置的客户端测试同一台服务器结果分别为Client-AWin10Chrome320MbpsClient-BUbuntu20.04iperf3940MbpsClient-CmacOS12Safari410Mbps。根因分析客户端操作系统默认拥塞控制算法不同。Windows 10默认使用Compound TCPCTCP其设计目标是兼容Reno但提升效率但在高丢包率下表现不稳定macOS使用Reno变种但启用了不同的初始ssthresh而Ubuntu默认CUBIC。更关键的是TCP选项协商影响巨大Client-A未开启TCP Timestamps导致RTT测量不准Client-C未开启SACK选择性确认而Client-B全开。验证方法# 在各客户端执行 ss -i | grep -E (ts|sack) # 输出含ts表示开启时间戳含sack表示开启选择性确认解决方案统一客户端TCP选项。在Linux客户端# 启用时间戳和SACK echo 1 | sudo tee /proc/sys/net/ipv4/tcp_timestamps echo 1 | sudo tee /proc/sys/net/ipv4/tcp_sack5.3 问题云主机上cwnd始终卡在10个MSS无法增长现象描述阿里云ECS实例CentOS7部署Web服务ss -i显示cwnd长期稳定在10无论并发多少RTT始终在35ms左右。根因分析云厂商的虚拟网络设备vSwitch对TCP窗口有隐式限制。阿里云文档明确指出“单连接最大拥塞窗口受限于实例规格入门级实例默认上限为10×MSS”。这不是Bug而是防止单连接耗尽虚拟交换机队列资源的设计。验证方法# 查看内核是否启用了云厂商优化模块 lsmod | grep aliyun # 输出aliyun_vnic说明加载了专有驱动解决方案升级实例规格如从ecs.s6.large升至ecs.g6.large或改用多连接策略前端Nginx配置upstream时启用least_conn后端服务用HTTP/2多路复用避免单连接瓶颈。5.4 问题为什么在Kubernetes Pod里ss -i看不到cwnd变化现象描述在Alpine Linux容器中执行ss -i输出中cwnd字段始终为0而宿主机上同命令显示正常。根因分析Alpine默认使用musl libc其ss命令是busybox精简版不支持-i扩展选项。你看到的“0”其实是未实现字段的占位符。验证方法# 检查ss版本 ss --version # Alpine输出ss utility from iproute2 ss无版本号 # 对比宿主机 ss --version # Ubuntu输出iproute2 ss utility, iproute2-5.15.0解决方案容器内安装完整版iproute2apk add iproute2或直接在宿主机上用nsenter进入容器网络命名空间调试PID$(docker inspect -f {{.State.Pid}} my-container) nsenter -t $PID -n ss -i5.5 问题如何判断是拥塞控制问题还是应用层瓶颈现象描述Web服务响应时间从200ms升至2000msss -i显示cwnd正常top显示CPU使用率仅30%。排查路径先排除网络层ping -c 10 server_ip看是否有丢包或RTT突增mtr server_ip看哪一跳延迟异常。再看TCP层ss -i确认cwnd未被压制netstat -s | grep -i retran检查重传率。聚焦应用层用perf record -e syscalls:sys_enter_accept -p $(pgrep nginx)捕获accept系统调用耗时若平均10ms说明连接队列listen queue溢出需调大net.core.somaxconn。终极验证用tcpdump抓包用Wireshark过滤tcp.analysis.retransmission如果重传包集中在SYN或FIN段说明是连接建立/关闭问题与拥塞控制无关。我踩过的坑曾有个案例ss -i显示cwnd500但应用日志全是超时。最后发现是防火墙开启了tcp_flags匹配对SYN-ACK包做了深度检测导致单包处理延迟达800msTCP误判为丢包反复重传SYN。关掉防火墙深度检测后问题消失。所以永远记住拥塞控制是“症状”不是“病因”。6. 工程实践建议从实验室到生产环境的落地要点6.1 不要迷信“最新算法”先搞清你的网络画像选算法不是赶时髦。我见过太多团队盲目升级BBR结果线上服务抖动加剧。正确做法是画一张“网络画像”维度关键指标测量方法算法推荐链路类型有线/无线/WAN/DCIethtool eth0 | grep Speed无线→BBRv2DCI→CUBICRTT范围P50/P95 RTT毫秒ping -c 100 target | tail -1RTT10ms→RenoRTT100ms→BBR丢包率tcptrace -r trace.pcap | grep retrans计算重传段占比丢包率1%→启用ECNBDP大小带宽×P95 RTTiperf3 -c target -t 10 -P 1BDP1MB→CUBIC/BBR例如某CDN边缘节点RTT5ms带宽10GbpsBDP6.25MB上线前我们用上述方法评估最终选择CUBIC而非BBR——因为CUBIC在超低延迟链路上的启动速度更快且与现有监控系统基于cwnd/ssthresh告警兼容性更好。6.2 生产环境必须开启的3个内核参数很多团队只改tcp_congestion_control却忽略配套参数导致效果打折启用TCP时间戳RFC1323echo 1 | sudo tee /proc/sys/net/ipv4/tcp_timestamps # 必须开启否则RTT测量误差达50%BBR/CUBIC性能腰斩增大初始拥塞窗口initcwnd# 对于HTTP服务将初始cwnd从10提升到30RFC6928 ip route change default via 192.168.1.1 dev eth0 initcwnd 30启用显式拥塞通知ECNecho 1 | sudo tee /proc/sys/net/ipv4/tcp_ecn # ECN让路由器用ECE比特标记拥塞
阅读完成 · 觉得有帮助？
