TCP状态转移

TCP状态转移图

TIME_WAIT为什么持续两个MSL(报文段最大生存时间)

TIME_WAIT 为主动关闭的一方所出现的状态，上图为客户端主动关闭，假如客户端不维护 TIME_WAIT 为两个MSL周期，可能会出现一下两个不正常的情况

• 如果最后一个 ACK 丢失了，Server 会重新发送 FIN 信号，而这时 Client 已经处于 CLOSED 状态，Client 将会响应 RST, 从而导致 Server 非正常关闭。
• 如果断开连接之后，Client 又重新和 Server 建立新的连接，如果此时上一次连接的延迟的 ACK 又重新出现，会干扰新的连接。

当然 TIME_WAIT 持续两个MSL 周期，并不能完全解决以上不正常情况的发生。 但是还是要 “心怀感恩”，毕竟给了你两个MSL周期，已经足够 ”仁慈“了。哈哈。

TIME_WAIT的危害

系统分配给进程的文件句柄的个数是有限制的，一般TIME_WAIT的时间长大概是1-4分钟，尤其像http服务器这种面向短连接的进程，会产生大量的TIME_WAIT状态，一旦文件句柄的数目到达上限，新的请求就无法进行处理了，而且大量的TIME_WAIT状态占用资源影响性能。

TCP 为什么三次握手

1.为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

比如下面这种情况：
client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接

2.信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值。

net.ipv4.tcp_tw_reuse = 1表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；

net.ipv4.tcp_tw_recycle = 1表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。