The Transport Layer

the TIME-WAIT state

After you hang up a call, you might pause a moment before redialing the same number — just in case a last word is still echoing on the line, or your goodbye didn't quite register. TCP does something similar at the very end of a connection. The end that closes first doesn't immediately forget everything; it sits in a holding pattern called the TIME-WAIT state for a short, defined period before truly releasing the connection.

Concretely, after the active closer sends its final ACK in the teardown, it enters TIME-WAIT and waits for twice the maximum segment lifetime (2 times the longest a packet could survive in the network, often a handful of seconds total). It does this for two reasons. First, if its final ACK was lost, the peer will resend its FIN; staying around lets the closer re-acknowledge it instead of replying with a confusing RST. Second, waiting ensures that any old, delayed segments belonging to this connection drain out of the network and die, so they can't be mistaken for data in a future connection that happens to reuse the same four-tuple (same IPs and ports).

Why it matters: TIME-WAIT is a deliberate, correct safety margin — not a bug, even though it's a frequent source of confusion. A heavily loaded server (or, more often, a busy client) that opens and closes vast numbers of short connections can accumulate many sockets stuck in TIME-WAIT, temporarily tying up local port numbers. That's why systems offer tuning knobs and why long-lived persistent connections (reusing one connection for many requests) are preferred over rapidly churning new ones.

After closing, a client's connection to a server shows up as TIME-WAIT for a few seconds. If the server's FIN was retransmitted because the client's last ACK got lost, the client is still around to acknowledge it cleanly — and that four-tuple won't be reused until the wait expires.

A brief 2MSL wait: catch stray FINs, let old segments die out.

Lots of sockets in TIME-WAIT usually means lots of short-lived connections, not a leak. It is by design. Aggressively disabling it can reintroduce the very bugs (mistaken old packets) it exists to prevent.

Also called
2MSL waitTIME-WAITTIME_WAIT 狀態