PR
図5 TCPのウインドウ制御がスループットに関係する理由<BR>ウインドウ制御は受信側からの確認応答を待たずに送信側のコンピュータが一定量のデータを送り出してしまう方式。ウインドウ制御を行わないと,送信の待ち時間が長くなるので,効率が悪くなる。
図5 TCPのウインドウ制御がスループットに関係する理由<BR>ウインドウ制御は受信側からの確認応答を待たずに送信側のコンピュータが一定量のデータを送り出してしまう方式。ウインドウ制御を行わないと,送信の待ち時間が長くなるので,効率が悪くなる。
[画像のクリックで拡大表示]
図6 測定ツールの受信バッファを大きく取ると,スループットも上がる&lt;BR&gt;バッファ・サイズが64Kバイトまでは,バッファが大きいほどスループットは向上する。ただし,64Kバイト以上に設定してもあまり変化はない。
図6 測定ツールの受信バッファを大きく取ると,スループットも上がる<BR>バッファ・サイズが64Kバイトまでは,バッファが大きいほどスループットは向上する。ただし,64Kバイト以上に設定してもあまり変化はない。
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]

確認応答を待たずに送り出す

 バッファ・サイズというのはNetperfの測定パラメータの一つ。受け取ったデータを一時的に保存するバッファ・メモリーの設定値である。デフォルトは8K(8192)バイトだが,オプションの設定で自由に変更できる。先ほどのデスクの指摘は,デフォルトの8Kバイトという数値がギガビット・イーサネットの通信には小さすぎるのではないだろうか,という意味だ。

 バッファ・サイズがスループットに影響する可能性があるのは,TCPのしくみと関係がある。

 TCPは,送り出したパケットごとに相手から確認応答を受け取って,通信の信頼性を確保する。ただ,このしくみはスループットを落としてしまう。送信側に無駄な待ち時間が生じてしまうからだ。

 確認応答パケットが送信元に届くには,パケットが相手に届き,相手のパソコンの中で処理されて確認応答が戻ってくるまでの1往復分の時間がかかる。その間,送信側は何もできない(図5[拡大表示])。これでは,伝送速度をどんなに高速にしてもスループットは上がらない。

 そこで,実際のTCPでは,あらかじめ決めた一定量のデータまでは確認応答を待たずに送る(図5の下)。こうすれば送信側は待ち時間なくデータを送り続けられる。

 確認応答を待たずに送れるデータ量をウインドウ・サイズと呼ぶ。通信回線が高速なほどウインドウ・サイズを大きく設定するが,大きければ大きいほどよいというわけではない。大き過ぎる値を設定すると,受信側で受け取り切れなくなるからだ。パケットが失われると,再送処理が発生するので,スループットはむしろ悪化する。

 そこでTCPではいくつかの要素から最適なウインドウ・サイズを算出し,調整しながら通信する。これがTCPのウインドウ制御だ。

 このとき,受信側のバッファ・メモリーの大きさはウインドウ・サイズを決める重要なパラメータの一つになる。バッファ・サイズを大きめに設定すると,TCPはウインドウ・サイズを大きく取れる。ギガビットの通信に合わせたウインドウ・サイズが使われることで,もっと高いスループットが出せるかもしれない。

バッファ・サイズを変えてみる

 ということで,Netperfでサーバー側のバッファ・サイズをデフォルトの8Kバイトから,16K,32K,64K,128Kと変化させてスループットがどこまで出るのか測定してみた(図6[拡大表示])。クライアント側パソコンにはPentium4マシンを使った。ギガビット・アダプタには,USB2.0用,コレガ製とインテル製の32ビットPCIカード*,さらにCSAで接続されているパソコン内蔵のギガビット・イーサネット・ポートの合計4種類を使った。

 結果は予想通りで,バッファ・サイズが大きいほど,スループットは向上した。特にその効果が顕著だったのは,CSA接続とインテル製(チップもインテル製)のPCIカードの二つ。バッファ・サイズが64Kバイトのときに約840Mビット/秒を記録した。

 一方,リアルテック製のチップ*を使ったコレガのPCIカードは,最大480Mビット/秒と,コレガのコメントに近い値を記録した。USB2.0接続のアダプタは,やはりUSBの転送速度がネックになるようで,バッファ・サイズを上げても,190Mビット/秒で頭打ちになった。