1. 延迟(RTT)与抖动(Jitter)测试
• 使用工具:ping(-c 20)、mtr(-r -c 100)来测 RTT 与丢包分布。
• 理想参考值:日本到中国主干路由 RTT 目标 <50ms、抖动 <10ms;跨太平洋到美国通常 120–200ms。
• 测试样例命令:ping -c 20 203.0.113.1;mtr -r -c 100 203.0.113.1。
• 判断标准:若 95% RTT 超出目标或抖动高且峰值频繁,说明链路不稳定或存在排队丢包。
• 排查方法:同时从多个节点(东京、关西、香港)测试,比较出发点差异判断本地出口问题或上游质量。
2. 丢包率与分组重排序检测
• 使用 mtr、iperf3(UDP 模式)与 tcptraceroute 检测端到端丢包和重传率。
• 丢包阈值:长期平均丢包 <0.5% 可接受;高峰丢包 >1% 会影响 TCP 性能和用户体验。
• 示例 iPerf3 UDP 命令:iperf3 -c 203.0.113.1 -u -b 200M -t 30,观察丢包与抖动报告。
• 分析重排序:若存在明显重排序(out-of-order >1%),应排查中间链路或多路径 LB。
• 建议:在高并发下做长时间(>30 分钟)测试以捕获突发丢包情况。
3. 实际带宽与并发吞吐测试(含数据示例)
• 工具:iperf3(多流)、curl/ab/wrk(HTTP 并发)验证真实应用吞吐。
• 并发测试:使用 100/500 并发连接,记录平均响应时间与 99% 响应分位。
• 案例数据:下面为一台日本 CN2 VPS(上行出口 CN2)对不同目的地的 1 分钟 iperf3 TCP 多流测试示例。
• 说明:表中为示例平均带宽、丢包与 RTT(测试环境:VPS 10Gbps 尼克,内核启用 BBR)。
• 建议:若真实 HTTP 并发下后端 CPU 或网卡饱和,需升级 NIC(1G→10G)或优化 NGINX keepalive。
4. 路由、BGP 与 ISP 对等关系检查
• 使用 traceroute 和 bgp.he.net 查看 AS 路径与是否走 CN2 GIA 直连链路。
• 关注点:跨境是否通过优质 CN2 GIA/MPLS 专线,避免绕路(经美国或欧洲回国导致延迟增大)。
• 检查泄漏/回程:从国内多个运营商节点回测,确认回程是否也走 CN2。
• 路由稳定性:观察 24 小时内的路由跳数和 RTT 波动,路由抖动可能来自 BGP 广告波动。
• 建议:要求供应商提供具体 AS 路径与 Peering 信息,并在 SLA 中写明丢包/延迟指标。
5. 服务器内核与网络栈调优(示例配置)
• 常见优化项:启用 BBR、调整 net.core.rmem_max/net.core.wmem_max、tcp_congestion_control=bbr。
• 推荐内核参数(示例):net.core.rmem_max=268435456;net.core.wmem_max=268435456;net.ipv4.tcp_congestion_control=bbr。
• 磁盘与 NIC:建议使用 10Gbps 网卡、开启 GSO/TSO、禁用 GRO 在特定场景调试。
• 系统规格示例:VPS 配置 8 vCPU(Intel Xeon)、32GB RAM、NVMe 1TB、10Gbps 公网口。
• 验证方法:调整后使用 iperf3 与 HTTP 并发测试,对比基线吞吐与 CPU 利用率。
6. CDN、DDoS 防护与真实案例
• CDN 验证:确认静态资源走 CDN,测量缓存命中率(目标 >85%)以降低原站带宽。
• DDoS 防护:需明确清洗阈值(例如 10Gbps 或 100k PPS),并测试峰值清洗响应时间。
• 真实案例:某电商客户在日本部署 CN2 无限流量 VPS(10Gbps),初期出现高并发下原站带宽用尽。启用 CDN 后,缓存命中率从 22% 提升到 90%,origin 带宽下降 85%,并通过云厂商 DDoS 清洗将峰值流量从 6Gbps 清洗至正常。
• 监控建议:部署流量镜像与 Netflow,设置阈值告警(例如 80% 带宽/秒、异常 SYN 增长速率)。
• 最后建议:在签约“流量无限”前要求试用期内进行上述测试并写入 SLA,确保路由、硬件和防护能力真实满足业务峰值需求。
来源:选择日本cn2流量无限前要测试的网络性能指标清单