跨境专线标称 1 Gbps，单连接却只有 40～60 Mbps，换到近端服务器就能跑满。CPU与出口都未饱和，运维常归咎线路质量。高延迟链路先撞上的往往是带宽时延积：往返越久，维持吞吐所需的未确认数据越多，线路再宽也会卡在等待确认。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：七九网络（服务器与主机），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
一、200 毫秒 RTT 下，窗口就是吞吐闸门
设链路速率 C、往返时延 R，所需带宽时延积为 C×R；若 TCP 有效窗口为 W，单连接吞吐上限近似 W÷R。200 毫秒 RTT 下，10 Mbps 业务约需 2 MB 的带宽时延积；窗口若只有 128 KB，吞吐仅约 5 Mbps，离百兆目标差近 20 倍。
接收端用窗口字段通告空间，窗口缩放因子可把传统 16 位窗口扩展到 MB 级；协商失败或缓存偏小，有效窗口会停在 KB 级。发送端还受发送缓冲区上限约束，超量数据只能排队，持续 write 也绕不过去。
ACK 返回前，发送端无法无限灌入数据。cwnd 足够而接收窗口偏小时，流量常呈“冲高后等待”；路径丢包又会使拥塞窗口下降。放大缓冲区只能缓解窗口限制，未必改善丢包和排队，BDP 不是低吞吐的唯一答案。
二、用往返时延采样锁定真正的瓶颈
先抓真实流量，记录往返时延采样、窗口通告、缩放因子、cwnd、重传率和零窗口时长。ss -tin 可查看 RTT、cwnd、unacked、rwnd，同时核对两端 socket 缓冲区。单次下载测速会受并发和超时干扰，不能代替窗口观测。
若 RTT 为 200 毫秒，rwnd 长期低于 BDP 需求而 cwnd 尚有空间，先查TCP接收窗口与缩放协商；若 sndbuf 已满、unacked 偏低，瓶颈更靠发送端；若重传频繁、cwnd 被压低且应用写入很快，应查路径丢包和拥塞。
应用读取慢也会伪装成线路慢。接收端久不调用 read，窗口收缩并触发零窗口，发送端只能等待。观察接收队列并做延后读取实验：若网络稳定、窗口随业务停顿下降，根因就是消费速度。窗口取值还应考虑突发量、代理跳数与 RTT 抖动。ServLlama 可集中采集主机和链路指标，关联 RTT、窗口与读取停顿。
从窗口推导吞吐上限
在无丢包的理想条件下，链路能长期保持的数据量首先受两端窗口约束。带宽为 B、往返时延为 R 时，填满管道所需的窗口应覆盖带宽时延积，即 B×R。以 100 Mbit/s、200 ms 为例，BDP 约为 2.5 MB；若接收端只公布 256 KB 的TCP接收窗口，吞吐便难超过 256 KB÷0.2 s≈10 Mbit/s。接收窗口并非必然只有 64 KB，启用窗口缩放因子后，双方可在握手中协商更大窗口；核查时应看实际缩放值和通告窗口，不能只看基础参数。
实际可发数据还受拥塞窗口、发送端 socket 的发送缓冲区上限、网卡队列及驱动描述符限制，任一环节偏小都会让长肥管道无法铺满。反过来，缓冲区过大也未必更优：应用持续灌入而队列管理不当时，会形成 bufferbloat，排队时延上升后引发丢包和重传，短时速率看似很高，持续吞吐却会下降。
用采样排除误判
往返时延采样最容易踩坑。空闲 ping 得到的是基础 RTT，满载 RTT 才接近排队后的真实值；应同时采样空闲、稳态负载和重传期间的数据，并用中位数与高分位数观察波动。只测一次，遇到瞬时丢包或队列膨胀，就会把 BDP 和窗口需求算错。抓包还应核对 Window Update、零窗口事件及接收窗口通告，因为接收端更新过慢时，即使带宽充足也会停顿。
另一个误区是把系统参数直接等同于端到端能力。不同内核对 sndbuf、rmem 的记账方式不同，TSO、GSO、卸载和 qdisc 也会改变报文观测。可执行检查清单：①用 iperf3 做多档时长、并发数的持续测试，记录吞吐、CPU、重传和时延；②确认窗口缩放协商及实际通告窗口；③按带宽和实测 RTT 计算 BDP，检查接收窗口、拥塞窗口和发送缓冲区是否留有抖动余量；④同时采集接口、qdisc 与 TCP 指标，区分链路丢包、接收端限速和本地排队；⑤调参后持续复测数分钟。只有窗口、缓冲、时延与丢包共同匹配，测算出的上限才可用于容量规划。
喜欢 
顶
难过
囧
围观
无聊
