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.
相关推荐
寻星探路7 小时前
【深度长文】万字攻克网络原理:从 HTTP 报文解构到 HTTPS 终极加密逻辑
java·开发语言·网络·python·http·ai·https
王达舒19947 小时前
HTTP vs HTTPS: 终极解析,保护你的数据究竟有多重要?
网络协议·http·https
朱皮皮呀7 小时前
HTTPS的工作过程
网络协议·http·https
Binary-Jeff7 小时前
一文读懂 HTTPS 协议及其工作流程
网络协议·web安全·http·https
盟接之桥10 小时前
盟接之桥说制造:引流品 × 利润品,全球电商平台高效产品组合策略(供讨论)
大数据·linux·服务器·网络·人工智能·制造
会员源码网11 小时前
理财源码开发:单语言深耕还是多语言融合?看完这篇不踩坑
网络·个人开发
米羊12112 小时前
已有安全措施确认(上)
大数据·网络
ManThink Technology13 小时前
如何使用EBHelper 简化EdgeBus的代码编写?
java·前端·网络
珠海西格电力科技13 小时前
微电网能量平衡理论的实现条件在不同场景下有哪些差异?
运维·服务器·网络·人工智能·云计算·智慧城市
QT.qtqtqtqtqt13 小时前
未授权访问漏洞
网络·安全·web安全