遇到这种情况，第一反应往往是：光模块问题？网卡瓶颈？运营商限速？

一、Mathis 公式是什么？

Mathis 公式由 Matt Mathis 等人于 1997 年提出，用于估算 TCP 在有丢包情况下的最大吞吐量。

1.22 是经验修正系数，来自 AIMD 拥塞控制模型的稳态推导。公式给出了一条天花板——无论带宽多大，只要 RTT 和丢包率确定，单条 TCP 流的吞吐就被限死了。

二、公式到底说明了什么？

把公式化简到最直觉的形式：

• RTT 越大，吞吐越低——延迟是线性打击
• 丢包越高，吞吐急剧下降——注意是平方根关系，影响远比你想象中大

三、实战案例分析

这次来看一条真实的链路：苏州核心节点 ↔ 香港节点，5 Gbps 专线，初次测试时带宽只有几十 Mbps，完全跑不起来。

# 链路参数
RTT    = 31 ms    # 苏州↔香港实测
MSS    = 1400 B
假设丢包 = 0.5%   # 光衰导致 CRC 错包

代入 Mathis 公式：

排查修复跳纤光衰故障后，使用 iperf3 跑 8 并发流，实测结果：

8 条并发流速率分布极为均匀，正向 651~667 Mbps，反向 655~667 Mbps，极差仅十几 Mbps。双向均已超过 5G 标称带宽，链路达标。

8 条流速率极差仅 16 Mbps，ECMP 调度均衡，无单流独占

四、为什么 TCP 会这样？

这是由 TCP 的 AIMD 拥塞控制机制决定的：加性增加（Additive Increase）+ 乘性减少（Multiplicative Decrease）。

• 一旦检测到丢包，拥塞窗口直接减半（乘性下降）。这是 CUBIC 和 Reno 的经典行为。
• 减半之后，每个 RTT 只增加一点（加性增长）。RTT=31ms 意味着每 31ms 才能涨一步，遇上频繁丢包就陷入"涨一点，砍一半"的反复循环。
• 最终形成一个由 RTT 和丢包率共同锁定的稳态吞吐上限——正是 Mathis 公式描述的状态。

这个过程用波形图来看就是著名的"锯齿形"：窗口缓慢爬升，丢包一瞬间砍半，再爬升，再砍半……如此反复，最终稳定在一个远低于链路带宽的水平。

五、另一个杀手：BDP 窗口不够

除了丢包，还有一个隐形杀手：带宽延迟积（BDP）。

填满 5 Gbps 链路需要的窗口 = 5 Gbps × 0.031s ÷ 8 ≈ 19.4 MB。而 Linux 默认最大 TCP 窗口才 6~16 MB，不够用。这就是为什么单流跑不满，需要 8 并发流来绕开这个限制。

六、不同丢包率的实际影响

以 RTT=31ms（苏↔港链路）、5G 专线为基准：

七、本次案例：修复前后对比

反向 414 次重传，在 120 秒 × 8 流的跨境测试中完全属于正常量级。主因是 RTT=31ms 下 CUBIC 拥塞窗口爬升偏慢，偶发重传计数。物理层无 CRC 误码，链路质量良好。

八、如何优化？

方向只有两个：

方向一：降低丢包

• 检查接口 CRC 计数和 input error
• 测量光模块收发功率和误码率（BER）
• 排查运营商链路是否存在隐性丢包
• 检查交换机缓冲区是否有 Microburst 队列溢出

方向二：绕开 TCP 的窗口限制

调大 TCP 缓冲区，覆盖 BDP 需求（建议 ≥ 32 MB）：

# /etc/sysctl.conf
net.core.rmem_max     = 67108864
net.core.wmem_max     = 67108864
net.ipv4.tcp_rmem     = 4096 87380 67108864
net.ipv4.tcp_wmem     = 4096 65536 67108864
# 切换 BBR（高 RTT 高带宽场景表现更优）
net.ipv4.tcp_congestion_control = bbr

应用层策略：

• 多 TCP 并发连接（对应 iperf3 -P 8），多流聚合可接近链路上限
• 考虑 QUIC 协议或 FEC 前向纠错方案

九、总结

Mathis 公式最大的价值是：在动手优化之前，先算出理论上限。如果实测和理论接近，说明瓶颈就是丢包和 RTT，和带宽无关。

当你再遇到"链路跑不满"、"iperf3 卡住"、"单向速度异常"，不用猜光模块，不用猜限速——