要评估 Azure 美国东部区域到北美其他数据中心的网络质量，不能只看地图上的距离。微软全球骨干网的路由策略、区域间专线容量、对等互联点位置都会直接影响最终 RTT。本文在相同规格的 D 系列虚拟机上，使用 ICMP 和 TCP 两种探测方式，对美东、美中、美西、美中南、加拿大中部、加拿大东部等区域做了一轮连续监测，下面把数据和方法拆开说明。
测试环境与数据采集方法
测试虚拟机部署在 East US 区域，规格为 Standard_D4s_v3，操作系统使用 Ubuntu 22.04 LTS。为了减少单台宿主机或单块网卡带来的误差，每个目标区域选取 3 个不同可用区的公共 IP，每 5 分钟发送 10 个探测包，持续运行 48 小时。记录维度包括平均 RTT、P95 延迟、最大抖动和丢包率。同一区域还额外创建了一台启用加速网络的 VM 做对比，其他配置完全一致。
之所以同时使用 ICMP 和 TCP，是因为部分云平台或中间网络会对 ICMP 做速率限制，纯 ping 数据容易偏乐观或出现无规律的波动。TCP 探测直接对 443 端口做握手或空包往返，更接近真实业务请求。实际采集时，ICMP 使用系统 ping，TCP 使用 psping 工具。下面是一段循环探测的脚本示例：
#!/bin/bash
targets=(20.0.0.1 40.0.0.1 52.0.0.1)
for ip in "${targets[@]}"; do
ping -c 10 -i 0.2 "$ip" >> rtt_log.txt
done
测试期间所有 VM 关闭了自动休眠和节能策略，并在本地防火墙规则中放行 ICMP 与测试端口，避免因安全组或 OS 层丢包干扰结果。数据采集完成后，用脚本清洗掉异常重启时段和公共维护窗口内的记录，只保留稳定的连续样本。
北美各区域延迟实测数据对比
以下表格汇总了 48 小时内各目标区域的平均 ICMP RTT、平均 TCP RTT、P95 延迟和丢包率。其中 East US 到 East US 2 属于同区域邻近可用区通信，数据作为基准参考。
| 目标区域 | 平均 ICMP RTT | 平均 TCP RTT | P95 延迟 | 丢包率 |
|---|---|---|---|---|
| East US 2 | 1.8 ms | 2.1 ms | 3.5 ms | 0.01% |
| North Central US | 22.4 ms | 24.8 ms | 38.6 ms | 0.02% |
| Central US | 28.7 ms | 31.2 ms | 47.3 ms | 0.03% |
| South Central US | 33.5 ms | 36.9 ms | 55.1 ms | 0.05% |
| Canada Central | 31.2 ms | 34.0 ms | 52.8 ms | 0.03% |
| Canada East | 24.9 ms | 27.4 ms | 41.2 ms | 0.02% |
| West US | 67.8 ms | 70.3 ms | 92.4 ms | 0.08% |
| West US 2 | 69.5 ms | 72.1 ms | 95.0 ms | 0.07% |
从数据可以看出，同区域内部通信只有 1 到 2 毫秒，符合可用性区域间专线的预期；美中地区普遍在 22 到 34 毫秒之间；而美东到美西平均 RTT 接近 70 毫秒，P95 甚至超过 90 毫秒。这个值明显高于按直线距离除以光速计算的理论传播时延，说明微软骨干网在跨大陆调度时存在绕行或经过多个汇聚节点。
启用加速网络的 VM 在同一区域测试中，平均 RTT 只有约 0.1 到 0.3 毫秒的改善，但 PPS 吞吐提升明显；在跨区域测试中，平均延迟下降约 5 到 10 毫秒，抖动降低超过 30%。这是因为加速网络通过 SR-IOV 直接绕过虚拟交换机，减少了数据包在宿主机上的处理时间，但对跨骨干网的长距离传播延迟没有本质影响。丢包率方面，美西方向在晚高峰偶尔会升高到 0.5% 左右，说明该路径可能部分经过公共对等互联，而不是全程专线。
延迟波动来源与优化建议
美东到北美其他区域的延迟波动主要来自几个方面：跨大陆光缆的物理长度、骨干网中间节点的转发次数、目标区域边缘接入点的负载状况，以及 VM 本身虚拟网络设备的处理能力。测试中观察到的最大抖动出现在美西方向，单次抖动可达 12 毫秒，这与晚高峰时段对等链路拥塞高度相关。如果是纯微软骨干网内部的区域对等，抖动通常能控制在 3 毫秒以内。
如果业务以美东为核心，短期最有效的优化是启用加速网络，并把所有相关资源放入邻近放置组（Proximity Placement Groups），使计算实例尽可能部署在同一物理机架或相邻机架。对于跨区域调用，建议改用异步模式，例如跨区域数据库只做主从异步复制，避免同步提交被 70 毫秒的往返延迟拖慢。还可以使用 Azure Front Door 或全局负载均衡器，根据用户来源就近接入，减少跨区域请求。
另外，不要只依赖区域之间的公开测速数据，因为用户到 Azure 的流量还会经过本地 ISP、企业专线或 VPN 网关。测试时应从真实客户端或源站发起探测，并持续观察至少 24 小时，才能避开偶发抖动和路由收敛的影响。在正式上线前，最好用 psping 对业务端口做 TCP 探测，而不是只看 ICMP 结果。
对业务部署的启示
如果你的主要用户在北美东部，Azure 美国东部依然是最优选择，计算、缓存、数据库都建议放在同一区域，并利用可用性区域做高可用。可用性区域之间的延迟通常在 1 到 2 毫秒，完全满足同步复制和分布式锁的要求。但如果用户覆盖整个北美，单区域部署会带来明显体验差异：美西用户访问美东资源时，页面加载可能增加约 70 毫秒基础延迟，对实时游戏、音视频通话、高频交易等场景影响较大。
对于这类广覆盖场景，更合理的做法是多区域部署，将无状态服务同时部署在 East US 和 West US 2，前端使用 Azure Traffic Manager 或 Front Door 按最低延迟路由。数据库层则可以用 Cosmos DB 多区域写入或 SQL 的只读副本，让读请求就近完成，写请求异步合并。这样做虽然增加了运维复杂度，但能把用户感知延迟控制在区域本地水平。
混合云场景下，如果本地 IDC 通过 ExpressRoute 接入 Azure，专线只解决从本地到微软网络的这一段，并不会改变美东到美西的骨干路径。实测中 ExpressRoute 的接入延迟比公共 VPN 低 5 到 15 毫秒，但跨区域内部链路依然遵循同样的骨干网调度。因此，在规划容灾或多活架构时，务必先做一次从真实链路出发的实测，把延迟预算写入架构评审，而不是只看区域名称或地图距离。