吞吐估算与瓶颈判断
TCP 的理论吞吐上限近似等于窗口除以往返时延，同样窗口下时延越大吞吐越低。实测明显低于这个上限时，按证据分流：出现重传说明路径丢包，窗口被填满说明接收侧处理慢，窗口很大而时延很高说明长肥管道下窗口不足。三类问题的证据各不相同，不会互相混淆。
基本信息
| 适用平台 | 所有 TCP 传输，配合 Linux 的 ss 查看内核态数值 |
|---|---|
| 估算公式 | 吞吐上限约等于 窗口 ÷ RTT |
| 三个方向 | 路径丢包、接收窗口受限、长肥管道 |
| 交叉验证 | ss -ti 查看 cwnd、rtt 与重传计数 |
典型使用场景
- 快速定位瓶颈归属：先算理论上限，再与实测值比较
- 区分丢包与窗口问题：看重传标记与窗口填充状态
- 长距离传输调优：评估窗口与缓冲是否需要放大
- 复测口径统一：固定文件大小与连接时长再对比
- 与内核指标印证：用 ss 输出的实时数值交叉检查
估算与统计
估算与统计
# 估算：窗口 64KB、RTT 50ms 时，上限约 1.28 MB/s
tshark -r a.pcap -q -z io,stat,0,"COUNT(tcp.analysis.retransmission)tcp.analysis.retransmission","COUNT(tcp)tcp"
ss -ti | grep -E 'cwnd|rtt|retrans' # 内核视角的实时状态症状对照
| 症状 | 瓶颈方向 | 证据 |
|---|---|---|
| 重传多且窗口未满 | 路径丢包 | tcp.analysis.retransmission |
| 窗口被填满且无丢包 | 接收侧窗口或处理速度 | Window Full 与零窗口 |
| 窗口大但 RTT 高 | 长肥管道 | 需要加大窗口与缓冲 |
| 抓包看不到异常但确实慢 | 应用或磁盘 | 看服务端处理耗时 |
用下载小文件测吞吐会同时受慢启动与磁盘读写影响，结果不可信。测吞吐应使用大文件与长连接，并记录测试时长与平均速率。
带宽单位换算容易出错：链路标称的兆比特每秒与工具显示的兆字节每秒相差八倍。报告里写清单位，能避免大量无谓争论。
估算结果只是上限，实际吞吐还要扣掉协议开销与双向确认的影响，实测低于上限并不必然代表存在故障。