目录TIMEWAIT `在有友好`大量` TIMEWAIT的情况下引发的`棘手的业务问题'必须可行且存在，`不符合原则的解决方法'如何`尽量合理处理` TIMEWAIT太多了
从图中可以看到，活动闭合处于TIME_WAIT状态； 被动关闭将处于CLOSE_WAIT状态。
该计时器是TIME_WAIT计时器，当主动侧a向对方b发送FIN之后被动侧b发送ACK时，主动侧a变为TIME_WAIT状态(为了等待b发送FIN ACK )。 如果在计时器时间内没有接收到来自b的FIN ACK，则a重新启动TIME_WAIT计时器并继续等待来自b的FIN ACK。 保证全双工管道的安全切断。
时间等待是友好的Note1。 什么是TIME_WAIT状态？
客户端在接收到服务器发送的FIN段后不会立即进入关闭状态，而在TIME_WAIT状态下，客户端连接需要2MSL的时间才能完全终止。
Note2:TIME_WAIT状态存在的两个原因
)1)可靠地终止TCP连接
如果消息段7(ack )丢失，则服务器重发消息段6(fin )，并且客户端必须保持在TIME_WAIT状态以处理重复接收的消息段6(fin ) (补充说明：如果没有2MSL等待时间，客户端只能通过RST段响应服务器，并且连接异常终止) )。
)2)允许旧的重复分解在网上消失
假设在12.106.32.254上的1500端口和206.168.112.219上的21端口之间建立了连接，关闭此连接。 经过一段时间后，在同一IP和端口之间建立另一个链接。 以下连接是上一个连接的头像，因为IP和端口相同。==TCP需要防止来自一个连接的旧重复包在该连接终止之后重构，且被误解为属于同一连接的新化身。==为此，TCP协议栈规定，处于TIME_WAIT状态的连接不能开始新的头像。 (因为TIME_WAIT状态的持续时间是MSL的两倍，这足以在沿传送方向的分组生存最大MSL秒之后丢弃，并且沿接收响应方向的分组最大MSL也丢弃，所以TIME_WAIT状态连接到先前化身
许多TIMEWAIT在某些情况下遇到的棘手业务问题是，在高并发短连接的TCP服务器上，服务器在处理请求后立即主动关闭连接。 在此场景中，大量套接字处于TIMEWAIT状态。 如果客户端并发性高，则会显示某些客户端无法连接。 让我来说明这一幕。 主动关闭TCP连接时，将显示TIMEWAIT。 我们为什么要关注这个高同时短接呢？ 有两点需要注意：
高并发性允许服务器在短时间内同时占用大量端口，但端口范围在0到0~65535之间，并不多。 删除系统和其他服务后，剩下的就很少了。 在此情况下，短连接是指“业务处理传输数据的时间远远短于TIMEWAIT超时时间”的连接。 在这里，有一个相对较短的概念。 例如，取网页，通过1秒钟的http短连接处理业务，关闭连接后，此业务使用的端口在TIMEWAIT状态下停留几分钟，但在这几分钟内，当有其他http请求到来时可以占用此端口如果只计算服务器的利用率，则可以看到服务器正常运行的时间和端口(资源)锁定而不可用的时间的比例为1:00，这极大地浪费了服务器资源。 (闲话不多说，从这个意义上讲，考虑到服务器的性能调整，长期连接业务的服务不需要考虑时间等待状态。 此外，如果熟悉服务器的业务场景，就会发现在实际的业务场景中，与较长连接相对应的业务并发连接数通常并不是很高。 )综合这两个方面，持续达到一定量的高并发连接会导致端口资源不足，拒绝为某些客户提供服务。 此外，这些端口是服务的临时分配，SO_REUSEADDR选项无法解决此问题。
一对矛盾： TIMEWAIT友好，头疼。 但是，有必要以友好的态度来看待它。 那是因为竭尽其能力保证了服务器的健壮性。
在可能且必须存在但不符合原则的解决方案linux中，在sysctl或proc文件系统中没有用于修改此TIMEWAIT超时时间的接口，并且在内核协议栈的代码中此TIMEWAIT包含利用SO_LINGER选项的强制关闭方式，发送RST而不是FIN，从而越过TIMEWAIT状态，直接进入关闭状态。 (详情请参阅详细解说插座选项的SO_LINGER。 )为什么我认为上述两种解决方法是可行的，但不符合原则呢？
首先，我们认为要依靠TIMEWAIT的状态来保证服务器程序的稳健性，网络上出现的乱七八糟的问题太多，首先服务功能必须正常。
那个不需要性能吗？ 不。 如果服务器上的短连接通信量到了我真的需要解决这个时间等待状态太多的问题的时候，解决的原则是尽快解决，而不是和时间等待做。 )如果尽量处理，但不能解决问题，拒绝部分服务要求，我将采取分机对抗这些高并发短请求的方法。 拿着
续十万并发的短连接请求，两台机器，每台5万个，应该够用了吧。一般的业务量以及国内大部分网站其实并不需要关注这个问题，一句话，达不到需要关注这个问题的访问量。真正地必须使用上述我认为不合理的方式来解决这个问题的场景有没有呢？答案是有，像淘宝、百度、新浪、京东商城这样的站点，由于有很多静态小图片业务，如果过度分服会导致需要上线大量机器，多买机器多花钱，得多配机房，多配备运维工程师来守护这些机器，成本增长非常严重。这个时候就要尽一切可能去优化。 如何尽量并合理地处理TIMEWAIT过多 sysctl改两个内核参数就行了，如下：
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
简单来说，就是打开系统的TIMEWAIT重用和快速回收，至于怎么重用和快速回收，这个问题我没有深究，实际场景中这么做确实有效果。用netstat或者ss观察就能得出结论。还有些朋友同时也会打开syncookies这个功能，如下：
net.ipv4.tcp_syncookies = 1
打开这个syncookies的目的实际上是：“在服务器资源（并非单指端口资源，拒绝服务有很多种资源不足的情况）不足的情况下，尽量不要拒绝TCP的 syn（连接）请求，尽量把syn请求缓存起来，留着过会儿有能力的时候处理这些TCP的连接请求”。
如果并发量真的非常非常高，打开这个其实用处不大。