「11>10」(無線LAN>10BASE-T)のはずが、どうにも遅い無線LAN。「環境によって異なります」などと思わせぶりなことが書いてあるので、あれこれいじってはみるものの、スループットは一向に改善しない。「俺って才能ないのかも」と思い悩んでいるアナタ。無線LANの世界では、「11<10」がまかり通ってしまうんですよ。
インターフェイスの転送速度には、一般にデータ本体を仕様どおりに滞りなく転送できているときのスピードが使われる。前後の手続きなどを考慮した実効値ではなく、データ転送中のクロックと変調方式(あるいは符号化方式)で決まる、いわば瞬間最大風速のようなもの。どちらかというと、まちがってもこれ以上のスピードが出ることはあり得ないという限界値なのである。
したがって、実質面では確実にそれを下回ることになるのだが、それでも2割引きくらいのところはキープしてくれるもの。4割だの5割だのとなってくると、やはり製品の不良とか、セッティング上の問題を疑ってみたくなる。実際、筆者もはじめて802.11b製品を試用したときには、正直いって「嘘だろ!」と思ってしまった一人だ。
減速の原因をひとことでいえば、プロトコル上のオーバーヘッドということになるのだが、50%オフでは、さすがにひとことでは納得できないものがある。今回は、無線LANがどうしてそんなに遅いのかというところを追求してみよう。
■
ロスを生むCSMA/CAと低ビットレート
「ホームネットワークのインフラ 第5回」で無線LANの基本的な仕組をお話したが、足を引っ張る第1の要因が、その中に登場した「CSMA/CA(Carrier Sense Multiple Access/Collision Avoidance)」というアクセス制御機構にある。CSMA/CAは、有線のイーサネットと同様「回線が空いていたら送信してよろしい」という単純なルールで、基本プロセスは「キャリア確認~送信~受信確認応答」という3つで構成されている。データを送る以外に、「キャリア確認」と「受信応答」という前後の手続きが余分に入るわけだ。
回線が空いていると判定する「キャリア確認」のための時間は、ビットレートに関係なく50μ秒。1Mbpsなら50bit分だが、11Mbpsなら550bit分の時間をここでロスしてしまう(ちなみに10BASE-Tは9.6μ秒、100BASE-TXなら0.96μ秒で送信開始)。
送信時には、データ本体以外に受信側が正しいタイミングで読み取れるようにするための同期信号(プリアンブル)や、通信に必要な各種情報(ヘッダ)を付加しなければいけない。ここでまたロスが出るわけだが、ここからが、有線と無線の差がさらに大きく開くところ。有線のイーサネットの場合、ビットレートは常に一定なのだが、無線は環境に応じていろいろなビットレートを使用する。相互接続を保証するためには、それらの中からどの局でも必ず受信できるレベルで通信を開始しなければいけない。データ本体は、11Mbpsにシフトして高速に転送できても、送信の開始はいつも決まって、ローギアの1Mbpsでスタート。その後、ヘッダに書かれたビットレートに切り換えてデータ部分を受信するというのが、無線LANのお作法なのである。
標準仕様では、全通信モードでプリアンブルに144μ秒、ヘッダに48μ秒(1Mbpsなので単純に144bitと48bit)の計192μ秒を消費する。これをロングプリアンブルといい、製品によっては、ショートプリアンブルと呼ばれるオプションをサポート。こちらが利用できると、プリアンブルが72μ秒に短縮され、ヘッダ部分を2Mbpsにシフトして送信するので(24μ秒)、ロスを96μ秒に押さえることができる。こうしてようやく、額面どおりのフルスピードでデータ本体が送り出せるようになるわけだが、まさに一瞬で終わってしまう瞬間最大風速の世界。送信後には、受信側がACK(ACKnowledge:肯定応答)を返すという、無線LAN特有の大きなタイムロスが待っている。
ACKパケットは、データ部分がわずか14バイトの小さなパケットに過ぎないが、通常のデータパケットと同様に、プリアンブルやヘッダが付加され、無線LANのお作法にしたがって送信しなければならない(ただしACKは送信完了10μ秒後に返すことができる)。以上を合計すると(ACKのデータ部分14バイトは含まず)、ロングプリアンブルで444μ秒、ショートプリアンブルで252μ秒(11Mbps換算で610ないし346バイト相当)の時間が、802.11bの無線LANで1パケットを送るたびに無条件で消費される計算になる。
■
無線LANの実効速度
グラフ1: スピードモードと実効レート |
|
|
以上のことを踏まえ、1000バイトのパケットを送った場合の無線LANの実効速度(5.5/11Mbpsはショートプリアンブル)をプロットしたのがグラフ1である。ビットレートに関係なく常に一定のロスが生ずるため、ビットレートに見合った実効速度が得られないことがわかる。データサイズが小さい場合も同様、ロスの占める割合が大きくなるため、グラフ2のようにガクンと効率が落ちてしまう。注意したいのは、これでもまだムダのないベストケースを示しているのであり、衝突やエラーが起こることなど一切考慮していない(RTS/CTSも含まれない)。これらが起こると、再送という特大のロスが生じ、転送速度にますますブレーキがかかる。
また、実際の使用にあたっては、この物理層の上に何らかのネットワークプロトコルが乗るため、そちらのロスも見逃せなくなる。たとえば、インターネットでおなじみのTCP/IPを使ったとしよう。すると、IPプロトコルやその上位層のTCPプロトコルなどのヘッダが漏れなくオマケに付いてくる。これだけなら、各20バイトずつの計40バイトがデータ部分に加算されるだけだが、問題は、TCPがプロトコルレベルで確認応答を行なう点にある(UDPの場合は送りっぱなし)。無線LANの物理層と同じようにACKパケット(中身はTCP/IPのヘッダだけ)を返すため、一方的にデータを送っている状態でも、常にパケットが往来してしまうわけだ。これが大きなロスを生み、11MbpsのTCP/IP上では物理層からさらに2Mbpsくらい実効速度が低下してしまうのである。
グラフ2: パケットサイズと実効レート |
|
|
では、これが54Mbpsまで行くと、はたしてどうなってしまうのだろうか。特に下位互換を継承する802.11gの場合には、かなり怖い結果になりそうな予感がするのだが、この続きはまた来週。
(2002/02/13)
|