TCP连接的状态——TIME_WAIT的存在意义

首先需要声明这是我在第二次学习TCP这部分内容时，根据教材总结出的我的理解，也是新手一个哈，如果还存在一些问题和误区，希望大佬能指正。

回顾三次握手、四次挥手

三次握手：

客户端向服务器端发送SYN报文，seq是序号
服务器端向客户端恢复ACK的确认信息，并发送自己的SYN
客户端再对服务器端恢复确认

四次挥手

发送断开链接的报文FIN，
对方回复确认信息，
当对方也需要关闭的时候，也给对方发送FIN，
对方再恢复ACK确认信息

状态转移图分析

起始是一个一个假想的状态，CLOSED，当程序被动打开，处于监听状态LISTEN，①客户端会向服务器端发送SYN报文，此时的客户端处于SYN_SENT状态，这个状态存在的时间特别短，所以在Linux中查看状态信息，一般不容易看到。②服务器端接收到客户端发送的SYN，并发送自己的SYN以及对收到报文的确认，同时服务器端处于SYN_RCVD状态，这个状态和上面提及到的服务器端的SYN_SENT一样，存在的时间很短。③客户端收SYN,ACK。

此时完成三次握手，客户端和服务器端都会处于ESTABLISHED状态，并在此状态进行数据的收和发

如果有一方想要关闭链接，则会进入到蓝框和紫框的四次挥手状态过程，具体分析如下：
首先明确：主动关闭的一端走蓝框的流程，被动关闭的一方走红框的流程
加入客户端主动关闭连接，就会发送FIN，并处于FIN_WAIT_1，此时服务器端接收FIN，并发送确认信息ACK，使得服务器端处于CLOSE_WAIT状态。当客户端接收到来自服务器端的ACK确认信息之后，进入到FIN_WAIT_2状态。
随后，如果服务器端想要关闭连接，就会向客户端发送FIN关闭连接的报文，然后程序关闭，处于LAST_ACK状态。客户端收到FIN,并发送给服务器端ACK，此时，客户端进入TIME_WAIT状态，当服务器端接收到ACK之后，消失。

那么重点来了：TIME_WAIT存在究竟有什么作用呢？
Linux高性能服务器编程中说到两点原因：
①可靠地终止TCP连接
②保证让迟来的TCP报文段有足够的时间被识别并丢弃

这里我用两个例子分别对两点作用加以解释：
例1：当进行程序关闭的时候，如果没有time_wait状态，那么主动关闭的一端就会在FIN_WAIT_2时收到FIN并发送ACK后直接退出,这个过程中，主动关闭的这一段发送的确认报文ACK在发送的过程中有可能发送失败，那么被动关闭的一端就有可能收不到ACK的确认信息，就会再次发送FIN，这使得TCP连接的终止并不可靠。
例2：如果蓝框是服务器端的关闭流程（这里只是举例，假设蓝框是服务器端，当然也可以是客户端，另一端也就是服务器端，都是可以的），紫框那部分是客户端的关闭流程，当网络中存在延迟的时候，有可能客户端已经关闭了，但是网络中延迟的那部分数据还没有发送到服务器端，如果这时候服务器端也立刻关闭，那延迟的这部分数据就无法被接收到，如果下一次再执行原来的端口，上次没被接收到报文就会被继续发送过来。所以此时，让主动关闭的服务器端处于time_wait状态，停留两个报文的生存期，从而保证让迟来的TCP报文段有足够的时间被识别并丢弃。