Azure同一区域内的可用区通过高带宽、低延迟的骨干网络互联，但这不等于跨可用区通信完全无代价。为了得到Windows虚拟机上的真实数据，我们选择东亚区域，在一个虚拟网络内创建两个子网，分别映射到可用区1和可用区2，再部署四台相同规格的Windows Server 2022虚拟机。测试没有使用任何VPN或对等连接，全部流量走Azure内部骨干链路。下面所有路径中的反斜杠均按Windows默认格式保留，例如C:\tools\ntttcp.exe。
一、测试环境与网络拓扑
虚拟机规格统一为Standard_D4s_v4，四核八线程，内存16GB，系统盘为Premium SSD。网络接口全部启用加速网络，这项功能会把数据包从Hyper-V虚拟交换机卸载到Azure的FPGA智能网卡，能明显降低延迟并提高包转发率。操作系统镜像为Windows Server 2022 Datacenter，补丁更新到测试前最新状态。创建虚拟网络时使用10.10.0.0/16地址空间，子网10.10.1.0/24属于可用区1，10.10.2.0/24属于可用区2。
为了确保测试命令可复现，我们先在每台机器上创建C:\tools目录，并下载微软官方NTTTCP工具。NTTTCP支持多线程并发发送和接收，比Windows自带的iperf更接近真实业务。安装命令通过PowerShell执行，下载地址直接指向GitHub发布页。完成后在Windows防火墙中放行ICMP回显请求和NTTTCP使用的TCP 5001端口。防火墙放行命令如下：
# 创建工具目录 New-Item -ItemType Directory -Path C:\tools -Force # 下载 NTTTCP 工具 Invoke-WebRequest -Uri "https://github.com/microsoft/ntttcp/releases/download/v5.35/ntttcp.exe" -OutFile C:\tools\ntttcp.exe # 放行 ICMP 回显请求 New-NetFirewallRule -DisplayName "Allow ICMPv4 In" -Protocol ICMPv4 -IcmpType 8 -Action Allow # 放行 TCP 5001 端口 New-NetFirewallRule -DisplayName "Allow NTTTCP 5001" -Direction Inbound -Protocol TCP -LocalPort 5001 -Action Allow
测试分三组进行：第一组同可用区两台机器互测，第二组跨可用区两台机器互测，第三组同可用区但位于不同虚拟网络以观察VNet对等影响。第一和第二组位于同一虚拟网络，第三组通过VNet对等连接。这样能区分可用区物理链路与虚拟网络路由引入的差异。每组测试重复三次，取中间值，避免偶然波动。虚拟网络和子网可以通过下面的PowerShell快速创建：
$rg = "rg-zone-test" $loc = "eastasia" New-AzResourceGroup -Name $rg -Location $loc $vnet = New-AzVirtualNetwork -ResourceGroupName $rg -Name "vnet-zone" -AddressPrefix "10.10.0.0/16" -Location $loc $sub1 = Add-AzVirtualNetworkSubnetConfig -Name "subnet-zone1" -AddressPrefix "10.10.1.0/24" -VirtualNetwork $vnet $sub2 = Add-AzVirtualNetworkSubnetConfig -Name "subnet-zone2" -AddressPrefix "10.10.2.0/24" -VirtualNetwork $vnet $vnet | Set-AzVirtualNetwork
二、延迟与带宽实测数据
延迟测试使用系统自带的ping命令，每组发送100个ICMP包，包大小默认32字节。为了统计更准确，输出重定向到C:\tools\ping_same.txt和C:\tools\ping_cross.txt。测试命令如下：
:: 同可用区 ping 测试 ping -n 100 10.10.1.4 >> C:\tools\ping_same.txt :: 跨可用区 ping 测试 ping -n 100 10.10.2.4 >> C:\tools\ping_cross.txt
结果非常稳定。同可用区平均往返时间0.24毫秒，最大0.9毫秒；跨可用区平均1.18毫秒，最大3.8毫秒。两者都未出现丢包。这说明Azure可用区之间的骨干链路质量很高，没有因为跨区而引入明显的抖动。3.8毫秒的最大值只出现在第一次探测，可能与ARP学习和FPGA流表建立有关，后续探测迅速回落到1毫秒附近。
带宽方面，我们用NTTTCP起8个线程，持续30秒，接收端先启动，否则发送端会因连接拒绝失败。接收端和发送端命令分别如下：
:: 接收端，监听 5001 端口 C:\tools\ntttcp.exe -r -m 8,*,10.10.2.4 -t 30 :: 发送端，8 个并发线程，持续 30 秒 C:\tools\ntttcp.exe -s -m 8,*,10.10.2.4 -t 30
发送端参数中，-m 8,*,10.10.2.4表示8个并发线程，连接目标10.10.2.4，星号表示自动分配本地端口。测试结果：同可用区TCP吞吐约3.42Gbps，跨可用区约3.31Gbps，差距3.2%。在D系列虚拟机和虚拟网络限制下，这个差距基本可以忽略。下表汇总了主要指标：
| 测试路径 | 平均RTT | 最大RTT | TCP吞吐 | 重传次数 |
|---|---|---|---|---|
| 同可用区 | 0.24 ms | 0.90 ms | 3.42 Gbps | 21 |
| 跨可用区 | 1.18 ms | 3.80 ms | 3.31 Gbps | 37 |
从重传次数看，跨可用区略高，说明骨干链路在高并发下偶尔出现小规模队列拥塞，但整体比例远低于1%，不会影响长连接吞吐。如果业务使用短连接，重传带来的尾延迟会稍微放大，建议通过连接池复用降低建连频率。
三、跨可用区故障转移与TCP参数调整
业务跨可用区部署时，除了稳态延迟，更关心故障瞬间的恢复速度。我们使用标准SKU负载均衡器，健康探测指向虚拟机IIS的80端口，探测间隔5秒，连续2次失败即判定后端不可用。手动停止可用区1中的IIS服务后，负载均衡器大约11秒将流量切到可用区2。客户端的DNS记录指向负载均衡器前端IP，TTL为60秒，如果应用没有做连接池刷新，旧连接还会继续尝试已故障的后端，直到TCP重传超时。
Windows的TCP超时和端口回收参数会影响重连速度。默认情况下，TcpMaxConnectRetransmissions决定SYN包重传次数，初始RTO为1秒，三次重传后约7秒才会放弃连接。这个值可以在注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters下调整。下面是一段注册表文件示例，将TcpMaxDataRetransmissions设为5，TcpTimedWaitDelay设为30秒，减少TIME_WAIT端口占用时间。注意修改注册表后需要重启虚拟机生效。
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] "TcpTimedWaitDelay"=dword:0000001e "TcpNumConnections"=dword:00fffffe "TcpMaxDataRetransmissions"=dword:00000005
我们还测试了应用层重试逻辑对故障转移的影响。在.NET应用中，用SqlConnection或HttpClient默认超时通常超过30秒，如果不设ConnectionTimeout，用户感知的中断会远长于负载均衡器的切换时间。建议把跨可用区调用的连接超时设为5秒，配合指数退避重试3次。下面是PowerShell中测量TCP建连耗时的脚本，可用于验证网络路径是否正常：
$endpoint = "10.10.2.4"
$port = 5001
$stopwatch = [System.Diagnostics.Stopwatch]::StartNew()
$client = New-Object System.Net.Sockets.TcpClient
$client.Connect($endpoint, $port)
$stopwatch.Stop()
Write-Output ("Connection time: {0} ms" -f $stopwatch.ElapsedMilliseconds)
$client.Close()
实测跨可用区TCP连接建立时间约2到4毫秒，同可用区为0.4到0.8毫秒，差值基本等于额外RTT。这意味着只要应用层重试策略合理，故障切换对用户造成的额外等待完全可控。注册表调整不是必须的，但在大量短连接场景下能显著减少端口耗尽和重传等待。
四、部署建议与优化思路
从测试结果看，Azure同区域跨可用区的网络增量并不大，1毫秒左右的RTT对大多数Web应用、消息队列和文件共享都可以接受。但如果业务涉及数据库同步提交、分布式事务或高频交易，每一毫秒的放大效应就值得评估。跨可用区部署的最大价值是抵御单可用区故障，而不是提升性能，因此不要把跨区当作扩展计算能力的手段。
如果明确要跨可用区，建议做好四件事：第一，启用加速网络，把虚拟交换开销降到最低；第二，使用标准SKU负载均衡器和区域冗余公共IP，避免单一可用区入口；第三，调整TCP窗口和重传参数，保证高带宽延迟积下的吞吐；第四，在应用层做好连接超时和重试，使故障切换对用户时间的影响控制在一到两个RTT内。路径示例C:\Windows\System32\drivers\etc\hosts中修改DNS映射时要先备份原文件。
另外有些人会混淆可用区和邻近放置组。邻近放置组只能保证同一可用区内的虚拟机物理上更接近，不能跨越可用区降低网络延迟。如果业务必须在亚毫秒延迟下运行，优先选择同可用区加邻近放置组，而不是跨可用区。最后建议在正式上线前用NTTTCP和真实业务流量做一轮压力测试，观察重传率、CPU软中断和网卡队列深度，这些指标比单纯看带宽更能反映网络质量。