Google Public DNSを使うとネット回線の速度が低下する？ 95
ストーリー by hylom
へー（棒） 部門より
へー（棒） 部門より
DNSの設定のせいでインターネットの通信速度が遅くなる、という話があるようだ（光回線なのに2Mしか出ず超遅かったけど、DNSの設定をやり直したら50Mの超スピードに戻ったって話。）。
光回線を使っているにもかかわらずスピードテストツールで回線速度を調べたところ約2Mbpsしか出ず、DNSをGoogle Publis DNSからプロバイダ提供のものに変更したら速度が大幅に向上した、という。
しかし、はてなブックマークではこれに対し疑問の声も上がっている。
仕組みを考えろ (スコア:5, すばらしい洞察)
単に、ISP最寄りのCDNノードではなく、GooglePublicDNSから近くISPから遠いCDNノードに割り振られただけでしょ
Re:仕組みを考えろ (スコア:4, 参考になる)
ですよね。
DNS的な問い合わせ元に応じてCDNのノードが割り振られるので、
ISP の DNSサーバー使えば、ISPに近いCDNノードが割り振られるけど、
Google Public DNS 使うと、その時使った Google 側の DNSサーバーに近い CDNノードが割り振られちゃう。
で、最適とはほど遠い経路になって遅くなると。
Re:仕組みは変わった。 (スコア:0)
>その時使った Google 側の DNSサーバーに近い CDNノードが割り振られちゃう。
嘘です。
Akamai だけでなく Google 自身が困るので、接続元の IP アドレスの geo-information を元にして、最適な IP を解決するようになっています。
Re:仕組みは変わった。 (スコア:4, 参考になる)
IPアドレスから得られるgeo-informationなんて、精度は国単位ぐらいまでしか信頼度ないよ。例えば、静岡あたりで接続していると長野の山中や東京千代田区だの回答がある程度の精度しかないからな。下手すると明石市だなんて回答まで来る。静岡の場合IPv4での地理情報だと長野か東京になることが多く、IPv6だと大阪近辺が返されることが多い。そんな信頼性がないものはネットワーク内の接続の位置関係は関係ないから使えるわけなかろう。
ただ、ネットワーク内の接続の位置関係と地理的条件を加味した調整を行おうとするプロジェクトはある。もっとも、どこまで実際のシステムに組み込まれて運用されているかは不明だ。
Google Public DNSと地理情報についてはこんな記事が公開されている。
Google Public DNS and Location-Sensitive DNS Responses
http://googlewebmastercentral.blogspot.jp/2014/12/google-public-dns-an... [blogspot.jp]
Akamaiあたりは顧客からクレームがあって、Google Public DNSとある程度協調をとって動作させようと調整を行っているようです。
成果としては、以下の文書がある。
Internet Draft: Client Subnet in DNS Requests
https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-00 [ietf.org]
Re:仕組みは変わった。 (スコア:1)
> IPアドレスから得られるgeo-informationなんて、精度は国単位ぐらいまでしか信頼度ないよ。
なので、Google には GeoIP なんか使って欲しくは無いんだが強制的に適用されるので超困っている。
IPv6 がネイティブで使えるようになったが、諸事情で HE の IPv6 トンネルを使い続けているのでググる際の位置情報が米国になる。超困る。
Re: (スコア:0)
お主、静岡でその回答がくるということは、Niftyあたりを使ってないか？ IPv6だとJPNE経由でKDDIの回線で、POIはNTT西日本で関西にある。IPv4だと、都道府県別POI経由で独自ネットワークになってて、東海地方という枠組みなら長野や名古屋なんて回答が来るし、その上位は東京のルータを経てIXその他に接続だから、長野や東京の回答があってもなにも不思議ではない。
Re:仕組みは変わった。 (スコア:1)
Niftyに限らずフレッツ系でv4を圏域ごとのPOIで通す古いISPならどこでもそうだけど
元nifの中の人なのでAC
Re: (スコア:0)
CDN として Akamai を使っている場合は、クライアントの geo-information を元に、Google DNS が最適な Akamai 側のノードの IPアドレスを返してくれるって話なんでしょうか？
でも、数ある CDN 会社すべてについて、その種の連携ができているわけではないですよね？
だとすると、今回の相手先は、そういう連携ができてない CDN を使っていたのでは？
Re: (スコア:0)
ソフトバンク光でバンダイチャネルとかの動画サイトを見るならば、プロバイダのDNSに接続したほうが、明らかに安定している。理由は簡単で、バンダイチャネルの場合、サーバーがソフトバンク系列のデータセンタに設置されているので、プロバイダのDNSとCDNが一番効率が良いからだ。
あと、ネットのワークのベンチマークだけれど、あまりあてにならないよ。自分のところのプロバイダがベンチマークが使っているサイトがあるプロバイダと直結の太い回線持っていたりすると、無意味に速い結果が表示されることがある。ソフトバンクって、tracertコマンドなんかで確認すると、ベンチマークを気にしてそういうことを平気でやっていることが多いからなあ。
Re:仕組みを考えろ (スコア:1)
> ソフトバンクって、tracertコマンドなんかで確認すると、ベンチマークを気にしてそういうことを平気でやっていることが多いからなあ。
なにか証拠を示して頂きたい
Re: (スコア:0)
ベンチマークが信用できないというのには一理あるけれど、プロバイダが、通信量が多い他のプロバイダやデータセンタと専用回線を持っていたり、直結回線を持っていたりするのは普通だよ。物理的にも技術的にも経済的にも回線の太さに限界がある以上、通信量が多い相手と直接接続したほうが経済的にパフォーマンスを稼げることが多いからね。
弱小のプロバイダだと、上位プロバイダにつながっているだけとかIXにつながっているだけというところもある。そういうプロバイダは、よほど安くない限りさっさと契約を解除したほうがいい。
Re:仕組みを考えろ (スコア:1)
traceroute を並列で動作させて応答の遅延とその時の多重度から
帯域を推測する事が可能かもしれません。
もちろん、そのような用途であれば ping で送出するパケットのサイズを
可変させる方がはるかに容易に帯域幅を測定できるはずです。
というより、もっとマシなツールがいくらでも……
Re: (スコア:0, 荒らし)
ですよね。
DNS的な問い合わせ元に応じてCDNのノードが割り振られるので、
ISP の DNSサーバー使えば、ISPに近いCDNノードが割り振られるけど、
Google Public DNS 使うと、その時使った Google 側の DNSサーバーに近い CDNノードが割り振られちゃう。
で、最適とはほど遠い経路になって遅くなると。
こう書くからには、今回使用された二つのスピードテストサイトでなんらかのCDNが使用されている証拠があるということですよね？
私にはわからなかったのですが、一体どのような根拠があってCDNが原因と主張されるのですか？
Re:仕組みを考えろ (スコア:1)
そうでなくともISPのDNS鯖が馬鹿みたいにスペック低いとかじゃない限り、わざわざGoogleの鯖に問い合わせかける時点で大半は遠回りになるよね。
Googleみたいな外部DNSはISPのDNSが障害を起こしたときの代替用だとおもうんだけど、何故わざわざ常用しようとするのか……
Re:仕組みを考えろ (スコア:1)
そう単純ではないかと。
ISPのDNSサーバがたまたま問い合わせ内容の答えをキャッシュしていたら、そのDNSサーバとやりとりのみで落ち着くけど。
最悪の場合は、ルートDNSから移譲先を辿る事なって、途中も含めてそれぞれのレスポンス速度に依存する。
どっちかというと、ISP側よりも、最終的に問い合わせに答える権威DNSサーバの性能に足を引っ張られる事例がありそうに思う。
Googleのは、どうせ、あらゆる情報を事前に収集して蓄積したGoogle内部のデータベースから返す、ってな方法なんだろうから、
聞かれてから世界中を飛び回って調べ始めるかもしれないISPのDNSサーバより有利になり得るかと。
Re: (スコア:0)
>何故わざわざ常用しようとするのか……
IPが簡単で覚えてるからじゃね…
Re: (スコア:0)
>何故わざわざ常用しようとするのか……
IPが簡単で覚えてるからじゃね…
全くその通りだ
新しく鯖とかセットアップした時取りあえず8.8.8.8入れとけば使えるというのがね
Re: (スコア:0)
ローカルの権威、兼、キャッシュDNSサーバを自分で立てるときの上流に、とかね。
自動配布されるISPのDNSサーバのアドレスはいつか変わるかも知れないわけで、
それに追随させる設定を真面目に考えるとめんどくさい。
勝手に追随してくれるDNSサーバのソフトもあるけど。
Re: (スコア:0)
DNSのレスポンスが、ISPのよりもGoogleの方が速い->DNS問い合わせが多いWEBページの表示が速くなる、といういっとき流行った、伊東家の食卓的テクニック（ナウい言葉でライフハック？）ですよね。
Re: (スコア:0)
インターネットコンテンツセーフティ協会による、ネット検閲の回避。
（確かめたわけじゃないけど、多分プロバイダのDNSと違って、Google Publis DNSには日本ローカルの検閲がかかってないと思う）
Re: (スコア:0)
Google Public DNSが持っているキャッシュの大きさと応答速度もバカにできない要素だと思う。
経路での遅延と比べた場合にどっちが早いかって話だと思う。
Re: (スコア:0)
それだけにしては遅すぎね?
Re: (スコア:0)
>単に、ISP最寄りのCDNノードではなく、GooglePublicDNSから近くISPから遠いCDNノードに割り振られただけでしょ
高度な地理的分散機能を持ったCDNをを使ってるサイトへのアクセスが遅くなるならそうだけど、
元記事のスピードテストは国内のレン鯖を使っててCDNじゃないよね。
ということで、「ただの気のせい」が答です。
Re: (スコア:0)
今回使用された二つのスピードテストサイトでなんらかのCDNが使用されていることはどのようにして見つけ出したのですか？
えー・・・ (スコア:5, すばらしい洞察)
良くわかってない人が書いたblogは記事にしてはいけない気がする、流石に。
Re:えー・・・ (スコア:1)
どうも開発者らしいけど、あまり変な情報を発信しないでもらいたいなぁ……
せめて『効果は個人差があります。技術的な仮説検証も裏付けも証拠もありません。』くらい書いておいてもらわないと。
考察 (スコア:5, 参考になる)
パフォーマンスネタなので、専門でやっている立場でコメントします。
1. DNSは世界的にパフォーマンスが遅延傾向にある
アメリカのパフォーマンス業界でホットな話題はDNSの遅延で、DNSのパフォーマンス改善は急務となっています。
現状のパフォーマンスは、ここが参考になるかと。
http://www.dnsperf.com/ [dnsperf.com]
2. USENのスピードテスト、BNRスピードテストは、CDNとは関係無い
サイトそのものはCDNを使ってますが、スピードテストで通信している先はCDNを使っていないです。Wireshark、Microsoft Network Monitor、Firebug、Developer Tool、どれを使っても良いのですが、モニタリングツールを使えばわかります。
USENは、sp.usen.com、BNRは、suite3.musen-lan.comとv3.musen-lan.com。
なので、DNSのIPを見て最寄りのエッジサーバから通信してるわけじゃないです。
3. DNSのパフォーマンス計測のデータが掲載されていない。
DNSに遅延の原因があるというのであれば、まずはDNSのパフォーマンスの計測を行うべきでしょう。スピードテストがDNSの遅延に影響されているという因果関係を説明するための実験が行われていません。
4. そもそもDNSの名前解決の時間は計算に含まれていない
USENのサイトに以下のように記載されています。
「複数サイズのデータを実際にダウンロードし、そのダウンロードにかかった時間から1秒あたりにどれだけのデータをダウンロードできているかを調べます。
ダウンロードしたデータ量÷ダウンロードに要した秒数＝回線速度となります。」
BNRのサイトに以下のように記載されています。
「本サイトの測定方法は、実際にテストサーバーからのデータを受信することにより、実際の通信速度を計測しております。」
USENのテストの場合は、33.7KB、85.0KB、1.1MB、2.8MB、9.8MB、20.2MBの順でファイルをダウンロードしています。
BNRのテストの場合は、118.2KB、236.4KB、472.6KB、774.9KB、1.5MB、3.0MBの順で、最初にsuite2.musen-lan.com、次にv3.musen-lan.comとサーバを変えて2回計測しています。
Flashのソースコードがどう書かれているのか分かりませんが、もし万が一、DNSのLookup時間が含まれていたとしても、最初のファイルのダウンロードの時点で、ローカルキャッシュされるので、パフォーマンスに多大な影響を及ぼすとは考えにくいです。
5. WiFi経由でテストをしてはいけない
WiFiの通信環境は、通信状況が大きくブレるため、外部との通信速度テストに使うには、不適切です。変数を減らすため、有線回線を使うべきです。
6. 数回のテストでは、数学的に何も証明できない
何回計測したのか分かりませんが、記事から察するに1回か2回というところでしょうか?
「たまたま、そうなっただけ」と言われても仕方がないです。
統計学で、信頼区間という概念があります。同じ調査をやったとしたら、どの位の確率で同じ結果になるか、というものです。
ちゃんと実験計画法に基いて実験・計測すべきですが、ラフに調べるにしろ、20～30回は計測してみるべきです。何故なら、必ず、計測にはブレが生じるし、外れ値も発生します。
最低でも、最速値と最遅値を外して計算するトリム平均を求めてないと…
ちゃんとやるなら、ヒストグラムとか、箱ひげ図ぐらい作らないと。
7. ダウンロード時間の最も影響を与えるのは、途中経路
サーバ側にボトルネックが無いと仮定した場合、ダウンロード時間に最も影響を与えるのは途中経路です。ホップ数と、各ホップのパケットドロップ率、レイテンシです。
まず、何よりも、経路検証をしないと、この手のテストは意味がありません。
下のレイヤーから徐々に上のレイヤーへと上がっていくのが、この手の試験の一般規則です。
先日、Computer Measurement Groupの2015年度のMichelson Awardを、ワシントン大学のRaj Jain教授が受賞されたんですが、Jain教授が書かれた「The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling」という本があります。
ワシントン大学では20年以上、パフォーマンス計測の教科書として使われています。Jain教授は、ネットワーク通信の計測とパフォーマンスのモデリングの権威ですし、この本の第二版が近日中に発売されますので、それを読んでから実験されて記事にされては如何かと。
この手の計測試験について、やり方を詳細に解説しておられます。
私としては、たまたまそういう計測値になっただけだろうし、DNS関係ないし、一番影響があったのはWiFiの通信状況じゃないの?って見解です。
Re:考察 (スコア:5, 参考になる)
まともに答えるべきかどうか、少し迷いました。
結論から言うと、専業でやってるんで、そういうのを判別するツールがあるんですよ。
皆さんが使えるのだと、BuiltWith(http://builtwith.com/)というのがあります。
それを使えば、簡単に判別できます。
さて、ツールだけで終わらせると、あまりエンジニアとしては良質な回答じゃないと思うので、もう少しRawなやり方を書きます。
対象となるサーバに対して、tracerouteをされましたか?
そうすれば、経路が分かります。
するとですね、東京のKDDIとNTTの回線2つからTracerouteしてみると、このサーバの手前にあるのは、125x63x33x13.rev.usen.ne.jpと125x63x33x130.rev.usen.ne.jpというサーバなんですよ。
まぁ、それだけでも、分かるんですが、もう少し、証拠を積み重ねましょう。
Akamai時代に習ったのですが、ネットワークの三角法というのがあってですね、幾つかのサーバ(IPでもいいです)が、物理的に同じ場所にいるのか、違う場所にいるのかを判別するやり方なんですよ。
異なる幾つかのASからTracerouteをかけたときに、同一のGatewayに接続されてホストに辿り着いた場合、物理的に同一のデータセンターにそのサーバが存在すると分かるわけです。
さて、日本から、このsp.usen.comにTracerouteをした場合と、ロンドンからTracerouteをかけた場合、CDNを使っているなら、異なるGateway、異なるサーバIPに辿り着くはずです。
でも、全く同じなんです。
もしかしたら、たまたま、同一になったかもしれないですか?
それでは、南米のベネズエラからTracerouteをかけてみます。同じです。
タイからTracerouteをかけてみます。同じです。
CDNの契約で、配信対象が日本国内だけかもしれませんね。
では、大阪のOCNからTracerouteをしてみます。同じです。
つまり、異なるASネットワーク6箇所からTracerouteをしても同じ場所に辿り着くわけです。
故に、USENのデータセンターにこのサーバは置いてあり、(分散配置型の)CDNは使っていないと断定できるのです。
それにですね、この手の試験にCDNを使っていたら、まっとうな試験ではなくなってしまいますよね。倫理的に。
商売的にも、「あなたの使ってる回線、遅いですよ。乗り換えませんか?」というマーケティングのリード集めが目的のサービスですから、CDNを使って高速化したら、問い合わせが得られないじゃないですか。
Re:考察 (スコア:2)
まず、スピードテストのページでFlashを使い通信しているわけですから、どのホストと通信をして、ファイルのダウンロードをしているかを確定する必要がありますよね?
だから、モニタリングツールが必要になるわけです。
それで、ホストが確定したら、そのホストがCDNサービスのものなのか、それとも普通のサーバなのかを確定するわけです。
私は、元の説明で、ドメインを根拠にしていないですよね。
ホスト名を根拠にしています。
通信先のホストが確定できれば、生のHTTP Headerを見て確認するもよし、面倒であれば、ツールを使うもよし、tracerouteの経路から判断するもよし、です。
Re:考察 (スコア:2)
「ネットワーク遅い→DNS変えたら早くなった」という内容が根本的に間違っているから、ここまで話題になってるのだと思いますが。
Re:考察 (スコア:2)
「風邪を引いた」：事実
「祈祷してみた」：事実
「風邪が治った」：事実
何一つ間違っていない。しかし、因果関係は証明されていない。
検証しました (スコア:3)
問題の再現性を検証し、再現を確認しました。
きっと、元の記事を書かれている方は、DNSの変更の後、OSの再起動をされていないのではないでしょうか。
DNSの設定を変更した後、再起動せずにテストをすると、確かにスピードテストの速度が低下します。
Windows10、MacOS(El Capitan)、Linux（Slackware）ともに、その現象を確認しました。
一旦再起動すれば、スピードテストの速度は元に戻ります。
Windowsも、MacOSも、DNSの設定変更後は、再起動が推奨されています。
Windows、MacOS、Linux、全てでDNSのキャッシュ、ルートキャッシュのクリアをしても遅延したままなので、そこが別のところに原因がありそうです。
キャッシュクリア後もスピードテストの速度は遅延したままでしたが、再起動後は速度が高速になりました。
ここから先は、興味がある方は、ご自分で調べて見てください。
ブロック回避 (スコア:2, 参考になる)
国内ISPのDNSで児童ポルノのブロッキングが行われるようになってます。
サーバー単位のブロックな為、8月に数日間twitterの画像が一切表示されなくなることがありました。
同じ誤爆によくブチ当たるのでうちではOpenDNSを使ってます。
Re: (スコア:0)
よく使うサイトが偏っているなら、固定回線でのDNSの応答速度だけなら、Google Public DNSでもOpenDNSでもなく、自宅設置DNSが一番速い。国内ISPのDNSで行われているブロッキングも関係ないしね。実際、うちの場合、DNS Benchでベンチマークとっても、プロバイダのDNSやGoogle Public DNS、NTT Americaなんかのサイトよりも、自宅設置DNSの方が速いものなあ。もっとも、非力なパソコンで、DNS建ててしまうと遅いだけのこともあるけれど、それも設定次第だからなあ。
いわせんなはずかしい (スコア:0)
NSAも忙しんだから急かしちゃダメ～
# んなわきゃ。。。ない。。よね？
Re: (スコア:0)
tradecraftの一環というわけか
ただの距離的な問題でしょ。 (スコア:0)
ただの距離的な問題でしょ。
Google のを使い続けるよ。
あるいは、AmericaNTTを使うわ。
Re:ただの距離的な問題でしょ。 (スコア:1)
129.250.35.250/251はPublic DNSではありません。 | Aimless [aimless.jp]
Re: (スコア:0)
nice joke
これが原因じゃないか？ (スコア:0)
>回線は、Softbank光。
タレこみでは省略されてるけど。
googleで不満はないけど (スコア:0)
flets光のDNS割り当てたらredditだの海外サイトに繋がらくなったのは何故…
だから129.250.35.250にしろって (スコア:0)
言ってないけど
レスポンスが変化するならわかるけど (スコア:0)
なんで名前解決の仕組みをいじっただけで回線速度が2M→50Mになると思えるのかわからん。
DNSの向け先を利用ISPのものにしようがGoogleのものにしようがDNSにリクエストを出してから答えが返ってくるまでの時間が変わるだけだろ？
ファイルの転送速度が変わるということではない。
Re:レスポンスが変化するならわかるけど (スコア:1)
DNS設定書き換えるとたぶんルーターが再起動してると思うので
「ルーターを再起動したら速くなった」
とかいう、ありがちな話な気が...
Re:レスポンスが変化するならわかるけど (スコア:1)
Re: (スコア:0)
1バイト転送するごとにコネクションを切断して名前解決からやりなおしてるのでは
Re: (スコア:0)
確かに、CDNが存在しない世界ならば、DNSにリクエストを出してから答えが返ってくるまでの時間が変わるだけだ。
しかし、CDNがあると話が変わってくる。契約しているプロバイダのローカルネット内にCDNのキャッシュサーバがあったり、CDNのサーバへの直結回線があったりすると、通常のバックボーン回線でオリジナルのサイトにアクセスするよりも、より太い回線かつ、ネットワーク的により近いサーバに高速でアクセスできることがある。当然、プロバイダのDNSは、契約しているCDNでアクセスできるサイトや直結回線があるサイトについては、DNSのレスポンスでそちらを優先する応答を行うようにチューニングされている。
Publis DNSを使ったりすると、馬鹿正直に混んでいるバックボーン回線を使ってオリジナルサイトにアクセスするためにファイルの転送速度が遅いということになる。
Re:IPv6 (スコア:2)
DNSとDHCPをごちゃ混ぜにしているかと。
DNSとDHCPは別物です。
GoogleのDNSにしたからといって、GoogleからIPはリースされません。
あくまでも、プロバイダからIPはリースされます。
また今回の元記事では、Wifiルータ経由で通信しているので、Wifiルータからプライベートアドレス(192.168.0.x/255のような)がリースされているはずです。
Re:IPv6 (スコア:2)
コメントを付ける前に、まず、ご自身で確認してみては如何でしょうか?
もしも、あなたがエンジニアであるなら、人が書いた事を鵜呑みにせず、まずは自分で確認する事が、職業上、とても大事なことだと思います。
(あなただけを指して書くわけじゃなく、ここについているコメント全てに共通して言いたいんですけどね)
nslookup -type=SOA sp.usen.com
と引けば、SOAレコードを持ってるDNSサーバが、gns11.usen.ne.jpであり、sp.usen.comはsp.usen.ddns.usen.ne.jpのCNAMEであると分かります。
それで、このホストがIPv6のアドレスを持っているかどうかを以下のコマンドで確認できます。
nslookup -type=AAAA sp.usen.ddns.usen.ne.jp gns11.usen.ne.jp
そうすると、このホストはIPv6のアドレスは持っていない事が分かります。
これは、suite2.musen-lan.comもv3.musen-lan.comも同様の手順でIPv6のアドレスを持っていないことを確認できます。
なので、この件に関して云えば、IPv4であるか、IPv6であるかによって経路が変わるという議論は終わりです。
あと、
http//it.srad.jp/comments.pl?sid=672638&cid=2924753
でも書きましたが、問題はOSの再起動をしていないことで発生していると思います。
これは、元記事を書いている本人に再起動したかどうかを確認したところ、再起動していないそうです。
Re:IPv6 (スコア:2)
「俺の環境では動く」というのでは論理的ではないというのは、全く同意です。
ですから、今までの議論で、色々と一つ一つ切り分けをしてきたわけで。
「CDNの話題も散々出てるのに」って書いてる時点で、このスレッド全体を読んでないんだなって分かるわけですが…(CDNは関与してないことは、切り分け済みです。)
それを違うんじゃないの? もっと可能性があるんじゃないの? その結論は勇み足が過ぎやしません?というのであれば、あなたの方でも具体的な検証作業をして、データを提示して議論するのがエンジニアってもんじゃございませんの?
ですから、あなたご自身の検証とデータを提示して下さい。
そうやって、複数人によって、ダブルチェック、トリプルチェックと積み重ねることに意義があると思います。私の検証だって、どこか抜け落ちてるところがあるかもしれないし。
「私は～だと考えていて、これをこうして検証してみたら、こうだったので、それは違うと思いますよ」という具体的なものがなければ、話が進展しないですし。