tcp四次挥手

tcp四次挥手

四次挥手，其实整体而言用一个生活中的例子可以解释，a，b2个人是战友，正在执行任务，a，b2个人拿着对讲机交流了战术，交流完成之后，a对b说，我说完了，b收到了，b思考一下，看自己有没有说完，如果说完了，就也跟a说，我也说完了，如果没有继续说，一直到说完为止。

看图

注意不一定是客户端先向服务器发送fin断开，谁都可以是主动方。

以客户端为主动方为例

fin-wait-1:表示客户端要关闭连接，向服务器发送fin报文。

close-wait:表示在等待关闭，当客户端发送fin给自己，服务器也会回应一个ack，此时则进入到close-wait状态，
在这个状态，服务器也要考虑自己是否还有数据发送给客户端，如果没有，发送fin报文给客户端。

fin-wait-2:只要客户端收到服务器的ack确认之后，就会处于此状态，然后等待服务器发送fin报文。

last-ack:服务器在发送fin报文后，最后等待客户端的ack报文，当收到之后ack报文后，进入closed状态

time-wait:表示收到了服务器的fin报文，并发送了ack报文，就等2msl后即可进入closed状态。当然如果在fin-wait-1的状态下面收到了服务器带fin标志跟ack标志的报问时，客户端直接进入time-wait 不需要进入fin-wait-2

closed：关闭状态

CLOSING：一种比较特殊的状态
1.表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文
2.如果双方几乎在同时准备关闭连接的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态
3.表示双方都正在关闭连接

也就是说我客户端与服务器都是主动方的时候

对于time-wait阶段的疑问

1.为什么要等2倍的msl？
首先msl是tcp报文在internet上的最长生存时间
也就是说 如果没有此阶段，上面的例子，客户端发送最后一个ack就关闭了，假设最后一个ack因为网络的原因，服务器没有收到ack，就会重新发送fin，这个时候可能出现的情况有以下几种
1.客户端可能有一个新的程序分配了同一个端口，如果收到fin后马上开始执行断开连接的操作，它可能是想跟服务器建立连接的。
2.客户端没有响应，服务器那边会重发多次fin。

总结一下，作用就是保证tcp传输的可靠性，防止本次连接的请求到下一次。

但是这里我有一个疑问？
假设服务端发送的FIN+ACK包在MSL的最后一个时刻传输到了客户端，而客户端回发了ACK包，此时客户端开始了TIME-WAIT；如果ACK经过MSL还未发送到，服务端就超时重传FIN+ACK包，FIN+ACK的存活时间是MSL，则在重发的（FIN+ACK包）+前一个ACK包，此时最极端情况为2MSL，则客户端要保持2MSL内能处理服务端重发的FIN+ACK包。
这里突然想，如果重发的FIN+ACK又丢失，那么已经经过2MSL，客户端发送过ACK包了，就默认服务器收到了ACK包关闭了连接，那么此时服务器不就关闭不了？

也就是如果重发的FIN+ACK又丢失，那么已经经过2MSL，客户端发送过ACK包了，就默认服务器收到了ACK包关闭了连接，那服务端不就无法正常关闭了？
我的答案就是，2msl只是防止，不是百分百的解决 ，可能响应rst，不然rst是干什么用的。

这里就不说为什么是四次挥手了，其实就是全双工的一个问题。

以上内容如果有不对请多多指教。