工作中无论是开发环境还是线上环境，我们都出现过大量的 timewait 状态的连接，例如下面这个例子
服务端简单的开辟一个 web server 监听 9966 端口
[图片上传失败...(image-7f5050-1694098134824)]
客户端进行疯狂的请求服务端
[图片上传失败...(image-53e0fe-1694098134824)]
瞬间就可以看到咱们服务端的出现大量的 TIME_WAIT 状态的连接
[图片上传失败...(image-5d230e-1694098134824)]
这个时候，如果客户端再不停的请求服务端的话，我们就可以看到会出现这样的一个错误 address already in use : connect
这个时候是表示咱们已经没有可以使用的端口， 地址都在被使用中
那我们来看一下为什么会出现上述这种情况，以及我们如何去解决他呢？
为什么会出现这么多的 TIME_WAIT 状态
上面其实咱们也看到了，出现大量 TIME_WAIT 状态，一般是出现在高并发场景，同时有多个请求进来， 如果基本都是短连接，那么服务端处理完毕请求之后就会关闭连接，那么服务端就会出现大量的 TIME_WAIT 状态的连接，需要等待 2 MSL 的报文最大存活时间，才会被系统释放回收，回收哦，又空余出连接数，来进行服务
简单的咱们可以使用如下命令来查看我们的 TIME_WAIT 状态的连接数
netstat -antp|grep TIME_WAIT |wc -l
上述这种情况，在并发的时候，我们的某些请求可能没有办法得到处理，这是为什么呢？
有一点网络基本知识的我们知道，咱们的 TCP 结构是这样的：
[图片上传失败...(image-d8527d-1694098134824)]
对于目的端口和源端口，在 tcp 包头上都是占用 16 bit ，那么就是分别 65535 个端口，此处客户端请求服务端，那么源端口最多也就是 65535 个连接
而当我们请求服务端时，报错地址正在被使用，咱们就需要等待最大 2MSL 的时间，才能正常连接服务端了
[图片上传失败...(image-b2c032-1694098134824)]
我们如何处理 TIME_WAIT 大量存在的情况
我们如何处理 TIME_WAIT 大量存在的情况呢？前提是我们先知道这个 TIME_WAIT 是产生在哪一边的，一般情况下多数是发生在服务端
对于 TCP 的三次握手和四次挥手就不在此处做详细阐述了，对于基本 TCP 原理中，客户端和服务端，哪一端先发起关闭连接，那么 TIME_WAIT 就会出现在哪一端，例如下面这个简图：
[图片上传失败...(image-52d21c-1694098134824)]
那么，我们可以知道上述例子，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 状态
感谢阅读，欢迎交流，点个赞，关注一波 再走吧
欢迎点赞，关注，收藏
朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力
[图片上传失败...(image-d55c38-1694098134824)]
好了，本次就到这里
技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。
我是阿兵云原生，欢迎点赞关注收藏，下次见~
网友评论