8.8.8.8、より速いブラウジングのための DNS アドレス

作者 Abel Avram , 翻訳者 鰈崎 義之 - CSKシステムズ 投稿日 2009年12月8日

セクション

運用/インフラ,

デベロップメント,

設計/アーキテクチャ

トピック

パフォーマンス&スケーラビリティ ,

Architecture

タグ

Browsers ,

Google

原文(投稿日：2009/12/04)へのリンク

 

Google は、さらなるブラウジングの速度向上の試みとして、2 つの公用 DNS サーバ、すなわち 8.8.8 と 8.8.4.4 を提供している。

DNS サーバは Web 名を、文字列の識別子からネットワークプロトコルの基盤で使う数字の識別子に変換するために使われる。Google によると、平均的ユーザは、典型的な一日のブラウジングでこのような変換を数百回必要としている。多くの Web ページは今日、複数のドメインのコンテンツを組み込んでいて複雑である。それぞれのドメインはドメイン名の解決を必要としている。名前解決の手順 - DNS サーバへの接続、数字の ID(IP アドレス) を検索、レスポンスの返却 – は、ブラウジングの待ち時間を増加し、結果的に完全にページをロードするのに時々数秒間必要とする。この例では、実に 11 秒もかかっている。

Google はこの DNS の待ち時間を受け入れ難いと考え、ブラウジングの速度を向上することを期待して 2 つの全世界的に分散した公用の DNS サーバを公開した。彼らは、主に 3 つの課題に取り組もうとしている。

• 速度: リゾルバ側のキャッシュミスは、遅い DNS レスポンスへの主な原因の一つだ。巧みなキャッシング技術は、これらのレスポンスの速度の向上に役立てることができる。Google Public DNS は、プリ・フェッチを実装している。レコードの TTL が期限切れになる前に、私たちは継続的に、非同期的に、多数の人気のあるドメインへのユーザリクエストと独立して、レコードを再読み込みする。このことは Google Public DNS 宛てのパケットがサーバへ到着し返る往復時間で多くの DNS リクエストを処理することを可能にする。
• セキュリティ: DNS は、ネームサーバのキャッシュを汚染し、悪意のある Web サイトへすべてのユーザを誘導する、成りすまし攻撃に対して脆弱性がある。DNSSEC のような新しいプロトコルが広範囲に採用されるまで、リゾルバは、彼らのキャッシュの安全性を維持するために追加措置を取る必要がある。Google Publi DNS は、クエリ名の大文字小文字をランダム化することと追加のデータを DNS メッセージに含めることにより、攻撃者が有効なレスポンスに成りすますことをより困難にする。
• 妥当性: Google Publi DNS は、DNS サーバの標準に従い、ブロッキング、フィルタリング、あるいはユーザのブラウジング体験を妨げる可能性があるリダイレクトを実行せずにコンピュータが期待する正確な応答を与える。

Google は 彼らの DNS サーバが優れている理由を以下のように述べている。

• 悪意のあるトラフィックを含む、クライアントトラフィックからの負荷を処理するための適切なサーバのプロビジョニング。
• DoS と増幅攻撃を防止。これは主にセキュリティの課題であるが、クローズドなリゾルバの方がオープンなものより影響が少ない。DoS 攻撃を防ぐことは、DNS サーバに掛かる余分なトラフィックの負担を排除することによってパフォーマンスの利益もまた得られる。攻撃を最小化するために使われているアプローチの詳細については、セキュリティ上の利点のページを見て欲しい。
• 共有キャッシュのための負荷分散は、サーバクラスタ全体の集約されたキャッシュヒット率を向上する。
• 名前解決のプリ・フェッチは、受動的キャッシングと大部分のリクエストをキャッシュで処理することを目的にすることで従来の制限に打ち勝つ。私たちは DNS プリ・フェッチ技術を経験することで、DNS 速度向上のための有効な機会を提供していると考えている。以下のように、私たちは利益、制限の概要を与え、プリ・フェッチの実装に挑戦し、どのようにそれらの挑戦が、トラフィック優先順位およびキャッシュのパーティショニングのような追加の技術と出会うかを楽しみにしている。
• すべてのユーザへの近接のためにグローバルなカバレッジを提供。

良く似ているが異なる話で、Google は、ブラウジングの速度をさらに向上するためにどのように Chrome が名前解決を処理しているかを明らかにした。Chrome ソフトウェアエンジニアの Jim Roskind は、いくつかの秘訣を語った。

• ページがロードされたとき、Chrome はすべてのリンクを解析し、あらかじめオペレーティングシステムに名前解決を要求することで IP アドレスを取得している。オペレーティングシステムがそれを終えていた場合は、レスポンスは既に OS のキャッシュ内にあるので、レスポンスは捨てられる。だから、ユーザがリンクをクリックするとき、ブラウザは対応する IP アドレスを要求し、もう一度名前解決することなしくキャッシュから返される。
• 別のソリューションはマウスを監視することである。ユーザはリンクをクリックしたいとき、200ms ほどリンクの上に留まり、その後実際にリンクをクリックする。この時間内に、Chrome はリンク先の IP アドレスを取得しようとする。
• Chrome に実装されている別のソリューションは、前に解決された名前を永続化するキャッシュを保持することである。だからユーザが特定のページを再訪問したとき、Chrom は既に使われるために準備された IP アドレスのリストを持っている。
• Chrom は、ブラウザが OS にロードされる前に、ホームページの IP アドレスをオペレーティングシステムに要求する。ブラウザのローディングが終了したとき、ホームページは、IP アドレスが既に OS のキャッシュ内にあるので素早くロードすることができる。これは起動時間を 250-500 ms 縮める。

将来的には、1-2% ほどの TCP/IP パケットは転送中に失われる。そして Windows 上では TCP/IP スタックは 3 秒のタイムアウトを持っており、その後再送を開始する。最初のパケットが失われたとき、ユーザはページがロードされるのを期待しながら待っているが、ターゲットの Web サイトは本当にコンタクトできなかった。3 秒は Google にとってあまりにも長い過ぎるので、彼らは、応答の無い TCP/IP パケットを再送するかサーバが妥当な時間内に応答しなかったときは新しい接続をオープンするメカニズムを Chrome に実装しようとしている。

 

• 次へ >