用户态 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 只有 1ms，BtlBw 为 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 透明转发。