Software Systems Atlas

中文

English

中文

English

主题

14.2 传输性能：RTT、窗口、丢包、队列与连接复用 ​

网络已经连通，跨海传输仍达不到目标吞吐；阿花要求先用 RTT、窗口和队列证据定位限制因素。

增大 socket buffer、切换拥塞控制算法或修改初始窗口，都可能改变性能，也可能扩大排队、突发和内存占用。调优前先判断连接受 RTT、拥塞窗口、接收窗口、应用供数还是瓶颈带宽限制。

延迟的四个来源 ​

一个包经过一段路径的时间可以粗略拆成：

text
propagation + serialization + queueing + processing
  • propagation：信号在介质中传播，与距离和路径有关；
  • serialization：把包的每一位送上链路所需时间；
  • queueing：等待链路或设备处理，负载接近容量时可急剧增长；
  • processing：协议、加密、转发和应用处理。

在 10 Mbit/s 链路上传输一个 1500-byte frame，仅序列化就约需：

text
1500 × 8 / 10,000,000 = 1.2 ms

更完整的线速计算还要考虑链路层开销；此例只展示数量级。

Bandwidth-delay product ​

BDP 是瓶颈带宽与 RTT 的乘积，近似表示填满路径时的在途数据量：

text
BDP = bandwidth × RTT

1 Gbit/s、80 ms RTT：

text
1,000,000,000 bit/s × 0.08 s = 80,000,000 bit
80,000,000 / 8 = 10,000,000 byte ≈ 9.54 MiB

若发送端拥塞窗口或接收端通告窗口长期远小于 BDP，单连接可能无法填满链路。但把 buffer 设为 BDP 并不保证达到带宽：应用供数、拥塞控制、loss、pacing、接收端处理和中间设备都可能成为限制。

三个不同的窗口 ​

  • congestion window, cwnd：发送端根据拥塞控制维护的网络承载估计；
  • advertised receive window, rwnd：接收端通告的可接收空间；
  • application buffer：应用与内核之间的发送/接收缓冲配置。

发送端可在途数据大致受 min(cwnd, rwnd) 限制，但实际发送还受 pacing、应用写入与协议实现约束。socket buffer 与 wire-visible window 也不是简单一一相等；Linux 还会计入管理开销并进行 autotuning。

TCP Window Scale 在握手时协商。连接建立后再修改缩放能力，不能追溯改变现有连接的协商结果。

观察 Linux TCP 状态 ​

bash
ss -tin dst 203.0.113.10

不同内核输出字段不同，常见信息包括 RTT 估计、cwnd、MSS、重传、pacing rate、delivery rate 与拥塞控制算法。解释前应保存：

bash
uname -r
ss -V
sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem

这些命令用于读取状态。不要把示例中的数值直接写入所有主机：容器 namespace、cgroup、内核版本、内存压力和发行版默认值都会影响行为。

判断单连接为何跑不满 ​

按证据检查：

  1. 应用是否持续提供数据，还是被磁盘、CPU、锁或上游限速；
  2. cwnd × MSS / RTT 的数量级是否接近观测吞吐；
  3. rwnd 是否成为更小限制，接收应用是否及时读取；
  4. 是否有重传、SACK、RTO 或持续 loss；
  5. pacing/delivery rate 与接口容量如何；
  6. 多流聚合能否提高吞吐；若能，单流控制或窗口更值得检查；
  7. 是否存在 policer、整形、VPN、隧道或云产品限额。

公式只是上限近似。ACK 策略、offload、应用 burst 与测量窗口会让短时间数值波动。

丢包不是唯一拥塞信号 ​

传统 loss-based 算法以丢包为主要拥塞信号；ECN 可在不先丢包的情况下标记拥塞；BBR 一类算法根据 delivery rate 与 RTT 建模。算法选择影响吞吐、队列、与其他流的公平性，也依赖内核实现版本。

不能写出“BBR 一定更快”或“CUBIC 一定公平”的通用结论。评估至少要覆盖：

  • 短流与长流；
  • 不同 RTT、带宽和 loss；
  • 与现有流量混跑时的公平性；
  • bottleneck qdisc 与 AQM；
  • CPU、内存与重传；
  • 目标内核中的具体算法版本。

生产切换需要灰度、监控和回滚，不应直接全局修改 sysctl。

Pacing、queue 与 bufferbloat ​

一次性突发整个 cwnd 会在瓶颈处形成短队列。pacing 把发送分布到一段时间内，降低 burst。公平队列和 AQM（如 FQ-CoDel）可隔离流并在队列过长前采取丢包或 ECN 标记。

增加队列/缓冲能吸收短突发，却也可能造成 bufferbloat：吞吐看似正常，交互延迟在负载下大幅上升。测试应同时观察吞吐与 loaded latency，而不是只看“下载跑满了”。

连接建立与复用 ​

TCP 与 TLS ​

新 TCP 连接需要握手。TLS 1.3 full handshake 通常能比 TLS 1.2 full handshake 更早发送应用数据；resumption 可进一步减少握手成本。准确 RTT 数取决于版本、resumption、证书验证、客户端认证和传输协议。

优化优先级通常是：

  1. 避免不必要的新连接；
  2. 保持连接有界复用；
  3. 正确配置 TLS 1.3 与 session resumption；
  4. 再评估 TFO 或 0-RTT 等有安全与兼容边界的机制。

两个独立的 curl 进程通常不会共享一个连接。要演示复用，应让同一个客户端实例连续发送多个请求，并从 trace 或 num_connects 证明复用，而不是只删除 Connection: close。

HTTP/2 可以在一条连接上多路复用 streams，但 TCP 丢包仍会阻塞该连接后续字节。HTTP/3 把 stream reliability 放在 QUIC 中，避免跨 stream 的传输层 HOL；它仍会受拥塞控制、路径 loss、同一 stream 顺序和端点处理限制。

TFO 与 early data ​

TCP Fast Open 在有 cookie 等条件时允许 SYN 携带数据；首次连接和中间设备兼容性会影响收益。TLS 1.3 0-RTT 发送的是可被重放的 early data，只适合应用明确允许重放的请求，并需要服务端防护。

两者都不是“打开开关就免费省一个 RTT”。必须测量成功率、fallback、重放边界和中间网络行为。

MTU 与 MSS ​

“小响应正常，大响应停住”常指向 PMTUD/PLPMTUD 或隧道 MTU。诊断时区分：

  • 链路 MTU；
  • 路径 MTU；
  • TCP MSS；
  • IPv4 fragmentation 与 IPv6 source fragmentation；
  • ICMP Packet Too Big/Fragmentation Needed 是否返回；
  • NIC offload 对本机抓包形态的影响。

MSS clamping 能在某些隧道边界缓解 TCP 问题，但它不会修复 UDP/QUIC，也不应替代查清路径 MTU 与 ICMP 策略。

iperf3 测量边界 ​

iperf3 需要在你控制或明确获准的两端运行：

bash
# server
iperf3 --server

# client: one TCP test
iperf3 --client 192.0.2.10 --time 20

# reverse direction
iperf3 --client 192.0.2.10 --reverse --time 20

它测的是测试主机之间、特定参数下的生成流量，不等于应用 goodput。并行 streams 可能掩盖单流问题，也可能压满共享链路。UDP 测试必须明确目标 bitrate，并同时解释 loss、jitter 和接收速率；不要把“TCP + UDP 同时跑”当作默认带宽测试。

变更前清单 ​

  • [ ] 已确认瓶颈是 transport，而不是应用供数或下游；
  • [ ] 有变更前的 RTT、吞吐、loss、重传、queue 与内存基线；
  • [ ] 只改变一个主要变量；
  • [ ] 知道参数作用域是 socket、route、namespace 还是 host；
  • [ ] 在目标内核与真实 RTT/loss 分布下测试；
  • [ ] 有灰度、告警与回滚；
  • [ ] 同时检查短流、长流和共存流量。

本课小结 ​

传输性能取决于路径 BDP、窗口、应用供数、loss、pacing 和 queue 的共同作用。内核参数不是越大越好，拥塞控制算法也没有脱离网络条件的冠军。下一课把视角移到 HTTP、缓存、CDN 和服务容量。

规范入口 ​

  • RFC 7323：TCP Extensions for High Performance；
  • RFC 5681：TCP Congestion Control；
  • RFC 7413：TCP Fast Open；
  • RFC 8985：RACK-TLP Loss Detection；
  • RFC 9002：QUIC Loss Detection and Congestion Control；
  • RFC 9260 不是 TCP 调优规范；查阅时注意协议名称与适用范围。

Built with VitePress | Software Systems Atlas

Copyright 2026 Steven Yang