解决TIME_WAIT过多造成的问题_oracle time wait-CSDN博客

本文链接：https://blog.csdn.net/itwuyi/article/details/110519401

解决TIME_WAIT过多造成的问题

1、TIME_WAIT状态存在的理由或者time_wait的作用？

1）可靠地实现TCP全双工连接的终止

在进行关闭连接四次挥手协议时，最后的ACK是由主动关闭端发出的，如果这个最终的ACK丢失，服务器将重发最终的FIN，因此客户端必须维护状态信息允许它重发最终的ACK。如果不维持这个状态信息，那么客户端将响应RST分节，服务器将此分节解释成一个错误（在java中会抛出connection reset的SocketException)。

因而，要实现TCP全双工连接的正常终止，必须处理终止序列四个分节中任何一个分节的丢失情况，主动关闭的客户端必须维持状态信息进入TIME_WAIT状态。

2）允许老的重复分节在网络中消逝

TCP分节可能由于路由器异常而“迷途”，在迷途期间，TCP发送端可能因确认超时而重发这个分节，迷途的分节在路由器修复后也会被送到最终目的地，这个原来的迷途分节就称为lost duplicate。

在关闭一个TCP连接后，马上又重新建立起一个相同的IP地址和端口之间的TCP连接，后一个连接被称为前一个连接的化身（incarnation)，那么有可能出现这种情况，前一个连接的迷途重复分组在前一个连接终止后出现，从而被误解成从属于新的化身。

为了避免这个情况，TCP不允许处于TIME_WAIT状态的连接启动一个新的化身，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个TCP连接的时候，来自连接先前化身的重复分组已经在网络中消逝。

2、大量TIME_WAIT造成的影响？

1）网络情况不好时，如果主动方无TIME_WAIT等待，关闭前个连接后，主动方与被动方又建立起新的TCP连接，这时被动方重传或延时过来的FIN包过来后会直接影响新的TCP连接；

2）同样网络情况不好并且无TIME_WAIT等待，关闭连接后无新连接，当接收到被动方重传或延迟的FIN包后，会给被动方回一个RST包，可能会影响被动方其它的服务连接。

3）过多的话会占用内存，一个TIME_WAIT占用4k大小。

3、如何尽量处理TIMEWAIT过多?

出现TCP: time wait bucket table overflow？如何处理？

简单来说，就是打开系统的TIMEWAIT"重用"和"快速回收"。

注意： Linux里TIME_WAIT专有的优化参数reuse、recycle，默认都是关闭的，这两个参数必须在timestamps打开的前提下才能生效使用。

编辑内核文件/etc/sysctl.conf：

	net.ipv4.tcp_timestamps = 1
	#表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭。
	net.ipv4.tcp_syncookies = 1 
	#表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭。
    net.ipv4.tcp_tw_reuse = 1 
    #表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
    net.ipv4.tcp_tw_recycle = 1 
    #修改系统默认的 TIMEOUT 时间，FIN_WAIT_2到TIME_WAIT的超时时间，默认是60s，优化到30s。
    net.ipv4.tcp_fin_timeout = 30
    #表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为20分钟。
	net.ipv4.tcp_keepalive_time = 1200 
	#表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为1024到65000。
	net.ipv4.ip_local_port_range = 1024 65000 
	#表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。
	net.ipv4.tcp_max_syn_backlog = 8192 
	#表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数字，TIME_WAIT套接字将立刻被清除并打印警告信息。默认为180000，改为5000。对于Apache、Nginx等服务器，上几行的参数可以很好地减少TIME_WAIT套接字数量，但是对于 Squid，效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量，避免Squid服务器被大量的TIME_WAIT套接字拖死。
	net.ipv4.tcp_max_tw_buckets = 5000

执行 /sbin/sysctl -p 让参数生效。

/etc/sysctl.conf是一个允许改变正在运行中的Linux系统的接口，它包含一些TCP/IP堆栈和虚拟内存系统的高级选项，修改内核参数永久生效。

4、注意

tcp_tw_recycle：回收TIME_WAIT连接。这个内核参数已经变成了大众处理TIME_WAIT的万金油，如果你在网络上搜索TIME_WAIT的解决方案，大多数都会推荐设置它，不过这里隐藏着一个不易察觉的陷阱：

当多个客户端通过NAT方式联网并与服务端交互时，服务端看到的是同一个IP，也就是说对服务端而言这些客户端实际上等同于一个，可是由于这些客户端的时间戳可能存在差异，于是从服务端的视角看，便可能出现时间戳错乱的现象，进而直接导致时间戳小的数据包被丢弃。参考：tcp_tw_recycle和tcp_timestamps导致connect失败问题。

tcp_tw_reuse：复用TIME_WAIT连接。当创建新连接的时候，如果可能的话会考虑复用相应的TIME_WAIT连接。通常认为「tcp_tw_reuse」比「tcp_tw_recycle」安全一些，这是因为一来TIME_WAIT创建时间必须超过一秒才可能会被复用；二来只有连接的时间戳是递增的时候才会被复用。官方文档：如果从协议视角看它是安全的，那么就可以使用。如果网络比较稳定，比如都是内网连接，那么就可以尝试使用。

不过需要注意的是在哪里使用，既然我们要复用连接，那么当然应该在连接的发起方使用，而不能在被连接方使用。举例来说：客户端向服务端发起HTTP请求，服务端响应后主动关闭连接，于是TIME_WAIT便留在了服务端，此类情况使用「tcp_tw_reuse」是无效的，因为服务端是被连接方，所以不存在复用连接一说。让我们延伸一点来看，比如说服务端是Java，它查询另一个Oracle服务端，然后主动断开连接，于是TIME_WAIT就落在了Java一侧，此类情况下使用「tcp_tw_reuse」是有效的，因为此时Java相对于Oracle而言是客户端，它是连接的发起方，所以可以复用连接。

如果使用tcp_tw_reuse，请激活tcp_timestamps，否则无效。