Tech Learning Daily

接続を識別するのは「4 つ組」である

TCP の接続は、送信元 IP・送信元ポート・宛先 IP・宛先ポート の 4 つの値の組（4-tuple、4 つ組）で一意に識別される。カーネルは届いたパケットのこの 4 つ組を見て、どのソケットに渡すかを決めている。

アプリから https://api.example.com に接続するとき、宛先 IP と宛先ポート 443 は決まっている。送信元 IP もマシンの IP で固定だ。毎回変わるのは送信元ポートだけで、これはカーネルがエフェメラルポート（ephemeral port、接続ごとに一時的に割り当てる送信元ポート）の範囲から自動で選ぶ。

Linux ではこの範囲を net.ipv4.ip_local_port_range で決めており、デフォルトは 32768〜60999、つまり 28,232 個である。同じ宛先（IP とポートの組）に対して同時に存在できる接続は、この個数が上限になる。宛先が違えば同じ送信元ポートを使い回せるため、問題になるのは「同じ相手に大量に繋ぐ」場合だ。

$ sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768	60999

閉じた側だけが TIME_WAIT に残る

close() を呼ぶと接続はすぐ消えるように思える。しかし実際は、TCP は両側が FIN（もう送るデータは無いという合図）と ACK（受け取ったという確認）を交換して終了する手順を踏み、先に FIN を送った側（アクティブクローズ側）は最後の ACK を送ったあとも TIME_WAIT という状態でしばらく残る。

 先に閉じる側            後から閉じる側
 ESTABLISHED             ESTABLISHED
    │ ── FIN ───────────────▶ │
 FIN_WAIT_1              CLOSE_WAIT
    │ ◀─────────────── ACK ── │
 FIN_WAIT_2                   │
    │ ◀─────────────── FIN ── │
    │                     LAST_ACK
    │ ── ACK ───────────────▶ │
 TIME_WAIT                 CLOSED
 （2MSL 待機。Linux は 60 秒）
    ▼
 CLOSED

待つ時間は仕様上 2MSL と定められている。MSL（Maximum Segment Lifetime）はパケットがネットワーク上を漂い続けうる最大時間の想定値で、TCP の仕様 RFC 9293 は MSL を 2 分としている。Linux はこれより短い 60 秒をカーネルのソースに定数 TCP_TIMEWAIT_LEN として埋め込んでおり、sysctl では変えられない。

TIME_WAIT 中のソケットはアプリからはもう見えないが、カーネルの中では 4 つ組を占有したままだ。そのため同じ 4 つ組で新しい接続を始めることは、原則としてできない。

なぜ 60 秒も待つ必要があるのか

TIME_WAIT には 2 つの役目がある。1 つ目は、最後の ACK が途中で失われた場合への備えだ。相手は ACK が来ないので FIN を再送してくるが、こちらが状態を完全に捨てていると、知らない接続宛てのパケットとして RST（強制切断）を返してしまう。TIME_WAIT で状態を残しておけば、再送された FIN に正しく ACK を返し直せる。

2 つ目は、古い接続の遅延パケットの混入防止である。ネットワーク経路の都合で遅れたパケットが、同じ 4 つ組で直後に張られた新しい接続に届くと、新しい接続のデータとして誤って受け取られかねない。パケットが消えるのに十分な時間 4 つ組を寝かせることで、この事故を防いでいる。

つまり TIME_WAIT は異常でもリークでもなく、TCP が正しく動いている証拠だ。TIME_WAIT 1 つあたりのカーネル内のメモリ消費も小さいため、数が多いこと自体はほとんど問題にならない。問題になるのは、ポートという有限の番号を食いつぶすときだけである。

ポートが尽きる計算と、本当の対策

計算は単純だ。同じ宛先への接続に使える送信元ポートが 28,232 個で、1 つの接続が閉じたあと 60 秒保持されるなら、毎回新規接続を張るクライアントが維持できるのはおおよそ 28232 ÷ 60 ≒ 470 接続/秒になる。これを超えるペースで「繋いで、1 リクエストして、閉じる」を繰り返すと、空きポートが無くなって connect() が EADDRNOTAVAIL（cannot assign requested address）で失敗する。

対策の本命は、接続を閉じないことだ。HTTP の keep-alive やコネクションプールで同じ接続を使い回せば、TIME_WAIT はそもそも発生しない。Go の http.Transport は宛先ホストごとに保持するアイドル接続数のデフォルト DefaultMaxIdleConnsPerHost が 2 しかない。同じ API に 100 並列で投げると、使い終わった接続のうち 2 本を超える分は閉じられ、その都度 TIME_WAIT が生まれる。並列度に合わせて上げておく。

tr := &http.Transport{
    MaxIdleConns:        200,
    MaxIdleConnsPerHost: 100, // デフォルトは 2
}
client := &http.Client{Transport: tr}

リバースプロキシでも同じことが起きる。nginx は 1.29.7 より前のバージョンでは upstream への接続を keep-alive せず、リクエストごとに閉じるのがデフォルトだった。古いバージョンでは upstream に keepalive を書き、HTTP/1.1 で接続するよう明示しないと、nginx とアプリサーバーの間に TIME_WAIT が積み上がる。

upstream app {
    server 127.0.0.1:3000;
    keepalive 16;  # ワーカーごとに保持するアイドル接続数
}
location / {
    proxy_pass http://app;
    proxy_http_version 1.1;          # 1.29.7 より前で必要
    proxy_set_header Connection "";  # 同上
}

カーネル側にも調整はあるが、補助と考える。ip_local_port_range を広げれば使えるポート数がそのまま増える。net.ipv4.tcp_tw_reuse は、TCP タイムスタンプで安全と判断できる場合に TIME_WAIT 中の 4 つ組を自分から張る新しい接続に再利用させる設定で、0 が無効、1 が全体で有効、デフォルトの 2 はループバック通信のみ有効だ。カーネルのドキュメントは専門家の助言なしに変えるべきでないと注記している。古いブログで見かける tcp_tw_recycle は NAT 環境で接続を壊す問題があり、Linux 4.12 で削除済みなので使えない。