网络协议实战（2）：TCP 拥塞控制与传输优化

问题背景上一篇把连接的开场与谢幕钉死在状态机上这一篇进入中间那段最值钱的时间连接建好了数据传输到底多快由谁说了算很多人的直觉是带宽决定的但现场一次次打脸千兆内网传文件只有几十兆ping 值正常的一条跨国链路吞吐随传输时间呈锯齿波动丢包率才 1% 的 4G 网路上TCP 硬是把百兆带宽用成了个位数给服务器升了万兆网卡大文件传输反而更慢。这些现象背后是同一件事——TCP 发送方对网络内部一无所知它只能从ACK 回得多快、包丢没丢里反推还能不能继续发而这个反推机制就是拥塞控制。本篇讲清四件事拥塞窗口怎么从慢启动爬到锯齿稳态为什么每 RTT 加 1 段、丢包减半这个看似笨拙的 AIMD 组合是数学上的最优解之一带宽时延积BDP如何决定窗口要开多大才不饱和以及为什么丢包率升高时吞吐是平方根崩塌而不是线性变差。核心原理第一层为什么必须有拥塞控制。路由器缓冲区是全网共享的稀缺资源没有纪律的发送方会把队列灌满——包不会消失只会排队排到超时然后所有人一起重传链路带宽被有效数据和重传数据同时吞噬整体吞吐归零。1986 年 Internet 的两次拥塞崩溃逼出了 Jacobson 1988 年的论文TCP 必须自我克制而且只能凭端到端信号克制因为协议设计上就没有路由器告诉你快慢这条在带反馈。于是拥塞窗口 cwnd 成了发送方的自我限额在途未确认字节不得超过它。注意与上一篇的接收窗口 rwnd 区分——rwnd 是对端接得下多少cwnd 是网络扛得住多少实际发送限额取两者最小值这是排查传输卡住时最先要分清的两条线。第二层AIMD 的三段舞步。窗口演化分三个阶段。慢启动起始 cwnd 很小Linux 默认 10 段RFC 6928但每个 RTT 收到的 ACK 让窗口翻倍——指数增长不是保守而是用最少轮次逼近可用带宽的数量级从 1 段爬到 1000 段线性要 1000 个 RTT、指数只要 10 个。到达慢启动阈值 ssthresh 后转拥塞避免每 RTT 只加 1 段用线性试探还有没有余量一旦溢出立刻退。丢包是满的证据若收到三个重复 ACK说明后面的段都到了只是中间掉了一个触发快速重传快速恢复——ssthresh 设为当前的一半窗口降到一半继续线性爬不回到慢启动若 RTO 超时那是最重的处罚窗口打回 1 段重新慢启动且超时计时器按 RFC 6298 指数退避最坏一次传输能等一分钟。加一减一、乘性减半这套 AIMD 被控制理论证明是多流公平收敛的少数正确组合之一线性减会让窗口永远回不去加性增保证探测温和乘性减保证大家按比例同时退让。第三层CUBIC 与 BBR 对包丢失即拥塞的反叛。Linux 自 2.6.19 起默认 CUBIC窗口是时间函数 w(t)C(t−K)³WmaxK 由上次丢包点 Wmax 算出。含义是距离上次丢包越久加得越猛爬回 Wmax 附近进入平台期小幅震荡等待更优路径。它的增长只依赖时间不依赖 ACK 数量顺带缓解了 AIMD 的 RTT 不公平同带宽下 RTT 短流吃掉的窗口比例天然更大。BBR 走得更远它承认现代网络的丢包很多是随机噪声而非队列溢出于是主动建模——用投递带宽和最小 RTT 算出链路真正的 BDP把窗口钉在装满管道但绝不满到排队配合 fq 排队器发出节拍均匀的小包既不靠丢包也不靠时延猜拥塞。代价是需要内核配合、调不好会在和 CUBIC 流抢带宽时过于激进。第一次代码实验及输出下面是一个确定性的 RTT 级模拟模型以轮为单位1 轮 1 个 RTT慢启动窗口翻倍、拥塞避免每轮 1、指定轮次发生丢包触发快速恢复ssthresh 与 cwnd 减半。它模拟的是 RFC 5681 描述的 Reno 行为骨架不是内核真实实现真实内核按 ACK 粒度增长、有计时器抖动但三条曲线的形状和稳态锯齿完全一致且每一步都可复现。MSS1460# 每段字节数INIT_CWND2# 起始拥塞窗口(段), 简化演示LOSS_ROUNDS{6,11,16,21,26}# 这些往返轮次触发丢包cwnd,ssthreshINIT_CWND,16total_pkts0print(轮次 cwnd ssthresh 阶段与事件)forrinrange(1,29):ifrinLOSS_ROUNDS:oldcwnd ssthreshmax(old//2,2)cwndssthresh note丢包: ssthresh%d-%d, cwnd 减半后进入恢复%(old,ssthresh)phase快恢复elifcwndssthresh:phase慢启动noteelse:phase拥塞避免notetotal_pktscwndprint(%4d %4d %8d %-4s %-2s %s%(r,cwnd,ssthresh,phase,|#*(cwnd*2),note))ifrnotinLOSS_ROUNDSandcwndssthresh:cwnd*2# 慢启动: 每轮收满一个窗口的 ACK, 窗口翻倍elifrnotinLOSS_ROUNDS:cwnd1# 拥塞避免: 每轮只加 1 段 (AIMD 的 AI)print(28 轮共发送约 %d 个段, 即 %d 字节 (%.2f MB)%(total_pkts,total_pkts*MSS,total_pkts*MSS/1048576))运行输出轮次 cwnd ssthresh 阶段与事件 1 2 16 慢启动 |#### 2 4 16 慢启动 |######## 3 8 16 慢启动 |################ 4 16 16 拥塞避免 |################################ 5 17 16 拥塞避免 |################################## 6 9 9 快恢复 |################## 丢包: ssthresh18-9, cwnd 减半后进入恢复 7 9 9 拥塞避免 |################## 8 10 9 拥塞避免 |#################### 9 11 9 拥塞避免 |###################### 10 12 9 拥塞避免 |######################## 11 6 6 快恢复 |############ 丢包: ssthresh13-6, cwnd 减半后进入恢复 12 6 6 拥塞避免 |############ 13 7 6 拥塞避免 |############## 14 8 6 拥塞避免 |################ 15 9 6 拥塞避免 |################## 16 5 5 快恢复 |########## 丢包: ssthresh10-5, cwnd 减半后进入恢复 17 5 5 拥塞避免 |########## 18 6 5 拥塞避免 |############ 19 7 5 拥塞避免 |############## 20 8 5 拥塞避免 |################ 21 4 4 快恢复 |######## 丢包: ssthresh9-4, cwnd 减半后进入恢复 22 4 4 拥塞避免 |######## 23 5 4 拥塞避免 |########## 24 6 4 拥塞避免 |############ 25 7 4 拥塞避免 |############## 26 4 4 快恢复 |######## 丢包: ssthresh8-4, cwnd 减半后进入恢复 27 4 4 拥塞避免 |######## 28 5 4 拥塞避免 |########## 28 轮共发送约 204 个段, 即 297840 字节 (0.28 MB)三个读图要点。第 1 到 3 行慢启动仅用 3 轮就从 2 段冲到 16 段指数的爬坡能力极强——这就是为什么慢启动这个名字吓人它对长传输几乎不慢真正慢的是后面。第 4 到 5 行过了 ssthresh 之后每轮只加 1从 16 到 18 用了 2 轮——线性试探在指数面前就是蜗牛所以窗口永远花很长时间才敢大却一瞬间就减半。从第 6 轮开始进入稳态锯齿cwnd 从 9 线性爬到 13、丢包砍到 6再爬到 10、砍到 5……注意一个残酷事实——后半程的窗口峰值13、10、9一次比一次低永远没回到过第一次丢包前的 18因为丢包轮次固定时减半的惩罚在复利。真实网络里队列位置由全网共同决定锯齿会围绕某个平衡点震荡但吞吐由丢包频率决定、不由线路标称速率决定这条结论在这张模拟表里已经立住了。工程化改进把窗口模型变成可调的参数分四步。第一步按 BDP 配置缓冲区而不是越大越好。窗口要开到 带宽×RTT 才能喂饱链路内核缓冲区若只有一两百 KB千兆广域网上的传输就永远爬不满sysctl net.ipv4.tcp_rmem/tcp_wmem调高 maxss -ti里看 cwnd 是否顶到了 rcv_space。反过来无脑调大也有代价队列深到几倍 BDP 时吞吐不再涨、延迟猛涨这就是 bufferbloat——路由器变成又慢又挤的停车场。第二步短连接的重头成本在慢启动前半程。一个典型 HTTPS API 响应十几 KB窗口还没爬开传输就结束了——上一篇讲过建连要一个 RTT这里再加一笔头几个 RTT 吞吐被窗口曲线压着。结论就是连接复用不是可选项HTTP keep-alive/HTTP2 复用一个已经爬开窗口的连接比新建快的那部分往往比协议开销本身更值钱。高并发短任务场景可适度调大初始窗口ip route change 路由 initcwnd 64 initrwnd 64。第三步按链路画像选算法。局域网/数据中心RTT 毫秒级、丢包近零CUBIC 足够追求极低时延可考虑带 ECN 的方案跨洲/移动网络RTT 大、随机丢包多net.ipv4.tcp_congestion_controlbbr且net.core.default_qdiscfqBBR 不拿丢包当拥塞抗噪能力最强两者都要成对设置只换算法不换排队器BBR 的节拍发包无从谈起。验证生效ss -ti每行连接会显示cc bbr。第四步学会观测窗口的证据链。iperf3 -P 1与-P 8对比单流与并发的差距差距大说明单流受限在窗口/丢包而非带宽ss -tin直接打印每条连接的cwnd、rtt、retrans、pacing_rate抓包里看重复 ACK 的密度和 RTO 后的窗口重启。这三件套能区分出带宽不够单流多流一样慢、无重传与拥塞控制受限多流快得多、有重传两类完全不同的问题。第二次代码实验及输出下面算两笔账一是不丢包时窗口要开多大才不饱和BDP二是丢包时 AIMD 单流的吞吐天花板Mathis 公式吞吐 ≈ MSS/(RTT·√(1.5p))RFC 5681 的稳态分析结果。纯算术模拟任何机器跑都一样。importmath MSS_BITS1460*8defbdp_bytes(bw_mbps,rtt_ms):带宽时延积: 链路上在途数据量, 也是窗口至少要开多大才不饱和returnbw_mbps*1e6/8*(rtt_ms/1000)defmathis_mbps(rtt_ms,loss):Mathis 公式(Reno 稳态吞吐上界): p - 0 时吞吐随 1/sqrt(p) 崩塌returnMSS_BITS/((rtt_ms/1000)*math.sqrt(3*loss/2))/1e6print( 第一部分: 不丢包时, 窗口要开多大才喂得饱链路 )forbw,rttin[(1000,0.5),(1000,20),(10000,20),(10000,150)]:wbdp_bytes(bw,rtt)print(链路 %5d Mbps, RTT %5.1f ms: BDP %9.0f 字节 %5.1f KB, 需 cwnd %4d 段(1460B)%(bw,rtt,w,w/1024,math.ceil(w/1460)))print()print( 第二部分: 丢包时, AIMD 单流吞吐天花板(Mathis) )forrttin(10,100):forlossin(1e-6,1e-4,1e-2):print(RTT %3d ms, 丢包率 %6.4f%%: 单条 Reno 流平均吞吐 %7.1f Mbps%(rtt,loss*100,mathis_mbps(rtt,loss)))print()print( 第三部分: 同样 1% 丢包, 把流数乘以 N 能救回多少 )fornin(1,2,4,10):print(并行 %2d 条流 x Mathis(100ms, 1%%) %6.1f Mbps 总吞吐%(n,n*mathis_mbps(100,1e-2)))运行输出 第一部分: 不丢包时, 窗口要开多大才喂得饱链路 链路 1000 Mbps, RTT 0.5 ms: BDP 62500 字节 61.0 KB, 需 cwnd 43 段(1460B) 链路 1000 Mbps, RTT 20.0 ms: BDP 2500000 字节 2441.4 KB, 需 cwnd 1713 段(1460B) 链路 10000 Mbps, RTT 20.0 ms: BDP 25000000 字节 24414.1 KB, 需 cwnd 17124 段(1460B) 链路 10000 Mbps, RTT 150.0 ms: BDP 187500000 字节 183105.5 KB, 需 cwnd 128425 段(1460B) 第二部分: 丢包时, AIMD 单流吞吐天花板(Mathis) RTT 10 ms, 丢包率 0.0001%: 单条 Reno 流平均吞吐 953.7 Mbps RTT 10 ms, 丢包率 0.0100%: 单条 Reno 流平均吞吐 95.4 Mbps RTT 10 ms, 丢包率 1.0000%: 单条 Reno 流平均吞吐 9.5 Mbps RTT 100 ms, 丢包率 0.0001%: 单条 Reno 流平均吞吐 95.4 Mbps RTT 100 ms, 丢包率 0.0100%: 单条 Reno 流平均吞吐 9.5 Mbps RTT 100 ms, 丢包率 1.0000%: 单条 Reno 流平均吞吐 1.0 Mbps 第三部分: 同样 1% 丢包, 把流数乘以 N 能救回多少 并行 1 条流 x Mathis(100ms, 1%) 1.0 Mbps 总吞吐 并行 2 条流 x Mathis(100ms, 1%) 1.9 Mbps 总吞吐 并行 4 条流 x Mathis(100ms, 1%) 3.8 Mbps 总吞吐 并行 10 条流 x Mathis(100ms, 1%) 9.5 Mbps 总吞吐三张表连起来读是一篇传输优化总论。第一张1Gbps 局域网RTT 0.5ms只要 61KB 窗口就饱和而同样带宽跨 20ms 的城网需要 2.4MB——千兆网很慢的锅常常是默认缓冲区只给了前者、链路却是后者万兆跨洋那一行直接给出结论不做大窗口窗口缩放、调缓冲区万兆在广域网上就是摆设。第二张是 √p 崩塌的现场丢包率从 0.0001% 到 1% 涨了 1 万倍吞吐掉到 1/100953.7→9.5因为 Mathis 公式里 p 在平方根下——丢 1% 的网和只丢一点点的网对 TCP 是两个物种同时 RTT 从 10ms 到 100ms 同样让吞吐掉 10 倍这就是 AIMD 的 RTT 不公平也是长肥管道偏爱 BBR 的数字理由。第三张泼一盆冷水多线程并行下载在带宽受限时有效在丢包受限时只是把同一天花板切成 N 份再乘回来还能把队列挤得更满真正该做的排序是降丢包换链路、开 FEC/QUIC→ 提窗口BDP 配置→ 最后才谈并发数。常见陷阱其一把缓冲区当吞吐药方队列深度超过几倍 BDP 后只有延迟在涨bufferbloat视频通话卡成幻灯片而测速却很好看就是这个调窗口的同时保持中间设备队列浅fq/codel。其二混淆 cwnd 与 rwnd抓包看到窗口字段是 0那是接收方应用读得慢零窗探针之后才会恢复调拥塞参数毫无用处先查对端消费速度。其三用 ping 判断带宽够不够ICMP 常常走低优先级队列、路径还不对称10ms 的 ping 说明不了丢包率——要看mtr的逐跳 Loss% 和ss -ti的重传统计。其四在丢包链路上盲调 initcwnd 到大值初始窗口是赌注赌错了前几个 RTT 的丢包会把窗口打回谷底还连累同路由的流改之前先回答这条链路稳态 p 是多少。其五只换 BBR 不换 fqBBR 的 pacing 依赖公平队列器排队节拍pfifo_fast 下实测吞吐可能不升反降。其六忘了 TCP 重传会重复占用带宽Mathis 公式的前提是丢包被重传补上应用层若还有自己的重试HTTP 客户端再转三圈拥塞会指数恶化退避必须带抖动。落地清单用iperf3 -P 1vs-P 8、ss -tin的 cwnd/retrans/rtt、mtr逐跳丢包三件套先给链路画像再动手调参广域网/大文件服务tcp_rmem/wmem max 按目标 BDP 上调必要时ip route change ... initcwnd 64跨洲或移动弱网net.ipv4.tcp_congestion_controlbbrnet.core.default_qdiscfq成对设置ss -ti确认cc bbr接口服务优先连接复用与预热keep-alive/HTTP2/连接池别为短连接反复付慢启动前半程的税拥塞类故障先看丢包再谈并发降 p → 提窗口 → 加并发顺序反了全是无用功这一篇把发送方的自我限额讲透了窗口是 TCP 在未知网络里靠 ACK 与丢包反推出来的猜测代价是丢包即减半、长肥管道爬得慢。但你有没有发现这一切都默认了一条 TCP 连接里只有一个字节流在排队HTTP/1.1 的队头阻塞、多连接互踩窗口的混乱正是这个模型的直接后果——而应用层协议两百年的历史就是围绕这条曲线做取舍的历史。下一篇《网络协议实战3HTTP/1.1 到 HTTP/3 的演进》看三代应用协议如何在握手、复用与拥塞之间反复权衡。参考来源RFC 5681: TCP Congestion Control: https://datatracker.ietf.org/doc/html/rfc5681RFC 6928: Increasing TCP’s Initial Window: https://datatracker.ietf.org/doc/html/rfc6928RFC 8312: CUBIC: A New TCP-Friendly High-Speed TCP Variant: https://datatracker.ietf.org/doc/html/rfc8312RFC 6298: Computing TCP’s Retransmission Timer: https://datatracker.ietf.org/doc/html/rfc6298ACM QueueBBR: Congestion-Based Congestion Controlhttps://queue.acm.org/detail.cfm?id3022184WikipediaTCP congestion controlhttps://en.wikipedia.org/wiki/TCP_congestion_control 觉得有用就点个赞 收藏方便回头查阅有疑问直接在评论区留言我看到都会回。 本文属于《网络协议实战》系列持续更新关注不迷路。 文章里的代码都能直接跑。想要可直接 clone 的完整工程 配套部署脚本 / 踩坑清单评论一声或发邮件到cj2664qq.com我免费发你。如果你正好在做类似系统、或有工程化难题想找人做也欢迎邮件聊一句——我按实际情况评估能落地的就接单或出方案。评论和邮件都能直接找到我不用跳别的平台。