全球CDN节点测试的核心目标, 说白了, 就是要去验证一下各个区域节点的、那种实际的网络性能到底有没有达到SLA标准, 从而确保那些终端用户们在不同地域进行访问的时候, 能够获取得到一种一致的、还有低延迟的服务体验。
至于这个测试, 它得要把延迟、丢包、带宽, 以及首字节时间（这里叫作TTFB）这四个核心维度给覆盖到, 然后, 还需要按照不同的区域分批次地去执行操作, 而且要求的是每一个批次的采样点数不少于5个, 最终所形成的, 是一个可以进行量化处理的性能基线的报告。。
一、核心测试指标
1. 所谓的网络延迟, 也就是我们常说的RTT, 是通过使用ICMP协议或者TCP协议来进行探测, 以此来测量客户端和CDN边缘节点之间的往返所花费的时间, 比较优秀的标准是同一个区域内的延迟要低于20毫秒, 如果是跨洲的数据传输, 延迟也要低于100毫秒。
2. 关于丢包率这一情况, 我们是在1000个数据包里面统计没有返回的那个包的占比是多少, 而对于正常的CDN节点来说, 它的丢包率应该是低于0.1%的这个数值的。
3. 用iperf3或者是专业的流量工具来测一下实际能用的下载带宽, 看看能不能达到节点上写的标称数值。
4. 首字节时间, 也就是大家常说的TTFB, 这个是通过curl命令来测量的, 测量的内容是, 从你发起HTTP请求开始, 一直到你收到第一个响应字节为止, 所花费的那个耗时, 它主要是用来反映节点回源效率的情况。
5. 查看HTTP响应状态码这一项, 大家需要去确认一下是不是所有的节点都返回了在预期中的那个200或者301这样的状态码, 顺便也要把那些5xx还有403出现的异常情况给排除掉。
二、关于测试工具的选择, 以及具体的执行方法的描述。
开展基础探测工作时, 可以使用MTR工具来进行路由追踪, 并且配合使用ping命令去进行测试, 要确保覆盖掉在全球范围内超过20个以上的城市节点, 同时要完整地记录下在网络传输路径中每一跳所产生的延迟情况以及出现丢包的具体表现。
关于性能压测, 可以通过gname.xin所提供的全球cdn性能监测面板来进行操作, 在此面板中只需要按一键键就可以发起来自多地域的并发测试程序。该程序会自动地将各个节点的延迟情况、带宽数据以及ttfb数据进行汇总处理。并且在完成上述工作之后, 生成用于对比的图表。
进行回源验证工作, 具体做法是模拟源站出现故障的情况, 然后去检查CDN节点的缓存命中率是不是符合预先设定的要求, 同时检查回源超时策略是否符合预先设定的要求。
在协议兼容性方面, 需要分别对节点的表现进行测试, 这包括HTTP/1.1协议、HTTP/2协议以及HTTP/3（QUIC）协议。
三、标准测试流程
1. 我们需要确定测试矩阵, 具体做法是按大洲进行划分, 涉及的区域包括北美、欧洲、亚太、南美以及非洲，在每一个区域内分别选取3至5个城市, 作为具有代表性的地点。
2. 进行基线采集的操作, 是要选择那些没有业务高峰的时间段来执行第一轮的全面测试任务。
3. 进行压力验证的操作是, 选择在业务高峰时段的时候来实施重新测试。其核心目的是要细致地观察, 当节点面对高并发负载情境时, 它的性能会出现怎样的衰减幅度, 以便准确地进行评估与判断。
4. 针对那些没有达到标准要求的节点, 我们要一层一层的来检查, 看看是域名系统解析哪里出了问题, 还是传输控制协议中的握手环节出现了故障, 再或者是传输层安全性协议的协商过程有错误, 最后还要去看看回源链路的情况。
5. 报告输出采用表格形式, 把各节点的四项核心指标的实测值和SLA阈值的对比列出来, 并且标注出有异常的项目以及建议采取的处理方案。
用户提问在同一个城市范围内进行了多次测试, 但是发现延迟的数值变化非常之大, 这种情况是不是属于正常的反应。
CDN的节点在不同的时候段里面, 他们的负载均衡的策略是不一样的, 所以如果波动的情况是在500毫秒以内的话, 那就属于正常的现象, 如果出现持续超过了SLA阈值30%的情况, 那就需要联系服务商来核查节点的当前健康状态。
我们要通过一些方法来判断CDN节点是不是真的已经生效了, 而不是用户直接连到了源站。
可以通过使用curl -v来查看响应头里面的X-Cache、Via字段, 确认请求确实是由边缘节点缓存或者代理进行处理了, 而不是穿透到了源站。
在完成一次全球CDN节点的全面测试过程以后, 建议进行每季度的重复测试动作, 或者是在遇到大版本升级情况以及节点扩容工作完成之后的时候立刻执行重复测试环节, 从而保证性能基线指标能够持续处于有效状态。
