测试美国服务器CN2 GIA线路的TCP BBR效果，怎样控制变量对比下载速度？

同一轮测试里更换美国服务器、切换线路、开启BBR，再把单线程下载改成多线程，即使速度提高，也无法判断是哪一个因素起了作用。验证TCP BBR在CN2 GIA线路上的效果，应先固定服务器、客户端、测试文件和下载方式，只切换发送端的拥塞控制算法，再比较重复测试的下载吞吐、完成时间和波动。

最有解释力的对照，是同一台美国服务器、同一条CN2 GIA线路、同一客户端，在相近时间内交替使用CUBIC与BBR下载同一个文件。线路、时段和应用条件应放到后续实验分别验证，不能混进第一轮。本篇采用参考实验和示例数据说明验收方法，表中数值不代表A5IDC某款服务器的实际测试结果。

一、建立基线：先确认下载速度由谁发送、在哪里测量

BBR应该在下载的发送端验证

从美国服务器下载文件到国内客户端时，大块数据的发送端是美国服务器。因此，要比较这次下载的拥塞控制效果，应检查服务器上实际承载下载数据的TCP连接，而不是只查看客户端有没有开启BBR。

BBR根据连接中的带宽与往返时延估计调整发送行为；CUBIC主要通过拥塞窗口增长和拥塞反馈调整发送量。机制不同，并不意味着BBR在所有线路、所有时间段都更快。

CN2 GIA属于线路条件，BBR属于TCP发送端的拥塞控制机制。两者不能相互替代：

• 线路决定路径、时延、可用带宽以及拥塞环境。
• 拥塞控制算法影响发送端如何利用这条路径。
• 实际下载速度还受服务器带宽限制、客户端接入带宽、接收窗口和应用处理能力约束。

如果下载域名经过CDN，客户端接收到的文件可能由CDN边缘节点发送。此时修改源站BBR，不能直接解释客户端下载速度变化。第一轮应使用直连源站的测试地址，并确认实际连接的服务器IP。

把基线写成可核对的记录

基线不只是“开启前下载一次”，而是记录对照条件。建议建立以下实验表：

服务器位于美国，不等于该次下载经过了预期的CN2 GIA路径。可以用路由观测辅助检查，但某个中间节点地址、某一跳的名称，不能单独证明完整线路质量；去程与回程也可能不同。线路身份应结合服务提供方的明确说明和路径记录核对。

中间路由器不回应探测，或者对探测报文限速，也不等于业务流量在该跳丢包。路径观测主要用于发现明显变化，不宜直接作为下载速度结论。

同时记录速度、时间和有效载荷

第一轮至少记录以下指标：

速度与完成时间互相校验，可以发现“文件没下完整”“错误页被当成文件”等问题。例如，完整下载十进制1 GB，也就是1,000,000,000字节，耗时100秒：

平均吞吐 = 1 GB × 8 × 1000 ÷ 100秒 = 80 Mbps。

对应的文件下载速度是10 MB/s。这里采用十进制口径：1 MB为1,000,000字节，1 Mbps为每秒1,000,000比特。工具若显示MiB/s，则使用二进制单位，不能直接把数值当成MB/s。

二、选择变量：第一轮只比较CUBIC与BBR

不把“开启BBR”与一组优化参数绑定

一些配置方法会同时调整拥塞控制、队列规则、TCP缓冲区和其他内核参数。这样可以测试“整套配置是否有效”，却不能证明“BBR本身带来了多少提升”。

第一轮应固定以下项目：

• 不修改TCP收发缓冲区、MTU和网卡卸载设置。
• 不更换内核，不比较不同实现版本的BBR。
• 不同时调整服务器带宽档位和出口线路。
• 不改变HTTP服务配置、压缩方式和连接数量。
• 不在CUBIC组使用一种qdisc、在BBR组使用另一种qdisc。

如果计划验证的是BBR配合fq的效果，应先让两组使用相同的fq环境，再建立基线。这里的结论将是“在该队列规则下，CUBIC与BBR的差异”，而不是把队列变化也算作BBR收益。

需要特别注意：net.core.default_qdisc表示默认队列规则，不等于所有正在使用的网卡已经切换到该规则。实际情况应以tc输出为准。

检查服务器是否具备对照条件

以下示例适用于使用Linux TCP协议栈、具备sysctl、ip、tc和ss工具的服务器。在美国服务器上执行：

uname -r
sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
ip -br link
tc -s qdisc show

tcp_available_congestion_control应能看到计划比较的算法。如果未列出bbr，不能直接照抄切换命令，也不能只凭这一项认定内核完全不支持BBR；应先核验该发行版的内核配置和模块状态。

查看qdisc时，要识别承载下载流量的实际出口网卡。多队列网卡可能显示mq及其下层队列，应查看相关层级，而不是只读第一行。

容器中的设置可能受宿主机内核和网络命名空间限制；应用也可能自行设置TCP_CONGESTION。所以，默认值显示为bbr只是配置证据，实际下载连接显示为bbr才是本轮实验的关键核验项。

临时切换，并保留恢复值

修改默认拥塞控制会影响采用系统默认算法的新建TCP连接，不只影响测试流量。建议在专用测试实例或获准的维护窗口进行，不要直接在繁忙业务服务器上反复切换。

先保存原值，以下操作不写入持久化配置文件：

BASELINE_FILE="$(mktemp /tmp/a5-bbr-baseline.XXXXXX)"
sysctl -n net.ipv4.tcp_congestion_control | tee "$BASELINE_FILE"
printf '基线文件：%s\n' "$BASELINE_FILE"

确认两种算法可用后，分别切换：

sudo sysctl -w net.ipv4.tcp_congestion_control=cubic

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

切换后应重新发起下载。已建立的连接不会因为修改默认值就必然改变算法；应用显式设置算法或监听套接字的行为，也可能影响新连接。因此，每组都需要检查实际连接。

对于HTTPS测试服务，可以在下载期间查看：

sudo ss -tinp '( sport = :443 )'

通过客户端地址和连接端口定位本次下载，核对输出中的拥塞控制名称、RTT和重传等信息。如果实际连接仍使用原算法，应暂停对照并核验应用行为，不能把这次数据记入BBR组。不要仅为让显示值改变而随意重启生产服务。

测试结束后，在保留上述变量的同一Shell中恢复：

sudo sysctl -w "net.ipv4.tcp_congestion_control=$(cat "$BASELINE_FILE")"

如果Shell已关闭，应使用此前记录的基线文件绝对路径。恢复默认值同样不会强制改变已经建立的连接。

三、控制条件：让每次下载具有可比性

使用足够大的静态文件，先测单连接

第一轮宜选用几百MB到数GB的不可压缩静态文件，使下载持续几十秒至几分钟。文件太小，TCP启动、TLS握手和请求延迟占比过高，结果容易变成“谁建立连接更快”，而不是持续传输能力对比。

也不宜无条件使用超大文件：一次传输持续太久，前后两组可能遭遇不同的网络负载。可先试下载，根据速度把正式测试时长控制在约60至120秒；若固定文件导致时长超出，也应记录实际时长，不在两组之间临时更换文件。

服务器应提前消除读盘冷启动的影响，两组使用一致的缓存条件。客户端可以把内容写入/dev/null，排除本地落盘速度，但这只代表网络接收能力；验收真实文件下载体验时，还要另做落盘测试。

下面是客户端命令示例。域名、IP和路径均为占位内容，必须替换为自己的直连测试服务；HTTPS证书应与域名匹配：

date -Iseconds

curl --http1.1 \
  --resolve download.example.com:443:192.0.2.10 \
  --fail \
  --silent \
  --show-error \
  --output /dev/null \
  --write-out 'http_code=%{http_code} remote_ip=%{remote_ip} bytes=%{size_download} seconds=%{time_total} bytes_per_second=%{speed_download}\n' \
  https://download.example.com/test-1gb.bin

这里固定目标IP、使用HTTP/1.1，并且每次独立执行一次单文件请求。正式测试时不要附加并行下载或分段下载选项，也不要让请求自动跳转到其他下载域名。

每次需要确认响应状态符合预期、下载字节数与文件大小一致。speed_download通常以字节/秒表示，换成Mbps应乘8，再除以1,000,000。

该平均速度包含请求及传输过程的时间开销，因此应搭配足够大的文件，并保持两组协议、TLS和请求方式一致。若另用测速工具采集稳定阶段吞吐，不要将它与整文件平均速度混在同一列。

交替测试，避免时段漂移

先连续跑完五次CUBIC，再跑五次BBR，容易把网络随时间变化的趋势算到算法头上。更合理的顺序是成对交替：

1. 完成一次不计入结果的预热下载。
2. 第一对按CUBIC、BBR顺序执行。
3. 第二对按BBR、CUBIC顺序执行。
4. 后续继续交替，每次确认实际连接算法。
5. 至少完成五对；结果波动较大时增加到十对或更多。

同一对测试应尽量靠近，但不要同时运行，以免两条下载流相互竞争。每次之间保持相近间隔，并记录准确时间。期间停止系统更新、备份、大文件上传等竞争任务，客户端也应避免无线信号变化和其他设备大量占用带宽。

下载过程中同步观察服务器CPU、磁盘和网卡流量。若某次恰好遇到明显的后台任务，保留原始记录并标注原因；不能因为结果“不好看”就删除。没有可核实异常原因的低速值，应留在结果中。

保留必要的TCP观测

下载速度回答“是否改善”，TCP状态用于辅助判断“为什么”。

建议在每次下载开始、中段和结束前，以相同方式查看连接状态。重点关注RTT、发送窗口、重传以及是否长期受接收端或应用发送能力限制。不要用一次ss快照代替整段监控，也不要把不同连接的累计计数直接相减。

高RTT路径尤其需要足够的在途数据量。例如，目标吞吐100 Mbps，RTT为170 ms：

带宽时延积 = 100,000,000比特/秒 × 0.17秒 ÷ 8 = 2,125,000字节。

也就是约2.125 MB的在途数据。若接收窗口、应用供数或其他限制不足，即使链路允许100 Mbps，也可能无法持续跑满。发现这类瓶颈后，应单独建立下一轮实验，而不是边测边调，再把改善归因于BBR。

四、观察结果：从参考数据判断提升是否成立

用成对结果，而不是峰值截图

以下为同一美国服务器、同一CN2 GIA线路、同一国内客户端的示例对照数据。两组均使用单连接HTTP/1.1下载，文件为十进制1 GB，队列规则和其他配置保持一致。

按中位数计算：

相对提升 =（87.6 − 74.2）÷ 74.2 × 100% ≈ 18.1%。

按这两个中位吞吐估算，1 GB文件的下载时间分别约为107.8秒和91.3秒，缩短约16.5秒。这里是根据速度换算的时间，正式报告中仍应保留每次工具直接记录的完成时间。

这组数据的解释力不在于出现了89.0 Mbps的高值，而在于五对结果中BBR均高于CUBIC，且两组结果在本窗口内没有重叠。它支持“该测试条件下BBR提升了单连接下载吞吐”，但五对样本仍不足以代表整天或长期表现。

不要从这十次下载里强行给出精确的P95结论。尾部表现需要更多样本，并覆盖业务关心的时间窗口。

验收门槛应在测试前确定

结果验收不能只问“有没有变快”，还要问是否达到业务目标。例如，可以在测试前约定：

• 主要指标：晚高峰单连接下载中位吞吐提高至少10%。
• 一致性要求：多数配对结果同方向改善，而不是只出现一次峰值。
• 体验要求：完整文件下载时间缩短，最慢样本未出现明显恶化。
• 资源约束：服务器CPU和其他业务连接表现没有明显退化。

这些是示例门槛，不是所有CN2 GIA服务器都应达到的标准。带宽已接近套餐上限时，要求再提升10%可能不合理；业务主要下载小文件时，则应把完整请求时间放到更重要的位置。

重传与RTT也需要谨慎解释。BBR吞吐提高，不代表重传一定减少；平均速度变快，也可能同时出现更高的排队时延。验收应根据业务需要同时查看速度、波动和延迟，不能只取最有利的一项。

提升很小时，先区分“没收益”与“没测出来”

两组速度接近，不一定说明配置失败。可能存在以下情况：

发现瓶颈后，不应立即同时更改接收缓冲区、下载线程数和文件服务配置。每改变一个关键因素，都应建立一轮新的对照。

五、复测线路、时段和应用，但保持结论范围清晰

时段变化：每个窗口都重做算法对照

要验证晚高峰效果，应在晚高峰内部重新交替测试CUBIC与BBR，不能拿上午的CUBIC与晚上的BBR直接比较。

以下仍为示例数据：

在网络较空闲、两组都接近限速上限的窗口，BBR可能没有明显的可见收益；在另一个窗口，收益可能更明显。每个窗口都应完整执行对照，而不是借用其他时间的基线。

正式验收可以覆盖多个日期，尤其是业务高峰。若多日配对差值方向一致，比单晚结果更有说服力；若改善幅度小于日常波动，则应增加样本，不急于宣布有效。

线路变化：不要混入算法对照

若还要比较CN2 GIA与其他美国线路，应将其列为第二个实验因素。理想条件是尽量固定服务器计算资源、带宽上限、文件和应用配置，并在每条线路上分别完成CUBIC与BBR对照。

比较不同商家的两台服务器时，CPU、虚拟化环境、出口限速和磁盘也可能不同。因此，这类结果更准确的名称是“两个服务方案的端到端下载对比”，不能把全部差距解释成线路或BBR的作用。

应用变化：单连接收益不能直接套到所有业务

第一轮单连接测试完成后，再分别验证多连接下载、小文件请求或真实业务并发，每轮保持其他条件一致。

多连接可能让两种算法都更接近带宽上限，从而缩小差距。小文件可能尚未进入稳定传输阶段就已完成，持续吞吐收益未必转化为明显的体验提升。若实际应用使用HTTP/3，其传输层基于QUIC，本轮Linux TCP拥塞控制对照也不能直接代表该协议的效果。

用于采购或配置验收的表述，应保留具体条件。例如：

在该美国服务器的CN2 GIA线路、指定国内运营商客户端和晚高峰窗口内，固定单连接HTTP/1.1下载、文件及队列规则后，BBR组中位吞吐高于CUBIC组，达到预先设定的下载速度目标；其他地区、运营商、协议和并发条件需要另测。

测试完成后，保存原始下载记录、内核版本、实际连接算法、队列规则、客户端网络和路径观测。发生内核升级、线路调整、带宽档位变化、客户端运营商变化或应用协议变化时，都应重新建立基线。

对美国服务器CN2 GIA线路而言，BBR效果不是一个脱离条件的固定百分比。只有当算法确实生效、其余条件保持一致、改善能够重复出现时，才能把下载速度变化归因于本轮拥塞控制调整；即便验收通过，也不能据此保证所有时段、所有访问地区或所有应用获得同样提升。

A5数据提供采用CN2 GIA线路的美国常规物理服务器，可承载面向国内访问的跨境网站、文件分发与业务接口，为持续下载和TCP传输优化提供服务器与网络资源基础。其美国服务器产品还覆盖AMD EPYC平台、大内存及NVMe存储配置，为数据库、容器和多任务应用提供计算与存储支持，满足从文件传输到业务后台的多类部署需求。