Reno-RNA是为解决传统TCP拥塞控制在高延迟网络中误判非拥塞丢包的问题而设计的Reno改进方案，其核心是在拥塞控制前增加丢包类型识别层，区分随机丢包、主动丢包与拥塞丢包，避免无效窗口减半，提升长肥网络吞吐稳定性。
在高延迟网络（如跨洲际链路、卫星通信或弱信号移动网络）中，传统拥塞控制算法（如 Reno 或 Cubic）容易误判丢包为拥塞，频繁收缩窗口，导致吞吐量骤降、带宽利用率低下。此时不能只看“带宽”，更要结合带宽 × 往返时延（BDP，Bandwidth-Delay Product）来评估真实传输潜力，并据此选择和配置更适应的拥塞控制算法。
先算清楚你的网络 BDP
BDP 决定了“管道里最多能塞多少数据”，是设置接收/发送窗口和选择算法的基础：
- 用
ping或mtr测出典型往返时延（RTT），例如 200ms - 用
iperf3 -c server测出稳定可用带宽，例如 100 Mbps（即 12.5 MB/s） - 计算 BDP = 带宽 × RTT = 12.5 MB/s × 0.2 s = 2.5 MB
- 这意味着：TCP 窗口至少要接近这个值（如设为 2–4 MB），才可能填满管道；若默认窗口仅 64 KB，99% 的带宽就空转了
选对算法：BBR 是高延迟场景的首选
传统算法依赖丢包作为拥塞信号，在高延迟下反应迟钝、激进退窗；而 BBR（Bottleneck Bandwidth and RTT）不靠丢包，而是主动探测带宽和最小 RTT，更适合长肥管道（Long Fat Network, LFN）：
- Linux 4.9+ 内核原生支持 BBR；启用命令：
echo "net.core.default_qdisc=fq" > /etc/sysctl.conf<br>echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf<br>sysctl -p
- 验证是否生效：
sysctl net.ipv4.tcp_congestion_control应返回bbr - BBR v2 进一步优化公平性和多流竞争，如内核 ≥ 5.10，建议升级并启用：
net.ipv4.tcp_congestion_control=bbr2
配套调优：让 BBR 发挥全部能力
单换算法不够，还需调整底层支撑参数：
-
增大 TCP 接收/发送缓冲区：避免 BBR 探测到的带宽被系统缓冲区卡住
→ 设置：net.ipv4.tcp_rmem="4096 524288 4194304"（min/default/max，单位字节）
→ 同理设置tcp_wmem，max 值建议 ≥ 2×BDP -
启用 TCP 窗口缩放（Window Scaling）：否则窗口上限被限制在 65535 字节，无法满足大 BDP
→ 确保net.ipv4.tcp_window_scaling = 1（默认开启，建议显式确认） -
禁用延迟 ACK（对交互类流量慎用）：高延迟下，等待 200ms 才回 ACK 会拖慢 BBR 的 RTT 采样频率
→ 应用层可设TCP_QUICKACK；或全局缩短：net.ipv4.tcp_delack_min = 1（单位 ms）
绕不开的现实：应用层也要配合
再好的内核算法，也受限于应用行为：
- 服务端务必及时从 socket 读取数据——否则接收窗口无法及时通告增大，发送方仍被压着发
- 避免在每条消息后
sleep(1)或同步阻塞写入，这人为引入毫秒级停顿，破坏 BBR 的连续探测节奏 - 如使用 HTTP，优先选 HTTP/2 或 HTTP/3（基于 QUIC），它们原生支持多路复用与更细粒度的流控，比 TCP+HTTP/1.1 更适配高延迟
