TCP四次挥手的标志位

Question

看了很多文章，发现对四次挥手的报文的标志位有一些差异。看到的主流的是

1. 第一次挥手 FIN = 1 ACK = 1
2. 第二次挥手 ACK = 1
3. 第三次挥手 FIN = 1 ACK = 1
4. 第四次挥手 ACK = 1

如果是这样的，那我想知道第一次挥手和第三次挥手为什么需要将ACK置为1，还是这个ACK只是为了确认之前的数据报文，和四次挥手关系不大。

Answer 1

• 1的ack是为了确认之前的包。
• 对于3的ack感觉是不必要的，我没有在rfc规范中查到3需要带上ack。然而抓了下包发现3确实是fin+ack，我想这个可能是实现层面的一个优化。如果2的ack丢失了，则3的ack可以补偿不这个错误。同时抓包也发现2和3的ack的值都是一样的：都是对1的确认。

Answer 2

第一次挥手ACK是确认之前数据传输的包。

第三次挥手由于是服务端主动发起的FIN报文（第二次挥手报文里面ACK置1已经表示确认收到了客户端的FIN报文），所以第三次挥手可以设置ACK = 1,也可以不设置，我猜是为了规范化符合tcp协议的要求，尽量每个包都去确认，让建立连接后的所有传输的包都有ACK确认。