部署到阿里云之后，不少人会先看购买页上的带宽规格，数字够大就觉得放心了。但带宽是上限，不是用户实际拿到的速度。同一个页面，北京用户、广州用户和海外访客的打开体验可能差很多，原因通常在延迟和丢包上。阿里云测速要做的，就是把这些差距测出来，变成可以对比的数字。
先搞清楚三个指标
- 延迟（RTT）：数据包往返一次的时间，单位是毫秒。同城访问一般在几毫秒到二十毫秒之间，跨境链路超过一百毫秒也很常见。判断是否正常，要看它和业务需求匹配与否。
- 丢包率：请求中丢失的数据包占比。丢包超过1%时，视频播放和长连接通常会明显卡顿，这一项比延迟更值得盯。
- 吞吐量：单位时间内实际传输的数据量，也就是下载或上传速率。大文件下载和数据备份主要看它。
方法一：用云监控拨测看用户侧体验
云监控提供站点拨测功能。在控制台可以选择拨测类型，比如HTTP(S)、Ping、TCP或DNS，再勾选多个省份和海外节点定时检测。结果会按地区给出响应时间和可用性曲线。具体入口和节点列表以控制台实际显示为准，界面位置可能会随版本调整。
设想一个常见情况：在线教育服务部署在华东地域，学生反馈课件加载慢。拨测结果显示，华东节点平均响应35毫秒，华南节点却有480毫秒。排查后发现跨网链路拖慢了静态资源，于是把课件迁到CDN。华南平均响应降到120毫秒左右，相关投诉也少了。这个例子说明，拨测最有价值的地方是找出哪个地区慢，而不是只看一个总平均值。
方法二：用iperf3测两台ECS之间的吞吐量
拨测反映的是应用层的响应时间，测不出带宽本身。要测两台ECS之间的真实吞吐，可以在两台实例上安装iperf3。服务端执行 iperf3 -s，客户端执行 iperf3 -c 服务端IP -t 30，跑满30秒后会输出速率。默认方向是客户端到服务端，加上 -R 参数可以测反方向的速率。
测试前需要在安全组里临时放行5201端口，来源最好只填测试机的IP，不要直接开放给0.0.0.0/0。测完立即删除这条规则。同地域内网测出的结果和公网测出的结果差别很大，记录时务必写清楚测试路径，否则两组数据没法比较。
方法三：用第三方工具交叉验证
只看阿里云自己的结果，容易漏掉盲区。可以用几个地区的第三方拨测站点做对照。如果怀疑是前端问题，就用浏览器开发者工具的Network面板，看单个资源的加载耗时。
某电商小程序的商品图加载缓慢。云监控里服务器响应正常，Network面板却显示单张图片下载超过2秒。继续排查后发现，图片没有压缩，也没有设置缓存。问题在前端资源，不在服务器或网络。两个工具一起看，才定位到根因。
一次完整测速的步骤
- 先确定测试目标。首页、登录接口和大文件下载关注的指标不同：首页看首屏延迟，接口看RTT和丢包，下载看吞吐。
- 在云监控里配置至少三个省份和两个海外节点的拨测任务，频率设为1分钟。节点应该按用户分布来选，用户在哪里，就测哪里。
- 连续观察至少24小时，并特别记录晚上8点到11点的高峰数据。白天正常，不代表晚上也正常。
- 用iperf3测试实例之间的吞吐，确认带宽够不够业务使用，测完删除临时安全组规则。
- 对比各地区数据，找出延迟最高或丢包最多的地区。问题集中在某个地区时，再考虑启用CDN或调整部署地域。先定位，再动手，不必一开始就改架构。
常见误区
- 测一次就下结论。网络波动大，至少要覆盖一个完整的业务周期，比如一周内的工作日和周末。
- 把带宽峰值当成平均速度。峰值只说明上限，日常体验要看平均值和P95这类分位数。
- 测完忘记关端口。5201端口留在安全组里，测速服务就一直暴露在公网上，这是很常见的安全隐患。
