TCP之三次握手与四次挥手

三次握手

三次握手的过程是为了确认双方的接收与发送能力是否正常。

1、第一次握手:客户端给服务器发送一个 SYN 报文,这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的。

2、第二次握手:服务器收到 SYN 报文之后,会应答一个 SYN+ACK 报文,这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

3、第三次握手:客户端收到 SYN+ACK 报文之后,会回应一个 ACK 报文,这样服务端就能得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常。

4、服务器收到 ACK 报文之后,三次握手建立完成。

具体过程:

当客户端发出第一个连接请求报文段时并没有丢失,而是在某个网络节点出现了长时间的滞留,以至于延误了连接请求在某个时间之后才到达服务器。这应该是一个早已失效的报文段。但是服务器在收到此失效的连接请求报文段后,以为是客户端的一个新请求,于是就想客户端发出了确认报文段,同意建立连接。假设不采用三次握手,那么只要服务器发出确认后,新的连接就可以建立了。但是由于客户端没有发出建立连接的请求,因此不会管服务器的确认,也不会向服务器发送数据,但服务器却以为新的运输连接已经建立,一直在等待,所以,服务器的资源就白白浪费掉了。

四次挥手

tcp是全双工通信,服务端和客服端都能发送和接收数据。

tcp在断开连接时,需要服务端和客服端都确定对方将不再发送数据。

  • 第1次挥手由客户端向服务端发起,服务端收到信息后就能确定客户端已经停止发送数据。
  • 第2次挥手由服务端向客户端发起,客户端收到消息后就能确定服务端已经知道客户端不会再发送数据。
  • 第3次握手由服务端向客户端发起,客户端收到消息后就能确定服务端已经停止发送数据。
  • 第4次挥手由客户端向服务端发起,服务端收到信息后就能确定客户端已经知道服务端不会再发送数据。

为什么需要四次挥手?而三次却不可以

主要是为了确认客户端和服务器端都已经关闭了,避免出现以下两种情况(此处暂时忽略超时机制)

1)客户端不知道服务器端已经关闭,还在继续发送消息,浪费网络资源。

2)服务器端不知道客户端已经关闭,还在等着客户端发来的消息,浪费服务器资源。

为什么TCP客户端最后还要发送一次确认呢?

主要防止已经失效的连接请求报文突然又传送到了服务器,从而产生错误。

如果使用的是两次握手建立连接,假设有这样一种场景,客户端发送了第一个请求连接并且没有丢失,只是因为在网络结点中滞留的时间太长了,由于TCP的客户端迟迟没有收到确认报文,以为服务器没有收到,此时重新向服务器发送这条报文,此后客户端和服务器经过两次握手完成连接,传输数据,然后关闭连接。此时此前滞留的那一次请求连接,网络通畅了到达了服务器,这个报文本该是失效的,但是,两次握手的机制将会让客户端和服务器再次建立连接,这将导致不必要的错误和资源的浪费。如果采用的是三次握手,就算是那一次失效的报文传送过来了,服务端接受到了那条失效报文并且回复了确认报文,但是客户端不会再次发出确认。由于服务器收不到确认,就知道客户端并没有请求连接。

为什么2、3次挥手不能合在一次挥手中?

因为TCP是一个全双工协议,必须单独拆除每一条信道。4次挥手的目的是终止数据传输,并回收资源,在客服端第1次挥手时,服务端可能还需要发送数据,在服务端的数据发送完成后,才能通知客户端不在发送数据。所以第2次挥手和第3次挥手不能合并。此时客服端虽然不再发送数据了,但是还可以接收数据,服务端可能还有数据要发送给A,所以两次挥手不能合并为一次。

挥手次数比握手多一次,是因为握手过程,通信只需要处理连接。而挥手过程,通信需要处理数据+连接

当客户端发出第一个连接请求报文段时并没有丢

文章参考自:

【TCP/IP】四次挥手的过程及原因 - 简书

今日头条

  • 2
    点赞
  • 17
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值