TCP三次握手 四次挥手

主动发起断开连接的一方，最后需要等待2MSL。

大写的ACK标志位为1，是针对SYN为1或FIN为1的报文的确认报文

ACK和ack不是一样的，ACK是和SYN FIN一样的标志位，只有0 1 两个值，而小写的ack是对报文序号seq的确认

四次挥手等待2MSL（Maximum Segment Life）的原因

1.客户端主动发起断开，发送FIN 进入 FIN_WAIT_1 状态

2.服务端收到FIN，发送ACK，这样就断开了一方的连接，客户端不可再发送数据（确认FIN的报文还是可以发的） 进入CLOSE_WAIT状态

3.服务端发送FIN 进入LAST_ACK 状态

4.客户端发送 ACK，进入TIME_WAIT状态，等待2MSL时间（服务端如果收到了这个确认，他就可以确认，双方一致同意关闭，就可以真正关闭了，无需再等待，服务端进入CLOSED状态）

原因1，看第4步客户端发送给服务端的ACK

服务端可能接收到了，也可能没收到这个ACK
如果服务端收到了这个ACK，可以直接关闭连接，无需再等待什么，但客户端不知道服务端有没有收到，毕竟没有后续的确认了，所以要等2MSL，防止服务端没收到该ACK信息
如果在客户端发送了这个ACK 1MSL时，服务端没收到，会认为对方没有收到自己的FIN请求（不会认为是自己没收到确认回复，保险起见），立刻重传FIN
再经过1MSL内，客户端这边会收到重传的FIN请求并重新ACK，以尽可能让对方连接正常关闭

当然，有人又思考了，本次服务端重传的FIN请求又他娘的丢了，这怎么办？
这个时候客户端在等待了2MSL后，发现没有数据来，就正常关闭了，而服务端这边，最后的FIN还没得到应答，又重传FIN，但对方已经关闭了
所以会收到客户端的RST报文，也会退出连接。
奥，服务端没有收到客户端的ACK，然后客户端没收到服务端重传的FIN？
这样的网络还有什么意义，啥也收不到，一直丢，所以也应该断开连接。
总之，客户端这边等待了2MSL后，都应该断开连接

原因2

断开连接，意味着要接收下一个新的连接，那如果某个TCP连接刚断开，马上建立一个新的连接，新的连接和上一个刚断开的连接相同，IP和端口相同
如果上一个连接发送的数据因为某些原因滞留在网络中，兜兜转转刚好在新连接建立起来后到了
那新的连接如何区分，这收到的数据，是上一个连接的数据还是新连接的数据？
所以，在客户端发送最后一个ACK后，等待2MSL，第一个MSL是等待客户端自己发送的数据到达对方，第二个MSL是对方发送的数据到达己方
这样2MSL后，网络里就“应该”不存在上一个连接的老数据了，或者说概率很低了。
像上面又他娘丢了的情况，确实还会让网络连接里仍然有上一个连接的数据，但概率很低了。