第5回 イーサネットを高速化するジャンボ・フレーム技術：PCハードウェア強化ラボ（1/3 ページ）

連載目次

ジャンボ・フレームで、ネットワークのパフォーマンスを向上させる

　ルータやネットワーク・インターフェイス・カード（NIC）など、最近のネットワーク機器の仕様を見ると、「ジャンボ・フレームをサポート」したという記述がよく見受けられる。これを使うと、多くのデータを一度に転送でき、パフォーマンスが向上する、例えばファイル・サーバやWebブラウザの速度が向上し、快適に使えるようになる、といったことを連想する。だがその一方で、「ジャンボ・フレームを活用するには、すべての機器がジャンボ・フレームに対応している必要がある」とも書かれているが、これは具体的にはどのような状態を指すのだろうか？ ファイル・サーバにアクセスする場合はなんとなく分かるが、ではインターネットにアクセスする場合はどうなるのか？ 今回は、イーサネットのジャンボ・フレーム技術とは何か、導入に当たって注意するべき点などについてまとめておく。

イーサネットのジャンボ・フレームとは？

　イーサネットでは、データ（ペイロード）を送信するためのデータ構造のことを「フレーム」というが、標準的なフレームの規格を拡張して、より大きなデータを送信できるようにしたものを「ジャンボ・フレーム」（もしくはジャンボ・パケット）という。

・pingでMTUサイズを調査する（Windows TIPS）

　イーサネットの標準規格では、1フレームで送信できるデータのサイズ（MTU：Maximum Transmission Unit、最大送信単位という。関連記事参照）は最小46bytes、最大1500bytesであるが（1byte単位で可変長）、ジャンボ・フレームではこれを最小サイズは46bytesのまま、最大データ・サイズの方をだいたい9Kbytesとかそれ以上のサイズまで拡大している。「だいたい」と表現しているのは、製品によってサポートされている最大サイズに違いがあるからだ。大きいものでは16Kbytesのものもあるが、ほとんどの場合は約9Kbytesのサイズまでサポートしている。だが製品によっては最大4Kbytesしかサポートしていないものもあるなど、特定の決まったサイズがあるわけではない。

　このようにさまざまに異なるサイズがあるのは、「ジャンボ・フレームの仕様には標準規格がない」からである（※1）。ジャンボ・フレームは、もともとはネットワーク機器ベンダであるAlteon Networks社（後にNortel Networksに買収されるが、Nortelもその後破産）が提唱したイーサネットの拡張規格である。送信するデータ部分のサイズを拡張するだけという単純な仕組みのため、システム的な対応は容易であり、それでいてネットワークのパフォーマンスを数十％向上させ、さらにCPUの処理負荷を半減できるなど、メリットは大きいとされている。ただしこれは今から10年ほど前のシステムにおける例であり、CPUやI/Oインターフェイスなどが高速化した現在のシステムでは少し事情は異なる。エントリ・システムですらギガビット・イーサネットの帯域をほぼ使い切ることはそう難しくない。詳細については、「Extended Frame Sizes for Next Generation Ethernets」という論文をインターネットで検索するか、ethernet allianceサイトの「White Papers」にある「Ethernet Jumbo Frames」などの文書を参照していただきたい。

　ジャンボ・フレームで利用可能な最大データ・サイズがベンダごとに異なるのは、主にシステム的な仕様や制限に起因していると思われるが（例えばネットワーク・コントローラ内部にあるバッファや制御回路に起因する制約など）、それを統一するには各ベンダの負担が大きいし、簡便な方法もないためか、結局統一されずに今日まで来ている。イーサネットでは最大1500bytesとなっているが、FDDI（光ファイバ）では4352bytes、TokenRingでは4464bytes、ATM AAL5では9180bytesなど、もともと媒体によってMTUは異なるし、ほかのプロトコルをカプセル化して送信する用途を考えると、今後もMTUの拡大に対する要求は増える一方である。現在検討されているいくつかのネットワーク関連規格では、もっと大きなMTUや、システムごとに異なるMTUが混在しても動作するように検討されており、将来的にはそのような規格の制定によってこの混乱の解決が図られるだろう。だが現在のところは、さまざまなMTUが混在していることを前提にして、ジャンボ・フレームを使うネットワークを設計・導入する必要がある。

　なお9KbytesのMTUをサポートしたジャンボ・フレームのシステムが多いのは、主にUNIX系OSでよく使われているNFS（ネットワーク・ファイル・システム）などを考慮しているからとされている。一般的なNFSの実装では、ファイルは8Kbytesのブロックに区切られてUDPプロトコルを使って転送しているが（現在ではTCPを使う方法も広く普及している）、このUDPパケットを分割することなく一度に送信できるようにするため、8Kbytesのデータといくらかのヘッダ情報などをすべて格納できるように9KbytesのMTUサイズが選ばれた。9Kbytesよりもさらに大きなジャンボ・フレームも理論的には可能であるが、フレーム内に用意されている32bitのチェック・コード（CRCコード）の特性により、11Kbytesを超えるとエラーの検出率が下がるので（データ長にして376bytesから約11Kbytesまでは同じ程度のエラー検出率だが、それを超えると信頼性が下がる）、この9Kbytes程度にしている。

MTUを大きくするメリット

　ジャンボ・フレームでは、MTUサイズ（データを一度に送信できる最大サイズ）が大きくなっているが、それによるメリットとしては次のようなものがある。

• 処理オーバーヘッドの削減
  　大きなファイルやデータを送信する場合、小さいパケットをたくさん送信するよりも、大きなパケットを1つ送信する方がパケットの総数が少なくて済む。パケットを1つ処理するたびに、例えばIPやTCPなどのヘッダを付けたり、外したりする必要があるが、これらは本来のデータ転送とは関係のない無用なものである。パケット数が少なくなるなら、無駄な処理、つまりオーバーヘッドが削減でき、結局は高速化できる。
• フラグメント化（断片化）の減少
  　MTUが大きなネットワーク媒体からMTUの小さなネットワークへパケットを転送しなければならない場合（これはルータの処理）、パケットを分割する処理（フラグメント化）が必要になるが、MTUが大きければ分割の必要性が少なくなる。
• 割り込み処理回数の削減
  　送受信するパケットの数が減少すれば、割り込み処理に必要なCPUサイクルも減少し、CPUの負担が減少する。

　このようなメリットがある一方、パケットが巨大化することにより、例えば送信時の帯域占有時間が長くなるといったデメリットもある。だが実際には100BASE-TXやギガビット・イーサネットなどの普及により、送信時の占有時間は抑制可能である。高速なネットワークほど、大きなMTUを使えば、さらに効率よく送信できるようになる可能性がある。

ジャンボ・フレームの構造

　通常のイーサネット・フレームとジャンボ・フレームの構造を以下に示しておく。イーサネットの動作原理については、以下の記事などを参照していただきたい。

• ギガビット・イーサネットへの移行を準備しよう
• 最適ネットワーク機器選択術
• 連載TCP/IP 第6回「イーサネット――イーサネットの規格とCSMA/CDアクセス制御方式」

イーサネットのフレーム構造
イーサネットで送信するデータには、送信する先と送信元のアドレス情報を付け、さらにデータのタイプ（プロトコルなど）を表す情報を付けてケーブル上へ送り出す。プリアンブルやFCSはイーサネットのコントローラによって自動的に付加される。受信側ではプリアンブルの直後からデータを取り込み始め、最後にFCSのデータが揃ったところで受信を停止する。FCSは上位レイヤへは渡されない。データ部分のサイズが1501bytes以上のものをジャンボ・フレームと呼ぶ。

　それぞれのフィールドの詳しい説明は次の通りである。

　まず一番上の標準のイーサネットのフレームについてみてみよう。

■標準フレームの場合
　先頭にあて先のMACアドレスや送信元MACアドレス、タイプ・フィールドなどが並び、その次から送信するべきデータが最大1500bytes置かれている。このデータ部分の長さをイーサネットのMTUという。送信するデータが何もない場合でもいくらかの埋め合わせ用のデータを置き（どういうデータを埋めるかは関知しない。通常はセキュリティのことを考えて、オール・ゼロ・データなどで埋める）、データ部分の長さは最低でも46bytes分を確保する。データ部に続き、最後に4bytesのエラー・チェック用コード（CRCコード）のフィールドが続く。ヘッダ、データ、FCSの3つを合わせると、最低でも64bytes、最長だと1518bytesとなり、これをイーサネットのフレーム長と呼ぶ。ただし場合によっては最後のFCS部分を除外し、フレーム長を64〜1514bytesと計算することもあるが、実質的には同じことである。

　VLANタグが利用される場合は送信元MACアドレスとタイプ・フィールドの間に置くので、この場合はフレーム長は4bytes分増加して68〜1522bytesとなる。1500bytesを超えるため、非常に古いイーサネット機器では問題になることがあるが、現在市販されている製品では問題ないだろう（VLANは標準規格のため、現在の製品はすべて対応している）。

■ジャンボ・フレームの場合
　ジャンボ・フレームとは、単にデータ部に1500bytesよりも多くのデータを格納したパケットのことである。構造的には標準フレームとの違いはなく、タイプ・フィールドやFCSもまったく同じである。データ部が1500bytes以下なら通常のイーサネット・フレームそのものである。

ジャンボ・フレームで通信するには？

　このように通常のフレームとジャンボ・フレームでは、データ部の長さ以外には違いがないので、通常のイーサネットとほぼ同じシステム、アルゴリズムなどが利用できる。

　とはいえ、イーサネットの最大MTUサイズは1500bytesであることを前提としたシステムやアプリケーション、OSなどが存在するので、どのコンピュータからでも勝手にジャンボ・フレームを送信するわけにはいかない。ジャンボ・フレームに非対応のシステムや機器では、ジャンボ・フレームのパケットを受信しても、それは単なるエラーのあるデータ（1500bytes目に正常なFCSが存在しないフレーム）とみなして破棄してしまうだけだからだ。途中まで（1500bytesまで）受信するのではなく、フレーム全体を破棄してしまう。さらにイーサネットの通信アルゴリズムでは、フレームが不完全／過大なので再送しろと要求することもないし、大きいからといって、イーサネット・レベルで（L2レベルで）誰かが分割して再送信することもない。だからジャンボ・フレームで通信したいコンピュータやネットワーク機器は、あらかじめお互いにジャンボ・フレームで通信するということを同意して準備している必要がある。

　なお、通常のネットワーク・プロトコルではこのような場合、通信開始時にお互いにネゴシエーションなどを行ってジャンボ・フレームで通信できるかどうかを確認するところだろう。そして、相手がジャンボ・フレームを受信可能な場合のみジャンボ・フレームを送信し、そうでなければ通常のフレームを送信する、というふうに動作させるに違いない。だがすでに述べたようにジャンボ・フレームには正式な規格がない。なので、ネゴシエーションの方法も決まってないし、事前にお互いのMTUサイズを調べたり、調査する標準的な方法もない。例えば、ジャンボ・フレームを有効にしたシステムをジャンボ・フレーム非対応のスイッチ／ハブに接続したり、通信経路の途中にジャンボ・フレーム非対応のスイッチ／ハブがあっても何も警告されないし、MTUが1500に再設定されることもない。

　これはとても不便ではあるが、何も決まっていない分、既存のシステムやプロトコルに対する変更は何もいらないというメリットもある。代わりにユーザー（管理者、人間）が、相互にジャンボ・フレームで通信可能な環境を整え、あらかじめセットアップしておくという必要性が生まれたが。