Ubuntu 26.04香港节点调优CN2 GIA TCP参数，如何验证延迟与吞吐变化？

测速从180 Mbps提高到195 Mbps，不一定意味着跨境电商页面更快；空载延迟保持在40毫秒，也不代表促销期间的接口响应不会超过1秒。香港节点的TCP调优是否有效，要同时看空载与负载下的延迟、单连接与多连接吞吐、业务尾延迟，以及CPU和内存代价，不能只比较一张测速截图。

对于Ubuntu 26.04上的CN2 GIA香港节点，可靠的验证方法是：固定大陆测试端、香港服务器、业务负载和测试时段，先记录原始参数，再分组调整TCP缓冲区与拥塞控制算法，最后判断吞吐收益是否伴随排队延迟、重传或资源占用上升。TCP参数可以改善主机对链路的利用方式，但不能降低物理传播时延，也不能把受限带宽或拥塞线路变成更高容量的线路。

一、先把“调优成功”改成可测量的目标

跨境电商香港节点通常承担两类不同负载：商品页、订单接口等小响应请求，以及商品图片、导出文件等较大对象传输。前者更关心完成时间与尾延迟，后者更容易受到接收窗口、拥塞窗口和带宽限制。

因此，测试前应明确要解决哪一种问题。

可以给一轮测试设定这样的验收线：在相同负载下，单连接吞吐提升至少10%，业务P95不劣化超过5%，错误率保持在业务允许范围内，且服务器仍有资源余量。这是示例验收线，而不是所有节点都应达到的通用标准。若原来已接近带宽上限，吞吐只增加几个百分点也可能合理；若订单接口本来就接近超时边界，尾延迟轻微上升也可能不可接受。

Ubuntu 26.04必须核对实际运行环境

发行版名称不能代替内核和网络栈信息。云镜像、升级镜像以及自定义内核，可能具有不同的默认参数、拥塞控制算法和队列规则。不要直接套用其他Ubuntu版本的“默认值”。

先记录：

cat /etc/os-release
uname -r
sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem
sysctl net.core.rmem_max net.core.wmem_max
ip route get 1.1.1.1
tc -s qdisc show

最后两项用于了解默认出口与队列配置。多网卡、多路由环境还应对真实测试端地址执行ip route get，确认业务流量实际经过的接口。

“CN2 GIA”应结合服务提供方的线路说明及大陆测试端的路径表现判断，不能只凭一次路由输出中的某个地址识别。去程和回程可能不同，不同大陆运营商也不应混为一组结果。

二、读懂四组指标，避免把带宽提升当成延迟优化

1. 空载RTT与负载RTT：区分基础距离和排队

空载RTT主要反映传播、路由转发和少量处理开销。TCP参数通常不会明显改变它。

负载RTT则是在传输或业务压力存在时测量的往返时间。它比空载RTT高出的部分，可用于观察排队膨胀，但不能简单认定全部来自香港服务器。

例如，一组参考结果中：

• 空载RTT中位数为42毫秒；
• 原配置满载时RTT中位数为110毫秒；
• 调整后满载时RTT中位数为65毫秒。

这说明基础路径没有明显变化，而负载下的排队表现改善了。反过来，如果测速更快，但满载RTT从110毫秒涨到220毫秒，交互请求可能变慢。

ICMP可能被限速或低优先级处理，所以ping适合做趋势对照，不宜单独作为页面体验的证据。应同时保留HTTPS请求耗时和TCP状态。

2. 单连接与多连接吞吐：分别回答不同问题

单连接吞吐能暴露一个TCP流是否受窗口、丢包或拥塞控制限制。多连接吞吐更接近多个用户共同占用链路的情况，但会掩盖单流问题。

如果单连接只有60 Mbps，而四连接合计达到190 Mbps，不能说线路只能跑60 Mbps，也不能说单个大文件已经能跑190 Mbps。应继续检查单流的接收窗口、拥塞窗口、重传及测试端能力。

带宽延迟积可以帮助判断缓冲区量级：

带宽延迟积 = 链路速率 × RTT，用来估算填满路径所需的在途数据量。

以200 Mbps、60毫秒RTT为例，采用十进制单位：

200,000,000 bit/s × 0.060 s ÷ 8
= 1,500,000 byte
= 1.5 MB
≈ 1.43 MiB

如果可用接收窗口长期只有256 KiB，那么按窗口除以RTT估算，上限约为：

262,144 byte × 8 ÷ 0.060 s
≈ 34.95 Mbps

这是忽略协议开销、丢包和应用停顿的估算，不是测速承诺。它的价值在于指出：窗口不足可能限制吞吐；窗口已经足够时，继续扩大上限未必有收益。

3. P95/P99与错误率：判断收益是否到达业务层

P95表示95%的样本不超过该值。平均响应时间变好，不能证明慢请求减少了。

请求耗时还要分层理解：

• TCP建连时间主要反映连接建立过程；
• TLS握手时间包含额外往返和加密处理；
• 首字节时间还包含服务器处理、数据库访问等；
• 总完成时间进一步包含响应体传输。

开启连接复用后，大量请求不再支付完整建连成本；经过CDN访问时，浏览器看到的也不一定是香港源站性能。因此，验证香港节点TCP参数时，应区分直连源站测试与真实用户访问链路。

计算P99需要足够样本。几十次请求中的“最慢一次”不能替代稳定的P99；业务压测宜积累数千至上万次请求，并保持对象大小和请求类型一致。

4. CPU、内存和I/O：解释网络指标为什么停住

吞吐停止增长，并不一定是线路到顶。

如果单个CPU核接近满载，其他核心较空闲，可能是单线程测试程序、TLS处理或软中断成为瓶颈。只看整机CPU平均值，会漏掉这种情况。

如果扩大TCP缓冲区后socket内存明显增加，同时业务缓存被挤压，调优可能将网络瓶颈转移到内存。tcp_rmem和tcp_wmem的最大值并不意味着每个连接立即分配这么多内存，但也不能据此忽略高并发下的实际占用。

文件下载还可能受磁盘影响。iperf3主要用于观察网络传输，不能证明真实文件服务同样快；后者还需对照磁盘延迟、吞吐和应用处理时间。

三、只调整能解释当前瓶颈的参数

缓冲区上限：按带宽延迟积和并发规模选择

Linux TCP通常具备缓冲区自动调节能力。tcp_rmem、tcp_wmem分别包含最小值、默认值和最大值，首先应检查实际连接是否受窗口限制，再考虑提高最大值。

对于前述200 Mbps、60毫秒的示例，数MiB级别已经值得测试，不需要直接设置数百MiB。16 MiB可以作为一组对照上限，但不是推荐给所有香港节点的固定答案。

net.core.rmem_max和net.core.wmem_max主要约束应用通过socket选项请求的缓冲容量；TCP自动调节还受TCP自身上限和系统内存压力影响。应用主动设置socket缓冲区时，行为也可能不同，必须结合实际连接观察。

下面示例仅用于已获授权、可维护的测试服务器：保存原值，保留TCP最小值和默认值，只将低于16 MiB的上限提高到16 MiB。

# 在root shell中执行；只修改当前运行参数，不写入永久配置。
backup="/root/tcp-before-$(date +%Y%m%d-%H%M%S).conf"

sysctl \
  net.ipv4.tcp_congestion_control \
  net.ipv4.tcp_rmem \
  net.ipv4.tcp_wmem \
  net.core.rmem_max \
  net.core.wmem_max > "$backup"

target=16777216

read -r rmin rdefault rmax < <(sysctl -n net.ipv4.tcp_rmem)
read -r wmin wdefault wmax < <(sysctl -n net.ipv4.tcp_wmem)

(( rmax < target )) && rmax=$target
(( wmax < target )) && wmax=$target

sysctl -w "net.ipv4.tcp_rmem=$rmin $rdefault $rmax"
sysctl -w "net.ipv4.tcp_wmem=$wmin $wdefault $wmax"

for key in net.core.rmem_max net.core.wmem_max; do
  current=$(sysctl -n "$key")
  if (( current < target )); then
    sysctl -w "$key=$target"
  fi
done

printf '回滚文件：%s\n' "$backup"

这些修改影响主机上的TCP行为，不只影响测速程序。应在维护窗口操作，保留原值，并为每组测试建立新连接。回滚方式是：

# 替换为上一段输出的实际备份文件。
sysctl -p /root/tcp-before-YYYYMMDD-HHMMSS.conf

回滚后也应重新建立测试连接，避免旧连接状态干扰比较。容器环境还需确认参数所属的网络命名空间。

拥塞控制：比较CUBIC与BBR，而不是预设胜负

拥塞控制影响发送端如何增加发送速率、如何响应拥塞信号。CUBIC与BBR都可以作为候选，但BBR并非在所有路径上都能同时提高吞吐、降低延迟。

先确认可用算法：

sysctl net.ipv4.tcp_available_congestion_control

仅当输出包含bbr时，才在测试窗口切换：

# 原值应已保存在前面的备份文件中。
sysctl -w net.ipv4.tcp_congestion_control=bbr

若不可用，应先核对镜像的内核配置和模块支持，不要把其他版本的加载命令直接套用。也不要仅凭bbr名称推断其具体实现版本。

队列规则同样影响发送节奏。fq支持按流调度和pacing，但云主机可能使用多队列或服务商定制配置，不能为了套用模板而直接替换现有qdisc。改变队列会影响其他业务，应作为单独实验，不与缓冲区、拥塞控制一次性混改。

还要注意方向：香港向大陆下载，关键发送端在香港；大陆向香港上传，拥塞控制主要由大陆测试端决定。只修改香港服务器，不能期待两个方向获得相同收益。

不把其他参数塞进“通用优化包”

tcp_nodelay是应用socket选项，是否使用取决于应用发送方式；小请求、长连接和大文件传输的需求不同。

监听队列、文件描述符上限等参数，只有出现连接接入压力时才值得单独评估。它们不能直接提高稳定连接的跨境吞吐。为了测速关闭TCP时间戳或窗口扩大，也可能破坏原有能力。

能定位到窗口不足，就测试窗口；能定位到发送行为差异，就测试拥塞控制。没有瓶颈证据时，保留默认值通常比批量改参数更可解释。

四、建立对照：网络测试和业务测试必须同时保留

固定测试端与时间窗口

大陆测试端应覆盖实际用户来源，例如电信、联通、移动分别采样；每组记录城市、接入方式和时间段。家庭Wi-Fi、本地下载任务、测试机CPU不足，都可能制造虚假的“香港节点瓶颈”。

至少比较三组：

若原算法已经是BBR，就不必重复切换到BBR；选择有意义的对照即可。按A、B、A或A、B、C、A交错测试，有助于识别时段波动。建议每组重复至少5轮，同时保留业务高峰和非高峰结果。

分别测单流、多流和满载延迟

以下命令需要预先准备iperf3。监听端口仅允许获授权的测试端访问；不要在生产节点上开放无人限制的测速服务。测试会消耗真实带宽，应避开业务峰值，并确认不会超过流量预算。

香港测试服务器执行：

# 将地址替换为香港服务器实际拥有的测试IP。
HK_IP="香港服务器测试IP"
iperf3 -s -B "$HK_IP" -p 5201

大陆测试端分别执行：

HK_IP="香港服务器测试IP"

# 大陆发送、香港接收：单连接。
iperf3 -c "$HK_IP" -p 5201 -t 60 -O 5 -J > upload-p1.json

# 香港发送、大陆接收：单连接。
iperf3 -c "$HK_IP" -p 5201 -t 60 -O 5 -R -J > download-p1.json

# 香港发送、大陆接收：四连接合计。
iperf3 -c "$HK_IP" -p 5201 -t 60 -O 5 -R -P 4 -J > download-p4.json

以接收端报告的有效吞吐为主，同时检查发送端重传和两端CPU。四连接结果是合计值，不是每条连接的吞吐。

每组分别记录空载与传输期间的延迟：

ping -D -i 0.2 -c 300 "$HK_IP" > ping-idle.txt

满载时，在另一个终端执行同样命令并保存为ping-loaded.txt。默认汇总没有P95，若需分位数，应从逐条RTT样本计算，而不是把最大值当成P95。

测试结束后停止监听进程。本文不要求修改防火墙；若测试必须调整访问规则，应另行备份规则、限定来源，并在完成后恢复。

同步观察TCP与主机资源

香港服务器在传输期间记录：

ss -tin '( sport = :5201 or dport = :5201 )'
ss -mtn '( sport = :5201 or dport = :5201 )'
cat /proc/net/sockstat

ss输出随内核和工具版本变化，可关注RTT、拥塞窗口、重传、发送/接收缓冲状态，以及可见的接收窗口限制、发送缓冲限制等信息。没有某个字段，不代表对应限制不存在。

若已安装sysstat，同步观察：

mpstat -P ALL 1
iostat -xz 1

重点看是否有单核或软中断压力、磁盘延迟上升。虚拟机还应留意CPU steal；它升高时，即使TCP参数相同，结果也可能因宿主机争用而变化。

用固定业务对象验证收益

网络对照后，再测试固定大小的商品图片、只读接口或静态对象。不要使用会创建订单、扣库存的请求做无隔离压测。

URL="https://业务测试域名/固定测试对象"

curl -sS --max-time 15 -o /dev/null \
  -w 'code=%{http_code} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} bytes=%{size_download}\n' \
  "$URL"

这些时间字段是从请求开始计算的累计时间。分析TLS阶段时，应结合建连时间理解；首字节时间也不是纯应用处理时间。

该命令只验证单次请求，不能代替并发压测。业务测试应固定连接复用方式、缓存命中条件、请求到达速率和对象大小，并记录失败请求。只比较成功响应，可能把超时样本排除后得到虚假的改善。

五、如何解释结果：吞吐增加，也可能不值得上线

下面是一组用于说明判断方法的参考数据，并非A5IDC节点实测。场景为200 Mbps链路、同一大陆测试端访问香港，HTTP数据来自固定业务压力，网络满载RTT来自同步测速。

A到B，单连接吞吐提高约35.7%，四连接却只小幅变化，说明原配置可能限制了单流效率，而总带宽已经接近可用上限。但B的满载RTT和HTTP P95变差，因此不能仅凭单流测速就上线。

B到C，吞吐继续提高，排队延迟和业务P95同时下降，这才构成更完整的正面证据。不过CPU也上升了，还要检查最忙核心及高并发余量。

吞吐更高，完成时间究竟减少多少

传输一个十进制20 MB对象，只考虑稳定数据传输：

20 MB × 8 = 160 Mb

126 Mbps：160 ÷ 126 ≈ 1.27秒
184 Mbps：160 ÷ 184 ≈ 0.87秒

理论传输阶段缩短约0.40秒，但没有计入DNS、握手、慢启动和应用等待。实际结果应以完整请求耗时验证。

如果对象只有20 KB，就不能按测速带宽推断明显收益。这类请求往往更受往返次数、连接复用和服务器处理时间影响。

三种常见的反面解释

吞吐提高，但负载RTT和P99变差： 对大文件传输可能有价值，对订单、支付回调等交互业务可能不合适。可考虑控制批量传输负载，而不是继续扩大缓冲区。

更换算法后不同运营商表现相反： 应分别评估，不能用一个平均值覆盖差异。若主要用户来源退化，就不能把结果称为业务优化。

算法变化不大，但CPU或I/O已饱和： 当前限制不在TCP。继续修改参数通常无效，应先处理应用计算、存储或虚拟化资源争用。

重传也要规范比较：同等时长、近似数据量下才容易理解绝对次数。吞吐变高意味着发送数据更多，重传数量增加不一定代表重传比例恶化。

六、上线边界与复测：留下足够容量，而不是追求跑满

调优结果至少应通过三道判断。

第一，收益能够重复出现。多轮配对结果整体改善，幅度高于正常波动，而不是只有最快一轮更好。

第二，业务指标没有被牺牲。主要用户来源的P95/P99、错误率、完整响应时间均可接受；吞吐改善没有明显增加满载排队。

第三，资源仍有余量。最忙CPU核、socket内存、业务缓存和磁盘延迟没有逼近危险区间。测试稳定后，才考虑写入持久化配置，并保留基线值和变更记录；一轮测速通过，不等于适合长期使用。

容量判断可以从业务流量做粗估。采用十进制单位，若平均响应体为250 KB、峰值为60请求/秒：

250,000 byte × 60 /s × 8
= 120,000,000 bit/s
= 120 Mbps

这个估算未计入协议开销、重传、图片突发及其他业务流量。对200 Mbps节点，120 Mbps只是响应体平均需求，不能据此认定还可以无条件增加约67%的请求。

更实用的方式是逐级增加请求到达速率，观察P95何时明显弯折、错误率何时上升、最忙核心是否饱和，以及负载RTT是否开始持续膨胀。容量应留在这些拐点之前，并为促销流量和线路波动保留余量。

当Ubuntu内核、镜像、队列规则、实例规格、业务响应大小、连接复用方式或线路路径发生变化时，应重新测试；主要运营商晚高峰出现持续退化，也应回到原对照方法复核。保留参数快照、原始测速文件、业务延迟分布和资源监控，才能回答下一次变化究竟来自TCP设置、服务器容量，还是跨境链路本身。