by
Anonymous Coward
on 2015年11月24日 15時44分
(#2922467)
ですよね。 DNS的な問い合わせ元に応じてCDNのノードが割り振られるので、 ISP の DNSサーバー使えば、ISPに近いCDNノードが割り振られるけど、 Google Public DNS 使うと、その時使った Google 側の DNSサーバーに近い CDNノードが割り振られちゃう。 で、最適とはほど遠い経路になって遅くなると。
ですよね。 DNS的な問い合わせ元に応じてCDNのノードが割り振られるので、 ISP の DNSサーバー使えば、ISPに近いCDNノードが割り振られるけど、 Google Public DNS 使うと、その時使った Google 側の DNSサーバーに近い CDNノードが割り振られちゃう。 で、最適とはほど遠い経路になって遅くなると。
仕組みを考えろ (スコア: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)
plalaとか、NGN経由でない方はv4でも平気で東京や大阪に飛ばしてくれるしな…
Re: (スコア:0)
> IPアドレスから得られるgeo-informationなんて、精度は国単位ぐらいまでしか信頼度ないよ。
ネットワーク的に近けりゃ(低レイテンシ、広帯域)、都道府県は愚か国が違ってても構わないかと。
隣家への接続よりも遥か彼方のデータセンターの方が回線は早くても何の不思議もない。
IPアドレスに対して返答すべき回答ってのは物理座標がいくら正確に分かっても判断は出来ない。
CDN側の情報とネットワーク構造が把握できていればIPアドレス(所属ネットワーク)で判断できる。
必要なのはCDNと連携取る事。うまく解決できないとしたら提携してないCDNだったか、
ネットワーク構造の判断に失敗したか、単にバグだったとかそんなところだろう。
Re: (スコア:0)
> ネットワーク的に近けりゃ(低レイテンシ、広帯域)、都道府県は愚か国が違ってても構わないかと。
一時期、朝鮮文字が広告で出てたけど、あれは普通の広告が視界に入るより不快だよ。
Re: (スコア:0)
それ公開DNSサーバにおけるCDNの問題と何か関係あるんですかね?
Re: (スコア:0)
CDN として Akamai を使っている場合は、クライアントの geo-information を元に、Google DNS が最適な Akamai 側のノードの IPアドレスを返してくれるって話なんでしょうか?
でも、数ある CDN 会社すべてについて、その種の連携ができているわけではないですよね?
だとすると、今回の相手先は、そういう連携ができてない CDN を使っていたのでは?
Re: (スコア:0)
提携してないCDNでは問題あるし、提携してても絶対ではないけど、
そもそもどっちのスピードテストもCDN使ってなさ気な感じなのよねー…
ISPのDNSが遅いとか落ちてるとかよく落ちるとかでも無ければパブリックDNSを使う必要はなさ気。
Re: (スコア:0)
ソフトバンク光でバンダイチャネルとかの動画サイトを見るならば、プロバイダのDNSに接続したほうが、明らかに安定している。理由は簡単で、バンダイチャネルの場合、サーバーがソフトバンク系列のデータセンタに設置されているので、プロバイダのDNSとCDNが一番効率が良いからだ。
あと、ネットのワークのベンチマークだけれど、あまりあてにならないよ。自分のところのプロバイダがベンチマークが使っているサイトがあるプロバイダと直結の太い回線持っていたりすると、無意味に速い結果が表示されることがある。ソフトバンクって、tracertコマンドなんかで確認すると、ベンチマークを気にしてそういうことを平気でやっていることが多いからなあ。
Re:仕組みを考えろ (スコア:1)
> ソフトバンクって、tracertコマンドなんかで確認すると、ベンチマークを気にしてそういうことを平気でやっていることが多いからなあ。
なにか証拠を示して頂きたい
Re: (スコア:0)
ベンチマークが信用できないというのには一理あるけれど、プロバイダが、通信量が多い他のプロバイダやデータセンタと専用回線を持っていたり、直結回線を持っていたりするのは普通だよ。物理的にも技術的にも経済的にも回線の太さに限界がある以上、通信量が多い相手と直接接続したほうが経済的にパフォーマンスを稼げることが多いからね。
弱小のプロバイダだと、上位プロバイダにつながっているだけとかIXにつながっているだけというところもある。そういうプロバイダは、よほど安くない限りさっさと契約を解除したほうがいい。
Re: (スコア:0)
こういうベンチマークって、そもそも自宅からプロバイダまでの速度を測ってる認識だったけど。
プロバイダから目的地までの速度を知りたいなら、別の手段を使わないかい?
Re: (スコア:0)
tracerouteでbandwidthがわかるとは!
天才現る!
Re:仕組みを考えろ (スコア:1)
traceroute を並列で動作させて応答の遅延とその時の多重度から
帯域を推測する事が可能かもしれません。
もちろん、そのような用途であれば ping で送出するパケットのサイズを
可変させる方がはるかに容易に帯域幅を測定できるはずです。
というより、もっとマシなツールがいくらでも……
Re: (スコア:0)
まあそういうときはpathcharを使うよね
Re: (スコア:0, 荒らし)
ですよね。
DNS的な問い合わせ元に応じてCDNのノードが割り振られるので、
ISP の DNSサーバー使えば、ISPに近いCDNノードが割り振られるけど、
Google Public DNS 使うと、その時使った Google 側の DNSサーバーに近い CDNノードが割り振られちゃう。
で、最適とはほど遠い経路になって遅くなると。
こう書くからには、今回使用された二つのスピードテストサイトでなんらかのCDNが使用されている証拠があるということですよね?
私にはわからなかったのですが、一体どのような根拠があってCDNが原因と主張されるのですか?
Re: (スコア:0)
なんでこの書き込みが荒らしなの? > モデレータ
Re: (スコア:0)
>ちっぽけな力でも行使できるとスカッとするのかな?
という考えが浮かぶってことは君がそういう人だということに他なりませんよ。
ちっぽけっすねー
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)
サーバに8.8.8.8とか、あなた頭大丈夫ですか?
いや、本気で心配するレベルだよ…
Re: (スコア:0)
IPなんか疎通すりゃなんでもよくね
Re: (スコア:0)
ローカルの権威、兼、キャッシュDNSサーバを自分で立てるときの上流に、とかね。
自動配布されるISPのDNSサーバのアドレスはいつか変わるかも知れないわけで、
それに追随させる設定を真面目に考えるとめんどくさい。
勝手に追随してくれるDNSサーバのソフトもあるけど。
Re: (スコア:0)
DNSのレスポンスが、ISPのよりもGoogleの方が速い->DNS問い合わせが多いWEBページの表示が速くなる、といういっとき流行った、伊東家の食卓的テクニック(ナウい言葉でライフハック?)ですよね。
Re: (スコア:0)
インターネットコンテンツセーフティ協会による、ネット検閲の回避。
(確かめたわけじゃないけど、多分プロバイダのDNSと違って、Google Publis DNSには日本ローカルの検閲がかかってないと思う)
Re: (スコア:0)
その代わりにGoogle検閲に引っかかる
まあ使い分けですよね
Re: (スコア:0)
キャッシュと処理容量がデカイから、ワーストなISP提供DNSよりは早い。
けれどベストなISP提供DNSの足元にも及ばない、という感じ。
ISP提供DNSが応答遅かったり応答が無かったりする場合や、
キャッシュ効いてない時のDNS応答が糞遅いドメインによくアクセスする場合は有用。
平均的な状況ならCDN他でトラブル起きる可能性があるからあえて使う意味は無いね。
あとまぁGoogle Public DNSとかはエニーキャストしてたはずだから、
CDN見たく最寄りのサーバに繋がるので言うほど遠くに繋がるわけでもない。
Re: (スコア:0)
Google Public DNSが持っているキャッシュの大きさと応答速度もバカにできない要素だと思う。
経路での遅延と比べた場合にどっちが早いかって話だと思う。
Re: (スコア:0)
それだけにしては遅すぎね?
Re: (スコア:0)
CDNの解決失敗だった場合、海底ケーブルやら何やらを散々経由した経路で海外につながったりするのでくっそ遅くなります。
国内同士でスピードテストサイトを変えた時の速度差なんてメじゃないくらいに差がでるはずですが…
参考:http://agilecatcloud.com/2009/08/16/%E6%B5%B7%E5%A4%96-internet-%E9%80%9F%E5%BA%A6%E3%83%86%E3%82%B9%E3%83%88/
自宅の回線が早いなら適当に海外のやつを試してみてください。(私の家は回線細いので調べようがない)
まぁそもそも問題のスピードテストはCDN使ってないようなので別の原因だとは思われますが。
Re: (スコア:0)
>単に、ISP最寄りのCDNノードではなく、GooglePublicDNSから近くISPから遠いCDNノードに割り振られただけでしょ
高度な地理的分散機能を持ったCDNをを使ってるサイトへのアクセスが遅くなるならそうだけど、
元記事のスピードテストは国内のレン鯖を使っててCDNじゃないよね。
ということで、「ただの気のせい」が答です。
Re: (スコア:0)
今回使用された二つのスピードテストサイトでなんらかのCDNが使用されていることはどのようにして見つけ出したのですか?
Re: (スコア:0)
なぜこれが素晴らしい?
publicDNSは以前から使用していて、その際は問題が出ていなかった。
CDNノードの割り振られ方の問題とするにはちょっと状況的に合わんだろ。
あげくに「設定するたびに速度が復活することがある」なんてブログに書かれているので、
こいつが使っている機器に問題ありってみるほうが自然じゃないか。
Re: (スコア:0)
本件に対しては見当違いな回答だけど、
「publicDNSによって速度低下する」という事例全般に対しては真っ当な考察。
publicDNSもCDNに対応はしてるけど、個別だし素の状態よりは落ちる。