8.8.8.8——用於快速瀏覽的DNS服務器

作者  Abel Avram
譯者 崔康   
發佈於  2009年12月10日 上午2時56分   
社區Architecture主題互聯網,性能和可伸縮性標籤Chrome,瀏覽器,Google                          

谷歌提供了兩台公共DNS服務器,分別是8.8.8.8和8.8.4.4,以進一步提高瀏覽網頁的速度。

DNS服務器的作用是,把網站名字——文字標識符轉換為底層網絡協議使用的數字標識符。根據谷歌統計,平均每位用戶每天需要數百次的這種轉換服務。如今,很多網頁都很複雜,包含了來自不同域名的內容,每一個域名都需要一次解析。域名解析過程——連接DNS服務器、找到數字ID、返回結果——增加了網頁瀏覽的延遲,導致加載網頁需要數秒鐘的時間,甚至11秒(如本例)。

谷歌認為這種DNS延遲是不可接受的,它開通了兩個分佈於全球的公共DNS服務器以提高瀏覽速度。他們試圖解決三個主要問題
  • 速度:解析器端的緩存丟失是導致DNS反應緩慢的主要原因。出色的緩存技術能夠提高響應速度。谷歌公用DNS實施了預取技術:在記錄的TTL過期之前,我們會不斷異步、獨自地刷新大量流行域名的記錄。這使得谷歌公用DNS能夠在數據包訪問服務器並返回的單次往返時間內處理很多DNS請 求。
  • 安全:DNS容易受到欺騙性攻擊,這種攻擊會破壞解析服務器的緩存並把所有用戶路由到一個惡意網站。除非新的協議如DNSSEC得到廣泛應用,解析器需要採取進一步措施保證它們的緩存安全。谷歌公共DNS通過打亂域名查詢記錄和在DNS消息中包含額外數據等措施使攻擊者難以欺騙有效的響應。
  • 有效性:谷歌公共DNS符合DNS標準,提供給用戶期望的準確反饋,不會阻礙、過濾或者重定向請求從而損害用戶的瀏覽體驗。
谷歌聲稱它們的DNS更優秀,因為
  • 充分利用服務器處理來自客戶的流量負載,包括惡意訪問。
  • 防止Dos攻擊和放大攻擊。雖然這主要是一個安全問題並對封閉的解析器影響更大一些,但是防止Dos攻擊也有利於性能,因為這消除了DNS承擔的額外流量負載。更多有關我們降低攻擊機會的辦法的信息,請查看安全優勢
  • 針對共享緩存的負載平衡,以提高服務集群間的聚合緩存命中率。
  • 預取名字解析,克服傳統的、被動的緩存機制,致力於處理緩存之外的大多數請求。我們正在測試一種DNS預取技術,認為很可能會大幅提高DNS速度。我們給出了其優勢概況、限制和挑戰,以及我們準備如何利用流量優先設置和緩存分區等技術應對這些挑戰。
在一個類似但不同的說明中,谷歌解釋了Chrome如何處理名字解析以提高瀏覽速度。Chrome軟件工程師Jim Roskind給出了一些提示:
  • 當頁面加載時,Chrome分析頁面的所有鏈接,同時提前要求操作系統解析這些名字以得到IP地址。當操作系統完成時,反饋被丟棄了,因為這些反饋現在已經存儲到了操作系統的緩存中。因此,當用戶點擊某個鏈接時,瀏覽器會詢問對應的IP,結果會從這些緩存中返回,而不需要再次解析。
  • 另一個解決方案是監控鼠標。當用戶想要點擊某鏈接時,他需要花費200毫秒停留並實際點擊它。在這段時間內,Chrome嘗試獲取該鏈接的IP。
  • 還有一個解決辦法是長時間的緩存之前的名字解析,當用戶重訪這個特定頁面時。Chrome已經準備好了IP。
  • Chrome要求操作系統在瀏覽器加載之前先解析主頁的IP。當瀏覽器的加載完成後,主頁能夠快速加載,因為其IP已經存儲在操作系統的緩存中。這減少了250-500毫秒的啟動時間。

關於未來:1-2%的TCP/IP數據包會在傳輸中丟失,TCP/IP棧在Windows上3秒後會超時重發。當第一個數據包丟失後,用戶等待頁面加載,但是目標網站還沒有真正連接。3秒對於谷歌來說太長了,因此他們將在Chrome中採取一種機制:當服務器在一定的時間內沒有響應的時候,要麼重新發送TCP/IP數據包,要麼重新發起一個新的連接。

查看英文原文:8.8.8.8, A DNS Number for Faster Browsing
一早用緊 8.8.8.8. 同 8.8.4.4. 了
唔怕轉 ISP
一早用緊 8.8.8.8. 同 8.8.4.4. 了
唔怕轉 ISP
觀星是答案 發表於 2009-12-17 16:56
我一早都轉左, 但係用tracert睇仲遠左 用落就冇乜分別
我一早都轉左, 但係用tracert睇仲遠左 用落就冇乜分別
kelvinlok 發表於 2009-12-18 17:35
遠就一定架啦
點可能近過 ISP 隻 DNS
遠就一定架啦
點可能近過 ISP 隻 DNS
觀星是答案 發表於 2009-12-18 23:52
遠左咪應該慢左
遠左咪應該慢左
kelvinlok 發表於 2009-12-19 00:23
可以 O甘諗
ISP 用隻 DNS server cheap O的, 所以都係慢


係唔係講lee個位呀
http://www.pcinhk.com/discuz/uchome/attachment/200912/27/58_1261911500JpJb.jpg

係唔係講lee個位呀
wo~~ 發表於 2009-12-27 19:00
o係router set啦
本帖最後由 杰仔 於 2009-12-27 19:31 編輯
o係router set啦
kelvinlok 發表於 2009-12-27 07:18 PM
610N ddwrt 好似出左final

冇野了
currently still a Work in Progress
610N ddwrt 好似出左final

冇野了
currently still a Work in Progress
杰仔 發表於 2009-12-27 19:28

真係有再話我知
匿名读者 写道 "曾经在用Ipv6反向代理访问Twitter文章中提到的反向代理的来源,http://aa.cx/ipv6-reverse-proxy,目前已经支持通过ipv6访问youtube了。
具体的步骤是:
访问Google的IPv6服务hosts ,将youtube相关域名的解析添加到hosts中
访问IPV6 reverse proxy for GFWed websites,将vX.lscacheX.c.youtube.com域名的解析添加到hosts中
添加一个额外的解析:2001:4860:c004::68 qwqy.vp.video.l.google.com
done, enjoy~

BTW:如果你使用的是windows,请注意用ipconfig /flushdns清空DNS缓存"
匿名读者 写道 "曾经在用Ipv6反向代理访问Twitter文章中提到的反向代理的来源,http://aa.cx/ipv6-reverse-proxy,目前已经支持通过ipv6访问youtube了。
具体的步骤是:
访问Google的IPv6服务hosts ,将youtube相关 ...
nissin 發表於 2009-12-30 15:48
這個對還是 ipv4 的網絡來說似乎沒什麼意思吧…

真係有再話我知
kelvinlok 發表於 2009-12-27 07:45 PM
http://www.dd-wrt.com/phpBB2/viewtopic.php?t=63539