TCP netstat TIME_WAIT & CLOSE_WAIT

TIME_WAIT is different from CLOSE_WAIT, and it's not necessarily a client-side fault. It happens due to how TCP handles connection termination.

Key Differences

TCP State Cause Who is responsible? Fix/Optimization
CLOSE_WAIT Server didn't close() the socket after client closed it. Server-side issue (socket left open). Ensure close(client_fd); is always called.
TIME_WAIT Server closed the socket first, waiting to ensure the client received the FIN. Normal behavior (not necessarily a problem). Use SO_LINGER or SO_REUSEADDR to mitigate excessive TIME_WAIT.

Why Does TIME_WAIT Happen?

  • When your server calls close(client_fd); , it sends a FIN to the client.
  • If the client follows the normal TCP closure process , it replies with ACK and sends its own FIN, which your server then ACKs.
  • Your server enters TIME_WAIT for 2×MSL (Maximum Segment Lifetime, usually 60s total) to ensure any delayed packets are handled before fully releasing the connection.

Is TIME_WAIT the Client's Fault?

  • If the client closes the connection first , the server goes to CLOSE_WAIT (which we fixed).
  • If the server closes first , TIME_WAIT is expected.
  • Too many TIME_WAIT sockets? It usually means many short-lived connections are being closed quickly.

How to Reduce TIME_WAIT Issues?

  1. Enable SO_REUSEADDR

    • Allows immediate reuse of the same port, even in TIME_WAIT state.
    c 复制代码
    int opt = 1;
    setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
  2. Use SO_LINGER to Force Immediate Closure

    • Not recommended unless necessary, as it can cause packet loss.
    c 复制代码
    struct linger sl;
    sl.l_onoff = 1;  // Enable linger
    sl.l_linger = 2; // Close socket after 2 seconds
    setsockopt(client_fd, SOL_SOCKET, SO_LINGER, &sl, sizeof(sl));
  3. Keep Connections Open Longer

    • If possible, reuse connections instead of opening/closing frequently.
  4. Tune TCP Stack (sysctl)

    • Reduce TIME_WAIT timeout if necessary:
    sh 复制代码
    sudo sysctl -p | grep net.ipv4.tcp_fin_timeout  # net.ipv4.tcp_fin_timeout = 2
    sysctl -w net.ipv4.tcp_fin_timeout=30

Conclusion

  • CLOSE_WAIT is a server-side issue (fixed by properly closing sockets).
  • TIME_WAIT is expected behavior when the server closes first.
  • Too many TIME_WAIT sockets? Use SO_REUSEADDR , linger options , or connection pooling if appropriate.
相关推荐
ESDWAN5 小时前
跨境网络丢包怎么定位?用MTR和Traceroute分析链路问题
网络
砺星Leetx5 小时前
工业总线选型与对接实战:PROFINET、EtherCAT、EtherNet/IP、PROFIBUS、Modbus-TCP 与 CC-Link
网络·网络协议·tcp/ip·控制器·国产拧紧系统
2401_868534786 小时前
软考网络规划设计师SSL协议知识点详解
服务器·网络
Escalating_xu6 小时前
【Linux 网络编程】手写序列化与反序列化:从 x op y 到能校验的文本协议
linux·运维·网络
POMAGTOR8 小时前
【磁吸式连接器选型工程解析:结构原理、应用场景与选型可靠性要点】
网络·嵌入式硬件
科技小登9 小时前
网站和游戏怎么选高防?DDoS防护、高防IP与高防CDN接入方案解析与边界评估
tcp/ip·ddos
阿文和她的Key12 小时前
PHP2Shell事故四层拆解:AI找洞是小时级,披露协调还是邮件级
网络·人工智能·架构·php
treesforest12 小时前
游戏账号安全风险分层方案:IP信号分层与人机复核实践
tcp/ip·安全·游戏·1024程序员节
QZ1665609515913 小时前
数据库监测的主动防御:实时感知,看见即掌控
网络·安全·网络安全
流浪00113 小时前
计算机网络篇8:传输层——序列化与反序列化,TCP 面向字节流的报文边界由应用层自己切
网络协议·tcp/ip·计算机网络·1024程序员节·序列化反序列化·面向字节流·面向数据包