❗ 本文最后更新于 4694 天前,文中所描述的信息可能已发生改变,请谨慎使用。
上一篇博客提到09年初WED团队开发的浏览器环境检测工具时,忘记说这个是aoao同学的创意了。不过没关系,据说他又在秘密规划新版本了,再据说新版要增加的DNS解析时间计算已经开发完成,点上面那个链接就可以抢先体验。。。
好吧,参加过11年Velocity大会的同学应该都知道facebook那个算DNS解析时间的方法了,像我这种穷人家孩子参加不起VC大会的,主办方很厚道的提供有PPT可供观看。看完PPT觉得不过瘾,还是来动手实战下吧。
首先看原理:
a <= <random number>
t1 http://a-doppler.facebook.com/test_pixel?HTTP1.0&t=1&size=0k
t2 http://a-doppler.facebook.com/test_pixel?HTTP1.1&t=2&size=0k
t3 http://a-doppler.facebook.com/test_pixel?HTTP1.1&t=3&size=0k
t4 http://a-doppler.facebook.com/test_pixel?HTTP1.1&t=4&size=10k
t1 = DNS + New Connection +RTT
t2 = New Connection + RTT
t3 = RTT
10k /(t4–t3)~TCP bandwidth
(来源:《MobilePerformanceVelocity2011.pdf》 by DavidWei.)
这方案有两个关键点:
1、为了避免各种DNS缓存,每组请求必须用一个从来没被用过的全新N级域名。这就要求你的域名支持泛解析。例如我为了这个实践,开了*.qgy18.com的解析。
2、每组的第一个请求响应必须以HTTP/1.0返回。我开始还没注意这个,经aoao提醒才明白,这样才可以确保后面的请求会重建Connection。
t2和t1指向同一个域名,且都需要重新建立连接,所以t2-t1是DNS解析时间;t2返回Connection: Keep-Alive,t3是在Keep-Alive指定的timeout时间内发起的新请求,且返回内容为空,所以是RTT(Round-Trip Time);t4在t3的基础上只是把返回内容大小由0k变成10k,所以t4-t3是加载这10k资源花费的时间,这就可以得到网络带宽了。为了减少网络波动,也可以多测几次取平均值。
明白了原理就好办了,剩下的几行代码相信大家都会写,略过。
相比Navigation Timing提供的统计,这种方法好处是兼容绝大部分浏览器,没有浏览器实现上的差异和bug,能较准确的反应浏览器查询DNS所花费的时长;缺点是部署起来比较麻烦。
本文链接:https://mailseason.com/post/how-to-get-dns-time-in-browser.html,参与评论 »
--EOF--
发表于 2012-01-07 21:31:36。查看本文 Markdown 版本 »
专题「HTTP 相关」的其他文章 »
- 记一次图片访问异常排查过程 (Apr 28, 2023)
- HTTP Alternative Services 介绍 (Aug 21, 2016)
- 关于启用 HTTPS 的一些经验分享(三) (May 05, 2016)
- 如何压缩 HTTP 请求正文 (Apr 18, 2016)
- HTTP 协议中的 Content-Encoding (Apr 17, 2016)
- 三种解密 HTTPS 流量的方法介绍 (Mar 28, 2016)
- HTTP Public Key Pinning 介绍 (Mar 05, 2016)
- 关于启用 HTTPS 的一些经验分享(二) (Dec 22, 2015)
- 关于启用 HTTPS 的一些经验分享(一) (Dec 04, 2015)
- HTTP 代理原理及实现(二) (Nov 20, 2015)
Comments
Waline 评论加载中...