如何提高,优化博客域名的解析时间,决定分理论和实验两步走。理论方面,全面学习了解下关于域名DNS解析的知识;实验方面,试用下常见的一些DNS域名解析服务(当然主要是免费的DNS域名解析服务)。
理论
当我们访问一个网站,在浏览器里输入网站的域名,相应的域名解析服务器(DNS服务器)会将域名解析成对应的ip地址,然后返回给浏览器。我们访问一个网站,实际是在访问一个基于ip地址提供的web服务(互联网早期三大经典应用ftp,www,e-mail背后都是ip地址)。
互联网里域名解析的体系及流程是这样的:
1.用户在浏览器中输入域名“mydomain.com”, 若本地浏览器没有缓存,则向LocalDNS发起请求。所谓LocalDNS一般为网络运营商提供的DNS服务,比如电信运营商的经典的114.114.114.114,各地区运营商的DNS(比如广东电信的202.96.128.86)。LocalDNS是域名解析的起点,电信运营商在这个领域有先天优势(他们提供的权威DNS解析服务能更快)。从这个角度考虑,这可能是众多云服务商都想推广自己的公共DNS的原因。比如百度云的180.76.76.76,阿里云的223.5.5.5,腾讯云(DNSPod)的119.29.29.29。
2-1.若LocalDNS服务器里缓存有域名mydomain.com对应的IP地址信息,则直接向用户返回IP地址信息,如此即完成了一次域名查询解析服务。可以看出这个过程时间会非常短,对于个人博客,这是最好的情况。LocalDNS返回最终的结果(IP地址信息)给用户,这个过程被称为递归查询。
域名对应IP地址信息缓存在LocalDNS服务器的时间,是由TTL控制,TTL即time to live,是我们在域名解析(即使用权威域名服务器)时设置的,一般可以设置成几秒到几分钟不等,最长可以设置24小时(86400s)。
2-2.LocalDNS若完全无缓存,则采用迭代查询的方法,向各域名服务器进行查询。
2-2.1LocalDNS最开始向根域名服务器查询。根域名服务器并不知道mydomain.com这个域名对应的具体IP,只是告知应该向.org TLD(Top Level Domain,顶级域名)查询。
2-2.2LocalDNS则紧接着询问.org顶级域名服务器,被告知应该询问AliDNS(mydomain.com这个域名使用AliDNS提供的权威域名解析服务),它知道。
2-2.3LocalDNS则转向AliDNS这个权威域名服务器,获知了mydomain.com域名对应的IP地址信息。
2-2.3.1LocalDNS将获取到的mydomain.com对应的IP地址信息反馈给用户,并遵循TTL设置,将结果缓存起来。
综合以上,域名解析过程有这些要点:
各层级的域名服务器都会缓存域名解析信息;
不同地区的访问者越多,域名解析信息越能及时被缓存,用户感知到的解析时间会越短。TTL设置的越长(缓存时间越久),可能需求的解析时间也会越短;
从域名解析时间角度考虑,个人博客站点(尤其首页)使用CDN可能并不是总是好的。因为访问量并不大,CDN IP地址多,如果没有及时缓存,可能致解析时间多变,久;
电信运营商来做域名解析(权威域名服务器),有先天优势。用户的LocalDNS多用他的,路近道宽。实践中发现 www.ctyun.cn (电信天翼云)这个域名各地解析时间平均只需几十毫秒,甚至多个节点只需几毫秒。作为对比,阿里云( www.aliyun.com ),腾讯云( cloud.tencent.com )都是100-200ms,逊色不少。比较可惜,天翼云的DNS解析没有免费版;
DNS DDOS攻击多发生于权威域名服务器端;
DNS劫持多发生于LocalDNS服务器端;
国外的权威域名解析服务(比如Cloudflare)有其优势,比如可能更靠近根域名服务器或者部分顶级域名服务器,但国内使用,单独看解析时间仍不理想。节点多位于中国境外,解析服务器与境内连接有网络带宽的瓶颈。
实验
通过前面理论分析,对于个人博客站点,要优化自己域名解析时间,唯一能做的就是选用合适的(解析速度快的)权威域名解析服务。主要是免费的域名解析服务。
目前提供免费域名解析服务(权威域名解析服务)的有:
阿里云的云解析 DNS
腾讯云的DNSPod
华为云的云解析服务 DNS
Cloudflare的DNS
其中DNSPod应该是国内解析量最大的,日均解析量为1700亿次,其次是阿里云的云解析,日均解析量大约是1000亿次。Cloudflare的数据量不清楚,可能是世界范围内规模最大的域名解析服务。华为云的云解析服务可以免费使用其他家收费才提供的各种高级功能。
除了以上,其实各提供公有云服务的IDC均会提供域名解析服务,为快速实验比较计,仅测试以上主流的四种。
实验前提:
通过Whois查询工具,收集到使用不同域名解析服务的个人博客域名,同时加入使用对应收费版的域名解析服务的网站作为对比。因各博客及网站域名解析里的TTL缓存时间不明确,因而采用不同时间段,多次访问被测站点的办法测试,时间跨度持续约3个星期,以尽可能排除缓存干扰。
测速平台:https://tool.chinaz.com/speedtest/ (仅评估域名解析时间,连接时间及下载时间忽略)
实验结果:
(测试时间2024.4.10-4.30)
样本网站 DNS解析服务商 DNS服务器 服务器地域 解析耗时
Q博客 DNSPod免费版 cotangent.dnspod.net,group.dnspod.net 香港,日本,新加坡等地域 100-150ms
W博客 DNSPod免费版 clean.dnspod.net,clifford.dnspod.net 境内IP 100-150ms
M博客 DNSPod免费 kama.dnspod.net,lake.dnspod.net Cloudflare 500-800ms
Z网站 DNSPod付费版 ns3.dnsv5.com,ns4.dnsv5.com 境内CDN 50-100ms
S博客 阿里云DNS免费版 dns11.hichina.com,dns12.hichina.com 境内IP 200-300ms
H网站 阿里云DNS付费版 vip3.alidns.comvip4.alidns.com 境内CDN 100-150ms
J博客 华为云DNS解析 ns1.huaweicloud-dns.com, ns1.huaweicloud-dns.cn 境内IP 200-300ms
I博客 Cloudflare DNS jay.ns.cloudflare.com, kara.ns.cloudflare.com Cloudflare 500-800ms
(实验过程省略。)
上面解析耗时数据可以不用过多关注(不够严谨),直接看下面的结论。
结论
(主要针对个人博客站长)
免费版域名解析服务解析时间波动较大(一般上午解析更快,下午及晚上较慢。当然解析服务本身是否稳定是另一个不确定因素),收费版的比较稳定;
使用国外CDN(比如Cloudflare),服务器,所需域名解析时间会更久。使用临近中国大陆地域的服务器,比如中国香港,新加坡,日本等,所需解析时间会较短;
更高级的收费功能(华为云DNS解析免费提供,其他家收费提供),比如负载均衡,更多的解析线路,更细致的地区划分,对于个人博客意义不大(个人博客不会部署那么多服务器);
CDN有种种好处,但从域名解析角度看,单IP更好;
个人博客可以设置更长的TTL时间(24小时,86400s),以达到最好的缓存效果;
使用某家的云服务器,然后使用同一家的域名解析服务,可能有更短的解析延时,更稳定的表现;
现在回到最开始的问题,我大概从2010年前后开始使用DNSPod的域名解析服务,彼时DNSPod还没有被腾讯收购。习惯使然或者其他因素,一直没考虑过更换或者尝试使用其他的域名解析服务。直到这次发现DNSPod延时居然这么久,测试一段时间后发现,各家免费的域名解析服务效果,性能,稳定性其实都差不太多。而DNSPod被我发现表现差,可能正巧这段时间其服务不太稳定。DNSPod对外公开的系统状态监控证实了我的这种猜想。可以看出DNSPod日正常解析量在1800亿次上下,而我测试期间(4月10-30日),有多次波动很大,最低到1400亿-1500亿次,最多减少了22%左右。
如此看来,免费的权威DNS服务器用得人多,对于服务商并非一定是好事(服务跟上,服务器数量,布局合理,技术更新等都需要花钱。当然想办法将免费用户转换成付费用户又是另一方面了)。对于云服务提供商,与传统电信运营商去竞争LocalDNS可能更有价值.
ppt.cc/fVjECx ppt.cc/fEnHsx ppt.cc/fRZTnx ppt.cc/fSZ3cx ppt.cc/fLOuCx ppt.cc/fE9Nux ppt.cc/fL5Kyx ppt.cc/fIr1ax ppt.cc/f71Yqx tecmint.com linuxcool.com linux.die.net linux.it.net.cn ostechnix.com unix.com ubuntugeek.com runoob.com man.linuxde.net v.gd/4A2G5b v.gd/VBg0IE v.gd/kVkm7n v.gd/jCKP1G linuxprobe.com linuxtechi.com howtoforge.com linuxstory.org systutorials.com ghacks.net linuxopsys.com v.gd/2P9wTx v.gd/FtfpqE v.gd/eMfHsm v.gd/Ub7mqv v.gd/RReVk0 v.gd/vS3uTI v.gd/4Zxmba v.gd/1BnFph
Pages
▼
No comments:
Post a Comment