TCPセグメント化で
ヘッダーの再生成処理が発生

 次に,TCPセグメント化の処理内容を説明しよう。


△ 図をクリックすると拡大されます
図7●TCP/IPパケットの構造

△ 図をクリックすると拡大されます
図8●TCPデータのセグメント化
 TCPでは,送信すべきユーザー・データが大きすぎて1つのパケットで伝送できない場合,そのデータを分割して複数のTCPパケットにする。これがTCPセグメント化である。TCPユーザー・データの分割単位は,最大セグメント長(MSS)と呼ばれ,データ・リンクによって異なる。理由は,MSSの大きさがデータ・リンクごとの最大転送単位(MTU)に依存しているからである(図7)。

 TCPセグメント化の例として,イーサネット上で送信すべきTCPユーザー・データが3000バイトの場合を示す(図8)。分割後のパケットのユーザー・データはMSSの値以下でなければならない。

 イーサネットのMTUは1500バイトなので,IPヘッダーとTCPヘッダーの分を除くと,TCPユーザー・データが格納できるのは1パケット当たり最大1460バイトとなる。TCPセグメント化では,TCPユーザー・データの分割と併せて,IPヘッダー,TCPヘッダーの生成処理が発生する。

Windowsはオフロード機能の有無を
問い合わせて利用を判断


△ 図をクリックすると拡大されます
図9●オフロード機能のメカニズム
 オフロード機能を利用する場合は,NICおよびミニポート・ドライバだけでなく,OSのTCP/IPプロトコル・スタックがオフロード機能に対応している必要がある。Windows Serverでは,NICを初期化するときに,NDISからミニポート・ドライバ(NICのデバイス・ドライバ)に対して各オフロード機能の有無を問い合わせる。その結果によって,どのオフロード機能を使用するかを判断する(図9)。

 オフロード機能が有効になっていると,該当する機能を使用する場面でTCP/IPトランスポートでは実際の計算をせずに,疑似値(例えば,チェックサム計算の結果)が生成されるようになり,CPU負荷の軽減が図られる。その後ミニポート・ドライバからNIC上の専用プロセッサに対して,実際の計算を依頼し,疑似値から正しい計算結果に置き換えるように指示される。


△ 図をクリックすると拡大されます
図10●実験環境の構成図
 今回は,TCP/IPチェックサムおよびTCPセグメント化のオフロード機能の効果を測定した。サーバー機のネットワーク・コンポーネントに対して「広帯域幅を使わせる負荷」をかけやすいアプリケーションとして,FTP(ファイル転送プロトコル)サーバーを選択している(図10)。

 検証対象サーバー上のFTPサーバーのコンテンツとしては,128Mバイトのファイルを8個用意した。負荷クライアント上で,仮想FTPクライアントを32個起動して,その8つのファイルにアクセス(GET命令によるファイルのダウンロード)する。各仮想FTPクライアントは,5分間連続でアクセスを繰り返す。

 検証対象サーバーのOSには,Windows Server 2003, Enterprise Editionを使用,2004年11月15日時点の修正プログラムをすべて適用し,最新のドライバ・ソフトを利用している。

 NICは,バス規格がPCI-XとPCIExpressの異なる2種類の製品を用意した。負荷をかけている状態で,それぞれ,オフロード機能を有効もしくは無効に設定したときのネットワーク・パフォーマンスおよびCPU使用率を計測している。

 検証対象サーバーのNICのプロパティのうち,以下をすべて[有効],もしくは[無効]にすることで,機能の有効/ 無効を設定した。これにより,TCP/IPドライバからミニポート・ドライバへの,タスク・オフロード機能をサポートしているか否かの問い合わせに対する応答を変えられる。

・受信TCPチェックサム・オフロード
・送信TCPチェックサム・オフロード
・受信IPチェックサム・オフロード
・送信IPチェックサム・オフロード
・大容量送信オフロード(TCPセグメント化オフロード)

 測定では,負荷クライアントから検証対象サーバーに負荷をかけている状態で,1秒おきに60回,「送信データ量(ビット/秒)」と「CPU使用率(%)」を検証対象サーバー上でサンプリングした。サンプリングで得られた値の平均を,検証結果として利用している。

CPU使用率が半分になる場合もある
データ転送速度の低減はわずか

 実験は次の3ケースで実施した。

(1)TCP/IPチェックサムとTCPセグメント化のオフロード機能を有効
(2)TCP/IPチェックサムのオフロード機能だけ有効
(3)オフロード機能を使わない


△ 図をクリックすると拡大されます
図11●オフロード機能の効果測定結果

△ 図をクリックすると拡大されます
図12●オフロード機能による命令実行数の割合の違い
 実験結果から,NICによって程度の差はあるが,オフロード機能によってCPU使用率が2~5割低減していることが確認できた(図11)。NICによってはオフロードによって,データ転送速度もわずかに低減している。ただし,低減率は4%未満であり,「CPU使用率の低減」というメリットが,「転送速度の低減」というデメリットを十分上回っていると判断できる。また,Windows Server 2003からデフォルトで[enable]になったTCPセグメント化オフロードが効果を発揮していることも検証できた。

 負荷がかかっている状況で,モジュールごと(上位5つとその他で区分)のCPU命令実行数のサンプリング結果から実行割合を計算したグラフを図12に示す。サンプリングは,1ミリ秒単位で60秒間採取した。分析の対象としてNIC2「NC320T」の測定データを使用している。

 この結果から,オフロード機能を有効にするとTCP/IPネットワーク処理に大きく関与している(1)tcpip.sys(TCP/IPドライバ),(2)NDIS.sys(NDISインターフェース・ラッパー),(3)q57xp32.sys(NC320T用のミニポート・ドライバ)のCPU命令実行数,およびその割合が激減していた。これらのことからオフロード機能がCPU負荷の軽減に十分役立っていることがうかがえる。tcpip.sysはTCP/IPの階層モデルのうちトランスポート層とインターネット層,NDIS.sysとq57xp32.sysは同じくネットワーク・インターフェース層に位置付けられる。

次期Windowsでは
オフロード機能が柔軟に選択可能に


△ 図をクリックすると拡大されます
図13●Longhornに実装されるNDIS 6.0
 以上によりオフロード機能がサーバー機のCPU負荷の軽減に役立っていることをその仕組みと検証結果を交えて理解していただけただろう。冒頭にも述べたように,オフロード機能はネットワーク帯域幅の広帯域化に伴い,今後ますます重要な技術として位置付けられていくと考えられる。

 米Microsoftは次期ネットワーク・アーキテクチャである「Chimney」でオフロードの対象を大幅に広げようとしている(図13)。Chimneyは,次期Windows(開発コードLonghorn)のNDIS 6.0に実装される見込みだ。

 Chimneyでは,論理スイッチとミニポート・ドライバの間で直接コネクションを持ち,これによりTCP/IPプロトコル・スタックのデータ転送にかかわる部分をまるごとオフロードすることでCPU負荷のさらなる大幅な軽減が可能だ。

 また,論理スイッチによって,NICが持つオフロード機能に合わせて自動的にオフロード機能使用の有無が選択され,アプリケーションからは透過的になる。OSによるオフロード機能対応への流れは,Linuxでも始まっている。ぜひ利用してほしい。



 

あなたにお薦め

今日のピックアップ

日経クロステック Active注目記事

おすすめのセミナー

セミナー一覧

注目のイベント

おすすめの書籍

書籍一覧

日経BOOKプラスの新着記事

日経クロステック Special

What's New

経営

クラウド

アプリケーション/DB/ミドルウエア

運用管理

サーバー/ストレージ

クライアント/OA機器

ネットワーク/通信サービス

セキュリティ