コンテンツにスキップ 
HTTP Keep-Alive はハンドシェイクを減らし、接続を開いたままにして、複数のリクエストを同じソケットで実行できるようにし、 サーバー負荷 減少します。ターゲットを絞ったチューニングにより、タイムアウト、制限、ワーカーを制御し、 遅延時間 コードを変更することなくスループットを向上させます。.
中心点
- 接続の再利用 CPUのオーバーヘッドとハンドシェイクを削減します。.
- ショート タイムアウト アイドル接続を防止します。.
- クリーン 限界 keepalive_requests の負荷を安定させる。.
- HTTP/2 そしてHTTP/3はさらに強力に統合されます。.
- 現実的な 負荷テスト 設定を保存します。.
HTTP Keep-Alive の仕組み
各リソースごとに新しい TCP 接続を開く代わりに、既存の接続を再利用することで、 握手 およびラウンドトリップ。これにより、TCP および TLS セットアップを常時実行する必要がなく、パイプラインが迅速に応答するため、待ち時間が短縮されます。クライアントはヘッダーによって接続が維持されていることを認識し、同じ接続を介して、連続して、またはマルチプレキシング（HTTP/2/3 の場合）を使用して、さらにリクエストを送信します。 ソケット. サーバーは、キープアライブタイムアウトによってアイドル状態を管理し、長期間リクエストがない場合は接続を切断します。この動作により、アセットの多いページの表示速度が大幅に向上し、接続確立回数が減少するため、CPU の負荷が軽減されます。.
接続の再利用：サーバーの負荷への影響
回避された再接続は、それぞれ CPU時間 カーネルおよび TLS 作業のために、これはモニタリングではより滑らかな負荷曲線として確認できます。データによると、多くの小さなリクエストが発生する場合、既存のソケットを再利用することでスループットを最大 50% 向上できることがわかっています。 多くの GET リクエストを含むベンチマークでは、ハンドシェイクやコンテキストの切り替えが少なくなるため、合計時間が 3 分の 1 に短縮される場合もあります。また、SYN/ACK パケットの発生頻度が減り、サーバーが実際のアプリケーションロジックにより多くのリソースを割けるようになるため、ネットワーク負荷も軽減されます。この相乗効果により、応答が高速化され、より安定した 応答時間 負荷がかかっている
リスク：タイムアウトが長すぎる、接続が開いたままになる
キープアライブタイムアウトが長すぎると、接続がアイドル状態になり、ブロックされます。 労働者 またはスレッドが、リクエストがないにもかかわらず生成されます。トラフィックが多い場合、オープンソケットは増加し、ファイルディスクリプタの制限に達して、メモリ消費量を増加させます。 さらに、不適切なクライアントタイムアウトは「デッド」接続を発生させ、すでに閉じられたソケットにリクエストを送信してエラーメッセージを生成します。イングレスおよび NAT ゲートウェイは、サーバーよりも早くアイドル回線を閉じる場合があり、それが散発的なリセットにつながります。そのため、私はアイドル時間を意図的に制限し、明確な制限を設定し、 反対側 （クライアント、プロキシ）を監視します。.
HTTP Keep-Alive 対 TCP Keepalive
私は、HTTP Keep-Alive（アプリケーションレベルでの持続的な接続）と TCP メカニズム「keepalive」を厳密に区別しています。HTTP Keep-Alive は、同じソケットを介してさらに HTTP リクエストを実行するかどうかを制御します。一方、TCP Keepalive は、大きな間隔でプローブパケットを送信して、「デッド」な相手側を検出します。 パフォーマンスのチューニングでは、主に HTTP Keep-Alive が重要になります。TCP Keepalive は、長いアイドル時間（エッジ接続や、強力なファイアウォールを備えたエンタープライズネットワークなど）に的を絞って使用しますが、不必要なネットワーク負荷が発生しないように、間隔は控えめに設定しています。.
特殊なケース：ロングポーリング、SSE、WebSockets
長寿命ストリーム（サーバー送信イベント）、ロングポーリング、または WebSocket は、短いアイドルタイムアウトと衝突します。私はこれらのエンドポイントを標準 API またはアセットルートから切り離し、より長いタイムアウトと専用のワーカープールを割り当て、IP あたりの同時ストリーム数を制限しています。これにより、長寿命のストリームが従来の短いリクエストのリソースをブロックすることを防ぎます。 SSE および WebSocket については、すべてのタイムアウトをグローバルに延長するよりも、明確な制限、読み取り/書き込みタイムアウト、および明確なハートビートまたはピンポン間隔を設定することをお勧めします。.
Webサーバーの主要なキープアライブパラメータ
私はほとんどの場合、キープアライブを有効にし、短いアイドルタイムアウトを設定し、接続ごとのリクエスト数を制限してリソースを節約しています。 リサイクルする. さらに、アイドル状態の接続がプロセスを過度に占有しないように、ワーカー/スレッドプールを調整しています。以下の表は、私が実際に頻繁に使用する典型的なディレクティブ、目的、および初期値を示しています。値はアプリケーションやレイテンシプロファイルによって異なりますが、最初のテストには十分な基礎となります。その後、タイムアウト、制限、および スレッド 実際の測定データに基づいて。.
| サーバー/コンポーネント | 指令 | 目的 | 開始値 |
|---|---|---|---|
| アパッチ | キープアライブ | 持続的な接続を有効にする | オン |
| アパッチ | KeepAliveTimeout | 接続終了までのアイドル時間 | 5～15秒 |
| アパッチ | MaxKeepAliveRequests | 接続あたりの最大リクエスト数 | 100～500 |
| Nginx | keepalive_timeout | 接続終了までのアイドル時間 | 5～15秒 |
| Nginx | keepalive_requests | 接続あたりの最大リクエスト数 | 100 |
| ハプロキシー | オプション http-keep-alive | 持続的な接続を許可する | アクティブ |
| カーネル/OS | somaxconn、tcp_max_syn_backlog | 接続の待ち行列 | トラフィックに合わせて調整 |
| カーネル/OS | FD制限 (ulimit -n) | 開いているファイル/ソケット | >= 100k（高トラフィックの場合） |
Apache: スタート値、MPM、ワーカー制御
高度に並列化されたサイトの場合、Apache では MPM を採用しています。 イベント, これは、古い prefork よりもアイドル状態のキープアライブ接続を効率的に処理するためです。実際には、クライアントがリソースをバンドルでき、ワーカーを長時間ブロックしないように、KeepAliveTimeout を 5～15 秒に設定することがよくあります。 MaxKeepAliveRequests を 100～500 に設定することで、適度なリサイクルを強制し、リークを防止し、負荷のピークを平準化しています。一般的なタイムアウトは 120～150 秒に短縮し、スタックしたリクエストがプロセスを拘束しないようにしています。スレッドとプロセスについてさらに詳しく知りたい方は、以下の重要な情報をご覧ください。 スレッドプール設定 さまざまなウェブサーバー用。.
Nginx と HAProxy：実用的なパターンとアンチパターン
リバースプロキシでは、2つのエラーが頻繁に発生します。1つは、「セキュリティ上の理由」からキープアライブがグローバルに無効化されている（ハンドシェイクの負荷が大幅に増加する）、もう1つは、トラフィックが少ないにもかかわらずアイドルタイムアウトが長く設定されている（リソースを消費する）ことです。 私は、クライアントが接続を切断した場合でもプロキシが接続を維持できるように、フロントエンドのタイムアウトをバックエンドのタイムアウトよりも短く設定しています。また、リクエストの順序とアイドル状態はプロファイルによって異なるため、サービスクラス（静的アセット対 API）ごとにアップストリームプールを分離しています。また、正しい コンテンツの長さ/転送エンコーディング-処理：長さの指定が間違っていると、接続の再利用ができなくなって「connection: close」が発生し、不要な再接続が繰り返される結果になる。.
Nginx と HAProxy：アップストリームプールを正しく使用する方法
Nginx を使用すると、バックエンドへのアップストリーム接続を開いたままにし、 keepalive プールサイズを調整します。これにより、アプリケーションサーバーへの TLS セットアップが削減され、CPU 負荷が大幅に軽減されます。ログで、開いているアップストリームソケットの数、再利用率、レイテンシの分布を監視し、プールサイズを目的を持って増減しています。 カーネル側では、FD 制限を増やし、somaxconn および tcp_max_syn_backlog を調整して、キューがオーバーフローしないようにしています。これにより、プロキシは高い並列性でも応答性を維持し、トラフィックを均等に分散することができます。 バックエンド.
オーバーヘッドを削減する TLS および QUIC の最適化
Keep-Alive の効果を最大限に発揮させるため、TLS レイヤーを最適化しています。TLS 1.3 と再開 (セッションチケット) によりハンドシェイクが短縮され、OCSP スタッピングにより証明書チェックが短縮され、スリムな証明書チェーンによりバイト数と CPU が削減されます。 0‑RTT は、リプレイのリスクを回避するため、反復可能なリクエストにのみ慎重に使用しています。HTTP/3 (QUIC) では、これは idle_timeout 決定的な要素：高すぎるとストレージのコストがかかり、低すぎるとストリームが中断します。また、以下の点についてもテストしています。 初期輻輳ウィンドウ 特に長距離では、低温接続における増幅限界が影響します。.
HTTP/2、HTTP/3、およびマルチプレクシングを効果的に活用する
HTTP/2 および HTTP/3 は、1 つの接続で多くのリクエストをまとめ、以下を排除します。 ヘッド・オブ・ラインアプリケーションレベルでのブロッキング。これにより、接続数が減少するため、キープアライブの効果がさらに高まります。私の設定では、重要な資産が最初に実行されるように、優先順位とフロー制御を構成するようにしています。また、複数のホスト名が同じ証明書を使用している場合など、接続の統合が有効に機能しているかどうかを確認しています。 HTTP/3とHTTP/2の比較 グローバルユーザープロファイルに適したプロトコルの選択を支援します。.
クライアントとアプリスタック：プールを正しく設定する
クライアントとアプリ側も再利用を決定します。Node.js では、HTTP/HTTPS に対して keepAlive-エージェントは、ホストごとにソケット数が制限されています。Java では、HttpClient/OkHttp で適切なプールサイズとアイドルタイムアウトを設定しています。Go では、 MaxIdleConns そして MaxIdleConnsPerHost gRPCクライアントは長時間の接続の恩恵を受けますが、私はping間隔を定義し、 キープアライブタイムアウト プロキシがフラッドしないようにしてください。重要なのは一貫性です。クライアントの再接続が過度に頻繁に行われると、サーバーの最適化はすべて台無しになります。.
負荷試験と測定戦略
タイムアウトのブラインドターンは、安定した結果をもたらすことはほとんどありません。 結果, そのため、私は体系的に測定を行っています。多くの小さなファイル、現実的な並列化度、地理的に分散したレイテンシを用いて、典型的なユーザーパスをシミュレートします。その間、再利用率、平均接続時間、エラーコード、およびオープンソケットとワーカー数の関係をログに記録します。 その後、KeepAliveTimeout を少しずつ変更し、応答時間と CPU 使用率の曲線を比較します。複数の実行でメトリックが安定している場合にのみ、その値を 製造.
観測可能性：重要な指標
私は具体的な指標を監視しています。1 秒あたりの新規接続数、再利用/再構築の比率、1 秒あたりの TLS ハンドシェイク数、オープンソケットとその滞留時間、レイテンシの 95/99 パーセンタイル、ステータスコードの分布（408/499 を含む）、および TIME_WAIT/FIN_WAIT2 などのカーネル状態です。 ハンドシェイクのピーク、499 の増加、TIME_WAIT バケットの増加は、多くの場合、アイドルタイムアウトが短すぎる、またはプールが小さすぎることを示しています。適切に実装されたロジックにより、チューニングの再現性が確保され、最適化が単なるプラセボ効果に終わってしまうことを防ぎます。.
クライアントとサーバー間のタイムアウト調整
クライアントは、サーバーよりも少し早くアイドル接続を切断して、「デッド」な接続が発生しないようにすべきです。„ ソケット 発生します。そのため、フロントエンドアプリでは、Web サーバーよりも低い HTTP クライアントタイムアウトを設定し、その設定を文書化しています。ロードバランサーについても同様です。そのアイドルタイムアウトは、サーバーのアイドルタイムアウトを下回ってはなりません。また、ネットワークパスで接続が失われないように、NAT およびファイアウォールのアイドル値も監視しています。この適切な連携により、散発的なリセットが防止され、安定性が確保されます。 再送信.
負荷下での回復力と安全性
持続的な接続は、Slowloris などの攻撃の誘因となってはなりません。私は、ヘッダー/ボディの読み取りタイムアウトを短く設定し、ヘッダーサイズを制限し、IP あたりの同時接続数を制限し、アップストリームでバックプレッシャーを確保しています。プロトコルエラーが発生した場合は、接続を確実に閉じる（開いたままにしない）ことで、リクエストの密輸を防止しています。さらに、適切な grace-閉じる際のタイムアウトを設定し、サーバーが開いている応答を適切に終了させ、接続が永遠に lingering-状態を維持する。.
ホスティングの要素とアーキテクチャ
強力なCPU、高速NIC、そして十分な RAM ハンドシェイク、コンテキストの切り替え、暗号化を高速化し、キープアライブチューニングを最大限に活用します。アプリの前にリバースプロキシを設置することで、オフロードが簡素化され、タイムアウトが集中化され、バックエンドへの再利用率が向上します。TLS、キャッシュ、ルーティングをより細かく制御するために、私は明確な リバースプロキシアーキテクチャ. 重要なのは、インフラが高度な並列処理に対応できるよう、ulimit -n や accept-Queues などの制限を早めに解除することだよ。明確な可観測性があれば、ボトルネックを素早く見つけて、 限界 しっかりと締めてください。.
デプロイ、ドレイン、OS の詳細
ローリングデプロイでは、キープアライブ接続を制御して終了させます。新しいリクエストは受け付けず、既存のものは短時間で処理（ドレイン）します。これにより、接続の切断や 5xx のピークを回避します。OS レベルでは、エフェメラルポートの範囲を監視しています。, somaxconn, 、SYNバックログ、および tcp_fin_timeout, 、TIME_WAIT の積極的な再利用などの時代遅れの調整手法を使用せずに。. SO_REUSEPORT Accept の競合を減らすために、複数のワーカープロセスに分散させています。目標は、カーネルキューに滞留することなく、多くの短命な接続を安定して処理することです。.
要約：パフォーマンス向上のためのチューニング
HTTP Keep-Alive を一貫して使用すると、接続の確立回数が減り、 CPU負荷 そして、明らかに高速化された応答。短いアイドルタイムアウト、接続ごとの明確な制限、そして十分なサイズのワーカーにより、アイドルソケットを抑制します。HTTP/2/3、アップストリームプール、および調整された OS 制限により、安定性を損なうことなく並列性を拡張します。 現実的な負荷テストにより、設定が実際に有効であるかどうか、そして次の改善点がある箇所が明らかになります。これらの構成要素を組み合わせることで、スループットが向上し、レイテンシが低く抑えられ、既存の リソース 最大限に。.
