PING direct.www.iij-netlightning.jp (216.98.104.213) 56(84) bytes of data.
64 bytes from 216.98.104.213: icmp_seq=1 ttl=246 time=85.7 ms
64 bytes from 216.98.104.213: icmp_seq=2 ttl=246 time=84.1 ms
64 bytes from 216.98.104.213: icmp_seq=3 ttl=246 time=83.6 ms
64 bytes from 216.98.104.213: icmp_seq=4 ttl=246 time=83.8 ms
PING netli.www.iij-netlightning.jp.ngrs.net (66.151.135.102) 56(84) bytes of data.
64 bytes from vip2-sjc-eq
デモサイトを試してみました (スコア:0, 興味深い)
でも疑い深い私はpingなどを打ってみました。
PING direct.www.iij-netlightning.jp (216.98.104.213) 56(84) bytes of data.
64 bytes from 216.98.104.213: icmp_seq=1 ttl=246 time=85.7 ms
64 bytes from 216.98.104.213: icmp_seq=2 ttl=246 time=84.1 ms
64 bytes from 216.98.104.213: icmp_seq=3 ttl=246 time=83.6 ms
64 bytes from 216.98.104.213: icmp_seq=4 ttl=246 time=83.8 ms
PING netli.www.iij-netlightning.jp.ngrs.net (66.151.135.102) 56(84) bytes of data.
64 bytes from vip2-sjc-eq
---- 末は社長か懲戒免職 なかむらまさよし
Re:デモサイトを試してみました (スコア:0)
こんなに差が出るわけはありません。
と指摘する前に間違いにお気づきのようですが、「興味深い」は訂正したほうが
いいと思いますけどね。＞モデレータな人
なお、うちからだと direct も netli も同じサーバ、同じ経路に見えて、
アクセス速度も同じに見えちゃいます。何ででしょう？
Re:デモサイトを試してみました (スコア:1)
＞こんなに差が出るわけはありません。
あまり詳しい情報は発表されていないようですが、その判断の根拠はどこでしょうか？
私はIIJの記事(PDF) [iij.ad.jp]の7ページ図3などを見て、まさにクライアントやサーバにとっての見かけ上のRTTを短縮する技術だと思ったのですが。
距離
Re:デモサイトを試してみました (スコア:1, 参考になる)
そのIIJのドキュメントに書いてありますよ。ちゃんと読みましょう。
そのドキュメントを要約してみます。
RTTを短縮するためには帯域を太くしてもダメで、物理的に距離を縮める
必要があり、そのためにサーバを分散するか、あるいはキャッシュサーバを
利用する方法が考えられますが、それらにはいろいろ問題があります。
そこで大きなRTTの影響を低く抑えるために、Netliでは、たとえば４０回の
通信（１パケットの送信、受信確認で１回のことと思われる）を３回にまで
減らすことにより、RTTの影響を抑えると説明されています。
RTTが170msで40回の通信だと、6800ms(6.8sec)かかるところ、3回に抑えて
510ms(0.5sec)で済むという説明です。
これはシェイクハンド方式のTCP通信に対して効果があるということです。
pingは小さなパケットを一回送って応答時間RTTを測るので、TCPにおける
RTTの影響を減らすNetliの技術では改善されないと思われます。
ドキュメントにも、あくまでWebの表示などを例にとって説明していることには
意味があります。
これ以上は予想になりますが、そのドキュメントの図３でいうと、AAPと
いうところでパケットを一度受信し、代理の受信確認を返し、いくつかの
パケットをまとめます。
ある程度まとめたパケットをVDC経由でクライアントに送信することにより、
RTTの値が大きい長距離回線での受信確認の回数を減らしてパフォーマンスを
上げるという仕組みではないでしょうか。
Re:デモサイトを試してみました (スコア:1)
＞これ以上は予想になりますが、そのドキュメントの図３でいうと、AAPと
＞いうところでパケットを一度受信し、代理の受信確認を返し、いくつかの
＞パケットをまとめます。
＞ある程度まとめたパケットをVDC経由でクライアントに送信することにより、
＞RTTの値が大きい長距離回線での受信確認の回数を減らしてパフォーマンスを
＞上げるという仕組みではないでしょうか。
VDC-AAP間のNetliプロトコルについてはあなたの書いてあることに完全に同意します。しかし、それをもってクライアント側からのpingが早くなるはずはないというのは短絡ではないかと言いたいのです。
Netli DNSはクライアントの場所によってサーバの名前解決の結果を変更するというようなものだと思うのですが、これによって、たとえば今回のデモサイトでは日本からは米国のサーバと通信しているつもりで実は日本にあるVDCとTCPレベルの通信をしていることになるはずです。これこそがNetliサービスの要ではないかと思っています。
これによって、米国サーバと直接通信するよりもRTTは小さくなりますし、pingも早くなるはずです。もちろんこれはクライアント-VDC間のことで、Netliプロトコルの使われるVDC-AAP間では当てはまりません。
もともとスループットが出ないのはRTTが大きすぎたせいなのですから、クライアント-VDC間、AAP-サーバ間でこの問題が解決されている以上、VDC-AAP間は必ずしもNetliプロトコルでなくとも、普通のTCPでもいいのではないかと思います。
クライアント-VDC間が（改善されても）もっともスループットが低いと仮定して、それ以上のスループットがVDC-AAP間で出ていれば問題ないでしょうから。もっとも、複数のクライアントの要求にこたえることを考えると、長距離通信に最適化されたプロトコルを使う意味はあるとは思います。でも、この種のサービスに必須というわけではない感じがします。
もちろんここに書いたことはすべて予想でしかありませんが。
Re:デモサイトを試してみました (スコア:0)
「サーバの分散配置」にあたります。
サーバの分散配置については月数百万円の追加費用が必要になると問題付け、
その解決方法としてNetliプロトコルを紹介しています。
そのNetli
Re:デモサイトを試してみました (スコア:1)
＞別のサービスを持ってきて議論しても、筋が違うとしか答えられません。
私はNetli DNSの仕組みはNetliサービスにとって不可欠なものだと思っています。このスレッドは「Re:デモサイトを試してみました 」ですが、この説明 [iij.ad.jp]にもあるとおり、デモサイトはNetli DNSとNetliプロトコルの両方を併用して実現されています。
IIJの記事にある「サーバの分散配置」は実際に機能するサーバを日本と米国の両方におくということですが、Netli DNSの働きは米国のサーバの代わりに単なる転送サーバとしてのVDCを使えるようにすることですので、このサービスの場合コストは月数十万円ですみます。