网站访问耗时优化 - 从数十秒到几百毫秒的“零成本”优化过程 - 阿里云子域GeoDNS国内外分流
网站访问耗时优化 - 从数十秒到几百毫秒的“零成本”优化过程 - 阿里云子域GeoDNS国内外分流
- Website Latency Optimization: A Zero-Cost Journey from Tens of Seconds to Hundreds of Milliseconds
- From 30 Seconds to 300 Milliseconds: Zero-Cost Website Performance Optimization
背景
之前为了保护我那台孱弱的小服务器的真实ip免受攻击,我将服务器的所有HTTP(s)服务限制为仅能通过域名访问,且把域名托管在了Cloudflare上开启了代理小云朵。
就这样几年过去了,越来越觉得网站访问是真的慢(不管有没有特殊网络都很慢)。并且有👇,所以决定优化一手。
沃尔玛发现,页面加载时间每减少 1 秒,转化数就会增加 2%…
最终,从每次访问“快则好几秒平均十来秒慢则好几十秒”到“粗略统计全球访问平均几百毫秒”的性能优化,并且几乎没有修改代码。(理想状态平均几十毫秒)
耗时原因分析
众所周知,正常情况下锅内外的网络传输都要不可避免地经过TheGreatWall,来保障国民的网络信息安全。
为什么CDN服务器遍布全球的赛博菩萨Cloudflare在锅内会变成减速CDN呢?大概率是经过了上面的它↑。
为了实锤一下,在服务器上执行命令
1 | |
得到结果20次请求的连接耗时、首字节返回耗时、总耗时:
1 | |
第二列和第三列几乎相同,说明服务端数据处理非常迅速,耗时几乎为0,而整个网络开销几乎均耗时在网络传输上(服务器–cloudflare–服务器),然后就有了第三列这灾难级别的耗时。
Geo-DNS分流
既然知道了网络开销的巨大头主要来自HTTP的跨境行为,所以让国内用户访问我的国内服务器,国外用户访问国外Github Pages(纯静态页面)不就好了么,具体访问的哪个IP对用户是无感的,且一个域名就能实现。
由于主域名letmefly.xyz托管在cloudflare上且仍有其用,而cloudflare的GeoDNS成本大约每个月几十美元(未详细统计确认),比小服务器贵很多,所以决定将blog.letmefly.xyz子域托管到免费的阿里云DNS服务上。(腾讯云DNS也有类似免费服务,但由于该域名购买自阿里云,所以选择了托管在阿里云上)
blog.letmefly.xyz子域托管
在cloudflare控制面板修改blog.letmefly.xyz的DNS记录为NS,值为ns1.alidns.com,再新建一个NS值为ns2.alidns.com。
在阿里云DNS解析控制台添加域名blog.letmefly.xyz,进行TXT校验(在cloudflare添加alidnscheck.letmefly.xyz的TXT类型的记录)。
添加记录:
| 主机记录 | 记录类型 | 解析请求来源 | 记录值 |
|---|---|---|---|
| @ | AAAA | 境外 | 2606:50c:0:8003::153 |
| @ | AAAA | 境外 | 2606:50c:0:8002::153 |
| @ | AAAA | 境外 | 2606:50c:0:8001::153 |
| @ | AAAA | 境外 | 2606:50c:0:8000::153 |
| @ | A | 境外 | 185.199.111.153 |
| @ | A | 境外 | 185.199.110.153 |
| @ | A | 境外 | 185.199.109.153 |
| @ | A | 境外 | 185.199.108.153 |
| @ | A | 中国地区 | 39.105.42.186 |
前面8个是Github(官方文档),最后一个是我的服务器。
是的,就这么简单,完事了!
服务器拉取Github脚本
服务器上设计为:启动一个webhook listener,当github仓库website分支更新时向服务器发送通知,服务器拉取最新源码,并原子化链接整个目录到nginx配置的目录。
1 | |
在github对应仓库–settings–webhook–新增–输入密钥(随机字符串,可由openssl rand -hex 32命令生成)–类型选择json–不需要额外数据。
本地在程序执行目录创建一个.secret文件并写入生成的密钥,后台运行该监听脚本即可。(上面方法俺设计的,嘻嘻)
结果
国内
在服务器上执行for i in {1..20}; do curl -o /dev/null -s -w "%{time_connect} %{time_starttransfer} %{time_total}\n" https://nextcloud.letmefly.xyz; done,结果:
1 | |
这个应该是直接走Localhost了?。
强制走公网:
1 | |
并另外启动一个窗口抓包:
1 | |
可以看到:
1 | |
说明走了公网。
诶,还是很快。
直接使用一台手中的设备测试,不在服务器上测试了
1 | |
这下没办法了,走的wifi连的服务器,还是很快。
国外
由于没有在国外的设备,所以临时写了个github action测下
1 | |
Github上测Github Pages似乎有点小作弊(bushi),但没办法了。
1 | |
国内外
也可以在itdog上测试国内外访问,网络质量及其不确定因素会增多,耗时结果稍高。
但HTTP请求只要不经过墙墙,平均还是比较快的。
国内外访问良民网站的DNS服务,也很快(并且还有缓存);国外访问Github(Anycast)本来就很快。
End
What’s more:
这次估计触发了关键词,在CSDN上发布时不是先发后审了。
同步发文于CSDN和我的个人博客,原创不易,转载经作者同意后请附上原文链接哦~
千篇源码题解已开源