富士通、UDP ベースの高速伝送システムを開発 36
ストーリー by reo
ヒャッハー転送 部門より
ヒャッハー転送 部門より
ある Anonymous Coward 曰く、
富士通が UDP ベースで高速にファイルやデータをやり取りする技術を開発した。TCP ではパケットロスやそれによる再送によって遅延や転送性能の大幅な低下が発生するが、この技術では独自の再送方式を利用することで無駄な再送や遅延の発生を抑えるという (富士通のプレスリリース、INTERNET Watch の記事より)。
従来の TCP を使った通信をこの技術を使った新プロトコルに自動変換する技術も開発したとのことで、既存のアプリケーションでも高速にデータのやり取りが可能になるそうだ。
開発された技術は以下の三つ。
- 品質の悪い通信環境においてスループットと遅延時間を改善する新プロトコル
- ネットワーク空き帯域のリアルタイム計測による通信帯域制御技術
- 既存の TCP アプリケーションに手を加えずに高速化する技術
2. はエンドホストの対応でどうにかなる問題なのだろうか。通信経路途中の可用帯域をどうやって推定するのかはプレスリリースだけではよくわからない。輻輳検知を使うのでは、という話を見かけた。なるほど。でもそれは空き帯域の計測と言えるのだろうか…。3. はプロキシみたいなイメージだろうか。識者の皆様からのツッコミ待ち。
隙間の多い中に1匹ならいいのでしょうが (スコア:4, 興味深い)
通信がある程度疎なTCP/IPの中に混じり込んだ時は速いかも知れませんが、全部がこのUDPベースのプロトコルで通信を始めてもパフォーマンスを維持できるんでしょうか。
ちゃんと、トラフィックを分け合うことができるんでしょうか。
昔VoIPの電話機を開発してた身としては、皆がある程度疎になるように通信してるから、今程度のパフォーマンスを維持できているように思えるので、隙間をぶんどる行為には多少の危険を感じます。
実際、トラフィックを目いっぱい使おうとするソフトはあちこちでプロバイダによるトラフィック制限を食らったりしていることもありますから。
Re:隙間の多い中に1匹ならいいのでしょうが (スコア:2)
ゲーム理論を用いた解析結果(*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]
Re: (スコア:0)
せめてリンク先のプレスリリースくらい読んでから書き込んだら?
Re:隙間の多い中に1匹ならいいのでしょうが (スコア:3)
読んだうえで、TCPの隙間を使うのが危なくないかと危惧してます。
あなたはあのプレスリリースを読んで、
この技術は
「既存のTCPのトラフィックは邪魔しないかもしれないが、自分たち同士のトラフィックはぶつかり合わないのか?」
「TCPのトラフィックが疎でなくなった場合に、果たして本当に既存のTCPを邪魔しないと言い切れるのか?」
という疑問を持ちませんか?
Re:隙間の多い中に1匹ならいいのでしょうが (スコア:1)
プレスリリースに
とありますから、実装と検証の過程でご指摘の問題が顕在化するかもしれませんね。
Re: (スコア:0)
良くも悪くも保守的な考え方ですね。
空いてるリソースがあって、それを積極的に100%有効利用すべきだと考えるか、
誰かの邪魔になるかも知れないから余らせておくべきだと考えるか。
トラフィックは回線増やせばどんどん太くしていけるんだから、
普通は前者取るんじゃないかなあ。
良い所取りを考える (スコア:0)
##ふつう?ふじつう?『じ』は何だろ。次?辞?自?
##痔じゃないな。多分。
Re: (スコア:0)
帯域の利用効率を上げるための技術であって,
帯域を専有するための技術では無いですね.
先入観に囚われ過ぎかと.
SSB比 (スコア:3)
SkeedSilverBullet と比較してどうなの?
Re:SSB比 (スコア:1)
私も連想しました。SkeedSilverBullet と別な部分に着目した技術なんでしょうか?
Skeed Silver Bullet Protocol の実装例 [srad.jp]
Re: (スコア:0)
ファイル転送に特化したものではなく、
既存のTCPを使用する一般のアプリケーションに対して効果が出るのがセールスポイントでは?
Re:SSB比 (スコア:1)
どうだ?
Re: (スコア:0)
通信は、エラー処理とバッファリングの小細工は、意外と面倒だよ。物理層に近い部分は実装されてるチップを如何に上手く使うか?が重要なので、上位層だけじゃ、場合によっては全然性能が出ない可能性もありますし。
Re:SSB比 (スコア:2)
いや,だから fault さんは
ファイル転送に特化したもので良いなら
エラー処理とバッファリングの小細工が不要だから(結構)簡単だよ
って言ってるんです.物理層のチューニングに注力するだけでいいので.
うーむ (スコア:2)
SCTPだとよくないのだろうか…
Re: (スコア:0)
目的が全然違う。
BI.DAN-GUNってやつがバージョンアップしたのかしら (スコア:2)
速度は20倍⇒30倍になってるみたいだけど。
BI.DAN-GUN
http://jp.fujitsu.com/journal/strength/technologies/200906-02.html [fujitsu.com]
昔からこういう (スコア:1)
TCPを追い出してUDPで通信すれば早くなった気がするかもしれない技術って出てるけど、みんなfairnessって考え方が抜けてるんだよね。
これがどうかは知らないけど。
Re: (スコア:0)
今のTCP通信が大量に飛び交ってる中で速度が出せるということは、途中遊んでる部分があるってことなんじゃ?
そして、すべての通信がこの方式になったとしても、それぞれ他の通信を阻害するような作りにはなってないと
(なってませんよね?それくらいは考えてますよね?)思うのです。
Next TCPを考えるのはどんどんやってって欲しいよ。
# TCPの冗長性は皆が認識しているので、それを何とかしてやりたいと思うのは悪いことじゃないんじゃ?
Re:昔からこういう (スコア:1)
TCPは車のトラフィックと同じ。TCPでは、
1. 事故が起こったら速度を下げる(事故が起こらないならどんどん速度をあげる)
2. 目の前の人の速度が遅くなったら速度を下げる(目の前の人の速度が遅くならないならどんどん速度をあげる)
のどちらか、または、併用したものを採用する。
インターネット標準は、1ですが、条件によって2を標準とするOSもあり。
1では、道の太さを無視して、事故が起こるまでは速度をどんどんあげていって、事故が起こると、通信速度を下げよう、というような処理を行っています。(これは、TCPの場合は事故が起こった場合のコストが比較的小さいからできる技です。)
NextTCPを考えるといっても、所詮、狭い道で早い速度を出しすぎると事故が起こるのは明確だし、事故が起こると渋滞が起こって余計に目標到達が遅くなってしまうから、ある程度ゆっくりな速度で走らざるをえないというのは自然の摂理なわけです。速度の上げ方を巧妙に選んだHighSpeed TCPというものもありますが、制御だけでがんばっても限界はあります。
TCPのエンドは、TCP単体では回線の太さを事前に知ることができないので、適切な速度を選びづらいという特性もあります。元記事のように、事前に回線速度がわかっていれば、1, 2 をベースとし、その増加量や再送手順を工夫した高い通信効率を持つ通信を実現することはできますが、それがすべてのインターネット通信に応用できるほどのものとはいえないでしょうね。
Re: (スコア:0)
「みんな」は「技術」にかかってるんじゃないの?
「どの技術もfairnessが抜け落ちてる」ていう意味にとったよ。
で、普及する要素あるの? (スコア:1)
#まずは自分とこでバグが出なくなるまで検証してみて欲しい
Re: (スコア:0)
富士通が今後自社ブランドで出す拠点間WAN高速化装置やリモートバックアップソフトウェアに組み込まれるんじゃないの。
顧客としては装置両端での見かけの帯域と遅延が改善されれば、
装置間での通信プロトコルがオープンかプロプライエタリかにはこだわらんよ。
>モバイル環境におけるウェブブラウジングを5倍高速化 (スコア:0)
するとリクエストが5倍増えたりする。
こんなの昔からあって (スコア:0)
こんなの昔からあって..Nomadic nodeとかとかとかとか
Web高速化でもFASTTCPとかとかとか....
Re: (スコア:0)
ソース読むと違いが書いてあるよ。
Re: (スコア:0)
違う車輪だと言い張らなきゃならないからね。主に特許庁に。
まあ富士通一社じゃいくら景気いい数字上げても誰も使わないで終わるだろうけどね。MP4みたいに業界上げてゴリ押ししないと。
帯域測定とかきちんとできるのかなぁ (スコア:0)
パケットの到着間隔を測定するということだろうけど、ジャンボフレームを使ったとしても、ソフトウェアOnlyでちゃんと計測できるのか。
NICでつぶされないだろうか。
あと、スイッチがボトルネックになったときは、バッファが小さくてぼろぼろ落ちることになるが、そのあたりの対策とか入っているのか、わからんな。