关键名称解释：FIN终止位，ACK确认位， ack确认号， （期望得到的seq）， seq数据传输序号
1.握手图
client server
（1） FIN=1（client请求终止）,ACK=1（确认之前收到的数据）,seq=x（发送给server要发送的数据序号）
------------------------------------------->
（2） ACK=1（确认收到seq=x） ,ack=x+1（期望得到的seq=x+1 ） , seq=y（好吧我发给你一个数据y）
<-------------------------------------------
（3） FIN=1（server请求终止） ,ACK=1（确认收到seq=x） ,ack=x+1 （期望得到的seq=x+1 ） , seq=w（好吧我又发给你一个数据w ）
<-------------------------------------------
(4) ACK=1（确认之前收到的数据）,ack=w+1 （期望得到的seq=x+1 ） ,seq=x+1 （发送给server要发送的数据序号）
------------------------------------------->
下图是个完整的过程，便于理解和记忆。
2.相应解释
断开连接端可以是Client端，也可以是Server端。假设Client端发起中断连接请求：
第一次挥手：客户端先发送FIN报文（第24帧），用来关闭主动方到被动关闭方的数据传送，也就是客户端告诉服务器：我已经不会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，客户端依然会重发这些数据)，但此时客户端还可以接受数据。
第二次挥手：Server端接到FIN报文后，但是如果还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以服务器端先发送ACK（第25帧），告诉Client端：请求已经收到了，但是我还没准备好，请继续等待停止的消息。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。
第三次挥手：当Server端确定数据已发送完成，则向Client端发送FIN报文（第26帧），告诉Client端：服务器这边数据发完了，准备好关闭连接了。
第四次挥手：Client端收到FIN报文后，就知道可以关闭连接了，但是他还是不相信网络，所以发送ACK后进入TIME_WAIT状态（第27帧）， Server端收到ACK后，就知道可以断开连接了。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，最后，Client端也可以关闭连接了至此，TCP连接就已经完全关闭了！
MSL（Maximum Segment Lifetime）报文最大生存时间,2MSL即两倍的MSL，TCP允许不同的实现可以设置不同的MSL值。
3.具体直白语言描述
client ：我要终止了
server：当然可以
server：终止了
client 确认：好的
这是client还是不相信网络，在在等2MSL 如果确实没收到servler端的信息，则关闭自己的通信端口
4.总结
其实谁发起，谁进行TIME_WAIT，等待超时进行结束。
一起起因是网络不稳定。
5.为什么是4次不是其他次那？
比如是3次，把
握手图（2）省略
客户端：我要端口连接
服务器端：去你大爷的老子还没忙完等着吧 ，等我忙完告诉你。 这样客户端会不断的发送请求，服务器端也压力大。所以先告诉他我收到了也就是（2）
至于（4）为什么不能省略？
TIME_WAIT ：TCP 四次握手结束后，连接双方都不再交换消息，但主动关闭的一方保持这个连接在一段时间（2MSL两个最大报文生命周期时间）内不可用。
原因：
- 确保最后一个确认报文能够到达（如果B没收到A发送来的确认报文，那么就会重新发送连接释放请求报文，A等待一段时间就是为了处理这种情况的发生）
- 避免新旧链接混淆。（等待2MSL可以让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接请求不会出现旧的连接请求报文）
参考：
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
