关于TCP四次挥手

今天看公众号编程珠玑推了TCP四次挥手的相关内容，想着打开复习一遍，在复习的过程中发现了一些新的问题，在此记录。
首先回顾TCP四次挥手的几个步骤：

1. 客户端向服务器端发送释放报文FIN = 1，处于FIN_WAIT1状态；
2. 服务器端收到后发出确认，向客户端发送ACK = X + 1，处于CLOSED_WAIT状态。（此时TCP处于半关闭状态，服务器端可以向客户端发送数据，客户端不可以向服务器端发送数据。）；
3. 当服务器端不再需要连接后，发送连接释放报文FIN = 1；
4. 客户端收到后发出确认，此时进入TIME_WAIT状态，等待2MSL后释放连接，B收到后确认释放。

TIME_WAIT的作用：

• 为了确保最后一个确认报文达到服务器端；
• 为了让本连接持续时间内所产生的报文从网络中消失。

情况一：如果第四次挥手时客户端给服务器端发送确认报文，服务器端却一直没有收到怎么办？

这里重点分析第三次和第四次挥手（上述3、4），以及TIME_WAIT状态：
首先TIME_WAIT时间是2MSL，在步骤4中，客户端发送确认报文给服务器后会等待1MSL的时间，如果服务器没有收到那么客户端会再发送一次，但是如果超过2MSL时间，客户端将不再重发确认报文并进入CLOSED状态。
那么如果客户端就此关闭不再发送确认报文给服务器端，服务器端就无法收到确认也就无法释放了？对于该问题，如果服务器端一直无法收到来自客户端的确认报文，那么会收到一个RST，认为出错。

参考资料：
LAST_ACK收不到ACK如何关闭？
会重发FIN，这时候分两种情况
(1)主动断开的一方还在TIME_WAIT状态中。这时候会发过来ACK， 被断开的一方收到后顺利从LAST_ACK进入到CLOSED。
(2)主动断开的一方经过了2msl已经CLOSED了这时候会返回RST。被断开的一方收到后也会进入CLOSED状态。总之LAST_ACK总会进入到CLOSED状态不需要超时机制。

另外补充连接复位RST：

四次握手不是关闭TCP连接的唯一方法。有时，如果主机需要尽快关闭连接(或连接超时，端
口或主机不可达)，RST (Reset)包将被发送.。由于RST包不是TCP连接中的必须的部分，可以只发送RST包(即不带ACK标记)。但在正常的TCP连接中RST包可以带ACK确认标记。

20190719更新 情况二：在挥手时，如果由服务器端率先发起终止连接，四次挥手会怎么进行？

今天和小伙伴讨论了TCP四次挥手的另一种情况：在挥手时，如果由服务器端率先发起终止连接，四次挥手会怎么进行？（参考@_stark）
一般而言，都是由客户端发起四次挥手，如果服务器端异常终止，当服务器进程被终止时，会关闭其打开的所有文件描述符，此时会向客户端发送一个FIN报文，客户端则会响应一个ACK报文，这样只完成了前两次挥手，即只实现了半关闭，客户端此时还能向服务器端写入数据。
但是，当客户端向服务器端写入数据时，由于服务器的socket进程已经终止，此时连接状态异常，服务器端并不会向客户端发送确认报文，而是会发送一个RST报文请求将处于异常状态的连接复位。 如果客户端此时还要向服务端发送数据，将诱发服务端TCP向服务端发送SIGPIPE信号，因为向接收到RST的套接口写数据都会收到此信号. 所以说，这就是为什么我们主动关闭服务端后，用客户端向服务端写数据，还必须是写两次后连接才会关闭的原因。