主动关闭与TIME_WAIT
TIMEWAIT状态本身 和应用层的客户端或者服务器是没有关系的。主动关闭的一方,在使用FIN|ACK|FIN|ACK四分组正常关闭TCP连接的时候 会进入TIMEWAIT状态。服务器在处理客户端请求的时候,如果你的程序设计为服务器主动关闭,那么你才有可能需要关注这个TIMEWAIT状态过多的问题。如果你的服务器设计为被动关闭,那么你首先要关注的是CLOSE_WAIT。
TIMEWAIT并不是多余的 。 在TCP协议被创造, 经历了大量的实际场景实践之后 , TIMEWAIT 出现了,因为TCP主动关闭连接的一方需要TIMEWAIT状态,它是我们的朋友。这是 《 UNIX网络编程 》的作者—-Steven对TIMEWAIT的态度。
TCP 要保证在所有可能的情况下使得所有的数据都能够被正确送达。
当你关闭一个 socket 时,主动关闭一端的 socket 将进入 TIME_WAIT 状态,而被动关闭一方则转入CLOSED状态。
其实不然。
这样安排状态有两个问题,
1. 我们没有任何机制保证最后的一个ACK能够正常传输,
2. 网络上仍然有可能有残余的数据包(wandering duplicates),我们也必须能够正常处理。
TIMEWAIT就是为了解决这两个问题而生的。
1.假设最后一个 ACK 丢失了,被动关闭一方会重发它的 FIN。 主动关闭一方必须维持一个有效状态信息(TIMEWAIT状态下维持),以便能够重发 ACK。 如果主动关闭的socket不维持这种状态而进入CLOSED状态,那么主动关闭的socket在处于CLOSED状态时, 接收到FIN后将会响应一个RST。被动关闭一方接收到RST后会认为出错了。如果TCP协议想要正常完成必要的操作而终止双方的数据流传输,就必须完全正确的传输四次握手的四个节,不能有任何的丢失。这就是为什么socket在关闭后,仍然处于TIME_WAIT状态的第一个原因,因为他要等待以便重发ACK。
2.假设目前连接的通信双方都已经调用了 close() ,双方同时进入 CLOSED状态,而没有走 TIME_WAIT 状态。会出现如下问题,现在有一个新的连接被建立起来,使用的IP地址与端口与先前的完全相同,后建立的连接是原先连接的一个完全复用。还假定原先的连接中有数据报残存于网络之中,这样新的连接收到的数据报中有可能是先前连接的数据报。为了防止这一点,TCP不允许新连接复用TIME_WAIT状态下的socket。处于TIME_WAIT状态的socket在等待两倍的MSL时间以后(之所以是两倍的MSL,是由于MSL是一个数据报在网络中单向发出到认定丢失的时间,一个数据报有可能在发送途中或是其响应过程中成为残余数据报,确认一个数据报及其响应的丢弃的需要两倍的MSL),将会转变为CLOSED状态。这就意味着,一个成功建立的连接,必然使得先前网络中残余的数据报都丢失了。
大量TIMEWAIT出现,并且需要解决的场景
在高并发短连接的TCP服务器上,当服务器处理完请求后立刻主动关闭连接。。。这个场景下, 会出现大量socket处于 TIMEWAIT 状态。如果客户端的并发量持续很高, 此时部分客户端就会显示连接不上。
我来解释下这个场景。主动正常关闭TCP连接,都会出现TIMEWAIT。为什么我们要关注这个高并发短连接呢?有两个方面需要注意 :
1. 高并发可以让服务器在短时间范围内同时占用大量端口,而端口有个0~65535的范围,并不是很多,刨除系统和其他服务要用的,剩下的就更少了 。
2. 在这个场景中,短连接表示“业务处理+传输数据的时间远远小于TIMEWAIT超时的时间”的连接。比如,1秒钟的http短连接处理完业务, 在关闭连接之后,这个业务用过的端口会停留在TIMEWAIT状态几分钟,而这几分钟,其他HTTP请求来临的时候是无法占用此端口的,服务器资源严重浪费。(说个题外话,从这个意义出发来考虑服务器性能调优的话, 长连接业务的服务就不需要考虑TIMEWAIT状态。同时,假如你对服务器业务场景非常熟悉,你会发现,在实际业务场景中, 一般长连接对应的业务的并发量并不会很高 )
综合这两个方面,持续的到达一定量的高并发短连接,会使服务器因端口资源不足而拒绝为一部分客户服务。同时,这些端口都是服务器临时分配,无法用SO_ REUSE ADDR选项解决这个问题