TCP的三次握手四次挥手

三次握手

在这里插入图片描述

第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。
第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;
第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。

  • 客户端:服务器,我想要和你建立连接,你同意吗?(SYN=1)
  • 服务器:客户端,我同意和你建立连接(ACK=1);我也想和你建立连接,你同意吗?(SYN=1)
  • 客户端:服务器,我同意和你建立连接。(ACK=1)

其实,在进行第二次握手时(即服务器向客户端进行应答时),可以看作时发了两次包,先回答客户端的服务请求(ACK=1,确认号ack=x+1),然后向客户端发出请求(SYN=1,序列号seq=y)

问题1: 三次握手中,为什么客户端最后还要再向服务器发送一次确认呢?
答:这是为了防止已失效的连接请求报文段突然又传到了服务器。所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常的情况,客户端发出连接请求,但因为连接请求报文丢失而未收到确认。于是客户端再重传了一次连接请求,后来收到了确认,建立了连接。数据传输完后,就释放了连接。客户端共发送了两个连接请求报文段,其中第一个丢失,第二个到达了服务器,没有所谓的“已失效的连接请求报文段”。

四次挥手

在这里插入图片描述

(1)客户端A发送一个FIN,用来关闭客户A到服务器B的数据传送。
(2)服务器B收到这个FIN,它发回一个ACK,确认序号为收到的序号加1。和SYN一样,一个FIN将占用一个序号。
(3)服务器B关闭与客户端A的连接,发送一个FIN给客户端A。
(4)客户端A发回ACK报文确认,并将确认序号设置为收到序号加1。

  • 客户端:服务器,我想和你断开连接,你同意吗?(FIN=1)
  • 服务器:我同意(ACK=1)
    (在此期间,服务器可能还会向客户端发送数据,但是客户端却不能再向服务器发送数据)
  • 服务器:客户端,我想要和你断开连接,你同意吗?(FIN=1)
  • 客户端:我同意。(ACK=1)
    再等待2**MSL(四分钟)时间后就真正断开了连接。

问题2: 为什么客户端发送完最后一个数据后要在TIME-WAIT状态等待一段时间呢?
答:第一:为了保证客户端最后发送的那个ACK报文段能够到达服务器。这个ACK报文段可能会丢失。因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。服务器会超时重传这个FIN+ACK报文段,而客户端就能在2MSL时间内收到这个重传的FIN+ACK报文段。接着客户端重传一次确认,重新启动2MSL计时器,最后客户端和服务器都可以进入到CLOSED(关闭)状态。如果没有2MSL等待时间,那么就无法收到重传的FIN+ ACK包,无法进入正常的CLOSED状态。
第二,防止“已失效的连接请求报文段”出现在本连接中。客户端在发送完最后一个ACK报文段,再经过时间2MSL,就可以使本连接持续的时间内所产生的报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值