用户态 TCP 端口转发：对 CUBIC 友好，对 BBR/KCC 收益不大

用户态 TCP 端口转发对 CUBIC 友好对 BBR/KCC 收益不大1. 核心观点用户态 TCP 端口转发gost、rinetd、socat把一条连接拆成两段。这种架构对 CUBIC、Reno、BIC 等丢包驱动算法有一定提升但对 BBR、KCC 等模型驱动算法收益很小甚至可能增加抖动和延迟。IP 透明转发路由 DNAT才是 BBR/KCC 的正确搭档。2. 为什么 CUBIC 能获益CUBIC 不看 RTT 绝对值也不估算瓶颈带宽。它只做三件事没丢包就涨窗有丢包就降窗窗口形状是三次曲线。端口转发让客户端只看到第一段链路短、低丢包。CUBIC 因此疯狂涨窗发包极快。转发器内部缓冲第二段的慢速整体吞吐可能超过直连。代价延迟增加、抖动变大、缓冲区被撑满。但对 CUBIC 来说用户通常接受。3. 为什么 BBR/KCC 收益不大BBR 和 KCC 依赖两个核心测量瓶颈带宽BtlBw最小 RTT传播延迟端口转发破坏了这两项测量。客户端到转发器的链路通常很短1ms, 1Gbps。BBR/KCC 测得的 min_rtt 只有 1msBtlBw 为 1Gbps。它们认为整条路径带宽很高、延迟很低于是把 pacing rate 和 cwnd 推到极大值。但真实瓶颈在第二段200ms, 10Mbps。转发器的接收窗口rwnd和自身拥塞控制会钳制发送速率。客户端虽然以高速率发包但很快被窗口限制数据堆积在转发器 buffer。结果BBR/KCC 看到的 RTT 逐渐变大因为 buffer 积压它们会误判为路径拥塞触发 PROBE_RTT 或降速。最终吞吐反而不如直连——直连时它们能直接看到真实瓶颈平滑调整。这不是 BBR/KCC 跑不满带宽而是端口转发让它们无法准确估计真实瓶颈。4. 一个例外特大缓冲区 Split-TCP如果转发器所在主机的 TCP 缓冲区tcp_rmem/tcp_wmem配置得极大并且转发器自身也运行 BBR/KCC即两端都跑模型驱动算法那么 Split-TCP 模式在极端恶劣的跨国弱网中可能展现出不同的行为。此时转发器就像一个巨大的海绵第一段链路的高速注入被巨量缓冲区吸收第二段链路即使频繁断流或抖动缓冲区也能持续向客户端返回 ACK维持第一段的高速。整体吞吐可能超过直连 BBR。代价缓冲区积压导致 RTT 膨胀到秒级实时性几乎归零。这不是“加速”而是用延迟换死吞吐。这种配置仅适用于对实时性零要求、只求最终完成的极低质量链路例如某些卫星备份线路、极端丢包场景。对于绝大多数要求延迟和抖动的场景视频、游戏、RPC这是灾难。5. IP 透明转发更好用iptables DNAT或策略路由做 IP 层转发不拆连接客户端发出的 TCP 包只改目标 IP原封不动送往后端。后端的 ACK 同样改源 IP 返回。一条完整的端到端连接一套拥塞控制状态。BBR/KCC 能直接看到整条路径的 RTT、丢包、ECN从而精确估计真实瓶颈带宽实现低延迟、高吞吐。6. 什么时候用端口转发只能用 CUBIC/Reno/BIC 的环境旧内核、特定设备。对延迟不敏感、只关心平均吞吐的下行场景如大文件下载。转发器到目标的链路质量接近客户端到转发器此时端口转发退化为近乎直连。极端弱网、实时性无要求、且转发器缓冲区巨大时Split-TCP 双端 BBR 可能换取更高死吞吐。7. 什么时候不用使用 BBR、KCC 等模型驱动算法且对延迟有要求绝大多数现代应用。追求端到端公平性。链路质量尚可不需要用缓冲区掩盖断流。8. 结论用户态 TCP 端口转发对 BBR/KCC 的收益远低于对 CUBIC 的收益。模型驱动算法需要看到真实瓶颈才能精准控制延迟和吞吐。唯一的例外在极端恶劣链路 巨大缓冲区 无实时性要求时Split-TCP 可以换取吞吐代价是延迟爆炸。这是工程取舍不是通用建议。如果你用 BBR 或 KCC 且在乎延迟优先选择 IP 透明转发。