1274 Chapter 61
61.6.7 The TIME_WAIT State
The TCP TIME_WAIT state is a frequent source of confusion in network program-
ming. Looking at Figure 61-4, we can see that a TCP performing an active close
goes through this state. The TIME_WAIT state exists to serve two purposes:z to implement reliable connection termination; and
z to allow expiration of old duplicate segments in the network so that they are
not accepted by a new incarnation of the connection.The TIME_WAIT state differs from the other states in that the event that causes a
transition out of this state (to CLOSED) is a timeout. This timeout has a duration
of twice the MSL (2MSL), where MSL (maximum segment lifetime) is the assumed
maximum lifetime of a TCP segment in the network.An 8-bit time-to-live (TTL) field in the IP header ensures that all IP packets are
eventually discarded if they don’t reach their destination within a fixed number
of hops (routers traversed) while traveling from the source to the destination
host. The MSL is an estimate of the maximum time that an IP packet could
take to exceed the TTL limit. Since it is represented using 8 bits, the TTL per-
mits a maximum of 255 hops. Normally, an IP packet requires considerably
fewer hops than this to complete its journey. A packet could encounter this
limit because of certain types of router anomalies (e.g., a router configuration
problem) that cause the packet to get caught in a network loop until it exceeds
the TTL limit.The BSD sockets implementation assumes a value of 30 seconds for the MSL, and
Linux follows the BSD norm. Thus, the TIME_WAIT state has a lifetime of 60 sec-
onds on Linux. However, RFC 1122 recommends a value of 2 minutes for the MSL,
and, on implementations following this recommendation, the TIME_WAIT state
can thus last 4 minutes.
We can understand the first purpose of the TIME_WAIT state—ensuring reliable
connection termination—by looking at Figure 61-6. In this diagram, we can see that
four segments are usually exchanged during the termination of a TCP connection.
The last of these is an ACK sent from the TCP performing the active close to the
TCP performing the passive close. Suppose that this ACK gets lost in the network.
If this occurs, then the TCP performing the passive close will eventually retransmit
its FIN. Having the TCP that performs the active close remain in the TIME_WAIT
state for a fixed period ensures that it is available to resend the final ACK in this
case. If the TCP that performs the active close did not still exist, then—since it
wouldn’t have any state information for the connection—the TCP protocol would
respond to the resent FIN by sending an RST (reset) segment to the TCP perform-
ing the passive close, and this RST would be interpreted as an error. (This explains
why the duration of the TIME_WAIT state is twice the MSL: one MSL for the final
ACK to reach the peer TCP, plus a further MSL in case a further FIN must be sent.)An equivalent of the TIME_WAIT state is not required for the TCP performing
the passive close, because it is the initiator of the final exchange in the connec-
tion termination. After sending the FIN, this TCP will wait for the ACK from its
peer, and retransmit the FIN if its timer expires before the ACK is received.