阿里云杭州到日本服务器单向卡死（5M vs 200K）排查实录与内核调优

最近处理阿里云杭州（国内）与阿里云日本（海外）服务器之间的数据同步时，踩到了一个极其典型的“网络链路不对称”坑。

在阿里云杭州（A）与日本（B）两端均配置 100M 带宽下，测试发现从 A 向 B 发送文件可达 5MB/s 以上，但从 B 向 A 拉取文件时网速却陡降至不足 200KB/s。记录一下从现象确认、网络诊断（MTR/路由不对称）、TCP 协议特性分析到最终内核级（BBR/TCP Window）调优的过程。

01. 复盘

在本次的测试与数据同步场景中，两端服务器的基本配置如下：

节点 A：阿里云杭州（中国大陆区域）
节点 B：阿里云日本（东京区域）
公网配置：两端弹性公网 IP（EIP）均配置为 100 Mbps 峰值带宽。

测试表现差距极大：

A 发送至 B（杭州 ➔ 日本）：网速稳定在 5 MB/s（约 40 Mbps）以上，表现符合跨国传输的正常预期。
A 从 B 拉取（日本 ➔ 杭州）：网速急剧下滑，跌破 200 KB/s（不到 1.6 Mbps），带宽利用率连 2% 都不到。

同为 100M 带宽，去程与回程的表现相差了整整 25 倍。这种典型的“单向极慢”现象，直接排除了服务器本地硬件（如 CPU/内存/磁盘 I/O）瓶颈，将问题锚定在了网络链路上。

02. 核心

造成跨国网络“去程飞快、回程爬行”的核心逻辑，可以归结为以下四个机制：

1. 运营商回程路由不对称（最根本原因）

数据在互联网中传输，去和回走的物理路径往往是不对称的：

去程（A ➔ B）：杭州阿里云发往日本，流量极大概率走的是阿里云内部优化骨干网或三大运营商的直连海缆，延迟低、节点少。
回程（B ➔ A）：日本发回国内，若未购买高价的中国方向优化带宽（如 CN2 GIA），海外运营商会将流量扔进普通的公网国际出口（如电信 AS4134 或联通 AS4837）。在进入中国国际入口时，流量遭遇拥堵节点，甚至绕道美国或新加坡。

2. BDP（带宽时延乘积）与 TCP 窗口限制

TCP 协议在长距离传输时受制于带宽时延乘积（Bandwidth-Delay Product）：

\text{BDP} = \text{带宽} \times \text{往返延迟 (RTT)}

跨国连接的 RTT 通常在 60ms - 200ms 不等。如果操作系统默认的 TCP 接收/发送缓冲区设置过小，数据包在等待对端返回 ACK 确认时，管道就会“空置”，导致百兆带宽跑不满。

3. 微小丢包诱发 TCP 拥塞控制“误伤”

传统的 TCP 拥塞控制算法（如 Cubic）对丢包极其敏感。在跨国回程公网上，只要存在 1%~2% 的微小丢包，Cubic 算法就会判定网络极度拥堵，主动将发送窗口砍半甚至降到最低，导致速率出现断崖式下跌。

4. 传输协议开销与单线程瓶颈

使用 SCP/SFTP 等基于 SSH 加密的协议传输文件时，由于其内部采用“串行块确认”机制，在长距离高延迟链路下，单线程传输能力会被严重打折。

03. 排查

为了定位并验证上述猜想，使用了以下诊断组合拳：

1. 路由路径追踪：`mtr`

使用双向 mtr 追踪，直接坐实了路由不对称的猜想：

# 从 A 追踪到 B
mtr -rw <B的公网IP>

# 从 B 追踪到 A
mtr -rw <A的公网IP>

诊断结论：A➔B 路径跳转极少且均为阿里云骨干节点；B➔A 路径在离开日本后，跳入了多个拥堵的国际公网节点，丢包率在特定节点骤增。

2. 内存级网络吞吐测试：`curl`

为了排除磁盘 I/O 干扰，利用 curl 将数据流直接丢弃至 /dev/null 进行纯网络吞吐测试：

# 测试下行（直接下载公网大文件）
curl -Lo /dev/null http://mirrors.aliyun.com/centos/7/isos/x86_64/CentOS-7-x86_64-DVD-2009.iso

# 查看性能面板重点关注指标：
# Average Speed 中的 Dload (下载) 与 Upload (上传)

3. 实时网卡流量监控：`sar` 与 `nload`

在监控网卡实时速率时，使用 sar 抓取数据：

sar -n DEV 1 100

指标单位权威换算表（针对 100M 带宽）：

sar 输出中的 rxkB/s 单位是 KB/s（千字节/秒），大写 B 代表 Byte。
换算关系： $1 \text{ rxkB/s} = 8 \text{ kbps}$ 。
100 Mbps 的理论物理极限约为 12,500 rxkB/s（即 12.5 MB/s）。
实测中：A 到 B 显示 5000+ rxkB/s（正常）；B 到 A 仅有 200 rxkB/s（极度异常）。

04. 优化

针对“回程线路差 + 丢包率高”的局限，可以通过系统层调优和工具升级实现大幅提速。

方案一：开启 BBR 算法（性价比之王，必做）

BBR（Bottleneck Bandwidth and RTT）算法由 Google 开源，它不再将“丢包”作为拥塞的唯一判断依据，而是在高丢包环境下依然能榨干物理带宽。

在 B 服务器（日本发送端） 上部署：

# 1. 检查当前内核拥塞控制算法
sysctl net.ipv4.tcp_congestion_control

# 2. 开启 BBR (适用于 Linux 内核 4.9+)
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf

# 3. 刷新生效
sysctl -p

实测效果：在回程丢包率 2%~5% 的环境下，开启 BBR 后，B➔A 的传输速度直接从 200 KB/s 提升至 3MB/s~5MB/s。

方案二：优化 TCP 系统缓冲区参数

跨国长距离链路需要调大 TCP 窗口上限：

# 追加至 /etc/sysctl.conf
cat >> /etc/sysctl.conf << EOF
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
EOF

sysctl -p

经过上面两个方案的配置，确实传输效果提升极大。当然还有其他的企业级的配置方式，阿里云也给了不少方案，比如专线、内网互通等，但是都太重了，对我们小团队能直接配置服务器解决的是最好的。

BLCL的博客小馆