Analysis and Solutions for Linux TCP TIME_WAIT and CLOSE_WAIT States

CLOSE_WAIT Accumulation and Server Hangs

In high-traffic web services, the accumulation of CLOSE_WAIT states can cause the server to hang. This cannot be resolved through kernel options or timeout settings; it requires an explicit close() call from the local application. The root cause is that the Passive Close side does not call close(), preventing the Active Close side from sending FIN and leaving the connection in CLOSE_WAIT. Solutions include separating the dependency onto a separate server (e.g., nginx) or modifying the application logic to ensure a proper termination process.

The Principle of TIME_WAIT and Correcting Misconceptions

TIME_WAIT is the final state for the Active Close side and persists for 2*MSL (Maximum Segment Lifetime). This is essential to prevent data integrity issues caused by delayed packets and to avoid connection failures if the final ACK is lost. While RFC 793 specifies 2 MSL, it is fixed at 60 seconds in systems like CentOS 6.

Contrary to many online documents, net.ipv4.tcp_fin_timeout does not change the TIME_WAIT timeout. We confirmed that TCP_TIMEWAIT_LEN is hardcoded as (60*HZ) in the Linux kernel source (include/net/tcp.h), making it unchangeable.

Kernel Behavior and Configuration Recommendations

Sockets in the TIME_WAIT state occupy the port for 60 seconds after the process exits, which can cause bind() failures. However, on modern environments such as 64-bit systems, the memory overhead is not significant. To prevent client local port exhaustion in server-to-server connections, you can consider using net.ipv4.tcp_tw_reuse, but caution is required in NAT environments.

net.ipv4.tcp_fin_timeout adjusts the timeout for the FIN_WAIT2 stage, and a value of around 90 is recommended. If the FIN_WAIT1 state persists, it indicates an issue with the remote peer's response, so you should check the OS-level retry logic.