なぜ短時間の接続が混雑したセルフホストサーバーに過負荷をかけるのですか？

セットアップと終了処理の作業が有用なリクエスト処理を上回ると、短時間の接続が多忙なセルフホストサーバーに過負荷をかけます。新しいセッションごとに、TCPハンドシェイク、TLS交渉、ソケット割り当て、認証、ログ記録、クリーンアップが必要になることがあり、応答が数バイトだけの場合でも同様です。

長時間のファイル転送はこれらのコストを一度だけ支払い、その後大量のデータを転送します。ヘルスチェック、ダッシュボード、モバイルクライアント、ウェブ資産、適切にプールされていないAPIコールは数百の小さなセッションを作成し、サーバーに固定コストの繰り返しを強い、最近閉じた接続の状態を保持させます。

根本原因：新しい接続ごとに固定作業が繰り返される

TCP接続は、アプリケーションデータが流れる前にハンドシェイクから始まります。HTTPSは暗号交渉を追加し、その後アプリケーションはセッションを作成し、資格情報を確認し、データベース接続を開き、ユーザー状態を読み込むことがあります。小さな応答の場合、これらのセットアップ段階がレイテンシとCPU時間の両方を支配することがあります。

短命接続のオーバーヘッドは、サーバーが高頻度で繰り返すと重要になります。ネットワークスループットがリンク速度に遠く及ばなくても、ロードアベレージの上昇や応答の遅延として現れることがあります。

接続の再利用はその比率を変えます。複数のリクエストが確立済みのトランスポートや、対応していれば暗号化セッションを共有できます。サーバーは接続状態の割り当てや破棄に費やす時間を減らし、アプリケーション処理により多くの時間を使えます。

キープアライブはハンドシェイクを減らすが、適切な制限が必要

HTTPキープアライブは、オブジェクトやAPIコールごとに新しい接続を開く代わりに、複数のリクエストが1つのTCP接続を使うことを可能にします。これにより往復回数が減り、ページやダッシュボードが多くのリソースを読み込む際の繰り返しセットアップを防ぎます。

HTTPキープアライブ接続は確立済みトランスポートを再利用することでレイテンシを下げます。境界はアイドル状態であり、過度に長いタイムアウトは多くの未使用ソケットがメモリや接続スロットを占有するため、クライアントのパターンに合ったタイムアウトとリクエスト制限が必要です。

プーリングは内部サービス呼び出しの両側で存在しなければなりません。リバースプロキシはクライアント接続を再利用しつつ、アップストリームにはリクエストごとに新しい接続を開くことがあり、負荷を移動させるだけで除去していません。データベースドライバーやAPIクライアントも同様に、セルフホストアプリ内で隠れたファンアウトを作ることがあります。

閉じた接続がカーネル状態を残すことがある

TCPセッションを閉じても、その状態がすぐに消えるとは限りません。積極的に閉じた側はTIME_WAITエントリを保持し、古い接続からの遅延パケットが同じアドレスとポートの組み合わせを使う後続接続と混同されないようにします。

大量のTIME_WAITエントリは、サーバーの自動的な障害ではなく頻繁な接続の入れ替わりを示します。高頻度になるとメモリを消費し、監視を複雑にし、古いエントリが期限切れになる前にクライアントの一時ポートを枯渇させることがあります。

カーネルタイマーの変更は通常最初の手段ではありません。どのクライアントやサービスが接続を開いているかを特定し、再利用が有効か確認し、リトライやヘルスプローブが頻度を増やしていないかを調べてください。積極的なタイマー変更はパターンを隠しつつ、遅延パケットに対するTCPの保護を弱めることがあります。

自動化により一見アイドル状態のサーバーで接続の入れ替わりが起きることがある

ホームサーバーは、コンテナのヘルスチェック、監視エージェント、ブラウザタブ、電話のウィジェット、メディアクライアント、リバースプロキシなどからリクエストを受けることがあり、人が積極的に使っていなくても接続が発生します。各プローブが新しい暗号化接続を開くと、短い間隔で軽量なチェックが継続的なセットアップ作業に変わります。

短命TCP接続の測定は、自動化されたクライアントやスクリプトが維持されたセッションよりも新しいセッションを繰り返す傾向を示しています。小規模なセルフホストサーバーでも、CPU、メモリ、ワーカーの制限が小さいため同様の挙動が見られます。

受け入れ接続数（秒あたり）、ハンドシェイクCPU使用率、開いているソケット数、TIME_WAITエントリ数、接続あたりのリクエスト数をカウントしてください。接続率がリクエスト量よりも大幅に速く増加している場合は、プーリングやリトライの挙動を調査しましょう。サービスがインターネットに公開されている場合は、ホームサーバーの公開状況チェックで露出境界をまず確認し、不要なスキャンを通常のクライアントと誤認しないようにしてください。

よくある質問

多くの短時間接続は常に問題ですか？

いいえ。現代のサーバーは多くの接続を処理でき、短いセッションはまれなクライアントには適切な場合があります。問題になるのは、接続率がCPU、ポート、ワーカー、メモリをサーバーが再利用できる速度よりも速く消費するときです。

HTTP/2は接続過負荷を解消しますか？

HTTP/2は少ない接続で多くのリクエストを多重化できるため、負荷を減らします。クライアント、プロキシ、アップストリームサービスが実際に交渉して再利用する必要があります。内部の経路はまだ別々のHTTP/1.1接続を使うことがあります。

TIME_WAITのタイムアウトを短くすべきですか？

負荷の原因を特定する前に変更すべきではありません。TIME_WAITは正常なプロトコル動作です。接続プーリング、持続的トランスポート、プローブ間隔、リトライ制限の調整が、カーネルの安全タイマーを短縮するよりも通常は効果的です。