タイムアウトが正しく設定されていない場合、失敗が常に明らかではありません。serverTimeoutが30秒に固定されている場合、ロングポーリングリクエストが504を返します。connectTimeoutが長すぎると、ダウンしているバックエンドに接続しようとするクライアントが再試行前に数秒間停止し、再試行のカスケードがトリガーされます。tunnelTimeoutが短すぎると、WebSocket接続が理由なくドロップし、ユーザーがゴースト切断を経験します。
ほとんどのシステムはタイムアウト設定をフラットなリストとして提示します。オペレーターはどの値がHTTPリクエストフェーズを制御し、どれがバックエンドレスポンス時間を制御し、どれがWebSocketトンネルに適用され、どれがFIN待機に影響するかを明確に識別できません。その結果、すべての値が高く設定されすぎて接続リークが発生するか、すべて低く設定されて正当なユーザートラフィックが切断されます。
WebSocketと長命の接続はこの問題が最も顕著になる場所です。HTTP keepaliveは30〜120秒の範囲で意味がありますが、WebSocketセッションは数時間オープンのままである可能性があります。tunnelTimeoutが独立して管理されていなければ、リアルタイムアプリケーションは通常のHTTPアイドル動作に制約されます。
TCPのティアダウン動作も重要です。clientFINとserverFINが制御されていない場合、半閉じた接続がファイルディスクリプタプールを使い果たす可能性があります。パブリックに面したサービスではこれがスロークローズ攻撃パターンと組み合わさってリソース枯渇問題になります。
TR7 タイムアウトプロファイルは9つの独立したタイムアウト軸を単一の名前付きプロファイルに収集し、すべてのプールがトラフィックタイプに応じた正しい待機、ドレイン、接続クローズ動作を適用することを保証します。
TR7はタイムアウトをプールにわたって個別の設定を散在させるのではなく、再利用可能な名前付きプロファイルを通じて管理します。
オペレーターはプロファイル名を定義し、その中に9つのタイムアウト値をグループ化します。同じプロファイルを複数のプールにバインドでき、Web、API、またはWebSocketプールに一貫した共有タイムアウト標準を提供します。
HTTP request、keepalive、connect、server、client、queue、tunnel、clientFIN、serverFINはそれぞれ独立したフィールドとして管理されます。すべてのフィールドは独自のトラフィックセマンティクスに従って調整され、あるタイムアウト値が別のものの代替として使用されることはありません。
WebSocketやHTTP CONNECTなどの長命の接続はtunnelTimeoutで別々に管理されます。チャット、ライブストリーミング、イベントストリームの接続はHTTPアイドルタイマーに制約されず、不必要にクローズされません。
TCP閉じる信号後に接続が保持される時間はクライアントとサーバーサイドで個別に設定されます。これによりFIN-WAIT式のリソース消費リスクが軽減され、パブリックに面したサービスでより積極的なドレインポリシーが可能になります。
タイムアウトプロファイルにより、オペレーターはすべてのトラフィックタイプに合わせて9つの独立したフィールドにわたって接続の生存期間と待機動作を精密に調整できます。
httpKeepaliveTimeoutはHTTP/1.1 keep-alive接続がリクエスト間でどのくらいオープンを維持するかを定義します。デフォルトは120秒です。高すぎるとアイドル接続がリソースを浪費し、低すぎると再接続コストが増加します。バックエンドのアイドル接続バジェットに合わせて調整されます。
httpRequestTimeoutはクライアントがリクエストラインとヘッダーを完了するために許可される時間です。デフォルトは30秒です。非常にゆっくりヘッダーを送信するクライアントはこの閾値で切断できます。パブリックに面したサービスでのslowlorisスタイルのパターンに対する重要な防御ポイントです。
connectTimeoutはTR7がバックエンドへのTCP接続を確立する際の待機時間を定義します。デフォルトは20秒です。長すぎると、ダウンまたは到達不能なバックエンドがクライアントを不必要に停止させます。迅速な障害レスポンスを必要とするAPIシナリオではより低いconnectTimeoutが有利です。
serverTimeoutはバックエンドがレスポンスを生成するために許可される時間です。デフォルトは90秒です。高速APIでは低く設定でき、重いレポーティング、ロングポーリング、スロークエリのエンドポイントでは上げられます。誤って低い値を設定すると、動作しているが遅いリクエストが504を受け取ります。
clientTimeoutはクライアントからデータが届くまでの待機時間です。リクエストボディのアップロード、パイプライン処理されたリクエスト、スロークライアントシナリオに適用されます。デフォルトは90秒です。大きなファイルのアップロードでは上げられ、パブリックAPIでのスロークライアントリスクを軽減するために下げられます。
queueTimeoutは接続キャパシティが満杯の場合にプールキューでリクエストが待機する時間を定義します。デフォルトは60秒です。超過するとリクエストはエラーで返され、クライアントが無限に保留されません。この値はmaxconn制限とアプリケーションSLAと共に考慮すべきです。
tunnelTimeoutはWebSocketとHTTP CONNECTトンネル接続のアイドル時間を定義します。デフォルトは120秒です；リアルタイムアプリケーションではこれを3600秒以上に上げられます。このタイムアウトはHTTP keepaliveから独立しているため、長命の接続がWebトラフィック設定に制約されません。チャット、ライブ通知、ストリームアプリケーションに重要です。
clientFINはクライアントからのFIN信号後に接続が保持される時間を設定します。デフォルトは3秒です。低い値により半閉じた接続がファイルディスクリプタを消費することを防ぎます。パブリックに面したサービスでFIN-WAITのリソース圧力を軽減するために特に重要です。
serverFINはバックエンドからのFIN信号後の接続動作を制限します。デフォルトは6秒です。serverFINをclientFINより高く保つことでバックエンドシャットダウン中のグレースフルドレインのより多くの許容度が得られます。この設定はトラフィックの多いバックエンドプールでの接続クローズ品質に直接影響します。
プロファイル-プールバインディングモデルにより、同じタイムアウト標準を複数のプールで共有できます。すべてのWebプールがwebプロファイルに、APIプールがapiプロファイルに、WebSocketプールがwebsocketプロファイルに向けられます。プロファイルへの単一の変更によりバインドされたすべてのプールのタイムアウト動作が集中的に更新され、設定の重複とドリフトが削減されます。
9つのプロファイルフィールドは対応するランタイムタイムアウトディレクティブ — connect、server、client、queue、tunnel、http-keep-alive、http-request、client-fin、server-fin — に変換されます。オペレーターは個々のディレクティブを書く代わりにプロファイルを通じて値を管理し、GUIとランタイム動作間の一貫したブリッジを作成します。
ヘルスチェックのタイミングは独自のタイムアウトフィールドで管理され、トラフィックタイムアウトプロファイルから独立しています。この分離は重要です：プローブのレイテンシと本番トラフィックの待機動作が混在しません。バックエンドのヘルスチェックは短く保ちながら、実際のエンドポイントのserverTimeoutを長くでき、サービスヘルスとユーザートラフィックを異なるセマンティクスで監視できます。
タイムアウトプロファイルはその値の範囲、デフォルト、小数サポート、トンネルセマンティクス、FINバランス、プールバインディングモデルと共に運用されます。
タイムアウトフィールドは0から60,000秒まで設定可能です。この範囲はサブ秒の防御設定から16時間を超えるセッションまでを網羅し、ロングポールと永続接続の要件に十分な柔軟性を提供します。
httpKeepaliveTimeoutは小数値を受け入れます。0.5秒などの値により、より精密なアイドルkeepalive動作が定義できます。残りの8つのタイムアウトフィールドは整数秒として扱われます。
デフォルト値はほとんどのWebおよびAPIトラフィックに適した安全な出発点を提供します。httpKeepaliveTimeout 120、httpRequestTimeout 30、connectTimeout 20、serverTimeout 90、clientTimeout 90、queueTimeout 60、tunnelTimeout 120、clientFIN 3、serverFIN 6秒が適切なベースラインです。特殊なトラフィックタイプに対しては、これらの値をプロファイルごとに調整すべきです。
tunnelTimeoutはWebSocketやHTTP CONNECTのようなトンネル接続に適用されます。HTTPリクエストまたはkeepaliveタイムアウトと同じではありません。長命の接続で低すぎると設定すると切断の問題が生じます。
デフォルトモデルでは、serverFINはclientFINより許容度が高いです。これによりバックエンドシャットダウン中のグレースフルドレインのためのより多くの余地が生まれます。パブリックに面したサービスでは、両方の値をより積極的に設定して半閉じた接続のリソース消費を削減できます。
TR7は組み込みのプリセットを課しません。オペレーターは自分のシナリオに合わせた名前付きプロファイルを作成します — web、api、websocket、longpoll、uploadなどの名前が組織の標準に合わせて定義できます。サービスごとの個別オーバーライドよりも適切なプロファイルにプールをバインドすることが推奨されます。
Webトラフィック用にデフォルト値に近いwebプロファイルを作成できます。Keepaliveがユーザーエクスペリエンスを維持しながら、requestとFINタイムアウト値がスローまたは半閉じた接続を制限します。同じプロファイルを複数のWebプールにバインドできます。
チャットアプリケーションはWebSocket接続が頻繁にドロップせずにオープンを維持する必要があります。websocketプロファイル内でtunnelTimeoutを3600秒などの長い値に設定し、他のHTTPタイムアウトはデフォルトに保てます。長命の接続はHTTP keepaliveウィンドウに制約されなくなります。
ロングポーリングエンドポイントはバックエンドがレスポンスするまで数分間待機することがあります。longpollプロファイルでserverTimeoutを300秒に設定することで5分の待機ウィンドウをサポートします。これがないと標準のAPIタイムアウトがリクエストを早期に切断します。
大きなPOSTボディやファイルアップロードトラフィック中はクライアントからのデータ着信が遅い場合があります。uploadプロファイルでclientTimeoutと必要に応じてhttpRequestTimeoutを600秒に上げられます。これにより正当だが遅いアップロード操作が切断されることを防ぎます。
バンキングAPIが素早いバックエンドレスポンスを期待する場合、connectTimeout 2秒、serverTimeout 5秒のような厳しい値を使用できます。スローまたはダウンしているバックエンドがクライアントを長時間停止させません。再試行とフェイルオーバー動作がより早くトリガーされます。
防御プロファイルはhttpRequestTimeout 5秒、clientFIN/serverFIN 1秒のような低い値を使用できます。この構造はスローヘッダー配信と半閉じた接続消費パターンを制限します。パブリックに面したサービスの攻撃面を縮小します。
Web、API、WebSocket、アップロードプールのための9軸の名前付きタイムアウトプロファイル。お客様自身の設定でのライブセットアップをご案内します。