赞
踩
声明: 本文不保证每个定义绝对严谨, 只是通过更加通俗易懂的语言来让阅读者更好的理解三次握手及四次挥手的过程!!!
首先我们来明白几个定义:
1. FIN: 请求关闭报文
2. SYN: 请求建立连接
3. ACK: 确认收到
4. MSL: 最大报文生存时间
三次握手理解起来比较简单, 说白了就是一个确认双方都能发送且都能接收的一个过程.
第一步: 客户端想要与服务器建立连接, 于是向服务器发送SYN报文请求连接.
第二步: 服务器收到客户端的连接请求之后, 服务器向客户端发送确认报文ACK及请求连接报文SYN
第三步: 客户端收到服务器的连接请求, 向服务器发送确认报文ACK
然后我们用通俗易懂的话来说一下这三步都在做什么:
第一步让服务器知道客户端能够发送, 第二步让客户端知道服务器能够接收并且能够发送, 第三步在服务器接收到ACK之后,服务器知道了客户端能够发送, 至此双方都能确认了对方能够收和发, 接下来就是愉快的互相收发数据的过程啦~
四次挥手是一个双方断开连接的过程, 这个过程中大家要理解的点有三个:
1. 为什么第二次挥手和第三次挥手不能合并为一次
2. 第二次挥手和第三次挥手之间的等待是在干什么
3. 主动发起方为什么要在第四次挥手之后等待2MSL的时间
我们逐步来解释:
第一步: 客户端做为主动发起方想要与服务器断开连接, 所以向服务器发送FIN报文
第二步: 服务器收到客户端的FIN报文, 向客户端发送ACK确认报文, 也就是说服务器告诉客户端说我收到你的关闭请求了
第三步: 服务器等待时间结束之后, 向客户端发送FIN报文, 告诉说客户端我请求关闭
第四步: 客户端收到服务器的FIN报文之后, 向服务器发送ACK确认报文, 告诉服务器说我也收到了你的关闭请求了. 此时如果服务器收到了ACK报文,服务器就关闭了, 而客户端还要等待2MSL的时间之后才能关闭
1. 为什么第二次跟第三次不能合并, 第二次和第三次之间的等待是什么?:
当服务器执行第二次挥手之后, 此时证明客户端不会再向服务器请求任何数据, 但是服务器可能还正在给客户端发送数据(可能是客户端上一次请求的资源还没有发送完毕), 所以此时服务器会等待把之前未传输完的数据传输完毕之后再发送关闭请求.
2. 主动发起方为什么最后要等待2MSL的时间:
上边我们说了服务器收到了最后一次的ACK报文之后就会关闭, 那客户端是不能知道服务器是否收到了这次ACK的, 所以客户端只能在这等待, 如果服务器在"超时时间"内真的没有收到最后一次的ACK,就会重新发送一次FIN, 那么在网络极端情况下(网络没断, 但是速度极慢, 需要整整1MSL的时间才能把报文发送过去),这次重发FIN需要1MSL的时间, 这一来一回需要的时间总和为:服务器超时时间+1MSL, 那为了保险起见,直接让客户端等待2MSL的时间, 如果2MSL之内客户端没有收到重发的FIN, 则默认为服务器收到了最后一次ACK,此时客户端就可以执行关闭了.
ps: 经阅读者反馈, 最后的四次挥手仍然不够通俗易懂, 那我在此给大家描述一个场景来跟四次挥手过程做个对照"
A: 主动发起方(客户端)
B: 被动关闭方(服务器)
A和B正在互相收发数据, 在B最后一次数据没发送完的时候, A突然说"FIN", B此时赶紧回复一句"ACK", 然后因为B之前的一次数据还没有发送完毕,所以要继续发送最后一次的数据, 等发完之后,B也对A说"FIN", A回复说"ACK", 此时A并不知道B有没有收到"ACK",A就会在此时开始等待, B也不知道B发的"FIN"A有没有收到, B会在发送完"FIN"之后等待一个"超时时间",如果超时之后仍然没有收到A发来的ACK,B就会认为他发的FIN并有有被A收到, 此时B就会重新发送FIN给A, 而在极端网络情况下一个报文可能需要一整个MSL才能发送成功, 那A的等待时间就是1个超时时间+1MSL, 为了更稳妥起见, 协议直接制定为主动发起方等待2MSL的时间, 如果A在2MSL的时间内都没有收到B重新发送的FIN, 则默认为B收到了最后一次ACK, 就可以执行关闭.
关于最后为什么要等待2MSL, 再次做个补充:
首先我们要明白主动关闭方是在等待什么? 是在等待服务器可能会重发过来的FIN, 那这个FIN在极端网络情况下需要多久才能发过来呢? 1. 服务器的超时时间(超时时间内服务器等不到ACK就会重发FIN), 2. 重发FIN所需要的最长时间(1MSL), 那这么算就是1个超时+1个MSL, 为了更稳妥直接为2MSL的时间.
不知道以上文字有没有更好的帮助你理解了tcp的三次握手及四次挥手, 有写的不对的地方欢迎评论指正交流.
最后我再抛出一个问题给诸位读者:
再次补充:
查阅了一些资料, 有的资料写着某些情况下只有三次挥手, 即第二次确认报文和第三次请求关闭报文合并为一次了,这种情况发生在服务器方的数据确认全部发送完毕时.此次补充不做真实性保证,诸位看看就行~
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。