工作中无论是开发环境还是线上环境，咱们都呈现过大量的 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 状态
感激浏览，欢送交换，点个赞，关注一波 再走吧
欢送点赞，关注，珍藏
敌人们，你的反对和激励，是我保持分享，提高质量的能源
好了，本次就到这里
技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。
我是 阿兵云原生，欢送点赞关注珍藏，下次见~