下载文件变大、并发连接增加、峰值请求变密时，访问美国服务器所需的容量，不只是“每秒要传多少数据”，还包括“每条连接能否及时把数据传完”。评估之前，应先区分短请求与持续下载，并明确目标吞吐量、完成时间和峰值并发。

往返时延（RTT）影响TCP吞吐量，是因为发送端不能无限制地发送未确认的数据：它受到拥塞窗口和接收窗口约束，并依赖确认报文推进发送。 当可用窗口不足时，RTT越长，同样大小的窗口每秒能够周转的次数越少；但如果窗口足够、连接持续时间足够长且丢包受控，高RTT并不必然意味着无法跑满可用带宽。

先把业务负载换算成吞吐需求

对美国服务器做容量判断，首先需要明确测的是单连接能力，还是多连接总能力。两者不能相互替代：并发下载可能已经占满带宽，但其中一条TCP连接的下载速度仍然达不到业务要求。

可以用以下变量描述负载：

对于持续输出数据的业务，应用层总吞吐需求可近似写为：

G需求 = λ × S

一个大小为S的数据对象若要求在T秒内完成传输，所需平均吞吐为：

G任务 = S ÷ T

这里尚未计入协议开销、重传和建连等待。如果T还包含连接建立、服务端处理等时间，就要先扣除这些时间，再计算实际数据传输阶段需要的速率。

不同大小的请求最好分别统计。平均值可能掩盖大文件的带宽压力，也可能掩盖短请求对RTT的敏感程度。

RTT怎样通过窗口限制TCP吞吐量

窗口决定可以有多少数据“在路上”

TCP发送端主要受到两个窗口约束：

• 拥塞窗口cwnd：发送端根据网络反馈维护，用于控制网络中的在途数据量。
• 接收窗口rwnd：接收端通告的可接收数据量，用于防止接收缓冲被压满。

在应用持续提供数据的前提下，可用在途数据预算近似为两者的较小值。若统一按字节计量，可写为：

W有效 ≈ min(cwnd, rwnd)

对于稳定传输、窗口是主要限制因素的连接：

G窗口 ≈ W有效 ÷ RTT

RTT使用秒，结果为字节/秒。换算成bit/s时，还要乘以8。

这并不表示TCP必须“发完一整窗，再停下来等一整轮确认”。实际传输使用滑动窗口，确认不断返回，发送端也不断补发数据；公式表达的是在途数据预算与反馈周期之间的关系。

在有效窗口不变且窗口确实构成瓶颈时，RTT增大，单连接吞吐量会近似按反比下降。 如果瓶颈是带宽上限或应用供数速度，就不能直接套用这个比例。

带宽时延积决定需要多大的在途数据量

若希望达到目标速率B，需要的在途数据量可用带宽时延积估算：

BDP = B × RTT

当B以bit/s计、RTT以秒计时，BDP单位为bit；除以8才是字节。

BDP可以理解为：为了让发送过程连续，在一轮反馈时间里需要有多少数据留在路径上。访问美国服务器时，如果目标吞吐提高，或实测RTT增大，所需窗口也会随之增加。

但接收缓冲配置大于BDP，不代表吞吐一定达标。接收窗口只是条件之一，拥塞窗口、应用发送能力和实际可用带宽也必须满足要求。高RTT也不能作为无限扩大缓冲的理由，因为队列积压本身可能进一步抬高RTT。

短传输还受到窗口增长速度影响

新TCP连接通常不会立即以路径最大容量发送，而是通过慢启动等机制逐步增加在途数据。窗口增长需要确认反馈，RTT越长，完成若干轮增长所需的实际时间通常越长。

因此，同一条路径可能出现两种不同表现：

• 持续大文件传输有时间完成爬升，稳态吞吐较高。
• 小文件或短连接在窗口尚未充分增长时就已结束，平均有效吞吐偏低。

丢包也会改变结果。拥塞控制可能因丢包或其他拥塞信号收缩窗口，恢复过程又依赖反馈；具体影响取决于拥塞控制算法、丢包模式及恢复机制，不能只凭RTT套用一个固定比例。

用受控测试区分窗口瓶颈与带宽瓶颈

测试应限定在自有或已获授权的客户端与美国服务器之间，并确认允许的测试时段、并发量和带宽占用。满速测试可能影响同路径上的正常业务，不宜直接在业务高峰执行。

固定测试条件

每组测试至少记录：

• 两端位置、测试方向、时间段、工具版本和拥塞控制算法。
• 单连接或多连接、测试持续时间，以及是否复用连接。
• 空闲RTT、传输期间的TCP RTT、重传、接收端吞吐。
• 两端CPU利用率及接口流量，排除明显的本地资源瓶颈。

测试下载时，美国服务器是数据发送端，应重点观察其发送侧TCP状态。上传与下载要分别测量，不能用一个方向的结果代表另一个方向。

先测单流，再测受控并发

在两端已安装iperf3、测试端口已经获准通信的环境中，可先运行版本检查：

iperf3 --version

美国服务器端启动测试服务：

iperf3 -s

客户端测试服务器向本地发送数据：

iperf3 -c <服务器地址> -R -t 30

随后在相同条件下进行多连接对照：

iperf3 -c <服务器地址> -R -P 4 -t 30

其中30秒与4条并行连接只是测试参数示例，不是性能结论或推荐生产配置；应根据获准的负载范围调整。测试结束后可用Ctrl+C停止服务。

若连接被拒绝或超时，先核对地址、服务监听状态及既有访问策略，这类失败本身不能说明RTT限制了吞吐。若曲线到测试结束仍持续爬升，应在授权范围内延长时长，再判断稳态能力。

Linux环境下，还可在发送端使用以下命令查看连接状态：

ss -tin

应定位目标测试连接，而非混看所有连接。不同系统版本输出字段可能不同，重点关注RTT、cwnd、MSS和重传变化。部分输出中的cwnd以报文段为单位，与BDP比较前需要结合MSS换算成字节。

怎样解释结果并计算容量余量

不要只保存一个平均速度。应同时保留启动阶段、稳定阶段和波动情况，并以接收端实际收到的数据量核对吞吐。

多流测试不能单独证明“窗口太小”；它只是对照证据。要确认窗口限制，应看到窗口量级相对目标BDP不足，并排除应用供数不足等因素。

容量规划可分别计算：

未来需求 = 当前峰值需求 × (1 + g)

容量余量率 = 1 - 未来需求 ÷ 实测可持续有效吞吐

这里的“实测可持续有效吞吐”应取多次代表性测试中可稳定维持的水平，而不是最高瞬时读数。单任务还要单独满足完成时间要求：总吞吐有余量，并不代表每条TCP连接都有足够性能。

窗口需求应使用目标速率和代表性负载下的RTT估算，但不要机械追随严重拥塞时被队列拉高的RTT，否则可能把排队问题误判为单纯缺少缓冲。

用复测结果确定扩容触发点

复测应保持方向、并发数、传输时长和连接复用方式一致，覆盖多个代表性业务时段；变更后尽量一次只改变一个变量。这样才能判断改善来自窗口、连接行为，还是可用容量变化。

监控阈值应同时覆盖三个维度：

• 单连接目标：代表性RTT下的单流吞吐是否持续低于任务需求。
• 总容量余量：计入增长后的峰值负载，是否开始逼近可持续有效吞吐。
• 服务质量：请求完成时间分位值、负载RTT和重传是否同步恶化。

具体阈值应通过逐级增加受控负载，找到吞吐不再有效增长、RTT开始明显抬升或完成时间接近业务上限的拐点，再结合增长预期与扩容准备周期预留余量。

如果单流受窗口限制、总带宽仍有明显空闲，单纯增加带宽未必有效；如果单流和多流都已经达到共享容量上限，且持续逼近业务要求，增加可用容量才更有依据。访问美国服务器时，真正需要判断的不是“RTT是否偏高”，而是在这个RTT下，窗口、持续传输时间和可用带宽能否共同支撑目标负载。