码迷,mamicode.com
首页 > 其他好文 > 详细

三次握手、四次挥手基础

时间:2019-11-22 01:14:00      阅读:89      评论:0      收藏:0      [点我收藏+]

标签:接收   情况下   多资源   第四次   lis   style   导致   详解   报文   

建立连接——“握手”;     关闭连接——“挥手”;

 

三次握手详解

      第一次:消息发送中,A端随机选取一个序列号作为自己的初始序号发送给B;

      第二次:B端使用ack对A发送来的数据包进行确认,因为已经收到了序列号为x的数据包,准备接收序列号为x+1的包,所以ack=x+1,同时B告诉A自己的初始序列号,就是seq=y;

      第三次:A端告诉B端收到了B的确认消息并准备建立连接,A自己此条消息的序列号是x+1,所以seq=x+1,而ack=y+1是表示A正准备接收B序列号为y+1的数据包。

 

为什么A端后来还要发送一次确认呢?

      为了防止已失效的链接请求报文突然又传到了B端,因而产生错误。

 

所谓“已失效的链接请求报文”的产生原因:

      正常情况:A发出连接请求,但因连接请求报文丢失而未收到来自B的确认报文,于是A再重传一次连接请求。后来收到了B的确认报文并建立了连接。数据传输完毕后就释放了连接。

      A共发送了两个连接请求报文段,其中第一个丢失,第二个到达了B端————没有“已失效的链接请求报文”;

 

      异常情况:A发出连接请求,但并没有丢失,而是在某些网络节点长时间滞留了,导致请求报文延误到某个连接释放以后才到达B端。本来这是一个早已失效的报文段。但B收到此失效的连接请求报文后就误以为是A又发出一次新的连接请求,于是向A发出确认报文段,同意建立连接。假设不采用三次握手,那么只要B发出确认,新的连接就建立了。而现在A并没有发出建立连接的请求,因此不会理睬B的确认报文,也不会向B发送数据;但B却认为新的传送链接已经建立了,并一直等待A发来数据,B的许多资源就此浪费了。

      采用三次握手可以防止该异常现象发生。刚才的情况下:A不会向B端的确认报文发送确认,B收不到A的确认就知道A并没有要求建立连接。

     

 

四次挥手详解:

      全双工:通信允许数据在两个方向上同时传输,即指A→B的同时B→A,是瞬时同步的。

      单工:在甲方向乙方传送数据时,乙方不能向甲方传送 。(比喻汽车的单行道。)

     

      TCP是全双工的,因此每个方向都必须单独进行关闭,当一方数据发送完成后再发送一个FIN来终止该方向的连接,但是收到一个FIN只是意味着这一方不会再收到数据,而这一方仍然可以发送数据,直到对方发送了FIN。

 

      第一次挥手:Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态;

      第二次挥手:Server收到FIN后,发送一个ACK给Client,确认序号为收到序号+1,Server进入CLOSE_WAIT状态;

      第三次挥手:Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态;

      第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态,接着发送一个ACK给Server,确认序号为收到序号+1,Server进入CLOSED状态,完成四次挥手。

 

为什么建立连接是三次握手,而关闭连接却是四次挥手呢?

      这是因为服务端在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。

      而关闭连接时,收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,己方也未必全部数据都 发送给对方了,所以己方可以立即close,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送。

三次握手、四次挥手基础

标签:接收   情况下   多资源   第四次   lis   style   导致   详解   报文   

原文地址:https://www.cnblogs.com/panweiwei/p/11909209.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!