【IT/通信】ソフトウェアだけで通信性能を大幅に改善する新技術を開発…日米間のファイル転送を30倍以上高速化／富士通研究所

株式会社富士通研究所は29日、通信性能をソフトウェアだけで改善できる、新しいデータ転送方式を
開発したと発表した。この技術を適用すると、ファイル転送や仮想デスクトップなどの
多様なアプリケーションにおいて、通信性能を大幅に向上できるという。

通信アプリケーションで標準的に利用されているTCPプロトコルでは、データ損失（パケットロス）が
発生した場合にデータを再送するため、無線接続時や回線が混雑している場合など品質の良くない
通信環境では、データ再送による遅延によって転送性能が大幅に低下する点が課題とされてきた。

こうした課題を解決するためには、従来、ハードウェアベースの高価なネットワーク高速化製品を用いる
アプローチが多く採用されていたが、今回は新たに開発した3つの技術を組み合わせることにより、
ソフトウェアのみで課題の解決に成功したという。

1つ目の技術は、UDPをベースに独自開発した効率的な再送方式を組み込み、パケットロス時のデータ再送の
遅延を低減する新プロトコル。このプロトコルでは、消失したパケットと送信中でまだ相手先に届いていない
パケットを高速に識別し、無駄な再送と遅延の発生を抑止可能にしている。富士通研究所では、
これをUDP上へソフトウェアで組み込み、UDPの持つ高速性能を維持すると同時に、UDPの欠点である
パケットの消失と順序の逆転を回避して、パケット送達の遅延時間を改善した。

これにより、標準的なTCPを利用する場合と比べて、日米間を想定したファイル転送で
30倍以上のスループット向上を実現するほか、パケット送達時間に伴う操作の遅延時間を1/6以下に短縮する。

2つ目は、開発されたUDPベースの新プロトコルを用いた通信と、従来のTCP通信が混在する環境を
最適化する技術。具体的には、ネットワークの空き帯域をリアルタイムに計測し、ほかのTCP通信の
帯域使用率が低い場合はUDPの帯域使用率を増やす一方、TCP通信の帯域使用率が高くなった場合は
UDPの帯域使用率を減らすことで、TCP通信が占める帯域を圧迫することなく、最適な通信帯域を確保する。

3つ目は、既存のTCPアプリケーションを変更することなく、新プロトコルを適用するだけで、
簡単にTCPアプリケーションの高速化を実現する技術。TCP通信を新プロトコルに自動変換する機能により、
ファイル転送、仮想デスクトップ、Webブラウジングなど、さまざまな既存のアプリケーションに
手を加えなくとも、性能を大幅に改善可能になった。

これらの技術を組み合わせることにより、TCPアプリケーションの高速化をソフトウェアのインストールだけで
簡単に実現できるほか、モバイル端末などへも容易に実装可能となる点が大きなメリット。
さらに、前述のように日米間を想定した通信環境で大きな効果が得られていることから、
今後普及が見込まれる国際回線や、無線回線を使ったさまざまな通信アプリケーションについても、
快適な利用が見込まれているとのこと。

富士通研究所が示した例によれば、モバイル環境におけるウェブブラウジングを5倍高速化したり、
国際データセンター間のデータ転送を30倍以上効率化したり、国際回線を利用した仮想デスクトップでの
画面表示の遅延を1/6以下にしたり、といった効果が想定されている。

なお同社では、既存のTCPアプリケーションを変更することなく通信を高速化する通信ミドルウェアとして、
2013年度中に実用化することを目指し、研究を進めている。

ソース：INTERNET Watch（2013/1/29 16:34）
http://internet.watch.impress.co.jp/docs/news/20130129_585519.html
画像：開発した新プロトコルの効果の説明図
http://internet.watch.impress.co.jp/img/iw/docs/585/519/03.jpg
画像：本技術の利用シーン（イメージ）
http://internet.watch.impress.co.jp/img/iw/docs/585/519/04.jpg
関連リンク：富士通のプレスリリース
http://pr.fujitsu.com/jp/news/2013/01/29-1.html

ルー大柴か？

さっぱりわけわからん

開発者にパテントは認められないのが悲しい現実
社畜は哀し

不思議だよね
電気の流れる速度って変わらないのに
転送を何十倍かにすることって
どういう仕組みなんだろうね

30倍以上とは画期的だね
ちょうど懸案になっている1.5Mの専用線があるんだけど
45Mにパワーアップするならもう一年延ばそうかな

エロファイルがどうなるんだ？

>7
光速の速さで保存できる様になるらしい

もともとUDPってTCPと比べても30倍以上速く転送できるプロトコルだったのか

低品質な回線じゃないと効果が大きくないってことか

仮にUDPでパケットロス0の理想環境でも
一般的な構成のTCPで転送する場合の30倍ってのは
おかしくね？

つーかこの説明だけよむとよくても
「UDPを平均50％くらい早くする」
くらいにしか思えない

どんなしょぼい通信回線でも３０倍速くなるってこと？
そうするともう海鮮スピードを上げる努力が無駄ってこと？
電話回線で光通信より早く通信出来るってこと？

とおもったけど、すごい沢山のノードを跨ぐ事前提なんだな
タイトル詐欺だろこれ

TCP■■□■■□■■□■■□■■□■■□■■□■■□ □＝無通信時間(大陸間のTCP受信確認待ち120ms〜)
UDP■■■■■■■■■■■■■■■■■■■■■■■■(受信確認なし)

アメリカ・欧州ではこの□(無通信時間)が長くなるので光速でも遅延・1秒辺りの速度低下が発生する。
>>1これ
?DP■■■■■■■■■■■■■■■■■■■■■■■■

>>12
例えば一般家庭で国内サーバへの接続だと殆ど高速化効果はない。
直接経路のない辺境へ繋ぐ場合ほど高速化効果がある
タンザニアの個人の家庭内サーバに日本から繋ぐとかだと
効果は高そうだ

UDPはヤバいよ、転送先のバッファが溢れようがなにしようが
問答無用で送ってくるからな。

ただしどうしても応答最初の初期遅延が入る

TCP□□□■■□■■□■■□■■□■■□■■□■■□■■□ □＝無通信時間(大陸間のTCP受信確認待ち120ms〜)
UDP□□□■■■■■■■■■■■■■■■■■■■■■■■■(受信確認なし)
?DP□□□■■■■■■■■■■■■■■■■■■■■■■■■ ＞＞このプロトコルができれば大陸間通信でも高速化する

30倍になるって相当特殊な状況だと思うぞ。

パケットロスの多くて長距離の時は現状の再送方式だと
再送の遅延が通信速度に大きく影響するから、こういう結果に
なるときはあるだろうけど。

パケットロスの無いときはぜんぜん効果ないはず。
無線で長距離のときはパケットロス結構あるから
速くなるのかなぁ。

μtorrentの質問はここでいいですか？

>>13
>>15
へーそうなんですか。ありがとうございます。
私の理解を超えるようです。

>>18
ack待ちがあるから、パケットロスのないときでも
効果のあるときはあるか。

ネットゲーでも海外の鯖でラグ無しで遊べるのか？

メモリ沢山食いそうだな
安いからいいか

47氏が前やってたやつの続き？

末端機器への対応は時間かかるだろうが、
とりあえず基幹回線部分だけでもこれに変換したら速くなる？

ネットプログラマなら誰でも一度は考える事でしょうな
構造は単純だし誰でも思いつくけど、品質を上げるほうが先だろって事と、TCPで十分だからいいやって話になっちまう

でもやってみたら劇的にスループットが上がったと。
時には理屈ばかりこねてないで、やってみるもんだねぇ
たとえ「条件によっては10倍」でも驚嘆すべき結果だよ

>>17
受信確認を過去に向けて超高速送れば待ちが無くなる

UDPがロスするような状態にかぎって30倍という事なので、使いどころがなぁ
もちろん無いよりあったほうがいい技術なのはその通りなんだけど…

F5アタックに強くなるのか

品質が悪くなりがちな無線通信との相性がよさそうだね

帯域がスカスカで余裕があるけど
パケットロスするような低品質回線では効果でる。

みんなが使って帯域ギリギリな回線で、これを使うと
効果が全くなくて、混雑をより招くと思う。

海外鯖にあるネトゲだと遅延が酷いのだがpingが改善されまくるって事？

>>22 >>33
ネトゲの遅延改善には望み薄。
ネトゲの通信方式は詳しくないけど、
UDPで改善されるなら、すでにUDP使ってるのじゃないだろうか。

>>34
うむ、そっかありが�d
FPSとかpingの違いで随分不利なので改善されたら嬉しかったんだけどな

通信じゃなくてファイル転送ね、だまされないように。

で、RFC書いたのか?RFCになってなければエンドポイント間の完全性は担保されないんだが。
少なくともInterOP+Shownetで実証実験しないと信用できないね。

>>31
無線に関しては802.x系だとCSMA/CAの制約があるんでなあ。もう少し物理レイヤー側で
信頼性を向上させんことにはどうしようもない。LTEかWiMAX2といった802.xのMAC以下で
コネクション性向を持った無線伝送システムじゃないと使えないと思うよ。

通信品質が高いことが条件でしょ
品質が悪いと逆に遅くなるっていう場合もある

>>38 いや、逆。
通信帯域には余裕があるけど、
品質悪くてパケット落とすような回線向き。

品質は高いけど、回線混んでて帯域いっぱい使ってるときに
やると逆効果。

下の状況の方が多い気がするんだけど。
品質の低い専用回線向け？そんな専用回線いやだなあ。

UDPって相手の事情も考えずにひたすら押し付けるプロトコルだからな。

わかったから、実用化してくれ。
法人向けじゃなくて、コンシューマ向けで。

>>5
逆
今までがアバウトすぎて水道に例えればバシャバシャ水漏れしてた
んで水漏れをしない水道管に変えたらあら不思議って話

オレはネット屋（ルータ・スイッチ）だが・・・
TCPのウィンドウ制御って、ノードがウィンドウサイズ分をドカっと送信するわけだ、ノード自身のNICの速度で。
すると、その先のNWのあるスイッチでストア&フォワードをしようとしたときに、パケットが送信キューから溢れる事がありえるんだ。

何言いたいかというと、TCPが経路上の帯域を検知する方法って「パケロスしたから一度に送るサイズを小さくしてみよう」くらいなもんで、
ドカっと送るやつを（ネット機器の送信キューがあふれないくらいに）チョロチョロと送ってもらうことが出来ればもう少し効率が良くなる。
実際にスイッチの送信キューのモードを変更してキュー長を長くしてバースト転送を吸収できるようにしてみると、1Gの帯域を複数で取り合うようなシーンでもだいぶスピードが出るようになる。

フレームギャップをどうにかしようと研究している人もいる。
http://www.gridmpi.org/publications/ns0601-slide.pdf
※オレの説明よりは4/24、5/24ページあたりが分かりやすい

株の超高速取引なんかでは、ストア&フォワードしていたらストアされる分が時間ロスになるからカット&スルーが流行りらしいけど、アレはどういうプロトコルなんだろうな。

とうとうカットアンドスルーを知らないNEが一線に立つようになったのか。
イエローケーブルにバンパイアタップをねじ止めしていたり、FDDIをリプレースしていた世代
としては隔絶の感がある。

ヘッダ読んだ時点でフレームを該当ポートに送りつけるだけなんだが。

馬鹿ハブが混じっていた時代だと、ぶっ壊れたフレームが伝送されてしまう恐れがあったので、
最短コリジョン時間分受信して、ヘッダが壊れていないことを確認してからフレーム本体を
該当ポートに流すといった工夫をしてあるのが多かった。
こいつの存在がジャンボフレーム普及の障害になってたりする。

しかしだ、CAMが糞安くなってバックプレーンまでワイヤスピードになってるこの時代に
カットアンドスルーなんて採用するってのは正直疑問だなぁ。まあpsで勝負してる人たちだから
そういう機械に大金を注いでも惜しくない、ってのはわからんでもないけどねえ。

「カット&スルーが流行ってるトレード界隈ではどんな上位プロトコルで通信してるのか」
じゃなくて
「カット&スルーとはどんなプロトコルなのか」
なのね
ちょっとビックリした

>>44
取引所のコロケーション借りて株転がす人々がカット&スルーの上にどんなプロトコル実装してるんだろうね、という意味。
カット&スルーでかつ1:Nで（パケット捨てられずに）動く仕組みが必要なわけだし。

※オレがNEになった時にはすでにWAN含めすべてがEthernetだったよ

じゃあ今は本来の性能の３０分の１しか発揮できてないってことなのか。

エロ動画サイトでシークがサクサク出来るようになればうれしい

今すぐやってくれ

海外に接続とか環境が悪い場合に改善するのはそんなものかな、と思うけど、３つ目の
環境が悪くない場合でのソフトインストールでどれほど改善されるんだ？
具体的な値がかかれてないな。

前回のニュースリリースよりわかりやすいわ。

TPCはパケットを一々伝送成功したのか否かの確認、失敗なら再送を繰り返す
手間が本来の通信速度を発揮できない足かせとなる。

だからデータ垂れ流しでエラーに目を瞑れば伝送速度をMAXに発揮するUDPに、
TPCより効率のいいエラー補完技術を組み込めば、結果的に速度が向上した
TPC互換通信が可能になるって寸法か。

つーか、>>1ってこれみたいなもんじゃないの？
http://ja.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

こっちの途中の話が分かりやすいかも。
http://www.4gamer.net/games/105/G010549/20100905002/

単純に確認応答の回数が減れば速くなるだろうね。

4>>それはできません。我がしやの社是ですから。

設計思想というか、打ち出し方がHOS powered by 篠原重工な感じ

wifiに実装してほしい

>>1
>2つ目は、開発されたUDPベースの新プロトコルを用いた通信と、従来のTCP通信が混在する環境を
>最適化する技術。具体的には、ネットワークの空き帯域をリアルタイムに計測し、ほかのTCP通信の
>帯域使用率が低い場合はUDPの帯域使用率を増やす一方、TCP通信の帯域使用率が高くなった場合は
>UDPの帯域使用率を減らすことで、TCP通信が占める帯域を圧迫することなく、最適な通信帯域を確保する。

すまんがここ逆じゃなくて？
TCPが空いていたらUDPを利用せずTCPを利用し、TCPが混んでいたらUDPで通信するのでは？
何かこの2つ目を見る限りは、結局TCPで通信した方が速いけど、余りにパケットロスが多い事例では
UDPを使った新技術の方が速くなる場合もあるってだけの話に聞こえる。

>>57

> TCPが空いていたらUDPを利用せずTCPを利用し、TCPが混んでいたらUDPで通信するのでは？

そこまでの機能はないってことじゃね？
状況に応じて切り替えてたら制御が重くなるでしょ。
UDPによる新プロトコルだけが支配下だから、自分が遠慮するだけという。
UDPが邪魔してデッドロックにはなりませんよ？

３０倍とか１／６とか　理論的にもありえないだろう
何か裏があるはず

>>59
高速道路の渋滞と同じ原理だろ
あれも「理論的には」起こらないはずのもの

TCPが混みエラーが増えると再送が多くなって通信環境が急激に悪化するから、
TCPが混まないようにするのが正解でしょ？

TCPのプロトコルそのものに混雑の根本原因があるならそこは変えられないわな
プロトコルってのは「規約」なんだから勝手に変えるわけにいかない

>>58
なるほど…ってことはこれが理論上最大になるのって何時だ？
TCPが空いてて元々UDPでも問題ない環境なら、TCPとUDPの通信効率の差が最大値。
TCPが混んでたら、新UDPは「パケットロス時のデータ再送の遅延を低減する新プロトコル。」だから
TCPほど速度が落ちないけど、TCPが混んでたらそもそも使用帯域も減らしてしまう・・・

ほどほどにTCPが空いててもパケットロスが適度に頻発する特殊環境下では、TCPとUDPの本来の理想的な
速度差を超えてTCPの30倍以上の速度が理論上出るはずって事なのか？

>>3
難聴のボケ老人に話す時、今までは一言一句事に復唱させてたが、
このプロトコルを導入すると、
じじいが「え？」って言うようになるから、
聞き返されたときだけ言い直す事でコミュニケーションがスムーズになる。

http://www.venturenow.jp/news/2004/12/13/1959_009941.html

一時期話題になった高速同期通信はどうなったの？

ＴＣＰってパケット１個でもロスると
そのパケットから後ろのデータを全部再送する。
パケロス検出してからNACKを投げて
相手からデータが再度送られてくるまでの時間に
スループットが３０倍にもなるほどのデータを受け取れる時間が経過してると・・・

計算したら
通信時間の半分くらい再送してるような状況みたいｗ

>>65
インターネット上でそんなことを実現するには
ルーターにお金を掛ける必要がでてきますｗ

当たり前だけど回線速度は上がらないよ
レイテンシが最悪の状況から30倍マシになるという事
単純に言うと
10Mbpsと言ってもTCPだと一回の通信で数回通信する、単純に10回としよう
UDPだと2回だけ（開始と終了だけ）
これで5倍高速化されたといっている
例えばWindowsのXPまでのファイル共有だとその一回の通信で数十回から数百回の通信をしていたので、
それが新プロトコルを使えば数十分の1の通信回数になる。
それで最大30倍といっているのだろう。
ぶっちゃけUDPが一番効率がいいのには変わりはない。

>>61
「混まないようにしたTCP」がこの新プロトコル

セキュリティを犠牲にしないの？

トレントか

富士通の仙台のかん○あつこさんは会長の愛人をしてると豪語してますが本当ですか
普通のオバタリアンなんですけど

>>70
セキュリティはもっと上のレイヤの役割だろ

>>1の下のほうの絵のDC間データ転送では
1TBの転送が23時間→40分なので、23*60/40 = 34.5倍　なのはいいとして
1TB/23時間 = 約101Kbit/秒
1TB/40分 = 約3.4Mbit/秒

101Kbpsしか出せない回線にも問題があるけど
そういう混雑している回線で3.4Mbps出すのは
あーー、別にルール違反でもないしオッケーかな？

>>9
通信品質が良い環境ならそんなに差はないだろう
ＴＣＰは一旦、パケット喪失が起こると、転送速度落としたりするからね

世界の基幹技術を支えるめちゃめちゃすごい事なのに
工作が酷くてさも大した事ないみたいな流れだな

俺はしがないゲームpgだけど
回線速度の上限がこれで増えるわけじゃないからな。
そもそもudp使うてるストリームとかゲームは関係ないぞ。

tcp通信時の体感のパケロスによる遅延感とか引っかかりは軽減されると思う。
顕著に改善されると推測されるのは、遠くて品質の悪い相手の時だろう。

エロ動画もサクサク見れるようになるの？(´･ω･｀)

そ、そんなおっきいの入らないよ。
へへっ
てのがudp

そ、そんなおっきいの入らないよ。
あっ、そ、そうか・・・ごめん
てのがTCP

>>66
ということは、>1の改善効果が高いのは太いけどレイテンシの大きな回線で、
細いけどレンテンシの小さな回線では効果が低いということになるのかな

大陸間通信とか効果あるってはなしだよね

>>81
伝送効率が【落ちにくい】ことが売りなので、そうなるね

ちゃんと読んだれよ。

http://pr.fujitsu.com/jp/news/2013/01/29-1.html
標準的なTCPと比較した場合、日米間を想定したファイル転送で30倍以上のスループットを実現し、
パケット送達時間に伴う操作の遅延時間を1/6以下に短縮しました。

日米間で遅延が300msecあると、4Gbpsの回線でも、実スループットが90Mbpsに落ちるところを、
本技術では3.3Gbpsになる。　　　というような話が書いてある。

検疫すげー

>>5
ネットワーク通信に使われる「プロトコル」の本質は1と0のデジタル信号だよ
電圧や周波数の変化で1と0をお互いに伝えている
一つ例えるならば、従来なら1000個の1と0で伝えていた情報量を500個で済ませる技術が出来たら通信速度は二倍になる、これは断るがアバウトな例えだけど（データ圧縮の例えと言える）

まあつまり、ある量の情報を送信する時、送受信する1と0の数が少なくて済むほど通信時間は短くなる、
つまり通信速度は上がる

TCPは確認応答や再送制御という、通信の効率上の問題がある、信頼性は高い
UDPは高速だが信頼性は低い

>>1の技術はUDPの高速性を維持しつつTCPの信頼性を実現すると読み取った

>株式会社富士通研究所は29日、通信性能をソフトウェアだけで改善できる、新しいデータ転送方式を
>開発したと発表した。この技術を適用すると、ファイル転送や仮想デスクトップなどの
>多様なアプリケーションにおいて、通信性能を大幅に向上できるという。

これは、酷い

専用線限定で使うならともかく、この書き方だとそうじゃない

他者のTCPと混在する環境でこんなの使ったら、帯域食いつぶして他者のTCPがまともに動作
しなくなるじゃないか

>通信アプリケーションで標準的に利用されているTCPプロトコルでは、データ損失（パケットロス）が
>発生した場合にデータを再送するため、無線接続時や回線が混雑している場合など品質の良くない
>通信環境では、データ再送による遅延によって転送性能が大幅に低下する点が課題とされてきた。

どうみても、他者と混在してるよなー、、、

>>87
同じパケット数でも、
TCPが再送で帯域食いつぶして自滅している場合でも
この技術なら無駄なく送るので速いという話だと思うが。

富士通はあかん

2011 Worldwide IT Services Vendors by Revenue
Rank　　Company　　　　　　Share　　　Revenue(M$)
1　　　　IBM　　　　　　　　　　7.1%　　　　60,039
2　　　　Hewlett-Pacard　　 4.2%　　　　35,799
3　　　　Fujitsu　　　　　　　　　3.0%　　　　 25,420
4　　　　Accenture　　　　　　3.0%　　　　25,385
5　　　　CSC　　　　　　　　　　1.9%　　　　16,209
　　　　Others　　　　　　　　　80.7%　　　681,679
Total　　　　　　　　　　　　　　100%　　　　844,531
http://www.tronshow.org/2013/j/data/3-3.pdf

2010 Worldwide IT Services Vendors by Revenue
IBM　　　　　　 56,424
HP　　　　　　　35,346
Fujitsu　　　　 24,117
Accenture 　　22,212
CSC　　　　　　16,106
Others　　　　638,750
Total Market 792,955
http://www.gartner.com/it/page.jsp?id=1666514

日本は売上高 3 兆3,962 億円と、ほぼ前年並みになりました。タイの洪水に起因する顧客の生産調整などに
よる売上減の影響が、オーディオ・ナビゲーション機器、ＬＳＩなどであったほか、サーバ関連、電子部品も
減収となりましたが、携帯電話や携帯電話基地局を中心としたネットワークプロダクトが増収となりました。
営業利益は 1,778 億円と、前年比 379 億円の減益になりました。ネットワークプロダクトの増収効果はありま
したが、ＬＳＩや電子部品などの減収影響のほか、ネットワークやクラウドサービスで先行開発投資を進めた
ことによります。
海外は売上高 1 兆5,171 億円と、前年比 2.3％の減収ですが、為替影響を除くと 1％の増収です。営業利益
は 80 億円と、ＥＭＥＡを中心に前年比 128 億円の改善となりました。
http://pr.fujitsu.com/jp/ir/finance/2011/pdf/all.pdf

＞海外は売上高 1 兆5,171 億円と、前年比 2.3％の減収ですが、

野村総研、海外売上高比率拡大　15年に５％に
2010/6/30 2:00日本経済新聞 電子版
　野村総合研究所の嶋本正社長は日本経済新聞記者に対し、海外売上高比率を「2015年に５％に引き上げる」方針を明らかにした。
前期の海外比率は１％前後。中国に進出した日本企業向けシステム開発が今後、伸びそうなため。12年３月期の海外売上高は前期実績
の３倍超となる100億円規模に増える見込みだ。
http://www.nikkei.com/article/DGXNASGD2902X_Z20C10A6DT0000/

あ、と思ったときにはすでにファイルが盗まれてるわけね？

あ　計算間違えてたわ　９割以上が再送ね

>>88
そんなプロトコルはすでにあるわけで開発の必要などない

>>93
そんな常識をドヤ顔で言われても。
富士通が値段付けて、買いたい奴が買うんだからどうだっていいだろ

全然読んでもわからないし、わかるまで読むつもりもないけど、
もしかしてこれ、転送速度の速いＵＤＰを使ってるだけじゃねーのか。

>>18
無線で大きなアドバンテージがあるなら，
衛星インターネットの環境が改善されるな．
漁船からネットしたいよ．

>>87
＞他者のTCPと混在する環境でこんなの使ったら、帯域食いつぶして他者のTCPがまともに動作
＞しなくなるじゃないか

30倍速いんだから、仕事（データの送受信）にかかる時間も30分の1だろ。さっさと回線が空くし、
無駄な再送パケットが減るんだから、トータルとしては、助かるのではないか？

でもその「仕事」がただのP2Pで違法ファイルの共有だったら、いつまでたっても処理が終わらなくて回線を食いつぶすだけだろうけど

>>96
漁船といわず、尖閣とか沖ノ鳥島に行って、日本の領土防衛任務（人柱とも）についてくれ。

UDPを利用した新しいプロトコルってところかな？
UDPは本来投げっぱなしだから、送信側にはとにかくデータを送信させ続けて、
受信側でやってこないデータを指定して再送させる
順番についてはバッファを用意しといて適時入れ替えして元のデータに戻す
こんな感じ？

迷惑メールもHD動画で来るようになるんですね
わかります
＞＜

>>99
まぁそんなとこでしょ。データのシーケンス番号だけじゃなく、パケットにも番号がついてるって
いうんだから、再送はまずはパケット単位で、しかも歯抜け可で行い、アッセンブルとかの
手間や時間をかけない、というような方式なんだろうね

３０倍と言わず１．５倍でも欲しがるとこは多いだろう
とにかく低コストなのがすごい

>>99 これっていまさらのネタなんだな。
ターボ符号か低密度パリティ検査符号ってやつの派生技術使ってるんだろ。

http://ja.wikipedia.org/wiki/%E3%82%BF%E3%83%BC%E3%83%9C%E7%AC%A6%E5%8F%B7

データ圧縮はしてないんじゃないの？　それにUDPレベルの通信してるっていってるのに、物理層レベルの符号化の話なんてされても

>>88
>同じパケット数でも、
>TCPが再送で帯域食いつぶして自滅している場合でも

問題はそっちじゃねーよ

自滅するのは勝手だし、無断な再送を抑えたければSACKを使えばいいだけ

>この技術なら無駄なく送るので速いという話だと思うが。

違う

パケットが落ちても速度を緩めないから速いんであって、それが大問題

>>87
>他者のTCPと混在する環境でこんなの使ったら、帯域食いつぶして他者のTCPがまともに動作
>しなくなるじゃないか

って、迷惑極まりない

>>97
>30倍速いんだから、仕事（データの送受信）にかかる時間も30分の1だろ。さっさと回線が空くし、

んなわけ、あるか

>無駄な再送パケットが減るんだから、トータルとしては、助かるのではないか？

SACK

>でもその「仕事」がただのP2Pで違法ファイルの共有だったら、いつまでたっても処理が終わらなくて回線を食いつぶすだけだろうけど

に限らず、速くなったらそれだけデータ量は増える

>>105
>>1の「2つ目」で解決されてるんじゃないの？

>>105
この富士通のがロスベースのAIMD／MIMD系の輻輳制御アルゴリズムならお前の言う通り。
だが世の中にはFair against Renoかつキューを埋めない範囲で性能の出るアルゴリズムもある。
例えばYeAH-TCPは、ロス率の高い伝送路上でも、ロスベースとRTTベースの２つのモードを
切り替えながら、キューを埋めず（他に迷惑をかけず）、パケットを落とさずに高い性能を維持する。
だから必ずしも他のTCPを圧倒する迷惑なプロトコルと決めつけるのは間違い。

余談だけどWindows Vista以降に載ってるCompound TCPはハイブリッドTCPの一種で、
ロスベースAIMDのTCP New RenoとRTTベースのTCP Vegasのcwndを足したアルゴリズム。
控えめな挙動のVegasはアグレッシブにキューを埋めようとするRenoに大負けする。
だからRenoとVegasを組み合わせてもReno＋αになるだけで、Renoを圧倒しない。
そしてVegasがMultiplicative Decrease直後のウィンドウサイズ不足を補ってくれて、
なおかつVegasがBDPの大きい伝送路上でもAdditive Increaseの遅さを補ってくれる。
単純かつ保守的で、CUBIC TCPほど素早い回復性能は望めないけど、良い方法だよね。

>>105の言うような「迷惑な」アルゴリズムのTCPもあって、
具体的にはScalable TCPやH-TCPみたいな奴のこと。
パケロスで輻輳を検出する（アグレッシブにキューを埋める）アルゴリズムのくせに、
相手から「パケロスしてんぞ！自重しる」と言われても
「（・３・）チッうっせーな、反省してまーす」のノリで、
すぐにウィンドウサイズを元通り大きくしてくる。

こういうアルゴリズムは、LANで使うとか、専用線での単一コネクションみたいに、
競合する通信路が無いか、問題にならない場合には最高の伝送効率を得られる。

全て昔からある効率化技術を並べて見せてるだけだけど

何と比較して３０倍以上なのかさっぱりわからん

従来っていうのはもしかして３０年くらい前の技術なんじゃないのか？

ベータテスターにやってやるからはよせい

>>107
うんにゃ

>>108
>だが世の中にはFair against Renoかつキューを埋めない範囲で性能の出るアルゴリズムもある。

キューが埋まってるかどうかの推測が、無理だってば

AQMやってるボトルネックでのキュー長の変動は少ないから、キューが埋まってるかどうか
正確なところはわからないし

それどころか、キュー長は20パケットとか50パケットのほうがいいって話があって、IXなんか
でいいかげんなスイッチが使われてるとそのパターンになるので、計測できるような変動は
出ない

>>113
基本的にRTTベースはBDPの小さい経路ではちゃんとした性能が出にくいから
そういう経路であえてRTTベースアルゴリズムを使う意味はあまりない。
そしてBDPの大きい経路ではボトルネックルーターのキューも充分に長いから、
意味のあるRTT変動値が取れる。単に使い所の問題。

ソースネクストのソフトみたいなもんかね？

>>111
せめて
http://pr.fujitsu.com/jp/news/2013/01/29-1.html
ぐらい読もうよ

>>116
> TCP通信を1.の新プロトコルに自動的に変換する機能を開発しました。
> これにより、ファイル転送、仮想デスクトップ、ブラウジングなどの
> 様々な既存のアプリケーションに手を加えることなく、性能を大幅に
> 改善することが可能となります。

>既存のTCPアプリケーションを変更することなく通信を高速化する通信ミドルウェア

SocksCapかGWでのプロトコルトランスレーターみたいなもんか。
当該のミドルウェアを両エンドポイントで使う必要がある点は一緒だな。
既存の高速TCP実装とどの程度の性能差があるかは知らんけど、
スタックの入れ替えが出来ないWindowsで動けば重宝しそうだね。

おいおい、今までそんなに大量のパケットロスが生じてたのかよ・・・！
驚愕なんですが

まともな事をいう>>102や>>108はすぐNG指定とか
ほんと工作がひでえな
フォーマット戦争は昔から苛烈なもんだが
なにもここでやるこたぁない

工作しているのは一人だけだね

【レス抽出】
キーワード：工作

76 名無しのひみつ 2013/01/30(水) 20:14:24.26 ID:7mlPE93N
世界の基幹技術を支えるめちゃめちゃすごい事なのに
工作が酷くてさも大した事ないみたいな流れだな

119 名無しのひみつ 2013/02/01(金) 20:36:23.66 ID:nIk4loVe
まともな事をいう>>102や>>108はすぐNG指定とか
ほんと工作がひでえな
フォーマット戦争は昔から苛烈なもんだが
なにもここでやるこたぁない

でも、100GB落とそうとすれば100GB転送するわけだろ？

>>118
大量にロスしていたんじゃなくて、ちょっとでもロスすると、その後しばらく通信が止まっていた。　ってとこだな。
無駄な待ちが減って効率がよくなった、と

>日米間を想定したファイル転送で
>30倍以上のスループット
これはまずTCPだと帯域の1/30以下でしか
通信できないと成り立たない訳だが、
富士通研究所はバカですか？

>>123
お前みたいな馬鹿こそ黙れよ。
TCPは帯域の1/30以下に落ちるなんて普通に有り得るんだよ。

TCPがUDPと比べて1/30の
スループットだなんて
構築ミスってるだけでは？

TCPはパケットロスを検出した時の対応が大げさ

んなこたー小学生でも知ってる
だがそれで1/30と言われたらそれはおかしい

こういうの普通にアプリ開発のツールとして無かったの？今まで
ラッパーDLLを同一フォルダに置いとくだけで開発者はTCPでプログラミングできて
UDPのスループット＆レイテンシが得られるっていう

んでDLL外せば普通に生TCPでテストできる

>>114
>そしてBDPの大きい経路ではボトルネックルーターのキューも充分に長いから、

それが間違いなんで、話は根本的に破綻してる

>意味のあるRTT変動値が取れる。

あと、たとえ全ての機器のキュー長が十分長いとしても、RTTには、ボトルネックだけじゃなく、
ボトルネックよりは平均速度は速いがキュー長が0ではないキューも寄与するんで、RTTから
ボトルネックのキュー長が0になったどうかの推測は無理

>単に使い所の問題。

キューが一個だけで十分長ければ使える技術ってかwwwww

問題は、実ネットワークには使い所がないことだな

凄いなぁ〜日本の技術

どんどん進化してる　日本人は天才だ

>>130
おまえは関連技術の論文読んでから喋ったほうがいいよ

>>132
どの論文読んでも、

>>130
>キューが一個だけで十分長ければ使える技術ってかwwwww

って結果しか出てねーぞ

キュー長が20パケットで性能が出るって論文があるなら、出してみろ

ここは最速ガラケーを待ちわびるスレですか？

　これは詐欺ビジネスだな

　　さっき計った光の速度

　　　　　回線　０．６Mb/s　　　
　　　　　ダウンロード　８１．２Kb/s

　　ＩＳＤＮかよ？

　　５年も光使ってるのに割引も一切なし。

　　光は最大１００Ｍｂ／ｓ　笑））））））））））



　　　　
　　

トーア使いに恩恵があるかと思ったがUDPじゃ関係ないのか

>>130
> 問題は、実ネットワークには使い所がないことだな

なんで実ネットワークでテスト運用もしたことがないと考えるんだろう。

あれ？これってwinnyの金子が随分前につくってたろ

なんで今さら富士通がどや顔で発表してんの？
パクリ？？

しかも、長距離では早くなるけど近距離ではほとんど意味が無い代物

>>138
「長距離通信だけ」「HTTPをこのプロトコルに変換して」「他の通信を圧迫しないように」
っつー実用化の話でしょ

>>130
RTT系TCPを否定しちゃったばかりに・・・不憫な子

>>137
実ネットワークにも、いろいろあるからねー

TCPの実ネットワーク速度の場合、実ネットワークで試験しないといけないから試験の間他の
トラフィックを止めて貰ったとか、そういう話がおおっぴらにどころか自慢げに喋ってるレベルだ
から、話にならないというか、テスト運用して実用性がないことが確認されたから、普及してねー
んだってば

具体的な論文を出すと内容の欠陥に突っ込まれるから抽象論に逃げてるってことからも、レベ
ルの低さがわかるな

>>141
もうとにかく富士通を批判したいための批判になってきたな。

>>142
富士通なんてどうでもいいから、具体的な論文、まだ？

>>138
俺も違いがわからないｗ

受け取ったパケットの整合性が取れるまで次を送らなかったのを、送るようにしたのかな？
見掛けは早いけど、回線の混雑具合は変わらないような。

エンドにぶち込む技術なんだろうから
yet another TCPって理解でいいのかな?

金子勇氏のクラウドコネクトとかぶってないか？

SSBPもUDPベースか。
どちらが優位かまだ分からないな。
しかし、これを食いに来たのは間違いない。

2つ目と3つ目の機能を大仰に付属させて来た、ということは、
ズバリ、「1つ目の技術」とSSBPの単体比較ではSSBPが勝る。

ＵＤＰで全部おくってもらい、受信失敗したところだけ再送
してもらえばいいだけじゃん。

つまりしつこいNTT東日本ですけどの勧誘は無視して良いってことですか？

大抵この手の性能が２ケタ以上上がる技術っては
どこかにトリックがある。

今まで経験から察するに、どこかで通信を一まとめにする（バッファ）サーバが
あって、ギッチリ詰め込んで、向こう側のサーバでバラすとかじゃない？
だからpingがめちゃ遅とか、ソフトをインストールしたサーバ間でしか使えないとか
弊害があって特殊用途でしか使われないと。

>>149
普通のゴミみたいなＰＣでは
その送達順序の逆転に速度的に耐えられない。

>>151
トリックは簡単。通信関連プロセスのCPU使用量が２桁跳ね上がる。

>>151
そもそも、速度は上がらない

3wayハンドシェイク省略で、ip偽装可能とかじゃないか？

リング型トポロジで解決じゃん

>>151
今回のはあくまでTCPと比べてって話
ベースになったUDPと比べたら速度は落ちてる

なるほど、わからん
coded TCPのやつをUDPでやったのか？

結局、独自プロトコルになるんだからSIPでもよくね？
わざわざUDPレベルで云々ていうのがワカラン。

プロトコルをトリッキーに使って通信性能を上げるって、
法律で言うと条文の解釈を解釈して適法性を判断するって感じ。
プロトコルの修正もむずかしいんだろうね、憲法改正が難しいように。

WAN高速化装置なんて何年も前からあるわけだが

IETFでも、馬鹿にされてる

https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=67486&tid=1363735726
From: [email protected] (Martin Rex)
To: [email protected]
Reply-to: [email protected]
Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director)
X-C5I-RSN: 1/0/933/12129/67486

Bob Braden wrote:
> On 3/4/2013 10:20 AM, Roger Jxrgensen wrote:
> > I'll ask a rather basic question and hope someone will answer in an
> > educational way - Why is congestion control so important? And where
> > does it apply? ... :-)
>
> Ouch. Because without it (as we learned the hard way in the late 1980s) \
> the Internet may collapse and provide essentially no service.

It is PR like this one:

http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html

That gets me worried about folks might try to "fix" the internet
mostly due to the fact that they really haven't understood what
is already there any why.

-Martin

分散コンピューティングをネットワークに適用した感じ？

>>スレタイ
せいぜい「パケットロス時間を30分の1に」だろ。
99.9%で通ってるバケットを99.997%にしただけだと思う。

TCPのUDPに比べての利点として複数ルートでの整合性構築にあり
ABCDのパケットが混雑を嫌ってACルートとBDルートに別れても効率良く転送できる所にある
それをACパケットが到着してBパケットの再送を要求したら回線は混雑するわ、無駄な行為だわで効率は劣る事になる

>>164
全ておかしいとだけ言っておこう

ｗｉｎｙの作者たちの会社でやってるのと同じようなこと？