Pleskウェブサーバ

HTTPコネクションの再利用とkeep-aliveの最適化：ウェブサーバーのパフォーマンス向上

どのように HTTPコネクションの再利用 と構造化されたキープアライブ・チューニングにより、TCPとTLSのハンドシェイクによるオーバーヘッドを削減し、ページがより速く応答し、サーバーがより少ない処理で済むようにします。適切なタイムアウト、制限、プロトコルの機能によって、私は以下のことを削減する。 レイテンシー, 負荷のピークを平準化し、スループットを大幅に向上させる。.

中心点

キープアライブ 握手を減らし、握手を短くする ロード時間.
タイムアウト 制限を守る リソース 効率的だ。
HTTP/2 とHTTP/3強化 再利用 多重化によって。.
クライアント・プーリング バックエンドを下げるレイテンシー.
モニタリング チューニングを成功に導く 測定可能.

HTTPコネクションの再利用とは？

私はこうしている。 コネクションの再利用, を使用すると、1つのTCPコネクションで複数のHTTPリクエストを送信できるため、高価な再接続を避けることができます。新しい接続ごとに3つのTCPパケットとTLSハンドシェイクのコストがかかるため、時間とコストが節約できます。 CPU を食べる。回線が開いたままであれば、後続のリクエストは同じソケットで実行され、ラウンドトリップを節約できる。CSS、JS、画像などの小さなリソースを多く含むサイトでは、オブジェクトごとの待ち時間が短縮されるため、特にメリットがあります。HTTP/1.1では、“Connection: keep-alive ”ヘッダが再利用のシグナルとなり、待ち時間が著しく短縮され、スループットが安定します。.

Keep-Aliveがウェブサーバーのパフォーマンスを向上させる理由

頼りにしているのは キープアライブ-カーネルとTLSのオーバーヘッドを削減し、1秒あたりより多くのペイロードが回線を通過できるようになるからだ。テストでは、ハンドシェイクが不要になるため、実効スループットが最大50%向上することがよくある。 CPU コンテキスト・スイッチの回数が減る。同時に、ブラウザが追加オブジェクトを素早く再読み込みできるため、ページの反応がより速くなります。短いタイムアウトでアイドル状態のコネクションがRAMを占有するのを防ぎ、keepalive_requestsの制限で安定性を確保しています。このようにして、アクティブなソケットの数をグリーンゾーンに保ち、ピーク負荷時のボトルネックを回避している。.

サーバー側の設定：Nginx、Apache、プロキシ

私はこう言った。 Nginx そのため、タイムアウトはRAMを節約するのに十分短く、ブラウザが複数のオブジェクトを連続してフェッチするには十分な長さになっている。典型的なウェブサイトの場合、私は60-120秒のアイドルタイムアウトと、実際のトラフィックパターンと比較した1接続あたり50-200リクエストでうまくいっている。例として、私がどのように開始し、その後微調整しているかを示します。リンクからキープアライブタイムアウトの設定オープン・ファイル・ディスクリプタやアクセプト・キューなどの詳細について詳しく説明する。リバースプロキシについては、proxy_http_version 1.1を有効にして、keep-aliveがきれいに渡され、バックエンドが再利用の恩恵を受けられるようにする。.

# Nginx (フロントエンド / リバースプロキシ)
keepalive_timeout 65s；
keepalive_requests 100；

# アップストリームへのプロキシ
proxy_http_version 1.1；
proxy_set_header 接続 ""；

# Apache (例)
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5

TLS、HTTP/2、HTTP/3：再利用を強化するプロトコル

コンバイン キープアライブ TLS 1.3、セッション再開、OCSPステープリングにより、接続がより迅速に利用できるようになりました。HTTP/2では、1つの接続に多くのストリームをバンドルすることで、アプリケーション・レベルでのヘッド・オブ・ラインの遅延をなくしている。この効果は 多重化, なぜなら、ブラウザは新しいソケットを作成することなく、並行してリソースをリクエストするからである。根拠のある分類については、以下を参照されたい。 HTTP/2 マルチプレキシング, これはHTTP/1.1との違いを明確に示しています。QUIC付きHTTP/3はまた、idempotentリクエストに対して0-RTTスタートを提供し、パケットロスが発生した場合の反応も明らかに速い。.

クライアント側の最適化：Node.jsとPython

起動させる キープアライブ これにより、API やバックエンドの呼び出しに必要なコネクションの確立が少なくなります。Node.jsでは、https.agentとコネクションプーリングを使用しています。Pythonのrequests.Session()はシンプルな方法で同じことを行い、サービスをより安定させます。これはトランスポートパスを短く保ち、双方向のラウンドトリップを節約します。その結果、レスポンスタイムがより安定し サーバー負荷.

// Node.js
const https = require('https')；
const httpsAgent = new https.Agent({
  keepAlive: true、
  keepAliveMsecs: 60000、
  maxSockets: 50
});

// 使用法：httpsAgent を使用した fetch / axios / ネイティブ https

# Python
インポート リクエスト
セッション = requests.Session() # 再利用とプーリング
r = session.get('https://api.example.com/data') #少ないハンドシェイク

代表的な数値とその効果

私は保守的なものから始める 価値観 そして、接続がアイドル状態でハングアップしがちか、あるいは接続が早く終了しがちかを測定します。負荷のピークが予想される場合は、タイムアウトを短くして、ブラウザに常に再接続を強いることなく、RAMの空きを保つようにしている。並列性が高い場合は、受け入れのボトルネックを避けるために、ファイル記述子の最大値を十分に高く設定する。以下の表は、私がどのように始め、どのような設定を行っているかを簡単にまとめたものだ。その後、段階を追って微調整し、次のようなメトリクスを注意深く観察する。訂正.

パラメータ	Nginx	アパッチ	標準的な開始値	効果
アイドルタイムアウト	keepalive_timeout	KeepAliveTimeout	60～120秒	再利用とRAM消費を均等化
接続ごとのリクエスト数	keepalive_requests	MaxKeepAliveRequests	50-200	ソケットあたりの利用率を安定させる
プロキシバージョン	プロキシ	–	1.1	キープアライブを有効にする
オープンディスクリプタ	worker_rlimit_nofile	ulimit -n	>= 65535	ソケット不足を防ぐ
受付キュー	net.core.somaxconn	リッスン・バックログ	512-4096	ピーク時の落下を低減

モニタリングと負荷テスト：重要なメトリクス

私の評価 再利用-wrk または ApacheBench を使って成功したことを記録し、ログやシステムメトリックスと関連付ける。オープンソケット、フリーソケット、保留中のリクエスト、ボトルネックを示すエラーコードが重要です。アイドル状態のコネクションが増えたら、タイムアウトを減らすか、keepalive_requestsを適度に減らす。接続が頻繁に切断される場合は、制限を増やしたり、バックエンドの応答が遅すぎないかチェックしたりする。こうすることで、待ち時間、スループット、コネクションの数がどの程度になるかを素早く見つけることができる。 リソース 相性がいい。.

WordPressの実践：少ないリクエスト、より速いファーストペイント

HTTPリクエストを減らすには CSS/JS アイコンをSVGスプライトとして使用し、フォントをローカルに配信します。ブラウザのキャッシュと組み合わせることで、再訪問時のネットワーク転送の回数を大幅に減らすことができます。ブラウザが必要とする新しいソケットの数が減るため、再利用の幅が広がります。より深く掘り下げたい場合は、実践的な手順をキープ・アライブ・チューニング・ガイド, にタイムアウトからワーカーのセットアップまでのチューニングパスが説明されています。最終的に重要なのは、ページのロードが明らかに速くなり サーバー負荷 は予測可能なままだ。.

スケーリングとシステムリソース

私はチェックする CPU-プロファイル、ワーカーあたりのメモリフットプリント、制限を増やす前のネットワークカード。より高い並列性は、各レイヤーに十分なバッファとディスクリプタがある場合にのみ有効です。NUMAアフィニティ、IRQディストリビューション、高速TLS実装は、さらなる予備を提供する。コンテナでは、オープンファイルの制限とホストのハード制限に注意を払う。こうすることで、トラフィックの増大ですぐに顕著になり、貴重なリソースを浪費するボトルネックを回避している。 パフォーマンス 費用。.

エラーパターンとトラブルシューティング

私は知っている エラー TIME_WAITソケットが多すぎたり、502/504が増えたり、RPSが突然変わったりといったパターンに気づくことが多い。それから、バックエンドがkeep-aliveを受け入れるかどうか、プロキシヘッダーが正しく設定されているかどうかをチェックする。不正確なアイドルタイムアウトは、しばしば個々のホップで連鎖反応を引き起こす。TLSの問題はhandshake_timeのスパイクとして現れるが、セッションの再開や1.3の最適化によって緩和される。ターゲットを絞った調整によって、私はエッジからアプリサーバーまでのチェーンを安定させ、次のように維持している。 応答時間 信頼できる。.

クロスシフトのタイムアウトを一定に保つ

私は調整します アイドルとアクティビティのタイムアウト CDN/WAF、ロードバランサー、リバースプロキシ、アプリケーションのすべてのホップにわたって。短すぎるオリジンのタイムアウトは、ブラウザがまだロードしている間に接続を切断する。長すぎるエッジのタイムアウトは、アイドル状態のソケットでRAMをいっぱいにする。そのため、私はカスケード接続を計画している：エッジを少し より短い ブラウザがアイドル、プロキシが中央、バックエンドが最長タイムアウト。こうすることで、RSTを回避し、高価なTLS接続が無意味に切断されるのを防ぐことができる。.

# Nginx: 正確なタイムアウトとアップストリームの再利用
client_header_timeout 10s；
client_body_timeout 30s；
send_timeout 15s；

proxy_read_timeout 60s；
proxy_send_timeout 60s；
proxy_socket_keepalive on; # デッドピアの検出を高速化する。

アップストリーム backend_pool {
  サーバー app1:8080；
  サーバー app2:8080；
  keepalive 64; # 上流のアイドル接続をキャッシュする
  keepalive_timeout 60s; # (アップストリームタイムアウトのあるNginxバージョンから)
  keepalive_requests 1000；
}

私は次のように区別している。 HTTPキープアライブ から TCP-キープアライブ (so_keepalive)を使っている。後者は、HTTPの再利用を不必要に終了させることなく、ハングしているリモート・ステーションを認識するために、特にプロキシ・ソケットで使っている。.

HTTP/2とHTTP/3の微調整：多重化を正しく使う

私はHTTP/2を設定し、ストリームがサーバー上でヘッド・オブ・ラインを発生させることなく効率的に並列実行されるようにしている。そのために、1セッションあたりの最大ストリーム数を制限し、アイドルタイムアウトを短くして、忘れられたセッションが取り残されないようにしている。優先順位付けは以下のように行う。 重要資産 そして、HTTP/3がidempotentリクエストだけのために、きれいな0-RTTセットアップを持っていることを確認してください。.

# Nginx HTTP/2の最適化
http2_max_concurrent_streams 128；
http2_idle_timeout 30s; # H2 レベルでの非アクティブ化
http2_max_field_size 16k; # ヘッダ保護 (セキュリティ参照)
http2_max_header_size 64k；;

と一緒に 接続の結合 (H2/H3)の場合、ブラウザは a 証明書のSANとIP/構成が一致すれば、接続が可能です。私は、静的なサブドメインを統合し、複数のホストをカバーする証明書を選択することで、これを利用しています。これにより、追加のハンドシェイクやポートの競合を避けることができます。.

カーネルとソケットのパラメータ一覧

リユースも確保している カーネルレベル ポートやソケットの不足が発生しないようにする。エフェメラルポートレンジ、FIN/TIME_WAIT動作、キープアライブプロービングは、安定性とハンドシェイクレートに直接影響する。.

# /etc/sysctl.d/99-tuning.conf (例、テストは慎重に)
net.ipv4.ip_local_port_range = 10240 65535
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5
net.core.netdev_max_backlog = 4096

を軽率に作動させるような危険な調整は避けている。 tcp_tw_reuse 一般にアクセス可能なサーバー上で。さらに重要なことがある、, 再利用の確率 そうすることで、そもそも短期的な接続が多くならないようにする。高負荷時には、ネットワーク割り込みがクラスター化してレイテンシのピークを発生させないように、IRQ分配とCPUアフィニティもスケーリングする。.

速度を落とすことなく安全性と虐待を防止再利用

Keep-Aliveは攻撃者を次のように誘う。 スローロリス-もし制限が欠落していれば、変種やHTTP/2の乱用が発生します。私は、正当な再利用パターンを妨げることなく、ヘッダーサイズとリクエストレートを強化します。反対 ラピッド・リセットH2の-patternで、同時ストリームとRSTレートの制限を設定し、目立つクライアントをログに記録する。.

# Nginx: 保護ルール
large_client_header_buffers 4 8k；
client_body_buffer_size 128k；

limit_conn_zone $binary_remote_addr zone=perip:10m；
limit_conn perip 50；

limit_req_zone $binary_remote_addr zone=periprate:10m rate=20r/s；
limit_req zone=periprate burst=40 nodelay；

上記の# H2固有のもの：http2_max_concurrent_streams、ヘッダー制限

も使っている。 しとやか シャットダウンにより、デプロイ中にキープアライブ接続がきれいに切れ、クライアントエラーが発生しない。.

# Nginx: コネクションをクリーンにクリアする
worker_shutdown_timeout 10s；;

ロードバランサー、CDN、アップストリーム：チェーン全体での再利用

私は次のことを確認している。間 LB/プロキシとバックエンドの再利用が行われる。そのために、十分なスロットを持つアップストリームプールを運用し、バックエンドでセッションが必要な場合はスティッキーまたは一貫したハッシュ戦略を使用する。CDNへの負荷は、少数の長持ちする起源-コネクションを制限し、POPあたりの最大コネクション数を制限することで、アプリ・サーバーが小さなソケットに溺れないようにする。.

重要なのは 同種のアイドルタイムアウト エッジはオリジンより早くコネクションを切断してはならない。そうしないと、多重化セッションが不必要に再確立されてしまう。HTTP/3では、ノートPCやモバイルクライアントがより頻繁にIPを変更することを考慮しています。.

クライアント・プーリングの深化Node.js、Python、gRPC

クライアント側では、私は感覚的なことに気を配っている。 プール そして、スタンピングやリークが起こらないように制限をクリアする。Node.jsでは、フリーソケットの制限とアイドルタイムアウトを設定して、コネクションがウォームな状態に保たれるようにしているが、永遠にオープンな状態になることはない。.

// Node.js エージェントの微調整
const https = require('https')；
const agent = new https.Agent({
  keepAlive: true、
  keepAliveMsecs: 60000、
  maxSockets: 100、
  maxFreeSockets: 20
});
// axios/fetch: httpsAgent: エージェント

# Python リクエスト: ホストごとに大きなプール
import requests
from requests.adapters import HTTPAdapter

セッション = requests.Session()
adapter = HTTPAdapter(pool_connections=50, pool_maxsize=200, max_retries=0)
session.mount('https://', adapter)
session.mount('http://', adapter)

のために 非同期 ワークロード（aiohttp）では、ソケットの最大数を制限し、DNSキャッシュを使ってレイテンシーを低く抑えている。そして ジーアールピーシー (H2)では、キープアライブPingを控えめに設定し、ネットワークにフラッディングを起こすことなく、長いアイドル期間が切断につながらないようにしている。.

チューニング・ループの指標と目標値

私は、再利用を可視化する重要な数字を用いて、チューニングを反復的にコントロールしている：

再利用枠 (リクエスト/コネクション) をフロントエンドとアップストリームで別々に行う。.
TLSハンドシェイク/秒 対リクエスト/秒 - 目標：握手の割合を減らす。.
P95/P99レイテンシー TTFBと合計で。.
アイドル接続 そして耐用年数。.
エラープロファイル (4xx/5xx)、リセット、タイムアウト。.
時間待ち/終了待ち-カウンターとエフェメラル・ポートの利用。.

シンプルなターゲットイメージ： TLSハンドシェイク/秒 を大きく下回る。 リクエスト, H2/H3では、輻輳のない1セッションあたり複数の同時ストリーム。.

再利用に有利なフロントエンド戦略

私は避ける ドメイン・シャーディング H2/H3では、ホストを統合し、プレロード/プレコネクトを選択的に使用することで、高価なハンドシェイクを避けることができます。帯域幅がボトルネックとなり、不必要にキープアライブスロットをブロックすることがないように、大きな画像を最新の圧縮された方法で読み込む。ヘッダーを小さく保ち、同じセッションでより多くのオブジェクトを効率的に送信するために、クッキーを最小限に抑えます。.

モバイルネットワークとNATネットワーク

移動無線とNAT環境 アイドルタイムアウト の方が短いことが多い。したがって、サーバーのアイドルを控えめにして、クライアントがより頻繁に再接続することを受け入れる。セッション再開と0-RTT(H3)により、再接続は依然として高速である。サーバー側では、プロキシ・ソケットのTCPキープアライブ・プローブが、デッド・パスを素早く廃棄するのに役立つ。.

ロールアウトと高可用性

デプロイメントでは接続を管理する ソフト オフ：新しいアクセプタンスを停止し、既存のキープアライブソケットを待ち、それからプロセスを終了する。多重化セッションがストリームの途中で終了しないように、コネクションの排出をLBの後ろに置く。ヘルスチェックは積極的に行うが、エラーを早期に認識し、プールを適切なタイミングで再構築するために、べき等である。.

素早く成功するためのまとめ

頼りにしているのは HTTP 接続の再利用、短いタイムアウト、適切な制限により、接続は生産性を維持し、アイドル時にリソースを占有することはありません。HTTP/2やHTTP/3のような最新のプロトコルはこの効果を強化し、クライアントのプーリングはバックエンドを緩和する。モニタリングによって、ソケットがアイドル状態になっていたり、不足しすぎている箇所を早い段階で認識し、繰り返し値を調整する。WordPressや同様のスタックについては、再利用とキャッシュ、アセット・バンドル、ローカルにホストされたフォントを組み合わせている。その結果、高速ページ、スムーズなロードカーブ、そして ウェブサーバー-それはあらゆる指標に表れている。.