GbEで影響度増すTCPのオーバーヘッド

図5●TCP/IPの受信ウインドウ・サイズの概念。 受信ウインドウ・サイズを大きくすることで，受信確認のパケットを待つことなく連続受信できるデータ量を増やす。

　TCP/IPでの実効速度を高める方法としては，データの流し方をチューニングするやり方がある。TCP/IPは，送り出したパケットが送信先に届いたことを確認してから，次のパケットを送る。一つのパケットを送っては応答を待つという方法では，パケットの往復にかかる時間分の遅延が発生し，その間は待ち時間として実効速度が低下する。応答パケットもわずかながら帯域を圧迫する。そこで受信を確認する間隔を長くする。この一度に連続して送れるパケットの総データ量を「ウインドウ・サイズ」と呼ぶ。ウインドウ・サイズを大きくすればするほど，送信と応答の待ち時間が減少し，オーバーヘッドが少なくなる（図5[拡大表示] ）。ウインドウ・サイズは，Windows XPが64520または17520バイト，Windows 2000が17520バイト，Windows 95/98/Meが8760バイトである。

　ただ，ウインドウ・サイズはどこまでも大きくすればよいというものでもない。送られてきたパケットのかたまりのうち一つでも欠けると，受信確認の取れていないパケットすべてを再送することになる。そのため，受信ウインドウ・サイズを大きくすると，かえってオーバーヘッドが増えてしまう可能性がある。

　ウインドウ制御はTCPのレベルで処理される。受信ウインドウ・サイズの値は，TCPのデータ部（MSS：Maximum Segment Size）の整数倍に設定するのが効率的だ。パケットの最大データ長を示すMTU（Maximum Transmission Unit）から40バイト（TCP/IPヘッダの部分）を引いた値がMSSになる。Windows 95/NTでは，受信ウインドウ・サイズの上限は65535バイトである。

　Windows 98/Me/2000/XPでは，受信ウインドウ・サイズに65536バイト以上の値を設定できるように改良が加えられている。64240×22といったように，通常の受信ウインドウ・サイズの乗数（最大で2の14乗）で設定できる。

図6●Windows 2000のTCP/IP通信API「Winsock」のバッファ・サイズとスループットの関係

　実際にウインドウ・サイズを変えてNetperfを実行した結果が図6[拡大表示]である。Netperfの測定用パラメータを変えることで，ウインドウ・サイズを増やした。Netperfは，WindowsのTCP/IPスタックを利用する「Winsock」というAPIを使ってデータをやり取りする。

　WinsockはWindows上のTCP/IPアプリケーションが使う標準APIでデフォルト値は8192バイト（8Kバイト）である。これを倍の16384バイト（16Kバイト）にすると，8192バイト時に630Mビット/秒だった計測結果が，657Mビット/秒となった。さらに32768バイトでは752Mビット/秒，65536バイトでは823Mビット/秒と上昇した。ただし，65536バイト（64K）をピークに，262144バイト以降はデフォルト値と同じ値にまで落ちている。

CPU負荷軽減にはジャンボ・フレーム

　ウインドウ・サイズを大きくして間断なくパケットを処理すると，それだけCPU使用率は高くなる。ウインドウ・サイズを大きくすると，単位時間当たりに処理するパケット数は増えるからだ。測定機のCPU使用率は99％と，ほぼ限界に達している。

図7●イーサネットの送受信単位を1514バイト以上に拡張した「ジャンボ・フレーム」がCPU使用率とスループットに与える影響 単位時間当たりに送受信するフレームの数が少なくなるため，CPUの負荷を軽減できている。

　このような場面で実効速度向上に効果があると見込めるギガビット・イーサネット向けの技術がある。「ジャンボ・フレーム」である。

　ジャンボ・フレームは米Alteon社が（現カナダNortel Networks社）が独自仕様として実装した拡張仕様である。フレームはイーサネットの伝送単位のことだ。イーサネットでは一つのフレームで最大1500バイトのデータを運べるよう規定してある。OSはデバイス・ドライバを通じて1500バイトごとにあて先や送信元を示すヘッダー情報を付け，TCP/IPの処理プログラムに渡す。

　この一つのフレームで運べる最大データ量1500バイトを，ジャンボ・フレームでは4074～16114バイトに拡張できる。カードによってサイズは異なるものの，ほとんどのギガビット・イーサネット・カードが対応している。フレーム当たりのヘッダーの割合も小さくなるので，転送効率が上がるというメリットもある。

　そこでフレームを4088バイト，9014バイトに拡張してTCP/IPの実効速度を測ってみた。結果は，4088バイトでは約78％，9014バイトでは61％にまでCPU使用率を軽減できた（図7[拡大表示]）。CPUの性能に余裕が出たことによって，転送速度も向上した。4088バイト時は975Mビット/秒，988Mビット/秒である。ほぼ限界値に近い。

図8●TCP/IPのウインドウ・サイズを変えたときのWindowsネットワークのファイル転送速度 NEC Express5800/56WgのRAMディスクから，hp ProLiant DL380 G2のNULデバイスにコピーした。スイッチはFXG-08TEで，9014バイトのジャンボ・フレームを利用。ただ上位プロトコルであるファイル共有のプロトコルがオーバーヘッドとなるため，効果は少ない。参考値としてWindows 2000が備える米Novell社のネットワークOS「NetWare」の互換プロトコル「IPX/SPX」で通信した際の値も記した。

Windowsのファイル共有には効果なし

　高性能なハードウェアとTCP/IPのウインドウ・サイズの拡大，ジャンボ・フレームによるチューニングで，NetperfによるTCP/IPのスループットは1Gビット/秒に迫ることができた。そこで最後に，この効果が実使用時にも効いてくるかを，Windowsのファイル共有の読み出しで計測した。

　計測では，Express5800/56WgにRAMディスク領域を作成し，読み込み先は「NUL」を指定した。NULはDOSの時代から存在する仮想デバイスで，コピー先にNULを指定するとデータはハードディスクに書き込まれることなく捨てられる。ハードディスクのボトルネックを取り除いた状態で計測するのが目的だ。ウインドウ・サイズはレジストリを編集して設定した。

　結果はNetperfのスループットとはかけ離れたものにしかならなかった。ウインドウ・サイズをデフォルト値より大きくしても，ネットワークを経由したファイルの読み込みには効いてこない。Windowsのファイル共有では，511Mビット/秒がやっとだった（図8[拡大表示]）。Windows 2000のデフォルト値17520バイトでも，504Mビット/秒で転送できている。ウインドウ・サイズ4380バイト時は217Mビット/秒，8760バイト時は468Mビット/秒とスループットが落ちているため，レジストリによる設定値が反映されていないわけではない。

　Windowsのファイル/プリンタ共有プロトコルSMB（Server Message Block）のオーバーヘッドが高いという可能性もある。ただSMBパケットの最大データ長は64Kバイトと，ウインドウ・サイズやジャンボ・フレームと比べて決して小さな値ではない。念のため，ブロードキャストを多用するNetBIOSを無効にしてWindows 2000から採用されたCIFS（Common Internet File System）経由のファイル共有を試してみても結果は変わらなかった。