CN2线路TCP调优是否有效？香港服务器Linux内核5.15如何做单变量验证

在香港服务器上使用 Linux 内核 5.15 调整 CN2 线路 TCP 参数，可能有效，但不会自动改善线路本身的路由、物理时延或运营商侧拥塞。只有当瓶颈确实来自拥塞控制、TCP 窗口、路径 MTU 或连接空闲后的发送策略时，调优才可能带来吞吐提升；如果测试期间 CN2 路由发生变化、跨境链路拥塞或对端接收能力不足，单纯修改服务器内核参数通常无法得到稳定收益。

判断“调优有效”不能只看一次下载速度。应先固定香港服务器、测试客户端、端口、文件或测试时长，再分别观察 ping 延迟、traceroute 路径、TCP 实际吞吐、重传、拥塞窗口和 CPU 利用率。若路径和 RTT 基本不变，只有一个 TCP 变量发生改变，同时连续多轮吞吐提升且重传、延迟没有明显恶化，才能把结果归因于该参数。

先定义什么叫“有效”

CN2 线路的验收目标通常不是单一数值。对于香港服务器与固定测试端之间的 TCP 传输，至少要同时观察以下指标：

可以采用一个明确的验收条件作为参考：同一时间窗口内进行至少三轮基线测试和三轮参数测试，测试结果的吞吐中位数提升达到约 10%，同时 P95 RTT 没有明显升高、重传没有持续增加，且路径没有发生明显变化。这个 10% 只是便于判断的参考门槛，低延迟业务、长连接业务和大文件传输业务可以分别设置不同门槛。

如果基线三次吞吐分别为 280、290、288 Mbps，参数测试为 322、330、326 Mbps，则测试中位数从 288 Mbps 提升到 326 Mbps，提升约为：

（326 - 288）÷ 288 × 100% ≈ 13.2%

如果这期间 ping 中位 RTT、TCP 路径和服务器负载基本相同，才具备继续保留该参数的依据。

建立香港服务器的基线

固定测试条件

单变量验证最容易被忽略的部分不是命令，而是测试条件。每一轮测试应尽量固定以下内容：

• 同一台香港服务器、同一个公网 IP 和同一个业务端口。
• 同一台测试客户端，测试客户端的网络接入、系统参数和网卡不变。
• 同一个传输方向。服务器向客户端发送和客户端向服务器发送，不是同一个实验。
• 同一种测试工具、相同的并发数、相同的测试时长。
• 测试前后尽量保持相同的时间段，避免把高峰时段和低峰时段直接比较。
• 不要在同一轮同时修改拥塞控制、TCP 缓冲区、队列规则和 MTU。
• 测试期间暂停大规模备份、镜像同步、系统更新等额外流量。
• 如果使用生产端口，优先选择低峰维护窗口；如果使用 iperf3，必须使用经过授权的测试客户端。

CN2 线路的路径可能随着目标地址、运营商、时间段和路由策略变化。即使服务器配置完全不变，也可能出现 RTT 或吞吐波动。因此，测试客户端不能频繁更换，否则无法判断变化来自服务器参数还是接入网络。

记录内核、路由和 TCP 参数

在香港服务器上先记录 Linux 版本、网卡状态、路由和当前 TCP 配置。以下命令只读取信息，不会修改系统：

uname -r
cat /etc/os-release

ip -br addr
ip -br link
ip route

sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_window_scaling
sysctl net.ipv4.tcp_mtu_probing
sysctl net.ipv4.tcp_slow_start_after_idle

sysctl net.core.rmem_max
sysctl net.core.wmem_max
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem

ss -s
ip -s link

uname -r 应确认实际运行的是 5.15 系列内核，而不是已经安装但尚未启动的其他内核。/etc/os-release 用来确认发行版，因为不同发行版对 sysctl 配置文件的加载顺序可能不同。

保存一份只读基线也很有必要：

mkdir -p "$HOME/cn2-tcp-validation"
{
  date -Is
  uname -a
  sysctl net.ipv4.tcp_congestion_control
  sysctl net.ipv4.tcp_available_congestion_control
  sysctl net.core.rmem_max
  sysctl net.core.wmem_max
  sysctl net.ipv4.tcp_rmem
  sysctl net.ipv4.tcp_wmem
  ip route
  ss -s
  ip -s link
} | tee "$HOME/cn2-tcp-validation/baseline-host.txt"

记录 ping 和路径

从固定测试客户端执行 ping。SERVER_IP 应替换为香港服务器实际地址：

SERVER_IP="203.0.113.10"

ping -c 50 -i 0.2 -W 2 "$SERVER_IP"

重点记录最小值、平均值、最大值和丢包率。不要只看平均 RTT，P95 或最大值更能反映测试期间的抖动。

随后使用 TCP traceroute。使用业务端口比单纯使用 ICMP traceroute 更接近 TCP 业务流量，但目标端口必须确实允许探测：

traceroute -n -T -p 443 -q 3 "$SERVER_IP"

如果客户端安装了 mtr，可以做一轮持续观察：

mtr -r -w -c 100 -T -P 443 "$SERVER_IP"

这里有三个判断边界：

1. ping RTT 基本不变，但 TCP 吞吐变高，才可能说明 TCP 控制策略发生了改善。
2. 测试参数没变，但 RTT 从 42 ms 变成 65 ms，不能把吞吐下降归因于服务器 TCP 配置。
3. traceroute 中某一跳出现星号，不代表该跳一定丢弃了业务包。许多中间设备会限制或降低对探测包的响应优先级，应结合最终目标地址的 ping、TCP 连接和实际吞吐判断。

如果 TCP traceroute 的末端路径发生明显变化，最好重新建立基线，而不是直接把两组结果放入同一个对照表。

让传输方向可控

测试方向必须明确。以 iperf3 为例：

# 在香港服务器上，以授权测试窗口启动服务端
iperf3 -s -p 5201

客户端向香港服务器发送数据：

SERVER_IP="203.0.113.10"

iperf3 -c "$SERVER_IP" -p 5201 -t 60 -P 1

此时主要观察客户端到香港服务器的上传方向。客户端请求反向测试时，服务器向客户端发送数据：

iperf3 -c "$SERVER_IP" -p 5201 -t 60 -P 1 -R

如果要验证香港服务器向外发送的 TCP 拥塞控制和发送缓冲区，-R 方向更有代表性。若要验证香港服务器接收方向，则应重点观察服务器接收窗口、接收缓冲区以及对端发送能力。

多连接测试可以补充观察并发场景，但不能替代单连接测试：

iperf3 -c "$SERVER_IP" -p 5201 -t 60 -P 4 -R

建议先固定 -P 1 完成单连接实验，再单独测试 -P 4 或其他并发数。单连接提升而多连接不提升，可能说明连接级窗口或拥塞控制改善有限；多连接提升而单连接不提升，则可能只是并发流叠加后的总吞吐变化。

每一轮至少运行三次，间隔 20 至 30 秒。测试期间可以在香港服务器上查看 TCP 流状态：

ss -tin

输出中常见的字段包括：

• rtt：当前 TCP 流估计出的往返时延。
• cwnd：拥塞窗口。
• ssthresh：慢启动阈值。
• bytes_sent、bytes_received：流量统计。
• bytes_acked：已经确认的数据量。
• delivery_rate：内核估计的有效交付速率。
• retrans：重传相关信息。
• snd_wnd：发送方看到的对端接收窗口。

ss -tin 是对当前连接的快照，应在传输进行中执行，而不是传输结束后才查看。

为了辅助判断全局计数变化，可以在测试前后分别记录：

nstat -az | grep -E 'TcpRetransSegs|TcpTimeouts|TcpInSegs|TcpOutSegs'

nstat 统计的是主机级数据。如果服务器同时承载其他业务，计数会混入其他连接，最好在维护窗口执行，或者只把它作为辅助证据。

根据带宽时延积判断缓冲区是否可能成为瓶颈

TCP 缓冲区不能简单地“越大越好”。判断窗口是否可能不足，可以先计算带宽时延积：

带宽时延积（字节）= 目标速率（bit/s）× RTT（秒）÷ 8

例如：

• 100 Mbps、RTT 45 ms：100,000,000 × 0.045 ÷ 8 = 562,500 字节，约 549 KiB。
• 500 Mbps、RTT 45 ms：500,000,000 × 0.045 ÷ 8 = 2,812,500 字节，约 2.68 MiB。

这不是应该直接写入内核的固定目标值。TCP 还会受到丢包、拥塞控制、对端窗口、应用读取速度和内存压力影响。它的作用是帮助判断：如果目标速率和 RTT 对应的带宽时延积已经明显大于 TCP 自动调优允许的最大窗口，才有必要验证缓冲区上限。

Linux 5.15 中常见的相关参数包括：

不要在同一轮同时修改 rmem_max、wmem_max、tcp_rmem 和 tcp_wmem。例如验证香港服务器向客户端发送时，应先判断发送方向哪个上限更小，再只改变一个发送方向参数。

读取当前值：

sysctl -n net.core.rmem_max
sysctl -n net.core.wmem_max
sysctl -n net.ipv4.tcp_rmem
sysctl -n net.ipv4.tcp_wmem

如果测试的是服务器接收方向，并且 net.core.rmem_max 是明显的限制值，可以先临时提高一个有限幅度，例如从 212992 字节提高到 4194304 字节，仅用于验证：

OLD_RMEM_MAX="$(sysctl -n net.core.rmem_max)"

sudo sysctl -w net.core.rmem_max=4194304
sysctl -n net.core.rmem_max

这只是示例值，不应视为所有香港服务器都适用的目标值。如果 net.ipv4.tcp_rmem 的最大值仍然小于该上限，修改 net.core.rmem_max 可能不会产生效果。此时应恢复前一个值，再单独验证 tcp_rmem 的最大值，而不是两个参数一起改。

恢复临时修改：

sudo sysctl -w net.core.rmem_max="$OLD_RMEM_MAX"
sysctl -n net.core.rmem_max

提高缓冲区会增加高并发连接的潜在内存使用量。测试期间应同时观察：

free -h
ss -s
vmstat 1 5

如果吞吐没有提高，但内存压力、连接数或软中断增加，就不能把该调整视为有效优化。

单独验证拥塞控制算法

Linux 5.15 是否支持 BBR，不能只根据内核版本推断，应先查看当前内核可用算法：

sysctl -n net.ipv4.tcp_available_congestion_control
sysctl -n net.ipv4.tcp_congestion_control

如果输出中包含 bbr，可以把当前算法记录下来，然后只修改拥塞控制这一项：

OLD_CC="$(sysctl -n net.ipv4.tcp_congestion_control)"

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sysctl -n net.ipv4.tcp_congestion_control

如果没有 bbr，不要为了完成测试同时更换内核、修改队列规则或安装其他组件。先把“内核是否提供该算法”作为前置条件，避免把多个变化混在一起。

拥塞控制参数通常主要影响新建立的 TCP 连接。修改后应关闭原有测试连接，等待旧连接结束，再重新启动 iperf3 或业务测试。测试时重点对比：

• 同一方向下的吞吐中位数。
• ss -tin 中的 cwnd、rtt、delivery_rate。
• 重传是否持续增加。
• 服务器 CPU 和软中断是否明显上升。
• 低并发与多并发结果是否一致。

恢复原算法：

sudo sysctl -w net.ipv4.tcp_congestion_control="$OLD_CC"
sysctl -n net.ipv4.tcp_congestion_control

不要把 BBR 和 net.core.default_qdisc 的修改放在同一轮。某些环境会推荐特定队列规则配合某种拥塞控制，但那属于另一项变量，必须单独建立基线、单独测试，否则即使结果改善，也无法知道是拥塞控制还是队列规则产生了作用。

只在有证据时验证 PMTU

路径 MTU 异常通常表现为：TCP 建连成功，但大包传输出现卡顿，重传集中增加，吞吐明显低于小包测试；也可能出现某些端口或某些客户端正常、另一些客户端异常。

可以先从客户端查看路径 MTU：

tracepath "$SERVER_IP"

如果 tracepath 显示的路径 MTU 比常见以太网环境低，或者 ss -tin 和重传数据支持存在 PMTU 问题，可以单独验证：

OLD_MTU_PROBING="$(sysctl -n net.ipv4.tcp_mtu_probing)"

sudo sysctl -w net.ipv4.tcp_mtu_probing=1
sysctl -n net.ipv4.tcp_mtu_probing

然后重新建立 TCP 连接，进行相同的单连接传输。若没有改善，或者 RTT、吞吐和重传均无明显变化，应恢复设置：

sudo sysctl -w net.ipv4.tcp_mtu_probing="$OLD_MTU_PROBING"

tcp_mtu_probing 不是通用加速开关。没有 PMTU 证据时长期启用，可能增加探测行为，却不会降低正常路径的 RTT，也不一定提高吞吐。

用示例数据区分“参数有效”和“线路变化”

下面是一组用于说明判断方法的示例数据，不代表某台当前香港服务器的实际测试结果。测试条件设定为：固定一台客户端，单连接、持续 60 秒、使用服务器向客户端发送方向，三次结果取中位数。

这个示例中，BBR 测试的吞吐提升约为 14%，而 RTT、路径和 CPU 没有明显异常，可以认为拥塞控制变量在该测试条件下产生了正向效果。接收缓冲区测试基本没有变化，说明该场景下接收窗口可能不是主要瓶颈，不能因为缓冲区参数“看起来偏小”就继续扩大。

另一种结果如下：

这组结果不能说明 TCP 参数导致吞吐下降。路径和 RTT 同时变化，优先应重新测试，或者把两轮数据标记为无效对照。

还有一种常见情况是：

• ping 中位 RTT 基本不变；
• traceroute 路径基本不变；
• cwnd 长期较小；
• retrans 持续增长；
• snd_wnd 并不小。

这更像是丢包或拥塞导致 TCP 无法扩大窗口，而不是单纯的缓冲区上限不足。继续盲目增大 rmem_max 或 wmem_max，通常不会解决路径上的真实丢包。

如果 snd_wnd 长期较小，而服务器发送端的 cwnd 尚未达到瓶颈，则受限点可能在客户端接收窗口、客户端负载或对端网络，单独调整香港服务器发送缓冲区不一定有效。

持久化前先完成回滚验证

临时修改成功后，不要立即写入系统配置。至少完成以下步骤：

1. 恢复原值，确认吞吐和 TCP 状态能够回到基线附近。
2. 再次应用测试值，确认结果可以重复。
3. 在不同时间段复测，确认收益不是某一次线路波动。
4. 确认内存、CPU、重传和延迟没有长期副作用。
5. 只持久化被单独验证过的参数。

建议先备份已有 sysctl 配置，再使用独立文件保存经过验证的单项配置，不要直接覆盖发行版原有配置：

sudo cp -a /etc/sysctl.conf \
  "/etc/sysctl.conf.bak.$(date +%F-%H%M%S)"

sudo mkdir -p /etc/sysctl.d
sudo cp -a /etc/sysctl.d/99-cn2-validation.conf \
  "/etc/sysctl.d/99-cn2-validation.conf.bak.$(date +%F-%H%M%S)" 2>/dev/null || true

例如，只有在拥塞控制测试已经重复成立后，才写入单项配置：

printf '%s\n' \
  'net.ipv4.tcp_congestion_control=bbr' |
  sudo tee /etc/sysctl.d/99-cn2-validation.conf

只加载这个文件，避免在验证阶段使用会一次性加载多个配置文件的命令：

sudo sysctl -p /etc/sysctl.d/99-cn2-validation.conf
sysctl -n net.ipv4.tcp_congestion_control

回滚时先保留备份，不要直接删除文件。可以将验证文件改名停用，再恢复原参数：

sudo mv /etc/sysctl.d/99-cn2-validation.conf \
  /etc/sysctl.d/99-cn2-validation.conf.disabled

sudo sysctl -w net.ipv4.tcp_congestion_control="$OLD_CC"
sysctl -n net.ipv4.tcp_congestion_control

如果原有配置文件中已经存在同名参数，还需要检查实际加载顺序，否则重启后可能出现“当前值与测试值不同”的情况：

grep -RInE 'tcp_congestion_control|tcp_rmem|tcp_wmem|rmem_max|wmem_max|tcp_mtu_probing' \
  /etc/sysctl.conf /etc/sysctl.d 2>/dev/null

常见失败结果的处理方式

吞吐没有提升，RTT 和路径也没有变化

这通常意味着当前瓶颈不在所修改的 TCP 变量上，可能是：

• 对端发送或接收能力不足；
• 测试文件或应用读取速度不足；
• 服务器 CPU、网卡或软中断已接近上限；
• 当前带宽和 RTT 对应的 TCP 窗口本来就足够；
• 该变量只影响另一条传输方向。

此时应保留原值，不要继续叠加更多参数。

ping 结果变化很大

如果同一轮 ping 的中位 RTT、P95 RTT 和丢包率都明显波动，先延长观察时间或换一个稳定窗口重新建立基线。TCP 参数不会直接改变 ping 的物理传播时延；ping 同时恶化时，优先怀疑线路拥塞、路径变化或测试端负载。

traceroute 中间节点丢包

只有中间节点显示丢包、但后续节点和最终服务器正常时，不能据此判定业务丢包。应以最终目标的 ping、TCP 重传和实际吞吐为准。如果从某一跳开始，后续所有节点和最终目标都持续出现异常，才更值得继续检查路径问题。

iperf3 提升，但真实业务没有提升

iperf3 能证明特定 TCP 流在固定条件下的传输能力变化，但真实业务还可能受到连接复用、请求大小、应用读取速度和并发模型影响。此时应在保持参数不变的情况下，用与生产业务接近的单个大文件或固定响应内容复测，再判断调优是否有业务价值。

参数应用后新连接正常，旧连接没有变化

这是正常现象。拥塞控制和部分 TCP 参数通常更容易在新连接上体现。验证时应停止旧的 iperf3 流，重新建立连接；不要把同一条长期连接前后的结果直接作为唯一依据。

修改缓冲区后内存压力增加

恢复原值，检查连接数、套接字数量和业务并发。TCP 最大缓冲区是上限，不代表每条连接都会立即使用全部内存，但大量并发连接会扩大潜在内存占用。大幅提高窗口上限前，应先根据带宽时延积逐步增加，而不是直接写入很大的数值。

复测条件与适用边界

对香港服务器 Linux 5.15 的 CN2 TCP 调优，最终应把结果记录为“在某个固定客户端、固定方向、固定时间窗口和固定并发条件下有效”，而不是简单写成“CN2 调优后速度提升”。如果只在单个时间点、单个客户端、单个测试流上提升，结论只能覆盖该场景；如果高峰时段路径或 RTT 发生变化，仍需重新测量。

一项参数可以保留的最低依据是：基线可重复、测试期间路径基本一致、只改变了一个关键变量、吞吐提升能够超过自然波动，并且重传、P95 RTT、CPU 和内存没有明显恶化。无法满足这些条件时，最稳妥的做法是恢复原配置，重新建立基线，而不是继续叠加更多 TCP 参数。