测试 本地-CDN-主机 的完整延迟

[cjccjj]

原来测速一直是香港新加坡日本这些延迟比较低，虽然出口主机是在美国的，但感觉这样应该还是最近的。
然而真正分别测试后发现，并非如此

延迟1是本地到CDN 延迟2是 主机到CDN 总延迟是二者相加

可以发现 虽然本地到香港延迟最低，但对我这台位于美国的主机，实际上使用 SFO 节点比香港的总延迟更低

我的测试方法是使用本工具 httping, 使用 CDN 上面 cache 的文件作为测试 URL
延迟1 在本地测， 延迟2 在主机测 （延迟2 实际上是反向了 但我感觉影响不大） 选同个地区最快节点

大家觉得我这个方法是否比较靠谱？

测试结果：

地区 延迟1 延迟2 总延迟
SFO 175.61 + 2.08 = 177.69
LAX 189.15 + 9.25 = 198.40
SEA 179.49 + 20.88 = 200.37
ICN 70.60 + 129.98 = 200.58
HKG 48.87 + 152.72 = 201.59
NRT 97.29 + 106.79 = 204.08
PHX 191.57 + 20.75 = 212.32
SLC 212.58 + 17.75 = 230.33
HIO 214.26 + 17.18 = 231.44
YVR 198.71 + 38.17 = 236.88
SIN 79.00 + 167.75 = 246.75
DEN 228.53 + 27.20 = 255.73
DFW 214.26 + 42.62 = 256.88
KUL 96.69 + 172.95 = 269.64
IAH 220.62 + 52.04 = 272.66
FRA 127.65 + 149.60 = 277.25
ORD 219.80 + 60.87 = 280.67
YYC 249.16 + 38.32 = 287.48
ATL 230.02 + 58.56 = 288.58
MRS 147.60 + 151.32 = 298.92
KIX 191.48 + 108.85 = 300.33

[XIU2]

Cloudflare CDN 的总体过程是：

访客 <=> Cloudflare Anycast IP 节点 <=> Cloudflare CDN 回源节点 <=> 网站源服务器

如果 Cloudflare Anycast IP 节点 有缓存，则会直接返回给访客，如果没有缓存，则会从上游寻找，有的话再返回给 Anycast IP 节点，然后再返回给访客，如果上游也没有，就会去网站源服务器上访问（即回源）再一层层返回给访客。

对于 CDN 来说 Anycast IP 不是最好的方案，但却是适合大部分人的方案（特别是在国内国外网络环境迥异的情况下来看），国外大部分地区访问 Cloudflare CDN 的网站，都会 Anycast 到当地节点（延迟可能就 几ms），而网站往往都少不了缓存，按特定条件把缓存存储在各个边缘节点上（比如某个网站的访客大都是美国的，那么该网站的缓存基本都处于美国的边缘节点上），确实可以显著提高网站访问速度。
即使网站的一些网页没有缓存（非静态网页，或者是一些动态接口什么的），Cloudflare 也会通过内部网络来回源，回源速度和稳定性也更有优势（相比你自己买个服务器把网站搭建到上面而言）。

不过国内因为不可抗力被 Cloudflare CDN（其他国际 CDN 都差不多这样）特殊对待，导致 Anycast 节点默认都分配到欧美了（一些移动用户可能会分配到香港），这就失去了 Anycast 技术的最大优势，才衍生出了本项目这种自选优选的玩法，国外基本上就用不上 CFST 。。。
所以国内访问 Cloudflare CDN，确实不是延迟低就速度更快，还有其他很多因素影响，至于你这个我也不是很清楚，你说的这个完整延迟测速方法也不够详细，我也无法判断。

但因为缓存的原因，理论上你一开始测试的那次才是准确的（相对的），后续因为缓存的原因，可能就会失准，但因为你每次测试选用的 Anycast IP（边缘节点）都不一样，因此测试结果也不会一样。

只有没有缓存的情况下，Cloudflare CDN 才会完整的走一遍上面的回源流程环节，即最终延迟就是：

访客 => Cloudflare Anycast IP 节点 => Cloudflare CDN 回源节点 => 网站源服务器 => Cloudflare CDN 回源节点  =>  Cloudflare Anycast IP 节点 => 访客 = 最终完整延迟

但如果你要测试完整延迟，理论上你只需要找个不会被缓存的小文件（或者 CF 里设置不缓存），或者下载测速地址随便加上个参数什么的（但可能还是需要在 CF 里设置缓存策略，来确保 CF 不会忽略地址参数去缓存），然后直接去访问这个小文件（文件要小就是为了尽量避免文件大小影响测试结果），看总消耗时间是多少，这个时间应该算是最契合你要去的 "完整延迟" 了。

---

CFST 的 HTTPing 只获取了头部（Header），我也不确定只获取头部是否能反映完整延迟，建议你用 curl 来测试：

这个命令就是和 HTTPing 一样的原理，-I 就是只获取头部，--resolve 就是强制给下载测速地址的域名指定 IP：

curl -I -X GET --connect-timeout 3 -m 5 -w "总耗时: %{time_total} 秒" -A "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.3987.122 Safari/537.36" --resolve 下载测速地址的域名:443:IP https://下载测速地址

而这个命令，则是获取完整下载测速地址的文件（-o /dev/null 是直接丢弃文件，因为只需要测算时间）：

curl -o /dev/null -X GET --connect-timeout 3 -m 5 -w "总耗时: %{time_total} 秒" -A "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.3987.122 Safari/537.36" --resolve 下载测速地址的域名:443:IP https://下载测速地址

你可以对比一下两者的结果，理论上后者因为传输内容更多，总耗时会更长一些，但如果你的文件很小的话，那么差别应该也不会那么大，但这种测试结果也有缺点，那就是 HTTP 测试本身因为环节比较多，因此受干扰的因素变量也会多，导致最终多次的测试结果可能都不太一样。

你要确保每次测试时的下载测速地址文件都没有被 Cloudflare 缓存，这样测速结果才有参考价值。

[cjccjj]

我这么测试的出发点就是要把两段分开，确保有缓存分别测，我考虑的原因是

1. 我大致测的情况 CFST 延迟是没有包括从CDN到源服务器这一段的
2. 从方便的角度，使用公开的测速 URL 那么99%是有缓存的

curl -o /dev/null -s -w "connect: %{time_connect}s, tls: %{time_appconnect}s, ttfb: %{time_starttransfer}s, total: %{time_total}s\n"
--resolve example.com:443:cdn_ipaddress https://example.com/file

我是用 cloudfront 在 behavior 分别设置了有缓存和无缓存的测试文件，主要看 curl 给的 ttfb 的时间，和文件大小无关，对比 CFST，看起来 CFST 大概率是没有包括后面一段的延时 （有一定的波动 不能100%确定）

当然我这样测也不完善，实际使用意义也不大。只是我发现并非选香港 日本 新加坡这些就一定最快，因为CDN内部互联也不是一定优化的很好，分开看能一定程度看到这个情况。

[XIU2]

说实话，没必要折腾这个，划不来，因为 Anycast 是动态的，你好不容易测出的结果，运气差可能过几天就变了。。。
虽然说延迟低不等于速度快，但是延迟低中找到速度快的概率也会更大，因为延迟低本质上就代表了你与该 IP 服务器直接的物理距离近，且中间路由数量少，如果多次测试延迟稳定不丢包的话，还能说明线路没那么拥塞，那么这种情况下显然更容易遇到速度快的。

当然了，因为影响的因素太多了，网络链接中的任意一个环节出问题或者被限制或者拥塞了，都会导致结果天差地别。

[XIU2]

自从写了这个软件解决了我的需求后，这几年频繁使用这个软件，就我个人的使用体验来说，我的建议是：
不要过分追求最好的，差不多就行了。

特别是对于 Cloudflare CDN 这种 Anycast IP 节点，更重要的反而是找到一个适合自己的 IP 段区间，只对这个 IP 段区间测速，而不是对所有 IP 大海捞针，这大幅降低了测速时间，甚至因为这个 IP 段区间质量比较稳定，我干脆 -dd 禁用了下载测速，只靠 TCPing 延迟测速就完事了，使用效果可能算不上最好，但却也不差了，我已经这样持续了一两年了吧大概。

Cloudflare CDN 的边缘节点虽然是 Anycast，但并不代表是完全无规律随机分配的，实际上也能找到一些规律，至少在我家联通网络环境下，我能发现一些 IP 段似乎只会分配到固定的物理实际地区（比如一些德国的），这些 IP 段可能很长时间也不会变地区（我之前用的一个德国的 IP 段，用了 2 年多才突然发现路由变了，延迟明显升高，变成美国的了，似乎是个大洗牌，我收藏的很多德国等地的 IP 段都变了，然后我又大海捞针，找到了一批德国的继续用，毕竟联通用欧洲的更有优势，可以从北京出口走陆路去欧洲服务器，比拥塞的广州和上海出口的海底光缆要宽敞一些）。