第5回 イーサネットを高速化するジャンボ・フレーム技術：PCハードウェア強化ラボ（3/3 ページ）
イーサネットのフレームを拡張して、数Kbytesのデータを1回で送信できるようにするジャンボフレーム。その仕組みや注意点について解説。
ジャンボ・フレームではイーサネットのフレームを、悪く言えば勝手に拡大して利用しているが、ほとんどの場合、ジャンボ・フレームをサポートしていないサーバやPC、さらにはインターネット上のサイトなどへも問題なく接続できる。だが少し考えるとこれは不思議でもある。
最初に、ジャンボ・フレームに固有の特別な通信のネゴシエーションはないと言ったが、MTUサイズが異なっている相手とどうやってそのあたりの調整（お互いが通信可能なフレームの最大サイズの調査）をしているのであろうか。
実は、ジャンボ・フレームを使ったからといって、特別な調整／ネゴエーション・シーケンスが行われているわけではない。例えばTCPで通信を開始すると、通常のイーサネットで行われているのと同じように3ウェイ・ハンドシェイクで通信が開始され、その後データの送受信が行われる。このシーケンスを図にすると、次のようになる。
TCP通信開始時における3ウェイ・ハンドシェイク
TCPコネクションのオープン処理では、お互いのMSS値（＝MTU−40）を交換し、小さい方の値が、お互いに送信可能な最大パケット・サイズとなる。通常は1460となることが多いが、ジャンボ・フレームの場合はもっと大きな値になるし、WANやインターネット回線を経由しているともっと小さい値になることが多い（PPPoEやVPNのカプセル化などのため）。これはジャンボ・フレームのための機能ではないが、お互いに送信可能なジャンボ・フレームのサイズを決定するのに利用できる。右の例では、以後このTCPコネクションでは、最大でも3000bytesのパケットしか送信しなくなる（別のコネクションでは、また別のMSS値が使われることになる）。
TCPの通信では（IPv4でもIPv6でも同じ）、最初に3ウェイ・ハンドシェイクと呼ばれるやり取りのシーケンスがあり、ここで通信路のセットアップが行われる（関連記事参照）。最初にSYNパケットを相手に送信するが（開始要求SYNを送信して、その確認ACKを待つ、というやり取りを双方から行う）、このSYNパケットと同時に「MSS（Maximum Segment Size）」の情報が相手に送られている。MSSの詳細は関連記事を参照していただきたいが、簡単に言えば、TCPレベルで送信可能な最大パケット・サイズという意味を持つ。実際のTCPのオープン処理では、MTUから40bytes（IPヘッダの20bytes＋TCPヘッダの20bytes）を引いた値をMSSとしている。つまり、相手から受け取ったMSSの値に40を加えれば、相手のMTUが分かるというわけだ。
TCPのオープン処理では、お互いのMSS値（40を足せばMTU値になる）を交換・比較し、どちらか小さい方を両者で共通の最大送信可能パケット・サイズとしている。通常は図左のように、どちらも1500から40を引いた1460を共通の最大パケット・サイズとしているが、ジャンボ・フレームが有効な場合は（図右）、お互いのMTUサイズが異なることが多いと予想される。だがどちらか小さい方のMSS値（ジャンボ・フレームをサポートしていない場合は1460になる）に合わせられるので、結果として、MTU値が違っていても相手と正しく通信できるというわけである。
この仕組みは、ジャンボ・フレームのために作られたものではないが、ジャンボ・フレーム環境でもうまく動作する。もともとインターネットやLANでは、MTUサイズの異なるさまざまな通信媒体が使われていたため、お互いに通信可能なMSS値を求める機能がTCPなどに組み込まれていた。それがジャンボ・フレーム使用時のネゴシエーションに使うことができたのは幸運だったし、こういう仕組みがあったからこそ、何の追加規格の制定もせずにジャンボ・フレームという技術が開発できたのかもしれない。
ところでこの仕組みは常に有効かというと、そうでないことに気付くだろう。TCPのコネクション開始時のネゴシエーションは、エンド・トゥ・エンドで行われる。つまり2台のジャンボ・フレームをサポートしたコンピュータが複数のハブを経由して接続されていても、常に同じ結果になる。間にジャンボ・フレームをサポートしていないハブがあったとしても、このネゴシエーションは成立するのである。3ウェイ・ハンドシェイクのパケットは60bytes弱と小さく、ジャンボ・フレーム通信は必要ないからだ。
だがこの状態でTCPの実際の通信を開始すると、途中のハブでジャンボ・フレームが破棄されてしまうことになる。こうなると、TCPのコネクションはつながったが、ジャンボ・フレームを使った通信ができないという状態になる（送信したジャンボ・フレームに対するACK応答がまったく返ってこない）。これは問題である。ただし通常の小さいフレームは通信できる。
このような場合の対処方法はTCP/IPの実装依存になるが、例えばWindows OSではMTUサイズを以後は576にして、再送する、というふうに動作している（576は規格で要請されているMTUの最小保証値）。これにより、まったく通信できなくなるという事態は回避できるが、ジャンボ・フレームどころか、通常のイーサネットのフル・サイズのパケットすらも使わないので、通信のパフォーマンスはあまりよくない。だからこのような事態が生じないように、ジャンボ・フレームのセグメントは、同一セグメント内では1つだけになるように運用するべきである。
送信失敗時の再送例
TCPの開始シーケンスでジャンボ・フレームのMTUをネゴシエーションしたが、途中にジャンボ・フレームをサポートしていないハブがあった場合の例。MTUサイズを小さくして再送信している。Windows VistaとWindows Server 2008 R2間での通信例。
（1）TCP通信開始時の3ウェイ・ハンドシェイクのやり取り。「*MYPC*」から「*SVR*」へTCPでデータを送信を開始した。まずクライアントからサーバ側へSynを送信し（フレーム番号2）、その応答とともにサーバ側からもSynを送信（フレーム番号3）、最後にクライアント側から応答を返信して（フレーム番号4）ハンドシェイク終了。合意したMSSサイズは4042。これらのフレームはいずれも60bytes前後しかないので、必ず通信は成功する。
（2）ジャンボ・フレームでの通信に合意したので、まず4Kbytesのパケットを2回送信（フレーム番号5と6）。だが応答がまったく返ってこない。0.3秒後にフレーム番号5を再送信（フレーム番号7）、さらに0.6秒後にもう一度再送信（フレーム番号8）。いずれもこれらのジャンボ・フレームは、途中でパケットがすべて破棄されていた。
（3）さらに1.2秒待っても応答が返ってこなかったので、MTUサイズを規格上の最小値（576）にして送信しなおしている（フレーム・サイズが590のもの）。するとすぐに応答が返ってきている（フレーム・サイズが60のもの）。送信する量を徐々に増やしている（最初は590bytesのフレームが1つ、次は2つ、最後のは4つ、など）。このように、このTCP接続では、以後はずっとこのサイズしか使わないので、あまりパフォーマンスはよくない。
なお、PMTU（Path MTU。通信経路途中の最小のMTU値を調べる方法）発見と呼ばれる検索シーケンスをネットワーク・セグメント内で行い、途中の機器のMTU値を調べるようにさせる方法もあるが、これは通常はルータが行うべき仕事であり、各コンピュータで設定・実行するような機能ではない。そのような必要性がないように、ネットワーク・セグメントを設計するべきである。
■そのほかのプロトコル
ところでTCPではうまくネゴシエーションできたが、UDP通信ではこの方式は期待できない。なぜならUDPでは通信相手との開始シーケンスがなく、いきなりパケットを送信するだけ、という通信形態だからだ。MTUサイズが異なっていると、相手が受け取れないような大きなジャンボ・フレームを送信してしまう可能性がある。この場合も、上位のアプリケーションによっては再送処理を行ってくれるかもしれないが（UDP自体には自動的な再送処理機能はない）、常に期待できるわけではない。このような問題が生じた場合の対応は面倒なので（例えば全コンピュータのMTU値を手動で設定・制限するなど。関連記事参照）、そのようなUDPのアプリケーションは使わない、という方法もある（そもそも再送もせずに、大型のUDPパケットを使うようなアプリケーションはあまりない）。
場合によっては、TCP/IP以外のプロトコルを使うアプリケーションもあるだろうが、その場合も自動的なMTU値のネゴシエーションは期待できないことが多い。
ルータとジャンボ・フレーム
ルータがあるようなネットワーク環境でジャンボ・フレームを使う場合は、ルータもジャンボ・フレーム対応品にする必要がある。ルータを経由してジャンボ・フレームをほかのネットワークへルーティングするには、まずルータまでジャンボ・フレームが届かないといけないからだ。ジャンボ・フレーム非対応のルータだと、ルータあてのジャンボ・フレームは捨てられてしまい、ルーティングすることができない。ルータから先へ送られるフレームは、必要に応じて（送信先ののインターフェイスのMTUに応じて）フラグメント化されて送信される。
なおルータを越えてその先にあるジャンボ・フレーム対応のシステムとTCPの接続を確立しようとすると、場合によっては標準の1500ではなく、ジャンボ・フレームのMTUサイズでネゴシエーションが行われてしまうことがある。これは先ほど述べたのと同じ状況である（ルーティング経路途中の小さいMTUを無視して、ジャンボ・フレームのMTUが使われてしまう）。ルータによっては、ルーティングするときに、TCPの3ウェイ・ハンドシェイクのパケットをチェックして、より小さい、適切なMSSサイズに書き換える機能を持つものもある。ルータを越えてジャンボ・フレームを送信したくない場合は、このようなルータを使うのも手である。
ジャンボ・フレームの効果
ジャンボ・フレームの効果を確かめるために、簡単なテストをしてみた。といっても、今どきのPCは非常に高速であり、ジャンボ・フレームを使わずとも簡単にギガビット・イーサネット程度なら飽和させてしまうほどのトラフィックを処理できる。そこで今回は少し古めのPC（Core 2 Duo E6600を使ったWindows 7システム）に、Core i7のデスクトップPCからパケットを大量に送信して、ネットワークのパフォーマンスを測定してみた。使用したツールはNTttcpという、マイクロソフト製のネットワーク・テスト・ツールである。
このツールを2台のシステム上で実行させ、ジャンボ・フレームのサイズを変更しながら、ネットワークの速度（何Mbit/sのデータを送受信できたか）とそのときのCPU使用率を測定した。サーバ側で「NTttcpr.exe -m 2,0,0」を実行し（2スレッドでデータを受信するモード）、クライアント側からは「NTtcps.exe -m 2,0,<SERVER名>」でTCPパケットを送信している。結果は受信側で計測したネットワークの使用帯域と、そのときのCPU占有率である。
NTttcpツールによる測定結果
2つのTCPコネクションを使ってパケットを一方的に送信し、その速度（スループット）とCPU使用率などを測定するテストを行った。結果はNTttcpの表示値。ギガビット・イーサネットで接続しているので、最大スループットは1000Mbit/sになる（ただしこれはワイヤー・スピード。実際にはTCPやIP、イーサネットのヘッダ／トレイラ、フレーム間ギャップなどがあるので、フレームごとに最大100bytes弱のオーバーヘッドがある。このため、フレーム・サイズ1.5Kbytesの場合では、スループットは最大950Mbit/s程度になる）。フレーム・サイズを大きくするほどスループットは上昇し、CPU使用率は低下しているが、最近のPCではギガビット・イーサネットでも容易に飽和させる程度の処理能力がある。
ジャンボ・フレームのフレーム・サイズが大きくなるほどCPUの使用率は下がっているが、スループットはすでに飽和するほどなので参考程度にしていただきたい。このシステムではあまり差はないが、古いマシンほど、フレーム・サイズによるスループットやCPU占有率に差が出るようである。
ジャンボ・フレームの活用方法
ジャンボ・フレームを使えば、大きなフレームを使って効率よく通信することが可能だが、すでに述べたように、ネットワークの構成方法やアプリケーションなどによっては通信できなくなる可能性もある。しかしこの場合でも、小さいフレームなら送受信できるので、トラブルが発生した場合には少々やっかいかもしれない。特に、勝手に個人で自分のコンピュータのジャンボ・フレーム機能を有効にしたりすると、通信の内容によって症状が違ってくるので、トラブルシューティングが難しくなる。会社などでジャンボ・フレームを利用する場合は、まずは完全に閉じた環境で、常に管理者の目の届くような範囲から始めるとよいだろう。例えばサーバ・ルーム内でサーバのバックアップ用ネットワークを構築するなどの用途が考えられる。なおインターネット側のインターフェイスではジャンボ・フレームを有効にする必要はないし、してはいけない。PPPoEを使うなど、もともとインターネット側のインターフェイスではMTUが1500bytesすらないのが普通である。ジャンボ・フレームの必要性はほとんどない。
また、せっかくコンピュータにジャンボ・フレーム機能が付いているのだから、ぜひ活用したいといった、漠然とした動機で導入するのもよくないだろう。現在の高性能なPCであれば、ジャンボ・フレームを使わなくてもギガビット・イーサネットのほぼ帯域いっぱいまで使用することはそう難しいことではない。だからジャンボ・フレームを導入しても、パフォーマンス向上の余地は実はあまりない。わずかばかりの性能向上を目指すよりは、無用なトラブルを避けるような運用の方が望ましいと思われる。
【更新履歴】
【2011/08/12】画面「送信失敗時の再送例」の解説文が一部間違っていたので、修正しました。
Copyright© Digital Advantage Corp. All Rights Reserved.