次の方法で共有

Load Balancer の TCP リセットおよびアイドルのタイムアウト

  • [アーティクル]

Standard Load Balancer を使用して、特定の規則のアイドル時の TCP リセットを有効にすることにより、シナリオのより予測可能なアプリケーション動作を作成します。 ロード バランサーの既定の動作では、フローのアイドル タイムアウトに達したときに、警告なしでフローを削除します。 TCP リセットを有効にすると、Load Balancer によりアイドル タイムアウト時に双方向 TCP リセット (TCP リセット パケット) が送信され、接続がタイムアウトして使用できなくなったことが、アプリケーション エンドポイントに通知されます。 エンドポイントは、必要に応じて直ちに新しい接続を確立できます。

ネットワーク ノードの既定の TCP リセット動作を示す図。

TCP リセット

この既定の動作は変更でき、受信 NAT 規則、負荷分散規則、送信規則に基づいて、アイドル タイムアウト時の TCP リセットの送信を有効にできます。 規則ごとに有効にすると、Load Balancer により、双方向 TCP リセット (TCP RST パケット) が、クライアントとサーバーの両方のエンドポイントに対して、一致するすべてのフローのアイドル タイムアウト時に送信されます。

TCP リセット パケットを受け取ったエンドポイントは、対応するソケットをすぐに閉じます。 これにより、エンドポイントの接続の解放の即時通知が提供され、同じ TCP 接続での今後の通信は失敗します。 必要に応じてソケットが閉じられ接続が再確立されるときに、最終的にTCP 接続のタイムアウトまで待つことなく、アプリケーションは接続を削除できます。

多くのシナリオでは、TCP リセットにより、フローのアイドル タイムアウトを更新するために TCP (またはアプリケーション層) キープアライブを送信する必要性が減ります。

アイドル状態の期間が構成上の制限を超えた場合、または TCP リセットが有効になっているアプリケーションが望ましくない動作を示す場合、TCP 接続の存続性を監視するために、TCP キープアライブまたはアプリケーション層キープアライブを引き続き使用することが必要になります。 さらに、キープアライブは、接続がパスのどこかでプロキシされている場合にも引き続き役立ちます (特にアプリケーション レイヤー キープアライブ)。

エンド ツー エンドのシナリオ全体を慎重に調べることで、TCP リセットを有効にしてアイドル タイムアウトを調整することのベネフィットを判断できます。 次に、アプリケーションの望ましい動作を確保するために、さらなる手順が必要かどうかを判断します。

構成可能な TCP アイドル タイムアウト

Azure Load Balancer Standard では、ロード バランサー規則、アウトバウンド規則、インバウンド NAT 規則に対して 4 分から 100 分の範囲でタイムアウトを設定できます。 既定値は 4 分です。 アイドル時間がタイムアウト値よりも長い場合、クライアントとクラウド サービス間の TCP または HTTP セッションが維持されるという保証はありません。 Azure Load Balancer Basic は最大で 30 分というタイムアウト範囲を持ちます。

接続が解除されると、"基になる接続が閉じられました: 維持される必要があった接続が、サーバーによって切断されました" というエラー メッセージをクライアント アプリケーションで受け取ります。

TCP リセットが有効になっていて、それが何らかの理由で失敗した場合、後続のパケットに対してリセットされます。 TCP リセット オプションが有効になっていない場合、パケットは自動的に破棄されます。

一般的な方法として、TCP keep-alive を使用します。 この方法を使用すると、接続が長時間アクティブ状態に維持されます。 詳細については、こちらの .NET の例をご覧ください。 keep-alive を有効にすると、接続のアイドル時間にパケットが送信されます。 keep-alive パケットにより、アイドル タイムアウト値に達することがなくなり、接続が長時間維持されます。

設定は、着信接続に対してのみ有効です。 接続の切断を避けるためには、アイドル タイムアウト設定よりも小さい間隔で、TCP keep-alive を構成するか、アイドル タイムアウト値を大きくします。 これらのシナリオをサポートするために、構成可能なアイドル タイムアウトのサポートを利用できます。

TCP keep-alive は、バッテリーの寿命に制約がないシナリオに適しています。 モバイル アプリケーションでは推奨されません。 モバイル アプリケーションで TCP keep-alive を使用すると、デバイスのバッテリーの消耗を速める可能性があります。

優先順位

さまざまな IP に対して設定されたアイドル タイムアウト値がどのように相互に作用する可能性があるかを考慮することは重要です。

着信

  • 参照するフロントエンド IP のアイドル タイムアウトとは異なるアイドル タイムアウト値が設定された (インバウンド) ロード バランサー規則がある場合、ロード バランサーのフロントエンド IP のアイドル タイムアウトが優先されます。
  • 参照するフロントエンド IP のアイドル タイムアウトとは異なるアイドル タイムアウト値が設定されたインバウンド NAT 規則がある場合、ロード バランサーのフロントエンド IP のアイドル タイムアウトが優先されます。

発信

  • アイドル タイムアウト値が 4 分 (パブリック IP 送信アイドル タイムアウトがロックされている値) とは異なるアウトバウンド規則がある場合、アウトバウンド規則のアイドル タイムアウトが優先されます。
  • NAT ゲートウェイはロード バランサーの送信規則 (および VM に直接割り当てられたパブリック IP アドレス) よりも常に優先されるため、NAT ゲートウェイに割り当てられたアイドル タイムアウト値が使用されます。 (同様に、NAT GW に割り当てられた IP の 4 分というロックされたパブリック IP 送信アイドル タイムアウトは考慮されません。)

制限事項

  • TCP リセットが送信されるのは、ESTABLISHED 状態の TCP 接続時のみです。
  • TCP アイドル タイムアウトは、UDP プロトコルの負荷分散規則には影響しません。
  • ネットワーク仮想アプライアンスがパス内にある場合、内部ロード バランサー HA ポートでは TCP リセットはサポートされません。 これは、ネットワーク仮想アプライアンスからの TCP リセットでアウトバウンド規則を使って回避できます。

次のステップ