TCP Nileを使用したTCPパフォーマンスの最適化
TCPは、データ伝送におけるネットワークの輻輳を回避するために、以下の最適化手法と輻輳制御戦略（またはアルゴリズム）を使用します。
渋滞制御戦略
Transmission Control Protocol（TCP）は、インターネット接続の確立と管理、転送エラーの処理、Web アプリケーションとクライアントデバイスの円滑な接続に長い間使用されてきました。しかし、パケット損失はネットワークの輻輳だけに依存するわけではなく、輻輳が必ずしもパケット損失を引き起こすわけではないため、ネットワークトラフィックの制御はより困難になっています。したがって、輻輳を測定するには、TCP アルゴリズムはパケット損失と帯域幅の両方に焦点を当てる必要があります。
ナイルアルゴリズム
Citrix システムズは、LTE、LTE Advanced、3Gなどの高速ネットワーク向けに設計されたTCP最適化アルゴリズムであるNILEという新しい輻輳制御アルゴリズムを開発しました。Nileは、フェーディング、ランダムまたは輻輳による損失、リンク層再送信、キャリアアグリゲーションに起因する固有の課題に対応します。
NILEアルゴリズム:
- ラウンドトリップ時間の測定値に基づいてキュー遅延を推定します。
- 測定されたキュー遅延に反比例する輻輳ウィンドウ増加関数を使用します。この方法では、標準の TCP 方式よりもネットワークの輻輳ポイントに近づくのが遅くなり、輻輳時のパケット損失が減少します。
- 推定キュー遅延を使用して、ネットワーク上のランダム損失と輻輳に基づく損失を区別できます。
通信サービスプロバイダーは、自社の TCP インフラストラクチャで NILE アルゴリズムを使用して次のことを行えます。
- モバイルネットワークと長距離ネットワークの最適化 — NILEアルゴリズムは、標準のTCPと比較して高いスループットを実現します。この機能は、モバイルネットワークや長距離ネットワークにとって特に重要です。
- アプリケーションで認識される遅延を低減し、サブスクライバーエクスペリエンスを向上させる：ナイルアルゴリズムは、パケット損失情報を使用して送信ウィンドウサイズを大きくすべきか小さくすべきかを判断し、キューイング遅延情報を使用して増減のサイズを決定します。この転送ウィンドウサイズの動的設定により、ネットワーク上のアプリケーション遅延が減少します。
コマンドラインインターフェイスを使用して NILE サポートを設定するには
コマンドプロンプトで、次のように入力します：
set ns tcpProfile <name> [-flavor NILE]
<!--NeedCopy-->
設定ユーティリティーを使った NILE サポートの設定
- [ システム ] > [ プロファイル ] > [ TCP プロファイル] に移動し、[ **TCP**プロファイル] をクリックします。
- 「 TCP フレーバー 」ドロップダウンリストから「 NILE」を選択します。
例：
set ns tcpProfile tcpprofile1 -flavor NILE
<!--NeedCopy-->
比例レート回復 (PRR) アルゴリズム
TCP 高速回復メカニズムは、パケット損失によるウェブの遅延を低減します。新しい比例レート回復 (PRR) アルゴリズムは、損失回復中に TCP データを評価する高速回復アルゴリズムです。輻輳制御アルゴリズムで選択したターゲットウィンドウに適した割合を使用して、Rate-Halvingを模したパターンになっています。これにより、ウィンドウの調整が最小限に抑えられ、リカバリ終了時の実際のウィンドウサイズは Slow-Start のしきい値 (ssthresh) に近い値になります。
TCP ファストオープン (TFO)
TCP Fast Open（TFO）は、TCPの最初のハンドシェイク中にクライアントとサーバー間で迅速かつ安全なデータ交換を可能にするTCPメカニズムです。この機能は、NetScalerアプライアンスの仮想サーバーにバインドされたTCPプロファイルのTCPオプションとして使用できます。TFOは、NetScalerアプライアンスが生成するTCP Fast Open Cookie（セキュリティクッキー）を使用して、仮想サーバーへのTFO接続を開始するクライアントを検証および認証します。TFO メカニズムを使用すると、1 回のフルラウンドトリップに必要な時間だけアプリケーションのネットワーク遅延を減らすことができます。これにより、短い TCP 転送で発生する遅延を大幅に減らすことができます。
TFO の仕組み
クライアントが TFO 接続を確立しようとすると、最初の SYN セグメントに TCP Fast Open Cookie が含まれ、それ自体が認証されます。認証が成功すると、NetScalerアプライアンス上の仮想サーバーは、スリーウェイハンドシェイクの最後のACKセグメントを受信していなくても、SYN-ACKセグメントにデータを含めることができます。これにより、データを交換する前に三者間のハンドシェイクを必要とする通常の TCP 接続と比較して、最大 1 回の往復を節約できます。
クライアントとバックエンドサーバーは、次の手順を実行して TFO 接続を確立し、最初の TCP ハンドシェイク中にデータを安全に交換します。
- クライアント自体を認証するためのTCPファストオープンクッキーがない場合、クライアントはSYNパケットでファストオープンクッキーリクエストをNetScalerアプライアンス上の仮想サーバーに送信します。
- 仮想サーバにバインドされたTCPプロファイルでTFOオプションが有効になっている場合、アプライアンスは（クライアントのIPアドレスを秘密鍵で暗号化することにより）Cookie を生成し、生成されたFast Open CookieをTCPオプションフィールドに含むSYN-ACKでクライアントに応答します。
- クライアントは、アプライアンス上の同じ仮想サーバーへの今後の TFO 接続に備えて Cookie をキャッシュします。
- クライアントが同じ仮想サーバーへのTFO接続を確立しようとすると、キャッシュされたFast Open Cookie（TCPオプションとして）を含むSYNをHTTPデータとともに送信します。
- NetScalerアプライアンスはCookie を検証し、認証が成功すると、サーバーはSYNパケット内のデータを受け入れ、SYN-ACK、TFOクッキー、HTTPレスポンスでイベントを確認します。
注: クライアント認証が失敗した場合、サーバーはデータをドロップし、セッションタイムアウトを示す SYN のみでイベントを確認します。
- サーバー側では、サービスにバインドされたTCPプロファイルでTFOオプションが有効になっている場合、NetScalerアプライアンスは、接続しようとしているサービスにTCP Fast Open Cookieが存在するかどうかを判断します。
- TCP Fast Open Cookie が存在しない場合、アプライアンスは SYN パケットで Cookie リクエストを送信します。
- バックエンドサーバーが Cookie を送信すると、アプライアンスはその Cookie をサーバー情報キャッシュに保存します。
- アプライアンスに特定の宛先 IP ペアの Cookie が既にある場合は、古い Cookie が新しい Cookie に置き換えられます。
- 仮想サーバーが同じ SNIP アドレスを使用して同じバックエンドサーバーに再接続しようとしたときに Cookie がサーバー情報キャッシュに存在する場合、アプライアンスは SYN パケット内のデータを Cookie と結合し、バックエンドサーバーに送信します。
- バックエンドサーバーは、データと SYN の両方でイベントを確認します。
注： サーバーがSYNセグメントのみでイベントを確認した場合、NetScalerアプライアンスは元のパケットからSYNセグメントとTCPオプションを削除した直後にデータパケットを再送信します。
TCP ファストオープンの設定
TCP Fast Open（TFO）機能を使用するには、関連する TCP プロファイルで TCP Fast Open オプションを有効にし、TFO Cookie Timeout パラメータをそのプロファイルのセキュリティ要件に適した値に設定します。
コマンドラインを使用して TFO を有効または無効にするには
コマンドプロンプトで、次のコマンドのいずれかを入力して、新規または既存のプロファイルの TFO を有効または無効にします。
注: デフォルト値は DISABLED です。
add tcpprofile <TCP Profile Name> - tcpFastOpen ENABLED | DISABLED
set tcpprofile <TCP Profile Name> - tcpFastOpen ENABLED | DISABLED
unset tcpprofile <TCP Profile Name> - tcpFastOpen
<!--NeedCopy-->
例：
add tcpprofile Profile1 – tcpFastOpen Set tcpprofile Profile1 – tcpFastOpen Enabled unset tcpprofile Profile1 – tcpFastOpen
コマンドラインインターフェイスを使用して TCP Fast Open Cookie のタイムアウト値を設定するには
コマンドプロンプトで入力します：
set tcpparam –tcpfastOpenCookieTimeout <Timeout Value>
<!--NeedCopy-->
例：
set tcpprofile –tcpfastOpenCookieTimeout 30secs
<!--NeedCopy-->
GUI を使用して TCP ファストオープンを設定するには
- [ 構成 ] > [ システム ] > [ プロファイル ] に移動し、[ 編集 ] をクリックして TCP プロファイルを変更します。
- 「 TCP プロファイルの設定」ページで、「TCPFast Open 」チェックボックスを選択します。
- [ OK]、[ 完了]の順にクリックします。
GUI を使用して TCP ファストクッキーのタイムアウト値を設定するには
[ 構成 ] > [ システム ] > [ 設定] > [TCP パラメータの変更 ] に移動し、次に [ TCP パラメータの設定 ] ページに移動して TCP Fast Open Cookie のタイムアウト値を設定します。
TCP ハイスタート
新しい TCP プロファイルパラメーター hystart により、Hystart アルゴリズムが有効になります。Hystart アルゴリズムは、終了する安全なポイント (ssthresh) を動的に決定するスロースタートアルゴリズムです。これにより、大量のパケット損失を発生させることなく、輻輳回避への移行が可能になります。この新しいパラメータはデフォルトでは無効になっています。
輻輳が検出されると、Hystart は輻輳回避フェーズに入ります。これを有効にすると、パケット損失の多い高速ネットワークでのスループットが向上します。このアルゴリズムは、トランザクションの処理中に最大帯域幅に近い状態を維持するのに役立ちます。そのため、スループットを向上させることができます。
TCP ハイスタートの設定
Hystart 機能を使用するには、関連する TCP プロファイルで Cubic Hystart オプションを有効にします。
コマンドラインインターフェイス (CLI) を使用して Hystart を設定するには
コマンドプロンプトで、次のコマンドのいずれかを入力して、新規または既存の TCP プロファイルで Hystart を有効または無効にします。
add tcpprofile <profileName> -hystart ENABLED
set tcpprofile <profileName> -hystart ENABLED
unset tcprofile <profileName> -hystart
<!--NeedCopy-->
例：
add tcpprofile Profile1 – tcpFastOpen
Set tcpprofile Profile1 – tcpFastOpen Enabled
unset tcpprofile Profile1 – tcpFastOpen
<!--NeedCopy-->
GUI を使用して Hystart サポートを設定するには
- [ 構成 ] > [ システム ] > [ プロファイル ] に移動し、[ 編集 ] をクリックして TCP プロファイルを変更します。
- 「 TCP プロファイルの設定 」ページで、「 Cubic Hystart 」チェックボックスを選択します。
- [ OK]、[ 完了]の順にクリックします。
最適化手法
TCP では、以下の最適化手法と方法を使用してフロー制御を最適化します。
ポリシーベースの TCP プロファイル選択
今日のネットワークトラフィックは、かつてないほど多様で帯域幅を大量に消費しています。トラフィックの増加に伴い、サービス品質 (QoS) が TCP のパフォーマンスに与える影響は大きくなります。QoS を強化するために、ネットワークトラフィックのクラスごとに異なる TCP プロファイルを使用して AppQoE ポリシーを設定できるようになりました。AppQoEポリシーは、仮想サーバーのトラフィックを分類して、3G、4G、LAN、WANなどの特定のタイプのトラフィックに最適化されたTCPプロファイルを関連付けます。
この機能を使用するには、TCP プロファイルごとにポリシーアクションを作成し、AppQoE ポリシーにアクションを関連付け、負荷分散仮想サーバーにポリシーをバインドします。
ポリシーベースの TCP プロファイル選択の設定
ポリシーベースの TCP プロファイル選択の設定は、次のタスクで構成されます。
- AppQoE を有効にする。TCP プロファイル機能を設定する前に、AppQoE 機能を有効にする必要があります。
- AppQoE アクションを追加します。AppQoE 機能を有効にしたら、TCP プロファイルを使用して AppQoE アクションを設定します。
- AppQoE ベースの TCP プロファイル選択の設定さまざまなクラスのトラフィックにTCPプロファイル選択を実装するには、NetScalerアプライアンスが接続を識別し、正しいAppQoEアクションを各ポリシーにバインドできるAppQoEポリシーを構成する必要があります。
- AppQoE ポリシーを仮想サーバにバインドします。AppQoEポリシーを構成したら、それらを1つ以上の負荷分散、コンテンツスイッチング、またはキャッシュリダイレクト仮想サーバーにバインドする必要があります。
コマンドラインインターフェイスを使用した構成
コマンドラインインターフェイスを使用して AppQoE を有効にするには:
コマンドプロンプトで次のコマンドを入力して機能を有効にし、有効になっていることを確認します。
enable ns feature appqoe
show ns feature
<!--NeedCopy-->
コマンドラインインターフェイスを使用して AppQoE アクションを作成する際に TCP プロファイルをバインドするには
コマンドプロンプトで、tcpprofiletobind オプションを指定して次の AppQoE アクションコマンドを入力します。
TCP プロファイルのバインディング:
add appqoe action <name> [-priority <priority>] [-respondWith ( ACS | NS ) [<CustomFile>] [-altContentSvcName <string>] [-altContentPath <string>] [-maxConn <positive_integer>] [-delay <usecs>]] [-polqDepth <positive_integer>] [-priqDepth <positive_integer>] [-dosTrigExpression <expression>] [-dosAction ( SimpleResponse |HICResponse )] [-tcpprofiletobind <string>]
show appqoe action
<!--NeedCopy-->
コマンドラインインターフェイスを使用して AppQoE ポリシーを構成するには
コマンドプロンプトで入力します：
add appqoe policy <name> -rule <expression> -action <string>
<!--NeedCopy-->
コマンドラインインターフェイスを使用してAppQoEポリシーを負荷分散、キャッシュリダイレクト、またはコンテンツスイッチング仮想サーバーにバインドするには
コマンドプロンプトで入力します：
bind cs vserver cs1 -policyName <appqoe_policy_name> -priority <priority>
bind lb vserver <name> - policyName <appqoe_policy_name> -priority <priority>
bind cr vserver <name> -policyName <appqoe_policy_name> -priority <priority>
<!--NeedCopy-->
例：
add ns tcpProfile tcp1 -WS ENABLED -SACK ENABLED -WSVal 8 -nagle ENABLED -maxBurst 30 -initialCwnd 16 -oooQSize 15000 -minRTO 500 -slowStartIncr 1 -bufferSize 4194304 -flavor BIC -KA ENABLED -sendBuffsize 4194304 -rstWindowAttenuate ENABLED -spoofSynDrop ENABLED -dsack enabled -frto ENABLED -maxcwnd 4000000 -fack ENABLED -tcpmode ENDPOINT
add appqoe action appact1 -priority HIGH -tcpprofile tcp1
add appqoe policy apppol1 -rule "client.ip.src.eq(10.102.71.31)" -action appact1
bind lb vserver lb2 -policyName apppol1 -priority 1 -gotoPriorityExpression END -type REQUEST
bind cs vserver cs1 -policyName apppol1 -priority 1 -gotoPriorityExpression END -type REQUEST
<!--NeedCopy-->
GUI を使用したポリシーベースの TCP プロファイリングの設定
GUI を使用して AppQoE を有効にするには
- [ システム ] > [ 設定]に移動します。
- 詳細ウィンドウで、「 拡張機能の設定」をクリックします。
- 「 拡張機能の設定 」ダイアログで、「 AppQoE 」チェックボックスを選択します。
- ［OK］ をクリックします。
GUI を使用して AppQoE ポリシーを設定するには
- [ **アプリエキスパート] > [ **AppQoE** ] > [アクション] に移動します。**
- 詳細ウィンドウで、次のいずれかの操作を行います：
- 新しいアクションを作成するには、[ 追加] をクリックします。
- 既存のアクションを変更するには、アクションを選択し、[ 編集] をクリックします。
-
「 AppQoE アクションの作成 」または「 AppQoE アクションの設定 」画面で、パラメータの値を入力または選択します。ダイアログボックスの内容は、「AppQoE アクションを構成するためのパラメーター」で説明されているパラメーターに次のように対応します (アスタリスクは必須パラメーターを示します)。
- 名前—名前
- アクションタイプ — 次の式で応答
- 優先度 — 優先度
- ポリシーキューの深さ：POLQ の深さ
- キューの深さ — PRIQ の深さ
- DOS アクション—ディスコクション
- ［Create］ をクリックします。
GUI を使用して AppQoE ポリシーをバインドするには
- [ トラフィック管理 ] > [ 負荷分散 ] > [ 仮想サーバー] に移動し、サーバーを選択して [ 編集] をクリックします。
- 「 ポリシー 」セクションで、(+) をクリックしてAppQoEポリシーをバインドします。
- 「 ポリシー 」スライダーで、次の操作を行います。
- ドロップダウンリストから AppQoE としてポリシータイプを選択します。
- ドロップダウンリストからトラフィックタイプを選択します。
- 「 ポリシーバインディング 」セクションで、次の操作を行います。
- 「 新規 」をクリックして、新しい AppQoE ポリシーを作成します。
- 既存のポリシーをクリックして 、ドロップダウンリストから AppQoE ポリシーを選択します。
- バインディングの優先順位を設定し、 ポリシーを仮想サーバにバインドをクリックします 。
- ［完了］ をクリックします。
SACK ブロック生成
1 つのデータウィンドウで複数のパケットが失われると、TCP のパフォーマンスが低下します。このようなシナリオでは、選択的受信確認（SACK）メカニズムと選択的繰り返し再送信ポリシーを組み合わせることで、この制限を克服できます。順不同のパケットが受信されるたびに、SACK ブロックを生成する必要があります。
順序が狂ったパケットが再構成キューブロックに収まる場合は、そのブロックにパケット情報を挿入し、完全なブロック情報を SACK-0 に設定します。順序が狂ったパケットが再構成ブロックに収まらない場合は、そのパケットを SACK-0として送信し、前のSACKブロックを繰り返します。順序が合っていないパケットが重複していて、パケット情報が SACK-0に設定されている場合は、ブロックをD-SACKします。
注: 確認済みのパケット、または既に受信された順序の悪いパケットの場合、そのパケットは D-SACK と見なされます。
クライアントリネギング
NetScalerアプライアンスは、SACKベースのリカバリ中のクライアント更新を処理できます。
PCB 上の end_point をマーキングするためのメモリチェックでは、使用可能なメモリの合計が考慮されない
NetScalerアプライアンスでは、使用可能な合計メモリを使用せずに、メモリ使用量のしきい値を 75% に設定すると、新しいTCP接続がTCP最適化をバイパスします。
SACK ブロックの欠落による不必要な再送信
非エンドポイントモードで DUPACKS を送信するときに、順序が狂ったパケットのいくつかで SACK ブロックが欠落していると、サーバからの再送信がさらにトリガーされます。
接続数の SNMP が過負荷のため最適化をバイパスしました
過負荷が原因でTCP最適化がバイパスされた接続数を追跡するために、次のSNMP IDがNetScalerアプライアンスに追加されました。
- 1.3.6.1.4.1.5951.4.1.46.13 (TCP 最適化が有効)。TCP 最適化で有効になっている接続の総数を追跡します。
- 1.3.6.1.4.1.5951.4.1.46.132 (TCP 最適化バイパス)。接続の総数を追跡するには、TCP最適化をバイパスしました。
ダイナミック受信バッファ
TCPパフォーマンスを最大化するために、NetScaler ADCアプライアンスはTCP受信バッファサイズを動的に調整できるようになりました。