Standard Load Balancer を使用して、特定の規則のアイドル時の TCP リセットを有効にすることにより、シナリオのより予測可能なアプリケーション動作を作成します。 ロード バランサーの既定の動作では、フローのアイドル タイムアウトに達したときに、警告なしでフローを削除します。 TCP リセットを有効にすると、Load Balancer によりアイドル タイムアウト時に双方向 TCP リセット (TCP リセット パケット) が送信され、接続がタイムアウトして使用できなくなったことが、アプリケーション エンドポイントに通知されます。 エンドポイントは、必要に応じて直ちに新しい接続を確立できます。
TCP リセット
この既定の動作は変更でき、受信 NAT 規則、負荷分散規則、送信規則に基づいて、アイドル タイムアウト時の TCP リセットの送信を有効にできます。 規則ごとに有効にすると、Load Balancer により、双方向 TCP リセット (TCP RST パケット) が、クライアントとサーバーの両方のエンドポイントに対して、一致するすべてのフローのアイドル タイムアウト時に送信されます。
TCP RST パケットを受信するエンドポイントは、対応するソケットを直ちに閉じます。 これにより、エンドポイントの接続の解放の即時通知が提供され、同じ TCP 接続での今後の通信は失敗します。 必要に応じてソケットが閉じられ接続が再確立されるときに、最終的にTCP 接続のタイムアウトまで待つことなく、アプリケーションは接続を削除できます。
多くのシナリオでは、TCP リセットを使用すると、フローのアイドル タイムアウトを更新するために TCP (またはアプリケーション 層) キープアライブを送信する必要性を減らすことができます。
TCPリセットとキーパライブのどちらかを選べます
シナリオに必要なメカニズムを決定するには、以下の基準を用いてください。
- アイドルフローが閉じられたことをエンドポイントに即座に通知したいときにTCPリセットを有効にしてください。そうすれば、アプリケーションが自分のTCPタイムアウトを待つ代わりに接続を整理して再確立できます。
- アイドル状態の継続時間が構成可能なアイドル タイムアウトの範囲を超える場合、または TCP リセットを有効にしているときにアプリケーションが予期しない動作をする場合は、TCP キープアライブを使用してください。 キーパライブはモバイルアプリには推奨されません。なぜなら、デバイスのバッテリーを早く消費してしまうからです。
- 接続がパス上のどこかにプロキシされている場合はアプリケーション層キーパライブを使用してください。なぜなら、プロキシがトランスポート層のキーパライブをリフレッシュするTCP接続を終了させることができるからです。
エンドツーエンドのシナリオ全体を慎重に検討することで、TCPリセットを有効にし、アイドルタイムアウトを調整することの利点を判断できます。 そして、望ましいアプリケーション動作を確保するためにさらに多くのステップが必要かどうかを判断します。
構成可能な TCP アイドル タイムアウト
Azure Load Balancer Standardは、ロードバランサールールとインバウンドNATルールに対して4分から100分のタイムアウト範囲があります。 アウトバウンドルール は4分から120分まで設定可能です。 デフォルトはすべてのルールタイプで4分です。 アイドル時間がタイムアウト値よりも長い場合、クライアントとクラウド サービス間の TCP または HTTP セッションが維持されるという保証はありません。 Azure Load Balancer Basic(廃止)は最大60分のタイムアウト範囲がありました。
接続が解除されると、"基になる接続が閉じられました: 維持される必要があった接続が、サーバーによって切断されました" というエラー メッセージをクライアント アプリケーションで受け取ります。
TCP リセットが有効になっていて、それが何らかの理由で失敗した場合、後続のパケットに対してリセットされます。 TCP リセット オプションが有効になっていない場合、パケットは自動的に破棄されます。
一般的な方法として、TCP keep-alive を使用します。 この方法を使用すると、接続が長時間アクティブ状態に維持されます。 詳細については、こちらの .NET の例をご覧ください。 keep-alive を有効にすると、接続のアイドル時間にパケットが送信されます。 keep-alive パケットにより、アイドル タイムアウト値に達することがなくなり、接続が長時間維持されます。
この節で説明するTCPのkeep-aliveは、インバウンド接続にのみ適用されます。 TCPリセットと設定可能なアイドルタイムアウトは、アウトバウンドルール上で別途サポートされています。 接続の切断を避けるためには、アイドル タイムアウト設定よりも小さい間隔で、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 分に固定されたアウトバウンド アイドル タイムアウトも考慮されません。)
制限事項
これらの制限は、Azure Load BalancerのTCPリセットおよびアイドルタイムアウトに適用されます:
- TCPリセットは、確立状態のTCP接続中のみ送信されます。
- アイドル タイムアウトは UDP のロード バランシング ルールではサポートされていません。
- ネットワーク仮想アプライアンス(NVA)がパス上にある場合、内部ロードバランサーの高可用性(HA)ポートルールではTCPリセットはサポートされません。 回避策として、ネットワーク仮想アプライアンスからTCPリセットしたアウトバウンドルールを使いましょう。
- ユーザー定義ルート(UDR)がトラフィックを内部ロードバランサーに転送する場合、内部ロードバランサーのHAポートルールではTCPアイドルタイムアウトはサポートされません。
次のステップ
- Standard Load Balancer を参照します。
- 送信規則について確認する。
- アイドル タイムアウトでの TCP RST の構成
