The Cable Guy – 2005 年 11 月

次世代の TCP/IP スタックのパフォーマンスの拡張機能

cable_guy

By The Cable Guy

このコラムで、次世代の TCP/IP スタックのパフォーマンスの拡張機能について説明します。これらの拡張機能には、受信ウィンドウの自動調整、ワイヤレス トラフィックの拡張機能および改善されたルーティング パスの検出および復旧が含まれます。

トピック

はじめに
Window Auto-Tuning を受ける
ワイヤレス トラフィックの拡張機能
改善されたルーティング パスの検出および復旧
IPv4 の近隣到達不能検出
デフォルト ゲートウェイの変更のフェールバックのサポート
詳細情報

はじめに

Microsoft Windows 2000 の TCP/IP スタックは TCP Receive Windows Scaling、SACK (Selective Acknowledgements)、およびよりよいラウンドトリップ タイム (RTT) の見積もりを含むパフォーマンスの拡張機能のセットを導入しました。Windows 2000 がリリースされてから数年間、高帯域およびワイヤレス リンクの使用がより普及するなど、ネットワーク帯域に多くの変更がありました。Windows Vista (現在ベータ テスト中) および Windows Server "Longhorn" (現在ベータ テスト中) の次世代の TCP/IP スタックには、高帯域、高レイテンシ、および高ロス ネットワーク環境のスループットを増大させるためのパフォーマンスの拡張機能の新しいセットが含まれています。

このコラムでは、次のパフォーマンスの拡張機能について説明します。

  • 受信ウィンドウの自動調整

  • ワイヤレス トラフィックの拡張機能

  • 改善されたルーティング パスの検出および復旧


Window Auto-Tuning を受ける

TCP Receive Windows のサイズは TCP 接続の受信データを保存するために使用されている受信ホストのメモリのバッファのバイトの総計です。接続が確立された後、Receive Window のサイズは各 TCP セグメントにアドバタイズされます。受信メモリのバッファ内の残りの空間をアドバタイズすることは、送信者が受信者が保存できないデータを送信することを防ぐ受信者側のフロー制御メカニズムです。送信ホストは最大限で、受信確認および受信ウィンドウのサイズの更新を待つ前に、受信者によりアドバタイズされたデータ量を送信のみができます。

Windows Server 2003 および Windows XP の受信ウィンドウ

Windows Server 2003 および Windows XP の TCP/IP スタックについて、最大の受信ウィンドウのサイズは次の通りです。

  • 送信インターフェースのリンク速度に基づく既定値を持つ: 実際の値は自動的に、TCP 接続の確立中にネゴシエートされた最大セグメント サイズ (MSS) の増分にさえも適応します。

  • 手動で構成可能: HKEY_LOCAL_MACHINE\System
    \CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize および HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\TCPWindowSize レジストリ値は最大 65,535 バイト (ウィンドウ スケーリングなし) または 1,073,741,823 (ウィンドウ スケーリングあり) に設定できます。ウィンドウ スケーリングなしでは、パスの帯域に関わらず、100 ミリセカンドの RTT のパスで約 5 メガビット/秒 (Mbps) のスループットしか得られません。

  • ウィンドウ スケーリングで 1 ギガバイト (GB) まで拡大できる: ウィンドウ スケーリングは RFC 1323 (英語) で定義されていますが、これにより、TCP は接続の確立中にウィンドウのサイズについての倍率をネゴシエートすることができます。HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts レジストリ値を 1 または 3 に設定することにより、ウィンドウ スケーリングを有効にすることができます。受け取られた同期 (SYN) セグメントがウィンドウ スケール オプションを含む場合、既定でウィンドウ スケーリングは、接続でのみ使用されます。

  • アプリケーションにより指定できる: 接続が開始されている場合、SO_RCVBUF Windows Sockets オプションを使用することにより、アプリケーションは最大の受信ウィンドウのサイズを指定することができます。ウィンドウ スケーリングについて、アプリケーションは 65,535 バイトより大きいウィンドウのサイズを指定する必要があります。

受信ウィンドウの正しい値は、しばしば決定することが困難です。送信者と受信者間のネットワークのキャパシティを満たすため、ウィンドウのサイズは接続についての帯域幅遅延積 (Bandwidth Delay Product:BDP) に設定される必要があります。これはラウンドトリップ タイムを乗じた帯域です。帯域幅遅延積が正しく決定されたとしても、受信アプリケーションがどのくらいの速度で受信データ バッファからデータを取得するか (アプリケーション取得率) は分かりません。スケーラブルなウィンドウのサポートにも関わらず、Windows Server 2003 および Windows XP の最大の受信ウィンドウのサイズは依然としてスループットを制限することができます。この理由は、これはすべての TCP 接続 (アプリケーションにより指定されていない限り) について決められた最大サイズであるためです。これにより、ある接続についてのスループットを向上させ、そのほかのスループットを減少させることができます。さらに、TCP 接続についての決められた最大受信ウィンドウのサイズは変化するネットワークの状況により変化しません。

次世代の TCP/IP スタックの受信ウィンドウ

ネットワークの現在の状態に基づく接続についての最大の受信ウィンドウのサイズの値を正しく決定するという問題を解決するために、次世代の TCP/IP スタックは受信ウィンドウの自動調整をサポートします。受信ウィンドウの自動調整は継続的に、帯域幅遅延積 (Bandwidth Delay Product:BDP) およびアプリケーション取得率を計測することにより、最適な受信ウィンドウのサイズを決定し、変化するネットワークの状態に基づき最大の受信ウィンドウのサイズを調節します。受信ウィンドウの自動調整は既定で TCP ウィンドウ スケーリングを有効にし、16 MB ウィンドウ サイズまで可能にします。データが接続でフローする時、次世代の TCP/IP スタックはその接続を監視し、接続およびアプリケーションの受信率の現在の帯域幅遅延積 (Bandwidth Delay Product:BDP) を計測し、スループットを最適化するために、受信ウィンドウのサイズを調節します。次世代の TCP/IP スタックは現在 TCPWindowSize レジストリ値を使用しません。

TCP ピア間のよりよいスループットで、ネットワーク帯域の使用率はデータ転送中増加します。すべてのアプリケーションが TCP データを受信するために最適化されると、ネットワークの全体の使用率が大幅に増加し、Quality of Service (QoS) の使用をフル稼働またはそれに近い状態のネットワーク上でさらに重要にします。

ワイヤレス トラフィックの拡張機能

System (UMTS) などに基づいているワイヤレス ネットワークはポータブル コンピューティング デバイスに可動性およびユビキタス接続を提供します。しかし、ワイヤレス ネットワークは、ネットワークの状態、シグナル減衰、電磁波妨害、およびモバイル コンピュータの場所の変更により、パケット損失の率も高くなる可能性があります。高ロス ネットワークの環境では、頻繁に発生する TCP タイムアウトと再転送によりスループットが著しく減少する可能性があります。

次世代の TCP/IP スタックは高ロス環境でのスループットを最適化するために次の RFC をサポートします。

  • RFC 2582 (英語) : TCP の高速リカバリ アルゴリズムに対する NewReno の変更
    RFC 2001 に定義されている高速リカバリ アルゴリズムは Reno アルゴリズムに基づいています。これは、高速再送信イベントのため、セグメントが再送信される場合、送信者が送信できるデータの量を増加させます。Reno アルゴリズムが単一の失われたセグメントに対しよく機能するとしても、失われたセグメントが複数ある場合、よく機能しません。NewReno アルゴリズムは、データのウィンドウ内の複数のセグメントが失われ、送信者が部分的な受信確認 (正常に受け取られたデータの一部のみの確認) を受け取る時、送信者が高速リカバリ中、送信率を増加できる方法を変更することにより、より高速なスループットを提供します。

  • RFC 2883 (英語) : TCP の Selective Acknowledgement (SACK) オプションへの拡張
    S SACK は RFC 2018 で定義されていますが、これにより、受信者は受信されたデータの非連続なブロックを 4 つまで示すことができます。RFC 2883 は、複製パケットを承認するための SACK TCP オプションのフィールドの追加の使用を定義します。これにより、SACK オプションを含む TCP セグメントの受信者が、不必要にセグメントを再送信した場合、確認し、その後の再送信を防ぐため、その動作を調節することができます。送信された再送信が少ないほど、全体のスループットはよくなります。

  • RFC 3517 (英語) : TCP の Conservative Selective Acknowledgment (SACK) ベースの損失回復アルゴリズム
    Windows Server 2003 および Windows XP の TCP/IP の現在の実装は、SACK 情報をどの TCP セグメントが宛先に到着していないかを確認するためのみに使用します。RFC 3517 は、重複確認応答が受け取られた場合、損失回復を実行するために SACK 情報を使用する方法を定義し、SACK が接続で有効である場合、Fast Recovery アルゴリズムを交換します。次世代の TCP/IP スタックは SACK 情報を接続ごとに追跡し続け、複数のセグメントが宛先で受信されていない場合、受信確認および重複確認応答がより迅速に回復するよう監視します。

  • RFC 4138 (英語) : Forward RTO-Recovery (F-RTO): TCP および Stream Control Transmission Protocol (SCTP) で誤った再伝送を検出するためのアルゴリズム
    RTT に突然の、および一時的な増加がある場合、TCP セグメントの誤った再伝送が起こる可能性があります。この増加が起こると、以前に送信されたセグメントの再伝送のタイムアウト (RTO) の期限が切れ始め、TCP はそれらの再伝送を開始します。データの完全なウィンドウを送信するちょうど前にこの増加が起こると、送信者はデータの全体のウィンドウを再伝送することができます。F-RTO アルゴリズムは次の動作を介し、誤った再伝送を防ぎます。

    RTO が複数のセグメントについて期限が切れる時、TCP は単に最初のセグメントを再伝送します。最初の受信確認が受信されると、TCP は新しいセグメントの送信を開始します。(アドバタイズされたウィンドウのサイズにより許可される場合。) 次の受信確認がタイム アウトしているのにまだ再伝送されていないそのほかのセグメントを確認すると、TCP はタイムアウトが誤ったものであったと確認し、タイム アウトしたそのほかのセグメントを再伝送しません。



    この動作の結果として、ワイヤレス クライアントがあるワイヤレス AP から別のものに移動する場合など、RTT に突然で一時的な増加が見られた環境について、F-RTO はセグメントの不必要な再伝送を防ぎ、さらに迅速にその通常の送信率に戻ります。SACK ベースの損失回復および F-RTO の使用は GPRS リンクを使用する接続に最適です。


改善されたルーティング パスの検出および復旧

TCP 接続がセグメントの再送信を開始する時、リモート トラフィックに新しいルーティング パスを自動的に試行するために、Windows Server 2003 および Windows XP の TCP/IP スタックは停止ゲートウェイ検出をサポートします。停止ゲートウェイ検出とは、コンピュータのデフォルト ゲートウェイを次の構成されたデフォルト ゲートウェイに自動的に変更するフェールオーバー メカニズムです。(コンピュータがインターフェースで複数のデフォルト ゲートウェイで構成されている場合。) しかし、Windows Server 2003 および Windows XP の停止ゲートウェイ検出は次を行ないません。

  • ローカル デフォルト ゲートウェイが失敗したか、それともリモート ゲートウェイ (ルータ) が失敗したかを区別します。

  • プライマリ ルーティング パスが復元された場合、デフォルト ゲートウェイをプライマリ デフォルト ゲートウェイに変更するためのフェールバック メソッドを提供します。

次世代の TCP/IP スタックはこれらの問題を、IPv4 の近隣到達不能検出および自動で変更されたデフォルト ゲートウェイ構成のフェールバックのサポートを介し解決します。

IPv4 の近隣到達不能検出

近隣到達不能検出とは IPv6 の機能で、これによりノードが隣接したノードが到達可能であるかどうかを追跡することができます。隣接したノードは、その隣接したノードに送信された IPv6 パケットが受信され、隣接したノードにより処理されたという確認があった場合、到達可能です。IPv6 は、ユニキャストの近隣要請および近隣広告メッセージの交換を介し、または接続がデータを送受信していることを示すために TCP などの上位層プロトコルに依存することにより、到達可能性を追跡します。近隣到達不能検出で、IPv6 ノードは隣接するノードがもはや到達可能でない時を確認し、エラー状態をそのほかのコンポーネントおよびアプリケーションに報告することができます。

次世代の TCP/IP スタックもまた、IPv4 ルート キャッシュの IPv4 の近隣の到達可能な状態を追跡することにより、IPv4 トラフィックについて近隣到達不能検出をサポートします。IPv4 近隣到達不能検出はユニキャスト アドレス解決プロトコル (ARP) リクエストおよび ARP 応答メッセージの交換を介し、または TCP のような上層プロトコルに依存することにより、到達可能性を確認します。IPv4 近隣到達不能検出で、IPv4 ベースの通信は、ルータを含む近隣のノードが到達可能でなくなり、その状態を報告する時を確認することにより、利益を得ます。

次世代の TCP/IP スタックで、TCP 接続がセグメントの再送を開始した場合、そのスタックは、ユニキャスト ARP リクエスト メッセージを送信することにより、現在のデフォルト ゲートウェイが依然として到達可能であるかどうかを確認しようとします。既定のルータが応答しない場合、次世代の TCP/IP スタックはデフォルト ゲートウェイを一覧の次のものに変更します。既定のルータが応答する場合、停止ゲートウェイ検出は最終的にはデフォルト ゲートウェイを一覧の次のものに変更します。

デフォルト ゲートウェイの変更のフェールバックのサポート

Windows Server 2003 および Windows XP の TCP/IP では、停止ゲートウェイ検出がデフォルト ゲートウェイを変更する時、新しいデフォルト ゲートウェイは、停止ゲートウェイ検出が一覧の次のものに切り替わるまで (デフォルト ゲートウェイの一覧を繰り返します) または、コンピュータが再起動するまで、既定のルート トラフィックのプライマリ ゲートウェイのままとなります。このため、Windows Server 2003 および Windows XP の TC/IP の停止ゲートウェイ検出は、フェールオーバー機能を提供しますが、フェールバック機能は提供しません。
デフォルト ゲートウェイのフェールバックが欠落していると、2 つのルータ (高キャパシティ プライマリ ルータおよびそれよりも低いキャパシティのバックアップ ルータ) を含むサブネットでスループットの問題が発生する可能性があります。高キャパシティ ルータに一時的なエラーが発生した場合、停止ゲートウェイ検出はサブネットのホストをバックアップ ルータに切り替える可能性があります。高キャパシティ ルータが再度利用可能となると、ネットワークのホストはすべてそれを使用できなくなります。この理由はこれらのホストはバックアップ ルータに切り替わるためです

次世代の TCP/IP スタックは、停止ゲートウェイを介し TCP トラフィックを定期的に送信しようとすることにより、フェールバックを停止ゲートウェイに提供します。停止ゲートウェイを介し送信された TCP トラフィックが成功すると、次世代の TCP/IP スタックはデフォルト ゲートウェイを以前確認された停止ゲートウェイに切り替えます。
高キャパシティ ルータおよびそれより低いキャパシティのバックアップ ルータの例で、高キャパシティ ルータが利用可能でなくなる場合、サブネットのホストはそのデフォルト ゲートウェイをバックアップ ルータに切り替え、定期的に TCP トラフィックを高キャパシティ ルータを介し送信しようとします。高キャパシティ ルータが利用可能となり、ホストが高キャパシティ ルータを介し送信された TCP トラフィックが正常に受信されたことを確認すると、サブネットのホストはそのデフォルト ゲートウェイを高キャパシティ ルータに切り替えます。プライマリ デフォルト ゲートウェイに対するフェールバックのサポートは、サブネットのプライマリ デフォルト ゲートウェイを介しトラフィックを送信することにより、より迅速なスループットを提供することができます。

詳細情報

Windows の TCP/IP に関する詳細情報は、次のリソースを参照してください。

The Cable Guy の全コラムの一覧と概要をご覧になるには、ここをクリックしてください。



表示: