OVHcloud在欧洲、北美和亚太均有数据中心，但中国大陆没有直连接入点，因此到国内公网延迟高度依赖国际出口线路和运营商之间的互联策略。不少开发者发现同一区域不同时段延迟波动很大，其实是回程路由绕行不同海缆造成的。本文用四个节点对国内三大运营商做连续测试，记录平均延迟、抖动和丢包，并分析如何优化。
测试环境与数据采集方法
本次测试选择OVHcloud在法国格拉沃利讷、加拿大博阿努瓦、新加坡、澳大利亚悉尼的四个公共云实例，规格均为最低配的2vCPU/4GB内存，操作系统为Ubuntu 22.04。国内测试端分别使用上海电信、广州联通和北京移动的家庭宽带及云主机。测试工具为Linux自带的ping和mtr，每个目标连续发送100个ICMP包，间隔0.2秒，同时运行mtr记录每一跳的路由和时延。为了避免高峰期拥堵影响结论，测试覆盖了工作日下午、晚间和凌晨三个时段，每个时段重复三次取中位数。
测试中需要特别注意的是，ping只能反映ICMP的往返时延，实际TCP业务经过状态检测防火墙或负载均衡后可能还会增加1到5毫秒，但整体趋势一致。另外国内运营商对ICMP的限速策略不同，联通和移动对ICMP的优先级略高于UDP，因此UDP业务的延迟可能比ping结果略差。下面给出本次测试使用的命令示例。
# 持续发送100个ICMP包，间隔0.2秒 ping -c 100 -i 0.2 51.79.xxx.xxx # 使用mtr查看每一跳路由和丢包率 mtr -r -c 100 --report-wide 51.79.xxx.xxx
在采集数据时，需要区分去程和回程。从国内发起ping测试的是去程与回程之和，OVHcloud到国内的回程延迟可能和去程不同，因为运营商往往采用不对称路由。更接近用户感知的是从OVHcloud实例上ping国内IP，因此我们在四个实例上都安装了测试脚本，定时向上海、广州、北京三个测速点发送探测，记录返回结果。这样可以完整还原用户访问业务时的真实链路。
此外，针对南方电信用户，还需要关注电信163骨干和CN2 GIA的区别。普通OVHcloud IP进入电信网络后通常走163，晚高峰拥塞明显，而CN2 GIA是质量较高的商业线路。评测期间我们还额外购买了一条CN2 GIA中转服务作对比，观察同一OVHcloud新加坡实例经不同回程线路的延迟差异，这部分结果在后面的优化章节会详细展开。
各区域节点延迟数据与骨干网表现
先给一组表格展示四个区域到国内三大运营商的平均延迟，单位为毫秒。
| OVHcloud区域 | 上海电信 | 广州联通 | 北京移动 | 平均抖动 | 丢包率 |
|---|---|---|---|---|---|
| 法国格拉沃利讷 | 268 | 245 | 271 | 12 | <1% |
| 加拿大博阿努瓦 | 231 | 218 | 236 | 9 | <1% |
| 新加坡 | 98 | 86 | 92 | 5 | 0% |
| 澳大利亚悉尼 | 152 | 139 | 147 | 7 | <1% |
欧洲节点延迟高的原因很直接：法国到中国没有直连海缆，回程通常先在本土接入Telia或Level3，再到伦敦或者法兰克福交换，然后经陆缆到莫斯科或中东，最后进入中国电信入口，全程超过一万公里。部分联通线路可能会绕行美国西海岸再到中国大陆，导致延迟更高。电信163在晚高峰时经欧洲回程会出现明显排队，抖动能到30毫秒以上。
加拿大节点位于魁北克，理论上到中国可以走北极海缆，但实际商业路由很少选这条，大多先南下到纽约或芝加哥，再横穿美国到西海岸的洛杉矶或圣何塞，接入电信或联通。这一圈绕行把距离拉长到约15000公里，所以延迟稳定在200到240毫秒。移动用户因为CMI在美西有PoP，回程相对集中，延迟略低于电信。
新加坡节点的表现最好，原因是地理位置近，且新加坡是亚洲海缆枢纽，多条海缆直连香港、广州、上海。移动网络与新加坡的互联通常走CMI自己的海缆或对等互联，回程很干净，实测90毫秒左右。联通会经香港PCCW或NTT到广州，延迟也能控制在85到100毫秒。电信走163的晚高峰会劣化，但如果换CN2 GIA，新加坡延迟可以压到65到75毫秒。
悉尼节点到国内的延迟处于中间档，因为南半球到北半球海缆距离长，而且多数路由先到悉尼，再经关岛、香港或日本回国，有些线路还会绕道美国西海岸，导致延迟上升。悉尼到上海电信平均152毫秒，但这个值在晚高峰可能跳变到180毫秒以上。
延迟优化路径与架构调整建议
从实测看，如果业务主要面向中国大陆用户，最直接的优化就是放弃欧洲和北美节点，优先选择OVHcloud新加坡或悉尼，尤其新加坡，成本和延迟平衡最好。但仅换区域还不够，因为电信163晚高峰丢包和抖动仍然会影响体验。此时可以引入CN2 GIA中转，通过一台位于香港或新加坡的CN2 GIA服务器转发流量到OVHcloud实例。这样做增加了少量成本，但能把电信线路的延迟降低30到60毫秒，丢包率趋近于零。
另一种做法是使用Cloudflare Argo或Akamai的动态加速，利用其在国内的边缘节点和智能路由，把用户流量就近接入，再通过内部骨干网转发到OVHcloud。不过这类服务对TCP和HTTPS比较友好，对UDP游戏或自定义协议可能支持有限。对于UDP业务，可以考虑租用支持UDP转发的IEPL专线或使用WireGuard隧道，但成本较高。
在系统层面也可以做优化。开启TCP BBR可以改善高延迟、高丢包场景下的吞吐和时延表现。以Ubuntu为例，可以通过sysctl修改内核参数：
# 检查当前拥塞控制算法 sysctl net.ipv4.tcp_congestion_control # 临时启用BBR（需要内核支持） sudo modprobe tcp_bbr echo bbr | sudo tee /proc/sys/net/ipv4/tcp_congestion_control # 永久生效 cat <<EOF | sudo tee /etc/sysctl.d/60-bbr.conf net.core.default_qdisc=fq net.ipv4.tcp_congestion_control=bbr EOF sudo sysctl --system
这套参数让内核使用fq队列和BBR拥塞控制，在高延迟链路下可以更快填满带宽并减少重传等待。需要注意的是，BBR的效果在丢包严重的线路上更明显，如果链路本身质量已经很稳定，提升幅度会变小。除了内核参数，还可以在应用层启用HTTP缓存、Nginx反向代理，把静态资源放在靠近用户的边缘节点，减少长链路往返次数。
综合来看，OVHcloud新加坡节点在三大运营商网络下表现最稳定，适合作为亚太业务入口。法国和加拿大节点不适合直接面向国内用户提供低延迟服务，但可以用作数据存储或备份，通过异步同步到国内。如果业务需要全球多区域部署，建议在OVHcloud新加坡与国内云之间建立专线或SD-WAN，并配合BGP社区调整回程路由，这样才能把公网延迟的不可控因素降到最低。