1. Overview
In TCP, the TIME_WAIT state is one of the states during connection termination. The initiator of the connection termination takes this time to ensure reliability. It ensures that the receiver receives the acknowledgment of its connection termination request.
In this article, we’re going to see when this TIME_WAIT state occurs during the connection lifetime, why this state is required, and some workarounds to avoid this state.
2. When Does the TIME_WAIT State Occur?
Let’s consider one scenario that two programs, A and B, are in communication through a TCP socket connection. Program A calls close on its socket and sends FIN packet to program B to terminate the connection. The one who initiated the termination is called to initiate an active close. Now program A is in the FIN_WAIT_1 state.
Program B, which receives a FIN packet, initiates the passive close and enters in the CLOSE_WAIT state. On receiving a FIN packet from program A, program B sends an ACK packet to program A. After receiving an ACK packet from program B, program A goes into the FIN_WAIT_2 state, waiting for a FIN packet from program B.
When program A receives a FIN packet from program B, it sends a final ACK packet to program B and enters into the TIME_WAIT state. However, program A doesn’t know that the ACK packet from it successfully reached the TCP protocol layer of program B.
Therefore, in the TIME_WAIT state, program A waits a reasonable amount of time to see whether program B retransmits the FIN packet to indicate that it never received an ACK packet from program A. If this happens, then program A must be able to retransmit the final ACK packet.
3. Why Is TIME_WAIT Required?
The time for which program A stays in the TIME_WAIT state is twice the Maximum Segment Lifetime (2*MSL). The MSL is the maximum time a TCP segment can exist in the network before being discarded. As per RFC 793, the value of MSL is defined as 2 minutes.
There are two primary purposes for the TIME_WAIT state. Firstly, it prevents delayed packets from one connection from being accepted by another socket relying on the same source address, source port, destination address, and destination port. Secondly, it ensures the reliable connection termination of the TCP connection. If the final ACK from A is lost, then the peer stays in the LAST_ACK state. Without the TIME_WAIT state, the remote end assumes that the previous connection is still valid – if it gets SYN for a new connection request for the same address, then it will terminate the request by sending an RST.
4. Working Around the TIME_WAIT State
A user may want to avoid the TIME_WAIT state for a couple of reasons. For instance, to create a new connection of the same kind immediately after a program crashes. Moreover, the socket structure occupies memory, CPU resources, etc., until the timeout. On a busy server where many connections are created and closed, some workarounds to avoid such scenarios may be required.
4.1. Restarting init.d Daemon
The init.d is the sub-directory of the /etc directory in the Linux file system. The content of this directory varies depending on the applications installed on your system. Usually, we can find a couple of scripts related to various services in our system.
The use of these scripts is to control (start, stop, reload, restart) the respective services during the booting of the system or while the system is running. A user with root privilege can control these scripts:
$ /etc/init.d/<script> <options>
Here,