（2014/1/10 17:27）
「IEEE 802.11ac」正式規格承認!
11ac規格は5GHz帯の周波数を使っており、最大通信速度は理論値で6.9Gbpsとされている。
しかし、現行の市販品においての最大通信速度は1.3Gbps（1300Mbps）が標準的。
今後、数年をかけて高速化が進んでいくとみられる。
----------------------------------------------------------------------
「802.11acの設計思想にみるTCP/IPの高速転送理論」
TCPは3ウェイ・ハンドシェイク=
wiki3ウェイ・ハンドシェイク?
により応答確認しない限りパケットの続きを送信しない
地球の裏か隣近所のPCか分からないが、届いた？ YES/NO ？を確認しないと
次の転送ができないシステム
応答確認なしに問答無用で送ることが可能なのはUDPであるが UDP通信は一般的に広まっていない。
応答確認には伝送距離(中継するルーター・スイッチング装置数)に比例する
伝送遅延(ping値)が発生する。
伝送遅延はパケット数に比例し パケット数x遅延＝速度低下マイナス成分
1秒は神様以外には技術上のばせない
相対性理論で光速近くに加速すれば可能
パケット数を1にすれば遅延は1回で済む
遅延が0とした場合、純粋な転送量は
なんとか質問部屋
---------------------------------------
100Mの回線でTCPとUDPではどの程度差が出るのか？
同じ100Mの回線で、
TCPによるデータ転送時間と
UDPによるデータ転送時間とでは
UDPのほうが速いのでしょうが、
2倍、3倍になるほどの違いがあるのでしょうか？
スループットと考えると
・遅れるデータ全体のスループットは変わりません。
100Mbpsは、TCPでもUDPでも100Mbpsです。
(実際には98.2Mbps)
---------------------------------------
こいつら全然分かってないｗ 致命的ミス
速度と一言に言っても
総合セッション帯域と1ユーザーセッションスループットがあって
それぞれ遅延、TCP/UDPによって速度も意味も違う。
1セッションスループットを上げるためにはTCPは最適化されてないので
ストリーミング等のセッション速度が必要な場合において
UDP的な応答をする仕様がある＝RTSP通信
ＲＴＳＰの動作概要
ＲＴＰ／ＲＴＣＰでは下位のプロトコルとしてＴＣＰ
（Transmission Control Protocol）ではなく、
ＵＤＰ（User Datagram Protocol）を用いる。ＴＣＰは、エンドツーエンドで確実にパケットを送り届けることを目的とし、
通信エラーが生じるとパケット再送を行うのに対し、
ＵＤＰはエラー処理やフロー制御を行わないプロトコルである。
このようになにやらめんどくさいことをしてるのは
TCPには高速伝送に弱点があるためです(速度以外にも、さらに「恐怖の致命的な弱点」があるわけだが)
話すと長くなるが、サーバーとも関係あるから
IEEE 802.11acで調べてみる。
TCPの遅延はしょうがないとして、遅延オーバーヘッドを改善する手段を考えると
最悪な例
スカスカの、遅延だらけのデータセット
「応答必須のTCP使うと、最悪こうなる」という例。
いい例
遅延は減らせない(空間は縮まらない)
＋応答挿入は必須
となると究極的にはこうするとTCP理論値で最速になる。
「パケットは1つで応答は1つ」
にすると。
TCPのチューニング設定でできる。
---------------------------------------------
[理論値]＝[最速値]ではない。
これは理想であって、現実は困難を伴うわけで
実際はさらに工夫が必要。
失敗例2
理想を追い求めて失敗しまくる例
結局これは遅延ありまくりの中で正常パケットをたまに送信するのと同じ
結果的に遅いし意味ない
1パケットサイズを大きくすると遅延のオーバーヘッドが低くなるが、
パケロスリスクが高まる
敗因はデーターパケット長くしすぎたこと
----------------------------------------
- データパケットは長くすると効率的
- データパケットは欠損がでる
- データパケット欠損がでたら非効率
最適解は「ほどほど」だが、それでは速度上昇があまりないので
802.11acとかは技術的にいろいろしている
つまり欲を言えば
- データパケットは長くしつつ
- データパケットは欠損がでたら訂正しつつ
- データパケットをできるだけたくさん大量に飛ばす
- 帯域幅をできるだけ増やす
IEEE 802.11acは、5GHz帯を用いる無線LAN技術で、
①多地点への同時アクセスや最大8チャネルのマルチチャネル通信を行なう
「MU MIMO」、
②チャネルボンディングによる80MHz/160MHzのチャネル帯域幅、
③1度の変調で8bitを転送する256QAMの採用などにより、
④最大で6.93Gbpsの転送速度に対応。現在市場には、
3x3 MIMOを採用した最大1.3Gbpsに対応する製品が登場している。
これだけでは何言ってるか分からないと思うが、
↑の観点から言えば、何してるかが理解できる。
帯域幅を増やす点については感覚的にも「そうすると速度が増えるだろう」
は分かるはず。
だが、その技術として
＞最大8チャネルのマルチチャネル通信
要するに並列通信だが、なぜ並列化しているのかと？
「1チャンネルの高速通信」でいけない理由＝光ファイバーは1チャンネルで十分速いわけで
「インフルエンザでのクラス閉鎖」
があるが、この考えでいけばわかりやすい
「pingロスした場合のデータパケットは全損する」
＝クラス閉鎖
で、インフルエンザの蔓延は予測できない＝パケロスは分からない。
ため クラス閉鎖＝学校全体閉鎖リスクを避けるために
多チャンネル化を行う
また別の理由からも多チャンネル化は無線通信の高速化にメリット
＜8チャンネルイメージ＞
パケロスが時間・空間分散化するので、秒単位での通信安定性は高まる
＝電波障害等である周波数帯の欠損が激しくても、他では維持できる。
[並列化したところで、パケロスが減るわけではない]が
アナログ的なじゃみじゃみパケロスが時間分散するので＝フーリエ変換？
デジタル処理をかけやすくなる
この分散化は基本理論であり、別の技術への橋渡しとして重要
②チャネルボンディングによる80MHz/160MHzのチャネル帯域幅、
これは「パケットを繋げるとロスが減る」の通り
1チャンネルを40Mhz/80Mhz→80Mhz→160Mhに
↑
「40Mhz→80Mhzだから高速化」というわけではなく、
TCP/IPは3wayハンドシェイク＝応答待ち遅延があるため、【1通信を合同した】
方がセッション応答遅延の割合が減るから高速化する
と考えるとわかりやすい
↑にある図参照
③1度の変調で8bitを転送する256QAMの採用などにより、
256QAMの説明は非常に難しい・・・
限られた周波数帯を多値化して効率的に利用、
「あ、こたつ出るならあれとあれとあれしてきて!」
みたいに1度に多数の指令を出す・受信する方法。
周波数帯は同じで、「ポインティングで絵文字」＝アスキーアート？
作ってそれをデジタル復号化処理してるのかなー
ナスカの地上絵？
こんな感じで落書きした周波数ドットの絵文字を受信して
意味を変換か
まあこうした複合・多チャンネル化・多値化をいろいろするわけだが
TCP/IPはそんなこと知ったこっちゃないので(古代から決まってる仕様だから変化しない)
TCP/IPの書式に戻さないといけない
めんどくさい暗号を書いてるわけで、それを遅延無くストリームにしないとだめ。
そんで、その計算で遅延したら遅延防止の技術の意味がないｗ
これはRAID計算CPUと同じか、
パソコン処理が必要、昔ならスパコンがいる計算だろう
ハードウェアRAIDするカードが今でも数万するように(高いんだわ)
IEEE 802.11acは多数の技術を盛り込んではいるが、
その実現には高性能なCPUと高速メモリ＝遅延しちゃだめだしが必要だろう
だからまだ実効6Gbps出る無線機器が出てないわけです。
(100万かけた実験機なら出てるかもしれんが)
つうか詐欺だな。スパコンクラスの高価な機器間の通信で6Gbs出る規格なだけ。
でも詐欺じゃないのか、無線機器が追いつけばいいだけと。
10Mbps規格も出た当初は10Mbps出る機械なかったが、
wikipedia/10メガビット・イーサネット規格
10MbpsLANなんて今じゃ完全に上に張り付いてるわけで
(機器のパフォーマンスが理論値限界と同格になった)
うーん。
有線ケーブルの場合、復号化とかじゃなくて、対電波障害技術なので
種々のケーブルがいろいろ開発されてるが、それは別の話
IEEE 802.11acは速度を上げるためにいろいろやってる
ガチでIEEE 802.11ac＝6Gbpsを出すには現状100万円単位の高性能マシーンが必要<
よって今は貧弱な速度しかでない、だがいつの日か6Gbps出るでしょう
ということでIEEE 802.11acの話は終わり。
マニアックすぎてレンタルサーバーとあんまり関係なかった。
TOP戻る