none
TIME_WAIT 的一个情况不太理解 RRS feed

  • 问题

  • 我的服务器和客户端都是在本机,添加了路由因此通信通过了网卡
    服务器是接受客户端通信后马上返回一条18字节大小的确认信息。

    在大量的通信,单机每秒2万左右,运行一段时间会出现因为大量的TIME_WAIT而阻塞的情况。

    我想问的是:
    我在自己的测试中,wsasend过程中使用的wsabuf.len设置的比实际要传递的信息字节数大,这种时候,居然没有出现TIME_WAIT卡死的情况(仅是出现了少量的TIME_WAIT)

    抓包分析没觉得有什么特殊的问题:
    两种情况(wsabuf.len正确和过大)都是服务器端首先关闭连接,都是发出[PSH,ACK]之后,马上发[FIN,ACK]数据报

    我实在是想不明白为什么会出现这种问题?

    PS:
    这么说不太礼貌,但是我不是想要解决因为大量TIME_WAIT阻塞的问题,而是因为这个问题发现了一个现象我不理解。谢谢各位。

    PPS:
    服务端使用的是IOCP进行通信,客户端是阻塞+线程池的方式

    PPPS:

    实在是不好意思 但是确实是搞不明白了

    2019年5月13日 9:02

全部回复

  • 你好,

    RFC 793将TIME-WAIT状态定义如下:

    TIME-WAIT - 表示等待足够的时间传递以确保远程TCP收到其连接终止请求的确认。 

    RFC 793将TIME-OUT设置为最大段寿命的两倍,即2MSL。由于MSL(数据包可以在Internet上漫游的最长时间)设置为2分钟,因此2MSL为4分钟。由于对ACK没有ACK,如果被动发送器没有收到对其FIN的ACK(理论上),则主动关闭器不能做任何事情,只要等待4分钟,如果它正确地遵守TCP / IP协议。

    那么出现这种情况,可能原因就是丢失数据包。但是发生在单个机器内部就非常罕见。

    你可以用netstat -ano 列出TCP连接情况,可以看到使用的端口。

    常用的方法无非是修改TIME-OUT的超时时间,修改端口数量,请参考下面的链接:

    https://blog.csdn.net/swartz_lubel/article/details/78106051

    上面的方法治标不治本,最好的方法是永远不要从服务器发起主动关闭。理想情况下,您应该在协议中设计一种方法,让服务器告诉客户端它应该断开连接,而不是简单地让服务器发起主动关闭。这个仅供参考。

    祝您工作顺利!

    Travis


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    2019年5月21日 3:29
    版主
  • 你好,

    请问您的问题解决了吗? 如果您使用我们的方案解决问题,请“将其标记为答案”,以帮助其他社区成员快速找到有用的回复。 如果您使用自己的方案解决问题,请在此处分享您的经验和解决方案。 对于有类似问题的其他社区成员也是非常有帮助的。 如果没有,请回复并告诉我们目前的情况,以提供进一步的帮助。

    Best Regards,

    Travis 


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    2019年5月27日 6:14
    版主