パスワードを忘れた？ アカウント作成
Close
6732 story

ラウンド・トリップ・タイム　イズ　マネー 44

ストーリー by Oliver
基礎を見直す 部門より

ninestars曰く、"以前/.Jでも取り上げられた、謎の高速プロトコル Netli の概要の解説がIIJの機関誌「IIJ News」の最新号に掲載されている。
記事の冒頭にあるような、一見して原因不明なパフォーマンス低下を経験した読者も少なくないだろう。TCP の通信では RTT(Round Trip Time) の増加に伴う実効速度の低下が大きく、ノードが物理的/ホップ数的に離れている場合はスループットを稼ぐことが難しい。TCP の特徴ゆえの欠点を解消するために、TCP そのものを見直すという発想は十分にアレゲである。その詳細が Patent Pending による未開示の為か「謎の高速プロトコル」と煽り文句が先行していた技術であるが、具体的な結果を示すことの出来る確かな技術と言えるのではないだろうか。
タレコミのタイトルは、あえて元記事そのままを使わせてもらった。件の解説記事のタイトルとして、また太平洋を跨ぐ ISP の本音が垣間見える良いフレーズだと思う。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

ラウンド・トリップ・タイム　イズ　マネー More

  • たしかにnetli経由のほうが速かった。

    でも疑い深い私は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-eqx-pnap.netli.net (66.151.135.102): icmp_seq=1 ttl=249 time=4.77 ms
    64 bytes from vip2-sjc-eqx-pnap.netli.net (66.151.135.102): icmp_seq=2 ttl=249 time=6.56 ms
    64 bytes from vip2-sjc-eqx-pnap.netli.net (66.151.135.102): icmp_seq=3 ttl=249 time=5.45 ms
    64 bytes from vip2-sjc-eqx-pnap.netli.net (66.151.135.102): icmp_seq=4 ttl=249 time=4.75 ms

    比較対象としてはこれでいいのでしょうかね？
    指揮者の意見求む！　じゃない、識者！
    --
    ---- 末は社長か懲戒免職 なかむらまさよし
    • http://netli.www.iij-netlightning.jp/info/　にある説明を無視していました。私は米国西海岸からお試ししてしまいました。。。 陳謝。
      --
      ---- 末は社長か懲戒免職 なかむらまさよし
      シェア
      親コメント
      • それでも早くなってるのは何でじゃ、と思ったのですが、こちら（大阪）では
        netli.www.iij-netlightning.jp = netli.www.iij-netlightning.jp.ngrs.net = 219.96.127.108
        に見えます。つながるサーバが違ってるみたいですね。
        東海岸と西海岸でもそれだけ効果があるもんなんですね。
        シェア
        親コメント
        • digしたらこんなのが出てきました。大阪と結果が違うのは、http://www.iij.ad.jp/service/system/IIJ-NL.html にある絵の「Netli DNS」ってのが関係しているのかなぁ。

          引用「エンドユーザからお客様のWebサイトへのリクエストがあると、Netli側のDNSは世界各地に設置された最寄りのバーチャルデータセンターへリダイレクトし」←最寄のVDCのアドレスを返すということ？？

          ;; QUESTION SECTION:
          ;netli.www.iij-netlightning.jp.ngrs.net. IN A

          ;; ANSWER SECTION:
          netli.www.iij-netlightning.jp.ngrs.net. 661 IN A 66.151.135.102
          --
          ---- 末は社長か懲戒免職 なかむらまさよし
          シェア
          親コメント
    • このpingの実行結果は、逆の意味で興味深くないですか?
      だって元々pingの結果がこれだけ違うのであれば、
      TCPの速度が違うのは当たり前なのだから。
      ICMPのRTTが同じになるような環境で実験すべきじゃないのか?

      PING direct.www.iij-netlightning.jp (216.98.104.213): 56 data bytes
      64 bytes from 216.98.104.213: icmp_seq=0 ttl=246 time=212.0 ms
      64 bytes from 216.98.104.213: icmp_seq=1 ttl=246 time=212.0 ms
      64 bytes from 216.98.104.213: icmp_seq=2 ttl=246 time=211.7 ms

      PING netli.www.iij-netlightning.jp.ngrs.net (219.96.127.108): 56 data bytes
      64 bytes from 219.96.127.108: icmp_seq=0 ttl=246 time=3.9 ms
      64 bytes from 219.96.127.108: icmp_seq=1 ttl=246 time=4.0 ms
      64 bytes from 219.96.127.108: icmp_seq=2 ttl=246 time=4.0 ms
      シェア
      親コメント

      • RTTが小さいのは当然では？

        具体的に考えて見ると、これは

        1. netli.www を近くに代理で配置して、
        2. そこに（DNS設定の結果）ブラウザからのアクセスを持ってきた時に代理でdirect.wwwにいく
        3. そこはnetliプロトコルを使うのでRTTは同じ（レイテンシは変わらない）ものの転送スピードを高速化（スループットを上げることが）できる
        4. その結果ページロードが完了するまでの速度も上がる
    • netli はRTTを短縮するような技術ではないようなので、ping の値が
      こんなに差が出るわけはありません。
      と指摘する前に間違いにお気づきのようですが、「興味深い」は訂正したほうが
      いいと思いますけどね。＞モデレータな人

      なお、うちからだと direct も netli も同じサーバ、同じ経路に見えて、
      アクセス速度も同じに見えちゃいます。何ででしょう？
      • ＞netli はRTTを短縮するような技術ではないようなので、ping の値が
        ＞こんなに差が出るわけはありません。

        あまり詳しい情報は発表されていないようですが、その判断の根拠はどこでしょうか？
        私はIIJの記事(PDF) [iij.ad.jp]の7ページ図3などを見て、まさにクライアントやサーバにとっての見かけ上のRTTを短縮する技術だと思ったのですが。
        距離を稼ぐためにNetliプロトコルで通信される中継ネットワークの部分では確かにRTTを短縮するような技術ではないようですが、それを通信路に含めたNetliサービス（？）では、RTTは短縮されたように見えるし、pingも速くなるのでは？
        実際私の追実験でも劇的に速くなりました。
        シェア
        親コメント

        • Re:デモサイトを試してみました (スコア:1, 参考になる)

          by Anonymous Coward on 2003年10月23日 1時49分 (#419631)
          >あまり詳しい情報は発表されていないようですが、その判断の根拠はどこでしょうか？

          その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の値が大きい長距離回線での受信確認の回数を減らしてパフォーマンスを
          上げるという仕組みではないでしょうか。
          シェア
          親コメント
          • とりあえず今回のサービス全体をNetliプロトコルと区別してNetliサービスと呼ばせていただきます。Netliサービスは大きく分けてNetliプロトコルとNetli DNSから成るのだと思います。

            ＞これ以上は予想になりますが、そのドキュメントの図３でいうと、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間で出ていれば問題ないでしょうから。もっとも、複数のクライアントの要求にこたえることを考えると、長距離通信に最適化されたプロトコルを使う意味はあるとは思います。でも、この種のサービスに必須というわけではない感じがします。

            もちろんここに書いたことはすべて予想でしかありませんが。
            シェア
            親コメント
            • あなたのいうNetliDNSでの手法は、そのIIJのドキュメントで説明のある
              「サーバの分散配置」にあたります。
              サーバの分散配置については月数百万円の追加費用が必要になると問題付け、
              その解決方法としてNetliプロトコルを紹介しています。

              そのNetli
              • ＞そのNetliプロトコルについての話題なのに、DNSによる分散配置という
                ＞別のサービスを持ってきて議論しても、筋が違うとしか答えられません。

                私はNetli DNSの仕組みはNetliサービスにとって不可欠なものだと思っています。このスレッドは「Re:デモサイトを試してみました 」ですが、この説明 [iij.ad.jp]にもあるとおり、デモサイトはNetli DNSとNetliプロトコルの両方を併用して実現されています。

                IIJの記事にある「サーバの分散配置」は実際に機能するサーバを日本と米国の両方におくということですが、Netli DNSの働きは米国のサーバの代わりに単なる転送サーバとしてのVDCを使えるようにすることですので、このサービスの場合コストは月数十万円ですみます。
                シェア
                親コメント
        • 単に近くのVDCが返事してるだけなのでは？
          IIJの記事のアナロジーに従えば、遠くの顧客が返事してるんじゃなくて近くの空港から返事が来てるだけ。
    • 物理的にパケットが速く飛ぶ技術じゃないからicmpでやるのは無意味だとおもいますけど。

      でもだとしたらタキオン発見?!

  • ネットワーク・プロトコル？ (スコア:0)

    by Anonymous Coward on 2003年10月22日 4時35分 (#418976)
    面白い記事だと思いましたが、NetliプロトコルがTCPをカプセル化する
    プロトコルのように考えられます。
    だとすると、MPLSを使うのと具体的にどう違うのか
    あまりよくわからないのですが、、
    （Netliプロトコルになっている間は、どのルータを通過しているのか
    とかはわからないわけですよね？これは）

    どこかにNetiプロトコルの詳細はないものでしょうか。

    • HTTP or HTTPSでしか使えない、という記述を見ると、Netliのノードにはキャッシュ機能が備わっているのではないかと思ったのでした。ブラウザからのリクエストに対するレスポンスをサーバーから先読みしてキャッシュしておく、みたいな。ただし、ノード間のスループットは普通のTCP/IPより高いよ～、と。

      アメリカ的には特許申請中だと、その技術の詳細は隠しておいたほうがいいのでしょうか？　

      --
      ---- 末は社長か懲戒免職 なかむらまさよし
      シェア
      親コメント

      • Re:ネットワーク・プロトコル？ (スコア:2, 興味深い)

        by Anonymous Coward on 2003年10月22日 7時58分 (#418999)
        HTTPS (with SSL)でも使える、というところが少し引っかかりますね。
        コンテンツをキャッシュするならばSSLで暗号化したままではいけません（解読するための鍵はクライアントだけが持つので）し、だからといって暗号化しない(without SSL)通信をしてしまっては意味がありません。
        さらにいえばHTTPS通信においてはNetliノードをProxyとして指定した場合を除きHTTPSリクエスト内容さえも読み出すことができませんから、そもそもキャッシュするという前提が成り立たなくなるように思います。
        シェア
        親コメント

        • Re:ネットワーク・プロトコル？ (スコア:2, 興味深い)

          by miri (12057) on 2003年10月22日 10時07分 (#419046) 日記
          PDF記事を見ると、キャッシュするというメカニズムは否定されています。
          TCPのACKが1回帰ってくる間にウィンドウサイズ分のデータしか遅れないから、1ウィンドウのデータを送るのにかかる時間をRTTが超えてしまうと通信が停滞してしまうのが問題なので、見かけのRTTを小さくするという手法なのだと思います。
          予想ですが、普通は遠くのサーバーがACKを返さないといけないところを、近くの転送サーバーがACKを返してトランスポート層のスループットを維持するのだと思います。そこから先の再送処理は転送サーバーに任せてしまうのでしょう。転送しているだけなのでSSLでも問題ないはずです。
          この方法だと確かにスループットは向上するでしょうが、アプリケーション層でのレスポンスは恐らく悪化するでしょうから、httpなどの送りっぱなしプロトコルなら問題ないものの、SSHなどのインタラクティブな通信には意味ないでしょう。というふうな意味でhttp/https専用なのではないでしょうか？
          シェア
          親コメント
        • おお、するどい。

          よく見ると、デモにはSSLの例がないなぁ。
          実際のところはどうなんでしょうか。

          でも、キャッシュとは言わないまでもサーバーからの先読みはSSLでも可能ですよね。そのセッションにだけ一時的に使われるキャッシュ、とでもいいましょうか。

          あとは1Mbpsで月額６５万円という価格。http://www.iij.ad.jp/service/system/IIJ-NL.html　より

          これって、貧乏性な自分にはう～んと唸ってしまう価格です。
          １０秒待たせればいいじゃん、みたいな。
          --
          ---- 末は社長か懲戒免職 なかむらまさよし
          シェア
          親コメント
          • RTT対策ならば、偽ackをルーターが出して次のパケットを要求しているんじゃないの？
            ルーター同士で連絡し合いデータ転送、要求者側に近いルーターは本物ackにあるセグメント番号を見て、そのパケットを作成し端末側に送信。
            こんな感じの気がするけど。
            TCPの窓拡張で窓でかくしたり、スロースタートなどの輻輳制御でスタート時のパケット数を絞っているのをやめれば良いだけの気がする。
            何故OSが拡張されたTCP窓を初めっから全開で開かないのかとか、何のために輻輳制御しているのか、存在しているのか、などを考えると、なえる技術の気がする。
            http1.1でキープアライブ使うときには推奨2セッションまでとかの考えあるよね。
            もっと沢山セッション張るとか、一つのセッションでも読み終わる前に次の要求するとかでも、大して困らない。

            ついでに、
            結局は先読み技術だよね。でかいファイル相手に要求し即切りされれば、回線やサーバーに負荷掛けるんじゃないの？
            まぁ、先読みサイズは制御しているだろうけどさ。
            シェア
            親コメント

            • Re:ネットワーク・プロトコル？ (スコア:1, 興味深い)

              by Anonymous Coward on 2003年10月22日 20時03分 (#419413)
              偽ACKというより、アナロジーから類推するに、通常のTCPだとend-endでハンドシェークしているのを、end-routerと中継回線とrouter-endに分割し、それぞれでハンドシェイクさせてるという事でしょうね。
              endからACKが来る事を予測してACKを先行するんじゃなくて、区間ごとにデータの保証を行うと。
              中継のNetli区間は、自組織内、または契約組織間で閉じており帯域の保証などもできるので、スロースタートやWindowサイズなどの輻輳制御はやらない（というか極力影響を減らす）、または、全く別のプロトコルで行うという感じなのでは？
              シェア
              親コメント
          • これだけ払うぐらいならサーバ借りた方が安いような気も・・・

            デモサイトで実際試してみましたが、確かに速くはなってるけど、それ程差も無いし。
            この程度の速度差で顧客が離れるというのは、いくら宣伝としてもちょ

            • シナリオからすると、日本にデータベースをおいてあるシステム（あ、Ｗｅｂ系です）を北米とかヨーロッパからアクセスするときに発生するイライラ感をなんとかしたい、というような企業がお客さんになるんじゃないでしょうか。

              確かに現地にもサーバーを置いて、データベースをリプリケーションさせる技もありますが、システム改造とかソフトウェアの輸出手続とかにかかる手間賃と、月額６万円を天秤にかけることになるのでしょうね。

              ＃自分なら素直に10秒でも20秒でも待ちます
              --
              ---- 末は社長か懲戒免職 なかむらまさよし
              シェア
              親コメント
              • あの～
                月額6万じゃなくて60万なんですが・・・
              • げ、本当だ。ゼロが一個多い。

                結論：１０秒待たせる
                --
                ---- 末は社長か懲戒免職 なかむらまさよし
                シェア
                親コメント

              • Re:ネットワーク・プロトコル？ (スコア:1, 興味深い)

                by Anonymous Coward on 2003年10月23日 11時55分 (#419800)
                ＞結論：１０秒待たせる

                1ヶ月の雇用コストが30万円の社員1000人が一日20回
                余分に5秒待つことによる損失は、月額約100万円。

                また、使っていてストレスになる業務システムは
                そもそも使われなくなって投資全体が無駄になったり、
                業務への取り組み意欲をそぐ等のマイナス作用があり、
                これも無視できないと思います。

                業務に頻繁にWEBを使用する企業、
                WEBで業務を効率化していこうと考えている企業にとっては、
                この月額60万円は有益な投資になると思います。
                シェア
                親コメント
              • >1ヶ月の雇用コストが30万円の社員1000人が一日20回
                >余分に5秒待つことによる損失は、月額約100万円。

                うさんくさいコンサルが良く使う手口ですね。
                1ヶ月の雇用コストが30万円の社員1000人が一日20回余分に5秒あったとしても、
                収入が100万円増えるわけじゃないので、それは損失ではありません。
              • ＞うさんくさいコンサルが良く使う手口ですね。
                ＞1ヶ月の雇用コストが30万円の社員1000人が一日20回余分に5秒あったとしても、
                ＞収入が100万円増えるわけじゃないので、それは損失ではありません。

                「うさんくさい」とはご挨拶ですが、前提が抜けていた点は過ちでした。
                無意識のうちに、自分の会社を前提に考えていていました。

                ・ 出来高払い賃金体系
                ・ フレックスタイム
                ・ 従業員のほとんどに毎月
              • 出来高払いなのに、残業代？
                そもそも、完全出来高払いなら、労働時間は給与に影響しないので、全く効果がないと思いますが。
                （業務時間の短縮によって、光熱費などの経費が多少は削れると思いま
              • あーごめん。
                働いた時間分の給料をくれる体系を出来高払いといっています。
                私の言葉の使い方がおかしいですか。そうですか。そうですね。

                ＞5秒×20回なんて、どうせコーヒー１杯余分に飲む時間でしょうから、給与が下がるわけではないですね。

                WEBアプリ操作中は、コンパイル待ち時間じゃないので机にかじりつきっぱなしです。
                コーヒー休憩を持ち出すと、従業員がコーヒー休憩を取る機会を
                増やしてしまうから5秒の損失どころではないという話もできます(笑)。

                で。まじめに論証する
              • 小ネタに反応:-)

                まず、なぜ日本にあるサーバに米国からアクセスさせるのかを考えましょう。
                理由としては

                • 日本でデータが発生するから
                • 日本に管理者がいるから
                • 日本に使う人の大半がいるから

                などが考えられます。
                最初の「日本でデータが発生するから」というのは日本にサーバを置いておく必然性としては非常に薄いです。
                日本のサーバにデータを転送しようと、米国のサーバにデータを転送しようと、さほどコストも時間も変わりません。

                次の「日本に管理者がいるから」というのも、あなたが前提としているような（そして月に60万も余分に払ってペイす

        • TCPアクセラレータだけだったら SKY-X [mentat.com]もNettgain [flashnetworks.com]もあるけどねぇ。
          あとコンテンツ圧縮もありってのが　AirH” [ddipocket.co.jp]の Fourelle Venturiってのがあるけど。

          っていまここ [atmarkit.co.jp]みたらＤＮＳに仕事をやらすってことだから
          　ポイント先をかえて　あたかもnetliエージェントがサーバーのよ

    • Re:ネットワーク・プロトコル？ (スコア:1, 参考になる)

      by Anonymous Coward on 2003年10月22日 8時48分 (#419010)
      カプセル化する・・・というか TCP の分割という感じでしょうか。

      pdf の記事にありますが、RTT は スループット=window size/RTT の形で効いてきますので、
      大陸間通信などで RTT が大きい場合、RTT = RTT1(user - VDC) + RTT2(VDC-AAP) + RTT3(AAP-server) と分けた方がスループット大きくなるやんという。
      とはいえ RTT2 の部分はやっぱり長くなってしまうので、そこへ RTT に抑制されない TCP 以外のプロトコル持ってくればなおラッキーと。
      シェア
      親コメント
      • > カプセル化する・・・というか TCP の分割という感じでしょうか。

        それに近いのではないかと思えます。
        ただし、完全に透過的に行うと。

        で、キモの、

        > そこへ RTT に抑制されない TCP 以外のプロトコル持ってくればなおラッキーと。

        ですが、強力
    • RTTはともかく、window size を強制的に大きくしちゃえばパフォーマンスは
      上がるのではないかと思いました。

      途中ノードでフラグメントされてしまうかもしれないので、RTTが大きい二点間で
      パケットを再構成しちゃって、まとめて送るようにすれば、受信確認の回数が
      減って速くなると思ったりします。
      ＃っていうか、Netliプロトコルってそうだったりする

  • 発音 (スコア:0)

    by Anonymous Coward on 2003年10月22日 11時47分 (#419102)
    読み方は「ねっとり」でいいんですか？
    　

    • Re:発音 (スコア:1)

      by miri (12057) on 2003年10月22日 20時30分 (#419436) 日記
      もともとNetLightningらしいので「ねっとらい」じゃないかな？
      tryとかけてポジティブなイメージを持ちましょう

      ＃いや、違うかもしれんが
      シェア
      親コメント

    • Re:発音 (スコア:0)

      by Anonymous Coward
      >読み方は「ねっとり」でいいんですか？

      粘着系のようで、あまり早く感じられないのは私だけか？

      • Re:発音 (スコア:0)

        by Anonymous Coward
        > 粘着系のようで、あまり早く感じられないのは私だけか？

        粘着なヒトの「ターゲットに対する反応」はとても早いですよ。

  • T/TCP (スコア:0)

    by Anonymous Coward on 2003年10月22日 22時19分 (#419484)
    T/TCPで中継してるだけだったり。
typodupeerror

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー