一个解除TCP连接的TIME_WAIT状态限制的简便方法

近日无意间发现了一个小窍门：当TCP连接所对应socket的接收队列中仍有未读数据时，将此socket强行close后，将使此socket连接不会进入TIME_WAIT状态，用"netstat -anp"命令查看可发现此连接将消失的无影无踪！上述情形在linux2.6.18-5-686-bigmem内核及winxp平台上验证通过。其他平台上，以及当socket的发送队列中仍有剩余数据未发送时强行close后是否可重现此现象，尚未进行验证。
那么说了这么多，这个窍门有什么用呢？对TCP的socket编程比较熟悉的人都知道，通常情况下，当一个socket已成功地在服务端和客户端建立连接后，无论是哪一方，先行调用close的那一方所对应的socket最终必会进入TIME_WAIT状态，并且会持续2*MSL，大约1-4分钟，然后由操作系统自动回收并将TCP连接设为CLOSED初始状态。这个过程按下图中的TCP连接状态转换过程进行：

在socket的TIME_WAIT状态结束之前，该socket所占用的本地端口号将一直无法释放。编写过高TCP并发并且采用短连接方式进行通讯的软件程序的人，都可能体会到，这样的通讯系统在高并发高负载下运行一段时间后，就常常会出现做为客户端的程序无法向服务端建立新的socket连接的情况。此时用"netstat-anp"命令查看系统将会发现机器上存在大量处于TIME_WAIT状态的socket连接，并且占用大量的本地端口号。最后，当该机器上的可用本地端口号被占完，而旧的大量处于TIME_WAIT状态的socket尚未被系统回收时，就会出现无法向服务端创建新的socket连接的情况。此时的通讯系统几乎停转，空有再好的性能也发挥不出来。
   如果能够在客户端程序主动关闭socket之前，让该socket的接收队列中仍保留一些数据（至少要有多余的一个字节的数据），然后调用close关闭，那么上述的无法向服务端创建新的socket连接的情况将不会出现。这是因为当socket的接收队列中仍有数据未被应用程序读走就被强行关闭时，操作系统（至少在笔者验证过的操作系统上的确如此）的TCP/IP协议栈驱动程序会在底层主动向服务端发送一个要求结束TCP连接的控制包，并将该TCP包头的flag控制字段中的RESET位置位，从而迅速结束了此TCP连接。这其实是操作系统对TCP连接断开的一种异常处理。而正常情况下（socket的接收队列中无未读数据），当应该程序调用close关闭连接时，底层驱动程序向服务端发送的要求结束TCP连接的控制包头的flag控制字段中是将FIN位置位，并且严格遵循上图所示的状态转换过程，最终到达TIME_WAIT状态并持续2*MSL的时间。
   知道了上述原理，具体如何利用呢？这有两种思路。第一种，从服务端入手，在服务端向客户端返回所有有效数据后，再在后面插入若干填充字节；而在客户端将有效数据读完之后，将填充字节留在对应socket的接收队列中，然后直接关闭连接。这个思路的好处是对客户端程序不需要做改动。第二种思路是从客户端入手，在客户端程序中控制从socket的接收队列中recv数据的节奏，将最后一个有效字节留在接收队列中不取出。但是怎么知道哪里是最后一个字节呢？最后一个字节的内容是什么？解决第一个问题的方法就是制定客户端与服务端通讯协议时应该考虑提供某种机制，让客户端解包时能够知道数据包何时结束，例如可以在通讯包的头部指示整个包的长度。解决第二个问题的方法是调用recv时使用MSG_PEEK标志，例如：
      ssize_t recvBytes = recv(socket,buf,buflen,MSG_PEEK);
当以MSG_PEEK标志接收数据时，数据将只从socket的接收队列中拷贝到指定的buf中，而相应的数据不会被移出接收队列。这样就能够既获得应用程序所需数据，又能将数据留在socket接收队列中，进而能够在关闭时使该TCP连接不进入TIME_WAIT状态。第二种思路的好处是不需要对服务端程序进行改动。笔者已将第二种思路实现并验证可行。

备注：在网上，解除TIME_WAIT状态限制有多种方法，其中有种方法是在socket建立后调用setsockopt函数如下：
   int option = 1;
   setsockopt(socket, SOL_SOCKET, SO_REUSEADDR, &option, sizeof(option));
如此就可以解决问题了。但实际上，有的平台不支持setsockopt函数，既使是在能够支持的平台，笔者经实际验证发现并不能达到目的。另有一些其他方法也各有利弊。所以，如果其他方法无效，本文中的方法就值得一试了。

一个解除TCP连接的TIME_WAIT状态限制的简便方法相关推荐

83998 连接服务器出错_服务端 TCP 连接的 TIME_WAIT 问题分析与解决
民工哥技术之路写在开头,大概 4 年前,听到运维同学提到 TIME_WAIT 状态的 TCP 连接过多的问题,但是当时没有去细琢磨:最近又听人说起,是一个新手进行压测过程中,遇到的问题,因此,花点时 ...
网络：TCP通讯之 time_wait 状态
基于TCP协议的通讯流程 1.TCP建立连接 2.TCP断开连接 3.TCP状态转换 TCP状态解释: SYN-RECVD:再收到和发送一个连接请求后等待对方对连接请求的确认 ESTABLISHED: ...
基础原理系列：服务端 TCP 连接的 TIME_WAIT 问题
几个方面: 问题描述:什么现象?什么影响? 问题分析解决方案底层原理 1.问题描述模拟高并发的场景,会出现批量的 TIME_WAIT 的 TCP 连接: 短时间后,所有的 TIME_WAIT 全 ...
close wait 过多原因_干货分享！服务端 TCP 连接的 TIME_WAIT 问题分析与解决
写在开头,大概 4 年前,听到运维同学提到 TIME_WAIT 状态的 TCP 连接过多的问题,但是当时没有去细琢磨:最近又听人说起,是一个新手进行压测过程中,遇到的问题,因此,花点时间,细深究一下. ...
linux服务器上tcp有大量time_wait状态的解决方法和原因解释
在检查服务器时,发现有很多连接超时情况出现,用netstat命令查看,tcp的time_wait状态较多,需要进行优化. 1. 看一下现在time_wait的数量 netstat -an | grep ...
TCP连接中time_wait在开发中的影响-搜人以鱼不如授之以渔
根据TCP协议定义的3次握手断开连接规定,发起socket主动关闭的一方socket将进入TIME_WAIT状态,TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),T ...
TCP连接中TIME_WAIT连接过多
2019独角兽企业重金招聘Python工程师标准>>> TCP连接中TIME_WAIT连接过多转载于:https://my.oschina.net/meowmeow/blog/36 ...
TCP连接（Time_Wait、Close_Wait）说明
修改Time_Wait和CLOSE_WAIT时间修改Time_Wait参数的方法 (在服务端修改) Windows下在HKEY_LOCAL_MACHINE/SYSTEM/CurrentControl ...
介绍一个查看TCP连接的工具TCPView
该工具可以帮助使用者查看该机器上建立的所有的TCP连接, 以及TCP连接所使用的端口信息, 连接的状态信息, 进程ID等. 还可以看到连接过来的对方的机器名, 端口号. 在工具窗体下方的工具栏里, 还 ...

一个解除TCP连接的TIME_WAIT状态限制的简便方法

一个解除TCP连接的TIME_WAIT状态限制的简便方法相关推荐

最新文章

热门文章