同区域实例之间的网络通信质量，往往决定了分布式系统的整体表现。数据库主从同步、消息队列吞吐、微服务间调用，这些场景对实例间延迟和带宽都非常敏感。为了搞清楚Google Cloud在同区网络上的真实水平，本文用iperf3和ping做了多轮测试，覆盖了不同机型和不同区域，下面是完整的测试过程和数据结论。
测试环境与工具准备
这次测试选用了us-central1区域的几组实例，分别是e2-standard-4、n2-standard-8和c2-standard-8，操作系统统一为Ubuntu 22.04。之所以选这三个机型，是因为它们分别代表了入门通用型、平衡型和高性能计算型，Google官方文档明确提到不同机器类型的网络带宽上限差别很大，e2系列的网络配额明显低于n2和c2系列。
测试工具方面主要依赖两个：ping用来测基础往返延迟，iperf3用来测TCP和UDP的吞吐带宽。每台实例启动后先在VPC防火墙规则里放行了iperf3默认的5201端口，同时放通ICMP协议，否则ping不通会浪费时间排查。命令如下：
# 安装测试工具 sudo apt update && sudo apt install -y iperf3 # 服务端启动（在被测目标实例上执行） iperf3 -s # 客户端发起TCP带宽测试（持续30秒） iperf3 -c 10.128.0.15 -t 30 -P 4 # 客户端发起UDP带宽测试 iperf3 -c 10.128.0.15 -u -b 5G -t 30
需要提醒的是，单线程iperf3在高速网络下容易跑不满带宽，因为单个TCP连接的吞吐会受限于CPU和内核参数，所以上面命令里加了-P 4开启四个并行流，这样测出来的数字更接近真实上限。测试过程中还通过htop监控了CPU占用，避免因为CPU打满导致数据失真。
实测数据：延迟与带宽表现
先看延迟。同一区域同一可用区内的两台n2-standard-8实例之间，ping的平均往返延迟稳定在0.1毫秒到0.15毫秒之间，抖动极小，连续跑一百次几乎没有超过0.3毫秒的离群值。而跨可用区（同区域不同zone）的实例之间，延迟上升到1毫秒到1.5毫秒左右。这个差异印证了官方的说法：同zone内实例物理距离非常近，走的是数据中心内部网络，跨zone则要经过区域骨干网。
带宽方面差距就更大了。e2-standard-4实测同区TCP带宽大约在8Gbps上下，而c2-standard-8可以跑到接近16Gbps，n2-standard-8也在12Gbps左右。这个结果和Google Cloud的机器类型带宽对照表基本吻合——vCPU数量越多、机型越高端，网络出口带宽配额越高。具体对比如下：
| 机型 | vCPU | 同区延迟均值 | 实测TCP带宽 |
|---|---|---|---|
| e2-standard-4 | 4 | 0.15ms | 约8Gbps |
| n2-standard-8 | 8 | 0.12ms | 约12Gbps |
| c2-standard-8 | 8 | 0.11ms | 约16Gbps |
UDP测试结果同样值得关注。在低速率下UDP丢包几乎为零，但把发送速率压到接近带宽上限时，丢包率开始明显上升，说明同区网络虽然质量很高，但超发流量依然会被限速丢弃。对于依赖UDP的业务比如实时音视频，发送端一定要做好拥塞控制和重传机制。
如何进一步提升同区网络性能
第一个也是最有效的手段是启用gVNIC网卡。老实例默认使用VirtIO-Net虚拟网卡，而gVNIC是Google专门优化过的网络接口，在高带宽场景下吞吐表现明显更好。创建实例时加上参数即可启用，已有实例则需要停机后修改：
# 创建实例时启用gVNIC gcloud compute instances create perf-test \ --zone=us-central1-a \ --machine-type=n2-standard-8 \ --network-interface=nic-type=GVNIC # 已有实例需先停止，再修改网卡类型 gcloud compute instances stop perf-test --zone=us-central1-a gcloud compute instances update perf-test \ --zone=us-central1-a \ --network-interface=nic-type=GVNIC
第二个思路是选对机型。如果业务本身就是网络密集型的，比如缓存集群、分布式存储，直接选c2或c3系列比e2系列划算得多。e2机型价格便宜，但网络配额低，多台e2堆出来的集群总带宽可能还不如几台c2，这时候按带宽需求反推机型往往更省钱。
第三个技巧是内核参数调优。默认的TCP缓冲区对超高速内网通信偏保守，适当放大可以减少高带宽长流场景下的瓶颈：
# 调整TCP缓冲区，提升内网大流量传输效率 sudo sysctl -w net.core.rmem_max=268435456 sudo sysctl -w net.core.wmem_max=268435456 sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 268435456" sudo sysctl -w net.ipv4.tcp_wmem="4096 65536 268435456"
最后提醒一点，做压测时尽量错开其他业务的流量高峰，并且多测几轮取平均值。云上网络存在邻居干扰的可能，单次测试的极端值参考意义不大。另外，如果发现实测带宽远低于机型对应的配额，先检查是不是CPU打满了，iperf3本身也很吃CPU资源。
总体来看，Google Cloud同区网络的水准相当不错，亚毫秒级延迟配上十几Gbps的带宽，足以支撑绝大多数对内网通信要求苛刻的架构。关键在于根据业务的带宽需求选对机型，并记得启用gVNIC，这样能把这个平台网络能力的上限真正用足。
Google Cloud网络延迟带宽测试修改时间：2026-09-06 20:15:11