パスワードを忘れた? アカウント作成
7305270 story
ネットワーク

富士通、UDP ベースの高速伝送システムを開発 36

ストーリー by reo
ヒャッハー転送 部門より

ある Anonymous Coward 曰く、

富士通が UDP ベースで高速にファイルやデータをやり取りする技術を開発した。TCP ではパケットロスやそれによる再送によって遅延や転送性能の大幅な低下が発生するが、この技術では独自の再送方式を利用することで無駄な再送や遅延の発生を抑えるという (富士通のプレスリリースINTERNET Watch の記事より)。

従来の TCP を使った通信をこの技術を使った新プロトコルに自動変換する技術も開発したとのことで、既存のアプリケーションでも高速にデータのやり取りが可能になるそうだ。

開発された技術は以下の三つ。

  1. 品質の悪い通信環境においてスループットと遅延時間を改善する新プロトコル
  2. ネットワーク空き帯域のリアルタイム計測による通信帯域制御技術
  3. 既存の TCP アプリケーションに手を加えずに高速化する技術

2. はエンドホストの対応でどうにかなる問題なのだろうか。通信経路途中の可用帯域をどうやって推定するのかはプレスリリースだけではよくわからない。輻輳検知を使うのでは、という話を見かけた。なるほど。でもそれは空き帯域の計測と言えるのだろうか…。3. はプロキシみたいなイメージだろうか。識者の皆様からのツッコミ待ち。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 通信がある程度疎なTCP/IPの中に混じり込んだ時は速いかも知れませんが、全部がこのUDPベースのプロトコルで通信を始めてもパフォーマンスを維持できるんでしょうか。
    ちゃんと、トラフィックを分け合うことができるんでしょうか。

    昔VoIPの電話機を開発してた身としては、皆がある程度疎になるように通信してるから、今程度のパフォーマンスを維持できているように思えるので、隙間をぶんどる行為には多少の危険を感じます。
    実際、トラフィックを目いっぱい使おうとするソフトはあちこちでプロバイダによるトラフィック制限を食らったりしていることもありますから。

    • ゲーム理論を用いた解析結果(*1)では、「TCP(亜種を含む)で帯域を取り合った人が勝ち」というルールを設定して、皆で通信(ゲーム)を始めると、(高いトラフィックをかけすぎるとパケット棄却率があがって自分の帯域が確保できなくなるので)自分のトラフィックを適度に抑えつつ、現在のインターネット標準の負荷ではなく)ある程度高い負荷をかけるという結果に収束するということがわかっています。

      さて、この状態下におけるネットワークの状態ですが、ルータのキューが常にいっぱいの状態であるので、帯域は最大限確保されますが、パケットの遅延が非常に大きくなるそうです。

      すなわち、専用回線で他にトラフィックがない場合で、VoIPなどもない場合は、UDPでがんがん負荷をかけていただいて構わないわけですが、VoIPやらsshやらが流れている環境では正直厳しいでしょう。

      で、一本まるまる専用線を(大容量データ転送だけに)占有できる環境は非常に稀でしょうから、そういう点を考慮して、どういうシステムが良いか、ということを考えると、ファイルサーバなら、DFSやらandrew fsやらの分散型ファイルシステムでレプリケーションを行う方式で、世界全国にサーバを持たせる形、そうでなければ、QoSで専用帯域を確保して通信を行うということが必要になります。

      (*1)Tcp connection game: A study on the selfish behavior of tcp users [psu.edu]

      親コメント
    • by Anonymous Coward

      せめてリンク先のプレスリリースくらい読んでから書き込んだら?

      • 読んだうえで、TCPの隙間を使うのが危なくないかと危惧してます。
        あなたはあのプレスリリースを読んで、
        この技術は
        「既存のTCPのトラフィックは邪魔しないかもしれないが、自分たち同士のトラフィックはぶつかり合わないのか?」
        「TCPのトラフィックが疎でなくなった場合に、果たして本当に既存のTCPを邪魔しないと言い切れるのか?」
        という疑問を持ちませんか?

        親コメント
        • プレスリリースに

          今後

          富士通研究所では、本技術を2013年度中に既存のTCPアプリケーションを変更することなく通信を高速化する通信ミドルウェアとして実用化することを目指します。

          とありますから、実装と検証の過程でご指摘の問題が顕在化するかもしれませんね。

          親コメント
        • by Anonymous Coward

          良くも悪くも保守的な考え方ですね。

          空いてるリソースがあって、それを積極的に100%有効利用すべきだと考えるか、
          誰かの邪魔になるかも知れないから余らせておくべきだと考えるか。

          トラフィックは回線増やせばどんどん太くしていけるんだから、
          普通は前者取るんじゃないかなあ。

          • リソースは回線増やせばどんどんふとくしていけるんなら、マージンも常に確保できるわけで、普通は後者を取る。

            ##ふつう?ふじつう?『じ』は何だろ。次?辞?自?
            ##痔じゃないな。多分。
        • by Anonymous Coward

          帯域の利用効率を上げるための技術であって,
          帯域を専有するための技術では無いですね.

          先入観に囚われ過ぎかと.

  • by tanig (11026) on 2013年01月30日 11時49分 (#2315713) 日記

    SkeedSilverBullet と比較してどうなの?

    • by nomnom (26419) on 2013年01月30日 11時59分 (#2315722) 日記

      私も連想しました。SkeedSilverBullet と別な部分に着目した技術なんでしょうか?
      Skeed Silver Bullet Protocol の実装例 [srad.jp]

      親コメント
    • by Anonymous Coward

      ファイル転送に特化したものではなく、
      既存のTCPを使用する一般のアプリケーションに対して効果が出るのがセールスポイントでは?

      • by fault (18699) on 2013年01月30日 16時56分 (#2316020)
        ファイル転送に特化したもので良いだけなら、俺だって簡単につくれるぞ
        • Long Fatな回線を前提
        • パケットの到着順序を保証しない
        • ネットワーク上に存在するパケットの数を一定に保つ
        • パケット再送が多過ぎるようなら、上記パケット数を見直す

        どうだ?

        親コメント
        • by Anonymous Coward

          通信は、エラー処理とバッファリングの小細工は、意外と面倒だよ。物理層に近い部分は実装されてるチップを如何に上手く使うか?が重要なので、上位層だけじゃ、場合によっては全然性能が出ない可能性もありますし。

          • by annoymouse coward (11178) on 2013年01月31日 3時03分 (#2316362) 日記

            いや,だから fault さんは
            ファイル転送に特化したもので良いなら
            エラー処理とバッファリングの小細工が不要だから(結構)簡単だよ
            って言ってるんです.物理層のチューニングに注力するだけでいいので.

            親コメント
  • by manmos (29892) on 2013年01月30日 13時06分 (#2315814) 日記

    SCTPだとよくないのだろうか…

  • 速度は20倍⇒30倍になってるみたいだけど。

    BI.DAN-GUN
    http://jp.fujitsu.com/journal/strength/technologies/200906-02.html [fujitsu.com]

  • by Anonymous Coward on 2013年01月30日 11時30分 (#2315698)

    TCPを追い出してUDPで通信すれば早くなった気がするかもしれない技術って出てるけど、みんなfairnessって考え方が抜けてるんだよね。
    これがどうかは知らないけど。

    • by Anonymous Coward

      今のTCP通信が大量に飛び交ってる中で速度が出せるということは、途中遊んでる部分があるってことなんじゃ?
      そして、すべての通信がこの方式になったとしても、それぞれ他の通信を阻害するような作りにはなってないと
      (なってませんよね?それくらいは考えてますよね?)思うのです。
      Next TCPを考えるのはどんどんやってって欲しいよ。

      # TCPの冗長性は皆が認識しているので、それを何とかしてやりたいと思うのは悪いことじゃないんじゃ?

      • by jsi (25633) on 2013年01月31日 6時38分 (#2316396)

        TCPは車のトラフィックと同じ。TCPでは、

        1. 事故が起こったら速度を下げる(事故が起こらないならどんどん速度をあげる)
        2. 目の前の人の速度が遅くなったら速度を下げる(目の前の人の速度が遅くならないならどんどん速度をあげる)

        のどちらか、または、併用したものを採用する。

        インターネット標準は、1ですが、条件によって2を標準とするOSもあり。

        1では、道の太さを無視して、事故が起こるまでは速度をどんどんあげていって、事故が起こると、通信速度を下げよう、というような処理を行っています。(これは、TCPの場合は事故が起こった場合のコストが比較的小さいからできる技です。)

        NextTCPを考えるといっても、所詮、狭い道で早い速度を出しすぎると事故が起こるのは明確だし、事故が起こると渋滞が起こって余計に目標到達が遅くなってしまうから、ある程度ゆっくりな速度で走らざるをえないというのは自然の摂理なわけです。速度の上げ方を巧妙に選んだHighSpeed TCPというものもありますが、制御だけでがんばっても限界はあります。

        TCPのエンドは、TCP単体では回線の太さを事前に知ることができないので、適切な速度を選びづらいという特性もあります。元記事のように、事前に回線速度がわかっていれば、1, 2 をベースとし、その増加量や再送手順を工夫した高い通信効率を持つ通信を実現することはできますが、それがすべてのインターネット通信に応用できるほどのものとはいえないでしょうね。

        親コメント
  • 天下の不治通^h^h^hもとい富士通が作った独自規格・・・誰が使うの?

    #まずは自分とこでバグが出なくなるまで検証してみて欲しい
    • by Anonymous Coward

      富士通が今後自社ブランドで出す拠点間WAN高速化装置やリモートバックアップソフトウェアに組み込まれるんじゃないの。

      顧客としては装置両端での見かけの帯域と遅延が改善されれば、
      装置間での通信プロトコルがオープンかプロプライエタリかにはこだわらんよ。

  • するとリクエストが5倍増えたりする。

  • by Anonymous Coward on 2013年01月30日 12時16分 (#2315736)

    こんなの昔からあって..Nomadic nodeとかとかとかとか
    Web高速化でもFASTTCPとかとかとか....

    • by Anonymous Coward

      ソース読むと違いが書いてあるよ。

      • by Anonymous Coward

        違う車輪だと言い張らなきゃならないからね。主に特許庁に。
        まあ富士通一社じゃいくら景気いい数字上げても誰も使わないで終わるだろうけどね。MP4みたいに業界上げてゴリ押ししないと。

  • by Anonymous Coward on 2013年01月30日 21時28分 (#2316186)

    パケットの到着間隔を測定するということだろうけど、ジャンボフレームを使ったとしても、ソフトウェアOnlyでちゃんと計測できるのか。
    NICでつぶされないだろうか。

    あと、スイッチがボトルネックになったときは、バッファが小さくてぼろぼろ落ちることになるが、そのあたりの対策とか入っているのか、わからんな。

typodupeerror

アレゲは一日にしてならず -- アレゲ見習い

読み込み中...