...
ウェブホスティングのロゴ

HTTPキープ・アライブ・タイムアウト：サーバー・パフォーマンスのための最適な設定

に焦点を当てている。 HTTPキープアライブタイムアウト スレッドをブロックすることなく接続が再利用されるように、アイドル時間を設定する方法を紹介する。具体的な値を説明し、典型的な落とし穴を示し、以下のような試行錯誤を経た設定を提供する。 nginx, Apacheとオペレーティングシステム。.

中心点

  • バランス短すぎると握手が増え、長すぎるとスレッドがブロックされる。.
  • 価値観ほとんどが5～15秒で、1接続あたり100～500リクエスト。.
  • コーディネーションクライアント、LB、ファイアウォールのタイムアウトを調整する。.
  • 特別なケースWebSocket、SSE、ロングポーリングは別途。.
  • モニタリングオープンソケット、FD、レイテンシを監視する。.

HTTP Keep-Aliveの簡単な説明

でTCPコネクションを保持している。 キープアライブ を開き、複数のリクエストが同じ回線を使うようにする。これにより、TCPとTLSのハンドシェイクを繰り返す手間が省け、また CPU-オーバーヘッドが大幅に削減されます。これは、アイコン、JSON、CSSのような多くの小さなファイルにとって特に有益である。新しい接続が回避されるたびに、コンテキスト・スイッチが減り、カーネル・ルーチンが軽減される。GETの割合が高いベンチマークでは、生成されるSYN/ACKパケットが少なくなり、より多くの計算時間がアプリケーションロジックに流れるため、全体の時間が大幅に短縮されます。.

移動平均のレイテンシーはより滑らかになり、1秒あたりの新規TCP接続数は減少する。これはマジックではなく コネクションの再利用 と常識的な制限を設けている。Keep-Aliveは、高速なレンダリングやキャッシュの代替ではないことが重要です。Keep-Aliveはネットワーク境界での待ち時間を短縮しますが、アプリ自体は効率的に応答し続けなければなりません。この両方が相まって パフォーマンス 顕著だ。.

適切なタイムアウトを理解する

タイムアウトは、非アクティブなコネクションがサーバーによって閉じられるまでの時間を定義する。 クローズ. .あまりに短く設定すると、クライアントが常に新しいTCPコネクションを開くことになり、これは オーバーヘッド が上げられる。あまり長く設定すると、アイドル接続が貴重なワーカーやスレッドを止めてしまう。再利用とリソースの消費のバランスにある。まず大まかに設定し、負荷テストで微調整する。.

また、レスポンスタイムとアイドルウィンドウの関係にも注意を払っている。2回のクリックの間の典型的なユーザー・インタラクションが2-4秒なら、5-15秒のタイムアウトが実際のパターンをカバーするのが普通だ。短いAPIコールは5-10秒、メディアワークロードは10-15秒を容易に許容できる。大げさに言わないことが重要だ。過度に長いタイムアウトが、それ以上のタイムアウトにつながることはめったにない。 スループット, しかし、しばしばブロックにつながる リソース. .オープンソケットの数が増えていることや、FDの数値が高いことから、私はこのことをすぐに察することができる。.

タイムアウトの種類をきれいに分ける

私は厳密に区別しています。 アイドルタイムアウト (Keep-Alive）、, 読み取り/ヘッダータイムアウト (サーバーがリクエストの着信を待つ時間）と 送信/書き込みタイムアウト (クライアントへの送信が許容される期間）。これらのカテゴリは異なるタスクを果たす：

  • アイドルタイムアウト： 非アクティブ接続の再利用とパーキング時間を制御する。.
  • 読み取り/ヘッダータイムアウト： 遅いクライアント(スローロリス)や送信されたヘッダーの半分から保護する。.
  • 送受信タイムアウト： クライアントでの遅い受信のためにサーバーが延々と待たされるのを防ぐ。.

時点では nginx 私はkeepalive_timeoutに加えて、文脈（http/server/location）ごとにheader_timeout/read_timeoutとsend_timeoutを意図的に使っている。新しいバージョンでは、オプションで キープアライブタイム, を使用すると、たとえそれがアクティブなままであっても、接続の最大寿命に上限が設定されます。この場合 アパッチ も使っている。 リクエスト読み取りタイムアウト (mod_reqtimeout）をチェックし タイムアウト (グローバル）とは別に KeepAliveTimeout. .この分離は、実利を伴わない資源の固定化に歯止めをかける重要な要素である。.

実際の推奨値

生産的な環境では、キープアライブのタイムアウトを5〜15秒、1接続あたりのリクエストを100〜500に設定している。この範囲では、接続の再利用率が高く、休止状態の接続数を低く抑えることができます。接続 nginx トラフィックが多い場合、新しいTCP接続が多すぎるようなら、keepalive_timeout 10sを開始値として、keepalive_requestsを200にしている。トラフィックがまばらな場合は、アイドル・トラフィックの氾濫を避けるために、もう一度下げます。.

より深く追求するならば、測定ポイントを用いた明確なチューニング・プロセスが有益であろう。この目的のために、測定からコンフィギュレーション、そしてコントロールまでの道筋を説明した実践的なガイドに、私のガイドラインをまとめた。手っ取り早く始めるには、以下の私の手順を参考にしてほしい。 キープアライブチューニング. .コントロール方法 再利用 と制限を設け、不測の事態を避ける。結局のところ、重要なのは安定した低遅延である。 スループット.

長いタイムアウトのリスク

長いタイムアウトは人工的な接続を維持する オープン となり、 リクエストがないにもかかわらずワーカーをブロックする。これによってソケットが膨れ上がり、ファイルディスクリプタの数が増える。プロセスが限界に達すると、接続を確立するときに accept エラーやキューを拒否するのが見える。メモリは増大し、ガベージ・コレクタやアロケータは追加の時間を費やし、待ち時間は増大する。エラーの場合、クライアントはすでにクローズされたソケットに送信し、暗号化された エラー.

適度な値を設定し、定期的にメトリクスをチェックすることで、これを回避している。低負荷時にアイドル接続が増えすぎたら、タイムアウトを下げる。トラフィックのピーク時に毎秒多くの新規接続が見られたら、慎重に少しずつ増やしていく。このようにして 定員 使用可能で、デッド・コネクションを防ぎます。その結果 ヒント 曲がり角で。.

設定：nginx、Apache、OSレイヤー

私はウェブサーバー・レベルから始めて、タイムアウトと制限を設定します。そして nginx 私は、keepalive_timeoutを5-15s、keepalive_requestsを100-500に設定しています。 event-MPMを使用するApacheでは、KeepAlive On、KeepAliveTimeout 5-15、MaxKeepAliveRequests 100-500を組み合わせています。 そして、予想される負荷に応じてワーカーやスレッドプールを調整します。これにより、アイドル状態のキープアライブが生産的になるのを防ぐことができる。 スロット バインドする。.

オペレーティングシステムレベルで制限とキューを増やした。ulimit -nを少なくとも100,000に設定し、net.core.somaxconnとtcp_max_syn_backlogを調整し、TIME_WAITの処理をチェックする。これによって、カーネルとプロセスに十分な リソース を提供する。最後に、IRQバランシングを介してNICからアプリまでのパスを検証する。これにより、ボトルネックをいち早く認識し レイテンシー 低い。

コンポーネント 指令／設定 推薦 ヒント
nginx keepalive_timeout 5～15秒 ショーター トラフィックが少ない場合は長く、小さなリクエストが多い場合は長く
nginx keepalive_requests 100～500 化合物をリサイクルし、削減する 雨漏り
アパッチ（イベント） KeepAliveTimeout 5～15秒 Event-MPMは、アイドリングを prefork
オペレーティングシステム ulimit -n ≥ 100.000 多くのオープンFD ソケット
オペレーティングシステム net.core.somaxconn 増加 接続拒否が減少 ピーク負荷

リバースプロキシと上流の再利用

私はいつもキープアライブだと思う エンドツーエンド. .エッジサーバーの背後には、リバースプロキシ→アプリサーバーのチェーンがあることが多い。nginxの場合、私は自分の キープ・アライブ・プールズ (upstream keepalive、keepalive_requests、keepalive_timeout)、proxy_http_version 1.1を設定し、„Connection: close “を削除した。これで 内部 ハンドシェイクを行い、アプリのバックエンド（Node.js、Java、PHP-FPM）をオフロードする。Apacheのmod_proxyでは、ホットスポットがプールを独占しないように、バックエンドサーバーへの持続的な接続を維持し、接続先ごとに制限しています。.

私は、クライアント→エッジとエッジ→バックエンドの再利用率を別々に測定している。エッジでの再利用率が高く、バックエンドへの新規接続が多い場合は、アップストリームプールを選択的に増やします。これにより、フロントエンドのタイムアウトをグローバルに増加させることなくスケーリングできる。.

ワーカー、スレッド、OSの制限

私は、ワーカー、イベント、スレッドを希望する値に従ってディメンジョン化するのではなく、次のようにディメンジョン化します。 負荷プロファイル. .そのために、アクティブなリクエスト、アイドル状態のワーカー、イベントループの使用率、コンテキストスイッチを監視する。スレッドがアイドルモードで止まっている場合は、タイムアウトやスレッドあたりの最大アイドル制限を下げる。もしCPUが常に100パーセントなら、アクセプトキュー、IRQ分配、ネットワークスタックをチェックする。FD制限やバックログの小さな修正は、しばしば大きな違いを生む。 効果.

私はヘッドルームを現実的に計画している。スレッドとFDに20～30％の予備があれば、ピーク時の安全が確保できる。やりすぎるとキャッシュがなくなり、無駄が増える。足りなければ、リクエストはキューに入れられたり、期限切れになったりする。の正しい交点は 定員 と効率性により、レイテンシーを低く保ち 安定性.

クライアント、ロードバランサー、ファイアウォールのタイムアウトの調整

行き止まりがないように、全行程に制限時間を設けた。 コネクション が作成される。クライアントはサーバーより早く終了するのが理想的だ。そうでないと、予期せぬリセットを見ることになる。NATとファイアウォールのアイドル値を入れて、コネクションがネットワークパスで失われないようにしている。 消える. .このチューニングは再送を防ぎ、負荷曲線を滑らかにする。.

私は、クライアント→LB→ウェブサーバー→アプリという一連の流れを理解しやすくするために、わかりやすい図を使用している。各リンクのアイドルタイムアウト、リード/ライトタイムアウト、リトライ戦略を文書化している。値を変更した場合は、その隣をチェックします。これによりパスの一貫性が保たれ、再現性のある測定結果が得られる。このような規律を守ることで トラブルシューティング を増加させる。 信頼性.

セキュリティー：スローロリスやアイドル虐待からの保護

寛大すぎるオープン・タイムアウト 攻撃面. .そのため、正当な再利用は許すが、悪意を持ってオープンし続けることは難しくなるような制限を設定している。nginxでは、headerとread_timeout、request_headers_sizeの制限、keepalive_requestsの上限を設定する。Apacheでは、mod_reqtimeoutを使い、IPごとの並列接続を制限する。レート制限と limit_conn を使うことで、多数のアイドル・ソケットの洪水を防ぐこともできる。長時間稼働するエンドポイントについては、ストリームへの攻撃が通常のAPIワーカーを拘束しないように、専用のプールを分けている。.

特殊なケース：ロングポーリング、SSE、WebSockets

長い流れと短い流れがぶつかる タイムアウト で、独自のルールが必要です。私は、これらのエンドポイントを古典的なAPIやアセット・ルートと技術的に分けている。SSEとWebSocketについては、より高いタイムアウト、専用のワーカープール、IPごとのハードリミットを設定している。ハートビートかピンポンで接続を維持し、切断を素早く認識する。こうすることで、ストリームが定期的にスレッドをブロックすることがなくなります。 短いリクエスト.

私は同時接続を制限し、積極的に測定している。高すぎる制限はFDとRAMを消費する。厳しすぎる制限は正当なユーザーを切り捨てます。私は、オープン、アイドル、アクティブ、およびドロップされた接続のクリーンなメトリクスでスイートスポットを見つけます。この分離により、グローバルな 増加 を保護します。 定員.

HTTP/2、多重化、キープアライブ

HTTP/2は 接続, が、タイムアウトに依存することに変わりはない。HTTP/2でもセッションが停止する可能性があるため、アイドルウィンドウは控えめにしている。高いkeepalive_requestsはここではそれほど重要ではないが、リサイクルは依然として有用である。ヘッド・オブ・ラインのブロッキングはフレーム・レベルに移動するので、私は引き続き、フレーム・レベルごとのレイテンシを測定する。 ストリーム. .さらに詳しく比較したい場合は、以下の背景情報をご覧ください。 HTTP/2 マルチプレキシング.

HTTP/2では、接続ごとのアクティブストリーム数に特に注意している。並列ストリームが多すぎると、アプリのスレッドに負荷がかかります。そこで、制限を遅くしたり、サーバーワーカーを増やしたりします。計測、調整、再計測。これにより 応答時間 希少・保存 リソース.

TLS、セッション再開、HTTP/3/QUIC

TLSハンドシェイクは高価だ。私は セッション再開 (チケット/ID)とOCSPステープリングにより、接続が終了した場合の再接続がより速くなる。HTTP/3では、QUICがトランスポート層を引き継ぎます。 QUICアイドルタイムアウト Keep-Aliveに似ているが、UDPベースである。パケットロスがTCPとは異なる影響を与えるため、ここでもウィンドウを適度に保ち、再送を測定する。混合環境（H1/H2/H3）の場合は、標準化された基準値を選択し、各プロトコルごとに微調整を行う。.

モニタリング、メトリクス、負荷テスト

私は直感よりも測定データを信頼し、明確なものから始める。 KPI. .重要なのは、オープン・ソケット、FDの使用率、新規接続/秒、待ち時間（P50/P90/P99）、エラー・レート、再送信です。私は現実的な負荷プロファイルを実行します：ウォームアップ、プラトー、ランプダウン。そして、タイムアウトの変更前と変更後のカーブを比較します。以下はその例である。 サーバーキューイング 待ち時間を明確に解釈するのに役立つ。.

私はすべての調整をタイムスタンプと測定値で記録している。これによって履歴を保存し、相関関係を認識することができる。私は悪影響を真摯に受け止め、素早くロールバックする。小さく、理解しやすいステップを踏むことで、多くの時間を節約できる。最終的に重要なのは、安定した レイテンシー と低い エラー率 負荷がかかっている

測定方法とツールの実際

  • 迅速検査： 私は、wrk、ab、vegetaなどのツールを使って、再利用のクォータ（-H接続：キープアライブかクローズか）、接続数/秒、レイテンシのパーセンタイルをチェックしている。.
  • システムビュー： ss/netstatはステータス（ESTABLISHED、TIME_WAIT）を表示し、lsof -pはFDの消費量を表示し、dmesg/syslogはドロップを表示する。.
  • ウェブサーバーのメトリクス： nginxのstub_status/VTSとApacheのmod_statusは、active/idle/waitingとrequests/sを提供する。ここから、アイドルのピークやワーカーのボトルネックを認識することができる。.
  • 痕跡： 私は分散トレースを使って、待ち時間がネットワーク境界で発生するのか、アプリ内で発生するのかをモニターしている。.

ステップ・バイ・ステップで設定

まず、実際の使用パターンを決定する。 インターバル クリックの間隔、レスポンスの大きさ。タイムアウトは10秒、keepalive_requestsは200、ワーカー数は控えめに。その後、代表的なデータで負荷テストを実施します。1秒あたりの新規接続数とFD利用率を評価します。それから 価値観 を2～3秒刻みで行う。.

負荷がかかってもレイテンシが安定し、FDのピークがリミットに達しないようになるまで、このサイクルを繰り返す。トラフィックが多いときは、明らかに新しいコネクションが減り、ワーカーがまだ空いているときだけタイムアウトを増やします。利用率が低い場合は、アイドリングを避けるためにタイムアウトを減らします。SSEのような特殊なケースでは、より高いリミットの専用サーバーブロックを設定する。この経路は セッティング レート段ボールなし.

Kubernetes、コンテナ、オートスケーリング

コンテナ環境では コンセントラック-制限、ポッドのFD制限、ノードのバックログ。Ingress、サービスメッシュ/プロキシ、アプリ間で一貫したアイドルタイムアウトを確保する。自動スケーリングについては、次の点に注意している。 ドレイン時間ポッドが終了するときは、„Connection: close “で新しいコネクションを拒否し、既存のコネクションにはクリーンなサービスを提供する。長すぎるキープアライブ値は不必要にドレインを増やし、短すぎる値はスケールアウト時にハンドシェイクストームを発生させます。.

グレースフル・シャットダウンとローリング・デプロイメント

また、スイッチを切ることも計画している。ロールアウトの前に、私は徐々にKeep-Aliveを減らすか、ターゲットを絞って送信する。 接続：閉じる のレスポンスで、クライアントが新しいアイドル接続を開けないようにします。nginxでは ワーカーシャットダウンタイムアウト を実行中のリクエストに使用する。Apacheでは、グレースフル・メカニズムを使い、MaxConnectionsPerChild/Workerを監視し、時間の経過とともに自動的にリサイクルされるようにしている。これにより、オープン・ソケットにハード・キャップをかけることなく、デプロイメントをスムーズに保つことができる。.

OSのチューニング：ポート、タイムアウト、カーネルパラメータ

  • 儚い港： ip_local_port_rangeには広い範囲を選択し、短時間の接続が不足しないようにする。.
  • TIME_WAIT： 私はTWのピークを見ている。最近のスタックはこれをうまく処理している。.
  • tcp_keepalive_time： HTTP Keep-Aliveと混同しているわけではない。これは、死んだピアを認識するためのカーネルのメカニズムであり、NATの後ろでは役に立つが、HTTPアイドルウィンドウの代わりにはならない。.
  • バックログとバッファ： somaxconn、tcp_max_syn_backlog、rmem/wmemは、負荷がかかったときにスロットルしないように、適切に調整してください。.

トラブルシューティングチェックリスト

  • keep-aliveにもかかわらず新規接続が多い： タイムアウトが短すぎるか、クライアント/LBが早く切断された。.
  • 高いアイドル値とフルFD： タイムアウトが長すぎるか、ワーカープールがトラフィックパターンに対して大きすぎる。.
  • 長時間のセッションの場合、RST/タイムアウトエラーが発生する： NAT/ファイアウォールのアイドルがパス内で短すぎる、リンク間の非対称性。.
  • ロングテール遅延（P99）： 送信/読み込みのタイムアウト、遅いクライアント、バックログの過充填をチェックする。.
  • エッジの負荷が低いにもかかわらず、バックエンドに過負荷がかかっている： 上流のケージがないか、小さすぎる。.

練習プロファイルと開始値

  • APIファースト（短いコール）： Keep-Alive 5-10秒、keepalive_requests 200-300、タイトなヘッダー/読み取りタイムアウト。.
  • Eコマース（混合）： 8-12秒、200-400、商品画像とキャッシュヒットの場合はもう少し余裕を持たせる。.
  • アセット/CDN的（小さなファイルが多い）： 10-15秒、300-500、強い上流プールと高いFDリミット。.
  • イントラネット/低負荷： 5-8秒、100-200、アイドリングが支配的にならないようにする。.

簡単にまとめると

スレッドをブロックすることなくコネクションが再利用されるように、HTTP keep-aliveタイムアウトを設定した。実際には、5-15秒、1コネクションあたり100-500リクエストで非常に良い結果が得られる。クライアント、ロードバランサー、ファイアウォールのタイムアウトを調整し、WebSocketのような長時間接続を分離し、OSの制限を調整する。クリーンなモニタリング、現実的な負荷テスト、小さなステップで、私は低負荷を達成しています。 遅延時間 そして高い スループット. .この規律を守る者は、既存のハードウェアから測定可能なパフォーマンスを引き出すことができる。.

現在の記事