为什么服务端会有那么多的 TimeWait ？

工作中无论是开发环境还是线上环境，我们都出现过大量的 timewait 状态的连接，例如下面这个例子

服务端简单的开辟一个 web server 监听 9966 端口

客户端进行疯狂的请求服务端

瞬间就可以看到咱们服务端的出现大量的 TIME_WAIT 状态的连接

这个时候，如果客户端再不停的请求服务端的话，我们就可以看到会出现这样的一个错误 address already in use : connect

这个时候是表示咱们已经没有可以使用的端口， 地址都在被使用中

那我们来看一下为什么会出现上述这种情况，以及我们如何去解决他呢？

为什么会出现这么多的 TIME_WAIT 状态

上面其实咱们也看到了，出现大量 TIME_WAIT 状态，一般是出现在高并发场景，同时有多个请求进来， 如果基本都是短连接，那么服务端处理完毕请求之后就会关闭连接，那么服务端就会出现大量的 TIME_WAIT 状态的连接，需要等待 2 MSL 的报文最大存活时间，才会被系统释放回收，回收哦，又空余出连接数，来进行服务

简单的咱们可以使用如下命令来查看我们的 TIME_WAIT 状态的连接数

netstat -antp|grep TIME_WAIT |wc -l 

上述这种情况，在并发的时候，我们的某些请求可能没有办法得到处理，这是为什么呢？

有一点网络基本知识的我们知道，咱们的 TCP 结构是这样的：

对于目的端口和源端口，在 tcp 包头上都是占用 16 bit ，那么就是分别 65535 个端口，此处客户端请求服务端，那么源端口最多也就是 65535 个连接

而当我们请求服务端时，报错地址正在被使用，咱们就需要等待最大 2MSL 的时间，才能正常连接服务端了

我们如何处理 TIME_WAIT 大量存在的情况

我们如何处理 TIME_WAIT 大量存在的情况呢？前提是我们先知道这个 TIME_WAIT 是产生在哪一边的，一般情况下多数是发生在服务端

对于 TCP 的三次握手和四次挥手就不在此处做详细阐述了，对于基本 TCP 原理中，客户端和服务端，哪一端先发起关闭连接，那么 TIME_WAIT 就会出现在哪一端，例如下面这个简图：

那么，我们可以知道上述例子，TIME_WAIT 是出现在服务端的，这是为什么呢？

因此客户端的请求连接头部中 connection 设置的一般是 close 字段，此时服务端的处理是一个短连接，服务端处理完毕之后，就会主动关闭连接

TIME_WAIT 含义是，我这边主动关闭连接， 我不会主动发送信息给你了，但是你发送的信息，我是可以正常接收的

其实咱们一般是可以这样来解决上述大量 TIME_WAIT 存在的情况的：

咱们简单思考一下，解决这个问题，要么是不产生这么多 TIME_WAIT 状态的连接，要么就是这个 TIME_WAIT 状态的连接能够更快的被释放掉，好空出闲置的端口来进行使用

对于这个思路的第一点：

客户端请求服务端的时候，头部的 connection 设置为 keep-alive，和服务端保持长连接的特性，保持存活一段时间

那么，对于思路的第二点：

那么是长连接，也是会有断开的时候，那么，如果是服务端这边主动断开的话，仍然会在服务端上出现 TIME_WAIT，我们是否可以考虑能够将这个TIME_WAIT 的时间缩短一点，就是去对 2MSL 做文章了

这个时间，可以根据咱们自身的设计来调整成 例如 1MSL 也是可以的，这并不完全是死的

注意哦：一般 1 个 MSL 是 120 秒，也就是 2 分钟

今天就是这样，下一次分享一波为什么需要 TIME_WAIT 状态