Why TIME_WAIT Isn't a Problem and How to Optimize It

1. Principle of TIME_WAIT

1.1 TCP connection termination

TCP connection termination follows a four‑handshake process; after the side that actively closes the connection (usually the server) sends the final ACK, it enters the TIME_WAIT state for 2×MSL (Maximum Segment Lifetime), typically 60 seconds.

1.2 Purpose of TIME_WAIT

It prevents old packets from interfering with new connections and ensures reliable closure by allowing retransmission of the final FIN if the ACK is lost.

2. Why large numbers of TIME_WAIT appear

High‑frequency short‑connection scenarios: web servers and API services that constantly create and destroy connections.

Server‑initiated closures: when the server, not the client, closes the connection, the server stays in TIME_WAIT.

Under‑utilized connection pools: applications that do not reuse connections create many new ones.

Load‑balancer architecture: reverse proxies or load balancers open many short‑lived connections to back‑end servers. When new connections exceed 1 000 per second, TIME_WAIT accumulation becomes noticeable; at 2 000 per second, 120 000 TIME_WAIT sockets appear after 60 seconds.

3. Monitoring and diagnosis

3.1 Script parsing

#!/bin/bash
TW=$(ss -ant state time-wait 2>/dev/null | wc -l)
RANGE=$(sysctl -n net.ipv4.ip_local_port_range 2>/dev/null)
REUSE=$(sysctl -n net.ipv4.tcp_tw_reuse 2>/dev/null)
echo "TIME_WAIT: $TW | Port Range: $RANGE | tcp_tw_reuse: $REUSE"
[ $TW -gt 50000 ] && echo "建议检查端口使用或连接模式"

Result can be visualized with the following screenshot:

3.2 Advanced diagnostic commands

# Count TIME_WAIT connections per IP
ss -ant state time-wait | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr

# Check FIN timeout
sysctl net.ipv4.tcp_fin_timeout

# View TCP memory usage
cat /proc/net/sockstat

4. Optimization strategies

4.1 Kernel parameter tuning

Enable TIME_WAIT reuse:

sysctl -w net.ipv4.tcp_tw_reuse=1

This allows sockets in TIME_WAIT to be reused for new connections, which is safer than the removed tcp_tw_recycle option.

Expand the local port range:

sysctl -w net.ipv4.ip_local_port_range="1024 65535"

Increase the number of available ports from the default ~28 k to over 64 k.

Adjust FIN timeout:

sysctl -w net.ipv4.tcp_fin_timeout=30

Reduce the FIN_WAIT_2 timeout to indirectly lower TIME_WAIT pressure.

Set a maximum for TIME_WAIT buckets:

sysctl -w net.ipv4.tcp_max_tw_buckets=200000

When the limit is exceeded, connections are reset to avoid resource exhaustion.

Configuration example (add to /etc/sysctl.d/99-sysctl.conf and reload):

net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_max_tw_buckets = 200000
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

4.2 Application‑level optimizations

Implement connection pools: reuse TCP connections to avoid frequent creation and teardown.

Shift closure to clients: let clients close connections so TIME_WAIT stays on the client side.

Enable HTTP Keep‑Alive: keep persistent connections to reduce new‑connection frequency.

Load‑balancer tuning: enable connection reuse at the proxy layer to lessen backend pressure.

5. Real‑world cases

Case 1 – API gateway optimization: an e‑commerce platform handling 5 000 requests per second saw TIME_WAIT exceed 100 k. By enabling tcp_tw_reuse=1, expanding the port range to 10 000‑65 000, and using a connection pool, TIME_WAIT stabilized below 20 k and system stability improved markedly.

Case 2 – Database connection tuning: a financial system suffered from frequent DB connection churn. Adjusting the connection‑pool settings, increasing tcp_fin_timeout, and optimizing SQL queries reduced connection wait time and improved database stability by about 40 %.

6. Best practices and cautions

Do not enable tcp_tw_recycle; it has been removed in Linux 4.12+ and breaks NAT environments.

Monitoring thresholds: TIME_WAIT < 30 % of available ports is normal; > 50 % warrants attention; > 80 % requires immediate optimization.

Tailor strategies to workload: long‑lived connections (e.g., WebSocket) differ from short‑lived REST APIs.

Deploy changes gradually: test in staging before applying to production.

One‑click detection script

#!/bin/bash
# tcp-tw-check.sh – Detect TIME_WAIT configuration and suggest optimizations

RED='\033[0;31m'
GREEN='\033[0;32m'
NC='\033[0m' # No Color

PARAMS=(
    "net.ipv4.tcp_tw_reuse"
    "net.ipv4.tcp_fin_timeout"
    "net.ipv4.ip_local_port_range"
    "net.ipv4.tcp_max_tw_buckets"
)

RECOMMENDED_VALUES=(
    "1"
    "30"
    "1024 65535"
    "200000"
)

TW=$(ss -ant state time-wait 2>/dev/null | wc -l)
echo "TIME_WAIT connections: $TW"

print_current_params() {
    echo "Current kernel settings:"
    echo "----------------------------------------"
    for param in "${PARAMS[@]}"; do
        value=$(sysctl -n "$param" 2>/dev/null)
        if [ -z "$value" ]; then
            echo "$param = ${RED}unset (default used)${NC}"
        else
            echo "$param = $value"
        fi
    done
}

print_recommendations() {
    echo
    echo "Recommended configuration:"
    echo "----------------------------------------"
    for i in "${!PARAMS[@]}"; do
        echo "${PARAMS[i]} = ${RECOMMENDED_VALUES[i]}"
    done
}

print_current_params
print_recommendations

Conclusion

TIME_WAIT is an essential TCP design, not a bug. Effective optimization requires understanding the service’s connection pattern, balancing system resources, and combining kernel tweaks with architectural changes such as connection reuse. Continuous monitoring and incremental adjustments are key to maintaining stability under high concurrency.