上一篇博客提到09年初WED團隊開發的瀏覽器環境檢測工具時，忘記說這個是aoao同學的創意了。不過沒關系，據說他又在秘密規划新版本了，再據說新版要增加的DNS解析時間計算已經開發完成，點上面那個鏈接就可以搶先體驗。。。
好吧，參加過11年Velocity大會的同學應該都知道facebook那個算DNS解析時間的方法了，像我這種窮人家孩子參加不起VC大會的，主辦方很厚道的提供有PPT可供觀看。看完PPT覺得不過癮，還是來動手實戰下吧。
首先看原理：
BASHa <= <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://imququ.com/post/how-to-get-dns-time-in-browser.html，參與評論 »
https://imququ.com/post/how-to-get-dns-time-in-browser.html