TCP接続のライフサイクル：ハンドシェイク、切断、およびTIME_WAIT

問題と前提条件

あるLinux APIクライアントが接続を再利用せず、単一のアップストリームに対して毎秒5,000件の短いTCP接続を開いています。その後、接続タイムアウトと大量のTIME_WAITソケットが報告されるようになりました。TCPがどのように確立・切断されるか、どちらのエンドポイントがTIME_WAITに入るか、なぜその状態が存在するのか、そしてこのインシデントをどのように診断し修正するかを説明してください。

明確な基準となる前提条件を設定します。クライアントの送信元IPは1つで、アップストリームのIPとポートは固定されています。エフェメラルポートの範囲はLinuxのドキュメントに記載されているデフォルトの32768–60999であり、予約ポートはありません。パケットキャプチャによると、クライアントが最初のFINを送信しており、観測されたTIME_WAITエントリは約60秒間持続しています。これら最後の2つの事実はシナリオから提供された証拠であり、オペレーティングシステムの普遍的な定数ではありません。

この質問は、バックエンド、インフラストラクチャ、SRE、クライアント、および一般的なソフトウェアエンジニアリングの面接に適しています。ここでの本質的な課題は、「3ウェイハンドシェイクと4ウェイ切断」を単に暗唱することではありません。TCP状態、4タプルの容量、およびパケット証拠を使用して、正常なクリーンアップと、エフェメラルポートの枯渇、パケットロス、アップストリームの過負荷とを区別することです。

面接官が見ているポイント

第一に、候補者がハンドシェイクによって両側の初期シーケンス番号が同期されることを説明できるかです。SYNは1つのシーケンス番号を消費し、確認応答（ACK）は次に期待されるシーケンス番号を示します。3番目のメッセージは、開始側が相手の初期シーケンス番号を受信したことを確認します。この目的を述べずにSYN、SYN+ACK、ACKを並べるだけでは不十分です。

第二に、候補者が全二重の切断セマンティクスを状態遷移に対応付けられるかです。2つの送信方向は独立して送信を停止できるため、通常の切断は一般にFIN → ACK → FIN → ACKとして示されます。ACKはFINと組み合わせることができるため、パケットキャプチャに常に4つの独立したパケットが含まれるとは限りません。優れた回答では、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、LAST-ACK、およびTIME-WAITが何を待っているのかを説明します。

第三に、候補者がTIME_WAITの保持者を特定できるかです。通常、これはアクティブクローズ（能動的切断）を行い、最後のACKを送信した側のエンドポイントになります。そのエンドポイントはクライアントの場合もあればサーバーの場合もあります。両方のエンドポイントが同時にアクティブクローズを行った場合、両方がTIME_WAITに入る可能性があります。クライアントかサーバーかというラベルだけで状態が決まるわけではありません。

第四に、候補者が大規模なTIME_WAITの数を何でも障害として診断してしまうことを避けられるかです。多数の短い接続があれば、当然ながら多くのエントリが生成されます。ポートの枯渇を判断するには、タプルの供給量、接続生成率、エラーの挙動、およびパケット証拠の間の関係性を把握する必要があります。

第五に、候補者がリスクの低い順に対策を提案できるかです。まず接続生成を減らし、次に容量とネットワークパスを調査し、最後にカーネル設定を検討します。状態を強制終了したり、バケット制限を下げたり、RSTを使用して通常の切断をバイパスしたりすると、明らかな容量問題が断続的な正確性の障害へと変わってしまう可能性があります。

最初に明確にすべき質問

• どちらのエンドポイントがアクティブクローズを行っているか？ 最初のFINを送信したエンドポイントが、通常アクティブクローズの経路をたどります。アップストリーム側が先に切断している場合、クライアント側のTIME_WAITには別の説明が必要になります。
• エラーデータにおける「接続タイムアウト」とは何を意味しているか？ ローカルポートの割り当ては、EADDRNOTAVAILなどのエラーで即座に失敗することがあります。SYN-SENTのまま再送を繰り返す接続は、ネットワーク経路、フィルタ、listenバックログの圧迫、または応答しないアップストリームを示唆しています。エラーの種類と発生期間によって調査アプローチが変わります。
• プロトコルで接続を再利用できるか？ HTTP keep-alive、コネクションプール、HTTP/2の多重化、またはその他の持続的トランスポートを使用することで、ハンドシェイクと切断の大部分を排除できます。容量拡張が関係してくるのは、1リクエストにつき1接続という挙動が本当に必要な場合のみです。
• ポートの制約はどこにあるか？ ホストにはエフェメラルポートの範囲があります。NAT、プロキシ、またはロードバランサーには、それぞれ独自のパブリックアドレスおよびポートマッピングプールがあります。ホストのポートに空きがあっても、下流の出口デバイスに利用可能なタプルがあるとは限りません。
• 接続先は固定されているか？ TCP接続は、送信元アドレス、送信元ポート、宛先アドレス、宛先ポートによって識別されます。同じローカルポートを異なる宛先に対して使用できるため、マシン全体の接続総数よりも単一のアップストリームへの集中度が重要になります。
• 稼働中のシステム構成はどうなっているか？ ポート範囲、予約ポート、TCPタイムスタンプ、再利用ポリシー、およびカーネルバージョンが容量に影響します。シナリオのデフォルト値はおおよその初期見積もりには役立ちますが、本番環境での結論には実際の値を読み取る必要があります。

30秒の回答フレームワーク

「3ウェイハンドシェイクは、両方の初期シーケンス番号を交換して確認します。クライアントがSYNを送信し、サーバーのSYN+ACKがクライアントの番号を確認して自身の番号を提供し、クライアントがその番号をACKします。通常の切断には2つの独立した方向があるため、一般的にはFIN、ACK、FIN、ACKとなります。最後のACKを送信するアクティブクローズ側は、通常TIME_WAITに入ります。これにより、再送されたFINを確認応答できるようにし、古い接続からの遅延重複パケットが同じタプルの新規利用に混入するのを防ぎます。

TIMEWAITの数が多くても、自動的にリークであるとは言えません。エラーの種類、SYN-SENTの数、パケットキャプチャ、およびポート範囲を調査します。単一の送信元IPから単一のアップストリームに対しては、提示されたデフォルト範囲で28,232個のポートが存在します。TIMEWAITの観測期間が約60秒で毎秒5,000件の新規接続がある場合、直近で必要なタプル数は約300,000となり、供給量を大幅に上回ります。私ならまずプーリングや多重化を追加し、次にNATとタプルの容量を調査し、その後に初めて範囲の拡大や送信元アドレスの追加を検討します。TIMEWAITを削除したり、tcptw_reuseを闇雲に変更したりすることから始めることはしません。」

ステップごとの詳細解説

ステップ1: シーケンス番号を用いたハンドシェイクの説明

クライアントの初期シーケンス番号をx、サーバーの初期シーケンス番号をyとします。

SYNは1つのシーケンス番号を消費するため、確認応答はx+1またはy+1になります。純粋なACKはシーケンス空間を消費しません。ハンドシェイクにより、各エンドポイントは相手の初期シーケンス番号を取得し、自身の番号が受信されたことの確認を得ます。また、過去の重複した接続要求が新しい接続と誤認される可能性も低減します。

2つのメッセージだけでは、開始側はサーバーの確認応答を確認していますが、サーバー側はクライアントがサーバーの初期シーケンス番号を受け入れたという確認を受け取っていません。「ネットワークが双方向で機能しているかを確認する」という表現は不正確な要約です。TCPは、確認応答可能で再送可能なシーケンス空間と共有接続状態を確立しています。

ステップ2: 2つの独立した方向からの切断プロセスの導出

TCPは全二重バイトストリームです。一方の送信方向を閉じることは「送信するデータがこれ以上ない」ことを意味しますが、そのエンドポイントは相手がまだ送信し終えていないデータを受信し続けることができます。したがって、通常の切断では2つの方向を終了します。

CLOSE-WAITソケットが継続して多数存在する場合、通常はアプリケーションが相手からの切断通知を受け取ったものの、自身のソケットを速やかに閉じなかったことを意味します。これはTIME_WAITとは異なる障害です。継続的なFIN-WAIT-2は、アクティブクローズ側のFINは確認されたものの、相手側がFINを送信していないことを意味します。これらすべてを一括して「解放されなかった接続」と呼んでしまうと、ステートマシンの診断価値が失われます。

4つのメッセージによる説明は有用な標準ケースであり、固定されたパケット数ではありません。残りのデータがないパッシブクローズ側は、ACKとFINを1つのパケットにまとめることができます。同時アクティブクローズではCLOSINGが使用され、両方のエンドポイントがTIME-WAITに残る場合があります。

ステップ3: TIME_WAITの2つの役割の説明

最後のACKを送信したエンドポイントが直ちに接続を破棄できない理由は、主に2つあります。

第一に、最後のACKが失われる可能性があるためです。パッシブクローズ側はLAST-ACKに留まり、FINを再送します。TIME_WAIT状態を保持しているアクティブクローズ側は、そのFINを再度確認応答（ACK）できます。もし状態が即座に消滅してしまうと、再送されたFINがRSTを受信してしまい、正常な切断の信頼性が損なわれます。

第二に、古い接続からの遅延または重複したセグメントがネットワーク上にまだ存在する可能性があるためです。TCPは4タプルによって接続を識別します。同じタプルがすぐに新しい接続に割り当てられると、古いセグメントが新しいシーケンス空間と重複してしまう可能性があります。TCP標準では、アクティブクローズされた接続を2 × MSLの間保持することを求めており、これにより古いセグメントを期限切れにし、再送されたFINを確認応答する機能を維持します。RFC 1337では、この保護を早期に終了すると、古いデータの誤受入れ、非同期化、および不正なACKの危険性がどのように再発するかが説明されています。

したがって、TIME_WAITは正確性を保証するためのメカニズムであり、メモリリークと同義ではありません。最初に問うべきは、なぜアプリケーションがこれほど多くの接続を作成するのか、タプルの供給が十分か、どちらのエンドポイントがアクティブクローズを行うかであり、カウントをゼロにする方法ではありません。

ステップ4: エフェメラルポートの圧迫状況の算出

Linuxのドキュメントに記載されているデフォルトのip_local_port_rangeは32768–60999です。予約ポートがないというシナリオの前提では、自動割り当てプールには以下が含まれます。

60999 - 32768 + 1 = 28232

単一の送信元IP、単一の宛先IP、および単一の宛先ポートの場合、古いタプルを安全に再利用できない期間において、約28,232個の送信元ポートスロットが存在します。毎秒5,000件の新規接続が発生すると、アプリケーションは約5.65秒でその数のタプルを生成します。

28232 / 5000 ≈ 5.65 seconds

また、シナリオでは観測されたTIME_WAIT期間が約60秒であることも示されています。直近の切断に伴う概算のタプル需要は以下の通りです。

5000 × 60 = 300000 recent connections

30万は28,232を大幅に超えているため、「単一送信元IP、単一アップストリーム、接続再利用なし」は明らかな容量リスクとなります。これは、障害が正確に5.65秒で発生することを証明するものではありません。安全なカーネルの再利用、確立済み接続、予約ポート、接続の持続時間、NATの挙動によって実際の結果は変化します。この見積もりは桁違いの不一致を証明し、次にどのような証拠を収集すべきかを調査者に示します。

同じ送信元ポートで異なる宛先への接続を処理できるため、マシン全体の新規接続総数をポート数で単純に割ることはできません。NATを使用している場合、希少なリソースは宛先に対するパブリックNATアドレスのマッピングタプルである可能性があります。

ステップ5: 状態、エラー、およびパケットによる原因の切り分け

システムの動作を変更しない証拠の収集から始めます。

ss -s
ss -Htan state syn-sent | wc -l
ss -Htan state time-wait | wc -l
ss -Htan state close-wait | wc -l
cat /proc/sys/net/ipv4/ip_local_port_range
cat /proc/sys/net/ipv4/ip_local_reserved_ports
sysctl net.ipv4.tcp_tw_reuse

次に、証拠に基づいて分岐します。

パケットキャプチャでは、誰が最初のFINを送信しているか、失敗した接続がSYNを送出しているか、どこで再送が発生しているかという3つの疑問に答える必要があります。ssの合計値だけではポートの枯渇を証明できず、「timeout」という単語を含むアプリケーションログだけではパケットロスを証明できません。

ステップ6: リスクの低い順での対策の実施

最初の対策は、接続の作成数を減らすことです。コネクションプール、HTTP keep-alive、HTTP/2多重化、またはその他の適切な持続的チャネルを設定し、リクエストが確立済みの接続を共有するようにします。これにより、ハンドシェイクのレイテンシ、CPU負荷、エフェメラルポートの使用量、およびTIME_WAITが同時に削減され、対症療法ではなく根本原因が解決されます。

次に、接続のライフサイクルを修正します。リクエストごとに正常な接続をアクティブクローズしないようにします。プールに適切な並行数制限、適切なアイドルタイムアウト、最大ライフタイム、およびアップストリームの並行数制限を設定します。サーバー側が過度にアグレッシブに切断してくる場合は、そのkeep-alive設定、ロードバランサーのアイドルタイムアウト、およびデプロイの挙動を調査します。目標は、アクティブクローズを単に相手側に押し付けることではなく、無意味な接続の頻繁な生成と破棄をなくすことです。

それでも再利用が不十分な場合は、タプルの供給量を増やします。予約ポートを確認した上で、より広いエフェメラルポート範囲を検討します。単一の宛先への集中は、複数の送信元IPまたは複数の宛先アドレスを使用することでも緩和できます。NATが存在する場合は、パブリックNATアドレスプールも拡張またはシャーディングします。アプリケーションネットワーク内で送信元IPを追加しても、アドレス変換後は効果がない場合があります。

その後に初めてカーネルの再利用設定を検討します。Linuxのドキュメントでは、tcp_tw_reuseはプロトコルの観点から安全と見なされる場合にのみTIME_WAITソケットを再利用すると説明されており、専門的な知識なしに変更しないよう警告されています。tcp_max_tw_bucketsは単純なDoS攻撃に対する防御的な制限値であり、ドキュメントには人為的に下げないよう明記されています。これを超えるとtime-waitソケットが即座に破棄され、警告ログが出力されます。変更を行うには、カーネルバージョン、タイムスタンプ、相手の挙動、負荷テスト、およびロールバック計画の証拠が必要です。

一般的な最適化としてRSTを使用しないでください。RSTは接続を強制中断し、状態を即座に破棄します。アプリケーションによって安全に処理されていないデータが失われる可能性があります。「サーバーに先に切断させる」ことも万能の解決策ではありません。これはTIME_WAITの負荷を移行させるだけであり、サーバー側のポート、メモリ、または接続状態の圧迫を引き起こす可能性があります。

ステップ7: 修正の検証

検証では、容量、正確性、およびネットワーク証拠を網羅する必要があります。

1. 同じトラフィックを再生し、秒あたりの新規TCP接続数、再利用率、リクエストスループットを比較します。
2. 特定の一時点だけでなく、SYN-SENT、TIME_WAIT、CLOSE-WAIT、ファイルディスクリプタ、ローカルポートの使用状況の推移を監視します。
3. 失敗したサンプルをキャプチャし、SYNが送出されているか、SYN+ACKが返ってきているか、どちらのエンドポイントがアクティブクローズを行っているかを確認します。
4. クライアント、NAT、ロードバランサー、アップストリームのトランスポートメトリクスを調査し、送信側のボトルネックを見落とさないようにします。
5. 継続的なテストを実行し、データの切り捨て、RST数の増加、テールレイテンシの悪化、またはプールの古い接続がないかを確認します。

成功の基準は、同じビジネストラフィックにおいて新規接続数が大幅に減少し、エラーが解消され、ポートのヘッドルームが安定し、リクエストの正確性が低下しないことです。TIME_WAITの数の減少はこれらの改善の結果であり、それ自体が唯一の目的ではありません。

優れた回答例

「インシデントからまず2つの事実を確認します。どちらのエンドポイントが最初のFINを送信しているかと、『タイムアウト』が即座のローカルエラーを意味するのか、応答のないSYNを意味するのかです。TIME_WAITは通常、最後のACKを送信するアクティブクローズ側に発生しますが、接続タイムアウトのように見える障害には無関係な複数の原因が考えられます。

接続確立時、クライアントは初期シーケンス番号xを含むSYNを送信します。サーバーのSYN+ACKはx+1を確認応答し、自身の番号yを提供します。その後、クライアントはy+1を確認応答します。これで両方のエンドポイントがシーケンス空間を交換および確認し終え、古い重複した接続試行を拒否できるようになります。切断処理では2つの送信方向を個別に閉じるため、一般的な順序はFIN、ACK、FIN、ACKとなります。アクティブクローズ側はFIN-WAIT-1およびFIN-WAIT-2を経て、相手のFINにACKを送り、TIME_WAITに入ります。この状態により、最後のACKが失われた場合に再送されたFINを再度ACKでき、古い接続からの遅延重複パケットが同じ4タプルの即時再利用を汚染するのを防ぎます。

このシナリオの容量には疑わしい点があります。ポート32768〜60999により、デフォルトで28,232個のエフェメラルポートが提供されます。単一の送信元IPが同一の宛先に対して毎秒5,000接続を作成し、観測されたTIME_WAIT持続時間が約60秒であるとすると、直近の切断は約30万件となり、ポートスロットを大幅に上回ります。ただし、見積もりだけで判断はしません。connectがローカルアドレスエラーで即座に失敗しSYNが出ない場合は、ホストおよびNATのタプル供給を調査します。多数のソケットがSYN-SENTのままで再送している場合は、ネットワーク経路、ACL、listenバックログ、アップストリームを調査します。

対策としては、まずプーリング、keep-alive、またはHTTP/2多重化を追加して新規接続を削減します。次に、プールのアイドルタイムアウト、アップストリームの切断動作、NAT容量を確認します。ワークロードで依然として高い接続確立レートが必要な場合は、エフェメラルポート範囲の拡張、送信元アドレスの追加、または宛先の分散を検討します。tcptwreuseはプロトコルの特定条件下でのみ安全であり、Linuxでは安易な変更に対して警告されています。TIME_WAITの短縮、バケット制限の引き下げ、RSTによる切断の強制から始めることはしません。最後に、同じ負荷の下で新規接続レート、エラー、すべての関連TCP状態、パケットキャプチャ、およびNATメトリクスを検証します。」

よくある間違い

• ハンドシェイクを単なる「挨拶」と説明する → シーケンス番号と確認応答のセマンティクスが抜け落ち、2つのメッセージでは不十分な理由を説明できなくなります → 両方の初期シーケンス番号と3番目の確認から導き出して説明してください。
• クライアントが常にTIME_WAITを保持すると決めつける → クライアントというラベルではなく、アクティブクローズの役割によって状態が決まります → 最初のFINと最後のACKを特定してください。
• 切断処理を厳密に4パケットとして扱う → ACKとFINは統合されることがあり、同時切断も存在します → 2つの独立した方向とその状態遷移として説明してください。
• 大量のTIME_WAITをすべてリークと呼ぶ → 短い接続では自然にこの状態が生成されます → 生成レート、ポート範囲、エラーの種類、パケット証拠を組み合わせて判断してください。
• すべての接続タイムアウトをポート枯渇のせいにする → SYNのパケットロス、ACL、アップストリームの過負荷、listenバックログの圧迫でもタイムアウトが発生します → 即座のローカル障害とSYN再送を区別してください。
• 最初にtcpmaxtw_bucketsを下げる → 制限を超えると状態が早期に破棄され、Linuxでは人為的に下げることに対して明確に警告されています → 容量を拡張する前に接続の頻繁な生成・破棄を減らしてください。
• 通常の切断の代わりにRSTを使用する → 状態を即座に破棄すると、安全に配信されていないデータが失われる可能性があります → 通常の完了にはFINベースの切断を維持し、RSTは真の異常終了のために予約してください。
• アプリケーションのポート範囲のみを広げる → 実際の制限はNATのパブリックマッピングプールにある可能性があります → 送信元ホスト、出口デバイス、およびアップストリームでタプル容量を確認してください。

フォローアップの質問

フォローアップ1: 最後のACKが失われた場合、TIME_WAITはどのように回復しますか？

パッシブクローズ側は、自身のFINに対する確認応答を待つためにLAST-ACKに留まります。最後のACKが失われた場合、パッシブクローズ側はFINを再送します。アクティブクローズ側は依然としてTIME_WAIT状態を保持しているため、再送されたFINを認識してACKを再送信し、待機タイマーを再起動します。もしアクティブ側のエンドポイントが接続を破棄していた場合、そのFINによってRSTがトリガーされ、信頼性のある正常な切断が維持できなくなります。

フォローアップ2: 大量のCLOSE_WAITが存在する状況との違いは何ですか？

CLOSE-WAITは、相手側がFINを送信し、ローカルのTCPスタックがアプリケーションに通知したものの、アプリケーションが自身の送信方向を閉じていないことを意味します。この間、ローカルアプリケーションは残りのデータを送信し続けることができます。これは通常、アプリケーションのライフサイクル、例外処理、またはファイルディスクリプタの管理に起因します。TIME_WAITは、アクティブクローズ側がやり取りを完了し、最後のACKの回復と古いセグメントの隔離を保護していることを意味します。どちらも切断処理中に現れますが、原因、残存データの送信能力、および修正方法は異なります。

フォローアップ3: 1つの送信元ポートが複数の接続にどのように属することができますか？

完全な4タプルによって接続が識別されます。宛先アドレスまたは宛先ポートが異なる場合、同じローカルポートで別の接続を識別できます。したがって、エフェメラルポートの圧迫状況は、送信元IPと宛先の集中度ごとに分析する必要があります。多数の宛先に分散されたトラフィックは、1つのポート範囲が示すよりも多くの総接続数をサポートできますが、単一のアップストリームへの集中は使用可能なタプルをより急速に枯渇させます。

フォローアップ4: クライアントを10インスタンスにスケールアウトすれば枯渇は解決しますか？

必ずしもそうとは限りません。独立した送信元IPによってホスト側のタプル供給量は増加しますが、すべてのインスタンスがわずかなパブリックIPを持つ単一のNATを共有している場合、接続はNATのマッピングプールに集約されます。また、アップストリームが送信元IPごとにレート制限を行っている可能性があり、同時接続数が増加すると相手のlistenバックログ、ファイルディスクリプタ、またはロードバランサーの容量を超える可能性があります。

フォローアップ5: tcptwreuseを検討すべきなのはどのような場合ですか？

まず、接続の再利用、プール設定、ポート範囲、およびNAT容量の改善を行っても依然として不十分であることを証明します。次に、正確なカーネルバージョン、TCPタイムスタンプの挙動、および相手側の特性を確認します。Linuxでは、プロトコルの観点から安全である場合にのみ再利用が許可されており、この設定を不用意に変更することに対して明示的に警告しています。負荷の下で再接続とデータの正確性をテストし、RST、エラー、レイテンシを監視し、ロールバックの準備を整えておきます。これはアプリケーションレベルの接続再利用の代替にはなりません。