为保证可比性,本次测试选择了主流供应商在新加坡节点的标准实例:包括AWS 新加坡(ap-southeast-1)、Google Cloud 新加坡(asia-southeast1)、Azure Southeast Asia、以及几家中小型云厂商(如 DigitalOcean、Vultr)。测试周期覆盖工作日高峰与非高峰时段,测试工具采用了 ping(ICMP RTT)、iperf3(TCP/UDP 吞吐量)、以及 mtr(路径与丢包率)。
实例均选用相近的 vCPU 与内存配置(例如 2 vCPU / 4GB),网络增强设置采用默认或可比的带宽包。每个测试点重复采样 100 次以上,记录最小/平均/最大延迟与 95/99 百分位吞吐量,剔除明显异常值后计算统计指标。
从中国大陆、香港、印度尼西亚和澳大利亚等地发起测量,以体现区域用户的不同网络路径对延迟与吞吐量的影响。
综合 ICMP 和 TCP 三类测试结果,Google Cloud 新加坡在平均延迟与 99 百分位延迟上表现最稳定:平均 RTT 通常在 10–25ms 区间(来自香港/中国南方的测试点),99P 延迟抖动较小。AWS 与 Azure 的延迟接近,但在高峰期偶尔出现短时抖动。
延迟优秀的节点通常与骨干直连和更少的中间跳数相关。使用 mtr 分析可见,表现差异主要来自于出境链路与最后一跳的丢包/排队策略。
若业务对延迟敏感(如游戏、实时通信),优先考虑 Google Cloud 或配置专线/加速网络的 AWS/Azure 方案,同时启用多可用区冗余以降低单点波动影响。
在 iperf3 TCP 测试中,不同厂商的峰值吞吐量与实例类型、网络限制密切相关。总体上,公有云大厂(AWS、Google、Azure)在短时峰值吞吐量上通常更高,实际测试中可稳定达到所标称带宽的 85%-95%。中小厂商在并发连接或长流量传输时更容易出现带宽抖动。
TCP 测试受限于拥塞控制算法与 RTT 值,长距离高 RTT 环境下吞吐量会显著下降;UDP 测试则更能暴露丢包和抖动问题。若业务是大文件同步或备份,建议优先关注 TCP 吞吐量;若是流媒体/实时视频,需要同时关注 UDP 丢包与延迟。
以 1Gbps 标称带宽实例为例,Google 与 AWS 的平均 TCP 吞吐可达 800–920Mbps,而部分小厂商在同样条件下稳定在 400–700Mbps 区间,且出现短时掉速。
通过 mtr 的路径追踪与长时间 ping 测试,可以看到多数厂商在核心链路上丢包率接近 0,但在出口或最后一跳偶发丢包。丢包率超过 0.5% 会明显影响实时业务体验。实测中,部分中小云厂商在高并发或夜间维护窗口出现丢包抬升。
丢包常见于:链路拥塞、路由临时调整、流量整形(带宽限制)或硬件故障。使用多路径测量能帮助定位是供应商内部问题还是上游链路问题。
建议启用多可用区/多区域部署、使用负载均衡与健康检查、以及部署链路监控告警。一些厂商提供的私有网络或专线服务对降低丢包与抖动非常有效,但成本较高。
选择要基于业务类型与预算权衡:对低延迟要求极高的业务(实时通信、线上游戏)应优先考虑延迟与抖动最小的供应商,并结合网络加速或专线;对大流量传输(视频分发、备份)应优先考虑峰值吞吐量与长期稳定性更好的实例类型。
关键考量包括:1) 实际测得的平均与峰值延迟;2) TCP/UDP 吞吐量与 95/99P 指标;3) 丢包率与抖动;4) 容灾与网络冗余能力;5) 成本与支持服务。
上云前建议做三步验证:1. 在预生产环境做多时段、多源点的延迟与吞吐量测试;2. 做长时间(数日到数周)的丢包与抖动监测;3. 根据结果做小规模灰度上云,再做性能回归。
持续监控比一次性测试更重要。利用日志和链路探针,结合CDN/边缘加速,可以在成本可控的情况下显著提升终端用户体验。