The Cable Guy
TCP 受信ウィンドウ自動チューニング
Joseph Davies
"TechNet Magazine"
の The Cable Guy の初回の記事へようこそ。TechNet Web サイトのコラムのファンである皆さんは、既にご存じのように、私たちはネットワークに関するあらゆる事柄を取り上げてきました。そしてこれからも毎月この伝統を守っていきます。もしあなたが新しい読者で、過去のコラムをお探しなら、
Cable Guy サイトを参照してください。
では、最初のトピック、TCP 受信ウィンドウについて説明します。
TCP 接続を用いたスループットはアプリケーションの送受信、TCP の実装の送受信、および TCP ピア間の伝送パスにより制限される場合があります。このコラムでは、TCP 受信ウィンドウ、TCP 受信ウィンドウが TCP スループットに及ぼす影響、TCP ウィンドウ スケーリングの使用法、および受信データに対して TCP スループットを最適化する Windows Vista™ の新しい受信ウィンドウ自動チューニング機能について説明します。
TCP 受信ウィンドウ
TCP 接続には重要な特徴がいくつもあります。第 1 に、TCP 接続は 2 つのアプリケーション レイヤ プロトコル間での論理ポイント ツー ポイント回線であるということです。TCP は一対多の配信サービスを提供しません。TCP は一対一の配信サービスだけを提供します。
第 2 に、TCP 接続は接続指向であるということです。データが伝送される前に、2 つのアプリケーション レイヤ プロセスが、TCP 接続確立プロセスを使用して、TCP 接続を正式にネゴシエートする必要があります。同様に、TCP 接続は TCP 接続終了プロセスを使用して、ネゴシエート終了後に正式に閉じられます。
第 3 に、TCP 接続で送信された信頼できるデータはシーケンシャルなものであり、受信側から受信確認を受けます。受信確認が受けられない場合は、そのセグメントは再伝送されます。受信側では、複製されたセグメントは破棄され、シーケンシャルでない順番で届いたセグメントは適切な順序で再配置されます。
第 4 に、TCP 接続は全二重であるということです。それぞれの TCP ピアについて、TCP 接続は 2 つの論理パイプから構成されます。送信パイプおよび受信パイプの 2 つです。
TCP ヘッダーには送信データのシーケンス番号および受信データの受信確認 (ACK) の両方が含まれます。
さらに、TCP は受信および送信論理パイプを介して送信されたデータを連続するバイト ストリームとして認識します。それぞれの TCP ヘッダーのシーケンス番号および受信確認番号は、バイトの境界線上で定義されます。TCP はバイト ストリーム内ではレコードまたはメッセージの境界を識別しません。アプリケーション レイヤ プロトコルでは受信するバイト ストリームを適切に解析できる必要があります。
一度に送信できるデータの量を制限し、受信側のフロー制御を提供するために、TCP ピアはウィンドウを使用します。ウィンドウとは、受信側が送信側に送信を許可するバイト ストリーム上のデータの幅のことです。送信側はウィンドウ内に含まれるバイト ストリームのバイトのみを送信できます。ウィンドウは、送信側の送信バイト ストリームおよび受信側の着信バイト ストリームに沿ってスライドします。
指定された論理パイプ (全二重 TCP 接続の 1 方向) の場合、送信側は送信ウィンドウを保持し受信側は受信ウィンドウを保持します。送信中のデータまたは ACK セグメントがない場合、論理パイプの送信および受信ウィンドウは一致します。言い換えれば、送信側が送信を許可した送信バイト ストリーム内のデータの幅は、受信側が受信可能な着信バイト ストリーム内のデータの幅と一致するということです。図 1 はこの送信と受信の関係を示しています。
.gif)
図 1 送信および受信ウィンドウの一致 (画像を拡大するには、ここをクリックします)
受信ウィンドウのサイズを示すために、TCP ヘッダーには 16 ビットのウィンドウ フィールドが含まれています。受信側がデータを受信すると、受信側は送信側に ACK を送信し、バイトの受信に成功したことを示します。それぞれの ACK 内で、ウィンドウ フィールドは受信ウィンドウ内に残るバイト数を記録します。データが送信され、受信確認され、アプリケーションにより取得されると、送信および受信ウィンドウの両方が右側にスライドします。受信ウィンドウとは、送信側から受信側に受信確認されていないデータをどれだけ送信可能かを制御するウィンドウのことです。
受信ウィンドウ内にはアプリケーションにより取得されていないデータ、および受信はされていても受信確認されていないデータが存在するので、TCP 受信ウィンドウには図 2 が示すように補足的な構造があります。
.gif)
図 2 TCP 受信ウィンドウのデータの型 (画像を拡大するには、ここをクリックします)
最大の受信ウィンドウと現在の受信ウィンドウの間の差に注目してください。最大受信ウィンドウは固定サイズです。現在の受信ウィンドウは可変サイズで、受信側が送信側に送信を許可するデータの残存量に対応しています。現在の受信ウィンドウのサイズは、送信側に送り返される ACK 内で使用されるウィンドウ フィールドの値のことです。また最大受信ウィンドウ サイズと受信され受信確認されていてもアプリケーションにより取得されていないデータ量の差のことでもあります。
TCP 受信ウィンドウおよび TCP スループット
TCP スループットを最適化するには (一般的なエラーのない伝送パスを想定したとして)、送信側は送信側と受信側の間の論理パイプを最大限活用する量のパケットを送信する必要があります。論理パイプの容量は次の数式により計算できます。
Capacity in bits = path bandwidth in bits per second * round-trip time (RTT) in seconds
この容量は帯域幅遅延積 (BDP) と呼ばれています。パイプは太い (広帯域幅) または細い (低帯域幅) または短い (低 RTT) または長い (高 RTT) 場合があります。パイプが太くて長い場合、BDP は最大になります。高 BDP 伝送パスの例には、衛星間通信または大陸間を結ぶ光ファイバ リンクを含むエンタープライズ ワイド エリア ネットワーク (WAN) があります。
TCP ヘッダー内でのウィンドウ フィールドのサイズは 16 ビットです。これにより TCP ピアは最大 65,535 バイトの受信ウィンドウ サイズに対応します。次の数式を使用して任意の TCP ウィンドウ サイズに対するスループットを概算できます。
Throughput = TCP maximum receive windowsize / RTT
たとえば、65,535 バイトの受信ウィンドウでは、伝送パスの実際の帯域幅に関係なく、RTT が 100ms のパス上では、およそ 1 秒あたり 5.24 メガビット (Mbps) のスループットしか実現できません。今日の高 BDP 伝送パスでは、初期に設計された TCP ウィンドウ サイズは、最大値に設定したとしても、それがスループットのボトルネックになってしまうのです。
TCP ウィンドウ スケーリング
より大きなウィンドウ サイズが高速伝送パスに対応できるようにするために、RFC 1323 (
ietf.org/rfc/rfc1323.txt (英語)) が、受信側が 65,535 バイトよりも大きなウィンドウ サイズを提供することを許可するウィンドウ スケーリングを定義します。TCP ウィンドウ スケール オプションにはウィンドウ スケーリング要素があります。ウィンドウ スケーリング要素と TCP ヘッダー内の 16 ビットのウィンドウ フィールドを組み合わせると、受信ウィンドウ サイズを最大約 1 GB に増加できます。ウィンドウ スケール オプションは接続を確立するプロセス中に同期 (SYN) セグメント内にのみ送信されます。両方の TCP ピアについて、受信ウィンドウ サイズに対して、異なるウィンドウ スケーリング要素を使用するように指定できます。TCP ウィンドウ スケーリングで送信側が接続上により多くのデータを送信できるようにすることで、TCP ノードは高 BDP を使用する伝送パスの種類のいくつかをより有効に利用できます。
受信ウィンドウ サイズは TCP スループットにとって重要ですが、最適な TCP スループットを判断するための他の重要な要素は、受信ウィンドウ内に蓄積されたデータをアプリケーションが取得する速度 (アプリケーション取得比率) です。アプリケーションがデータを取得しないと、受信ウィンドウは次第にいっぱいになり、受信側が提供する現在のウィンドウ サイズが小さくなります。極端な例では、最大受信ウィンドウすべてがいっぱいになった場合、受信側が提供するウィンドウ サイズは 0 バイトになります。この場合、受信ウィンドウがクリアされるまで送信側はデータの送信を停止する必要があります。したがって、TCP スループットを最適化するには、接続に対する TCP 受信ウィンドウを、接続する伝送パスの BDP およびアプリケーション取得比率の両方を反映した値に設定する必要があります。
たとえ BDP およびアプリケーション取得比率の両方を正確に判断できたとしても、それらは時間と共に変化します。BDP 比率は伝送パスの輻輳に基づいて変化します。またアプリケーション取得比率はアプリケーションがデータを受信する接続数に基づいて変化します。
Windows XP の受信ウィンドウ
Windows XP (および Windows Server® 2003) での TCP/IP スタックでは、最大受信ウィンドウ サイズに多数の重要な属性があります。第 1 に、デフォルト値は送信インターフェイスのリンク速度に基づいています。実際の値は、TCP 接続を確立する間にネゴシエートされ、最大セグメント サイズ (MSS) まで自動的に調整されます。
第 2 に、最大受信ウィンドウ サイズは手動で設定できます。HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize および HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\InterfaceGUID\TCPWindowSize のレジストリ値により最大 65,535 バイト (ウィンドウ スケーリングなしの場合) または 1,073,741,823 バイト (ウィンドウ スケーリングありの場合) に設定できます。
第 3 に、最大受信ウィンドウ サイズにウィンドウ スケーリングを使用できます。HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts レジストリ値を 1 または 3 に設定することによりウィンドウ スケーリングを有効にできます。既定では、ウィンドウ スケーリングは、受信された SYN セグメントがウィンドウ スケール オプションを含む接続に対してのみ使用されます。
最後に、最大受信ウィンドウ サイズは、接続が開始されたときに SO_RCVBUF Windows Sockets オプションを使用することにより、アプリケーションで指定できます。ウィンドウ スケーリングの場合、アプリケーションは 65,535 バイトより大きいウィンドウ サイズを指定する必要があります。
拡張可能なウィンドウをサポートするにもかかわらず、Windows XP での最大受信ウィンドウ サイズで引き続きスループットを制限できます。その理由は、最大受信ウィンドウ サイズは、アプリケーションによって指定されない限り、すべての TCP 接続に対する固定の最大サイズだからです。これを使用して、いくつかの接続に対してはスループットを増加し、また他の接続に対してはスループットを減少できます。また、TCP 接続に対する固定の最大受信ウィンドウ サイズは、アプリケーション取得比率または伝送パス内の輻輳により変化しません。
Windows Vista の受信ウィンドウ自動チューニング
特に高 BDP を使用する伝送パスに対するスループットを最適化するために、Windows Vista (および "Longhorn" というコード名の Windows Server の次のバージョン) の次世代 TCP/IP スタックは受信ウィンドウ自動チューニングをサポートします。この機能は BDP およびアプリケーション取得比率を測定し、また進行中の伝送パスとアプリケーションに対するウィンドウ サイズを調整することにより、最適な受信ウィンドウ サイズを決定します。
受信ウィンドウ自動チューニングは、既定で TCP ウィンドウ スケーリングを有効にし、16 MB までの最大受信ウィンドウ サイズを許可します。データが接続上で伝送される間、次世代の TCP/IP スタックは接続を監視し、現在の BDP およびアプリケーション取得比率を測定し、スループットを最適化する受信ウィンドウ サイズに調節します。次世代の TCP/IP スタックは TCPWindowSize レジストリ値を使用しなくなりました。
受信ウィンドウ自動チューニングには多くの利点があります。受信ウィンドウ自動チューニングは、接続ごとに最適な受信ウィンドウ サイズを自動的に決定します。Windows XP では、TCPWindowSize レジストリ値がすべての接続に適用されます。アプリケーションは、Windows Sockets オプションを使用して TCP ウィンドウ サイズを指定する必要がなくなりました。また IT 管理者が、特定のコンピュータに対して TCP 受信ウィンドウ サイズを手動で設定する必要がなくなりました。
受信ウィンドウ自動チューニングにより、Windows Vista ベースの TCP ピアは、通常、Windows XP ベースの TCP ピアよりもより大きな受信ウィンドウ サイズを提供できます。これにより他の TCP ピアは、ACK (TCP 輻輳管理による制限) が待機することがなくなり、より多くの TCP データ セグメントを送信するので、Windows Vista ベースの TCP ピアへのパイプを十分に使用することができます。 Web ページまたは電子メールなどの典型的なクライアント ベースのネットワーク トラフィックの場合、Web サーバーまたは電子メール サーバーは、より多くの TCP データをより迅速にクライアント コンピュータに送ることができます。その結果ネットワーク パフォーマンスが全体的に向上します。接続に対する BDP およびアプリケーション取得比率が高いほど、パフォーマンスはより向上します。
ネットワークへの影響については、これまでは TCP データ パケットのストリームは通常より遅い、一定のペースで送信されてきましたが、それがより迅速に送信されることにより、データ伝送中のネットワーク使用率がより大きくなります。Windows XP および Windows Vista ベースのコンピュータの場合、長く、太いパイプで同じデータ伝送が実行されます。伝送されるデータ量は同じです。しかし、Windows Vista ベースのクライアント コンピュータに対するデータ伝送は、より大きな受信ウィンドウ サイズと、サーバーからクライアントへのパイプをサーバーが十分に使用できることによって、より速くなります。
受信ウィンドウ自動チューニングは高 BDP 伝送パスのネットワーク使用率を増加させるので、サービスの品質 (QoS) の使用またはアプリケーション送信比率の調整が、稼働中の伝送パスまたは容量が限界に近づいている伝送パスに対して重要になる場合があります。この予期される必要に対処するため、Windows Vista はグループ ポリシーに基づいた QoS 設定をサポートします。これにより IP アドレスまたは TCP ポート上で送信されるトラフィックに対する調整比率を定義できます。詳細については、
ポリシーに基づく QoS に関するリソース (英語) を参照してください。
.