为什么建立 TCP 连接是三次握手,而不是两次或者四次?


接下来,从以下三个方面逐一进行分析:

  • 三次握手才可以阻止历史连接(主要方面)
  • 三次握手才可以同步双方初始序列号
  • 三次握手才可以避免资源浪费

一、阻止历史连接

我们考虑一种场景,客户端发送 SYN(seq = 80)报文后宕机了,而且该报文还被网络阻塞了,服务端并没有收到,接着客户端重启后,又重新向服务端建立连接,发送了 SYN(seq = 100)报文(注意!不是重传 SYN,因为重传的 SYN 序列号是相同的
在这里插入图片描述
[抛个问题,如果新的 SYN 先于 RST 到达,服务端又该如何处理?]
如果是两次握手,就无法阻止历史连接,因为服务端没有中间状态用来给客户端阻止历史连接,导致服务端初始化一个历史连接,造成资源浪费
在这里插入图片描述

二、同步双方初始序列号

使用 TCP 协议通信的双方,各自必须维护一个「序列号」,序列号是可靠传输的一个关键因素
在这里插入图片描述
四次握手也能同步双方初始序列号,但由于第二步和第三步可以优化成一步,所以就成了「三次握手」

两次握手只保证了一方的初始序列号能被对方成功接收,没办法保证双方的初始序列号都能被确认接收

三、避免资源浪费

在这里插入图片描述

### TCP建立连接采用三次握手的原因 TCP建立连接采用三次握手主要有两个重要原因。一是为了防止已失效的连接请求报文段突然又传到服务端,因而产生错误。假定出现一种异常情况,即客户端发出的第一个连接请求报文段并没有丢失,而是在某些网络结点长时间滞留了,一直延迟到连接释放以后的某个时间才到达服务端,本来这是一个早已失效的报文段。但服务端收到此失效的连接请求报文段后,就误认为是客户端又发出一次新的连接请求,于是就向客户端发出确认报文段,同意建立连接。假定不采用三次握手,那么只要服务端发出确认,新的连接建立了,这样服务端一直等待客户端发来数据,服务端的许多资源就这样白白浪费了,可能还会产生死锁问题,采用三次握手恰好就避免了这个问题 [^3]。 二是为了同步客户端和服务端的初始序列号以及确认双方的发送和接收能力。客户端向服务端发送连接请求报文段,包含自己的初始序列号,服务端收到后发送确认报文段,包含自己的初始序列号和对客户端序列号的确认,客户端再发送确认报文段,完成序列号的同步。通过三次握手,双方都能明确对方的序列号和接收能力,确保后续数据传输的正确性 [^1][^2][^3][^4]。 ### TCP断开连接采用四次挥手的原因 TCP断开连接采用四次挥手是因为TCP是全双工通信,即双方都可以独立地发送和接收数据。当一方想要关闭连接时,它会发送一个FIN报文段,表示自己已经没有数据要发送了,但仍然可以接收对方的数据。另一方收到FIN报文段后,会发送一个ACK报文段进行确认。此时,发送FIN的一方不能再发送数据,但可以接收数据。之后,另一方也可能有数据要发送,当它发送完所有数据后,会发送一个FIN报文段,表示自己也没有数据要发送了,对方收到后再发送一个ACK报文段进行确认,至此连接完全关闭。由于每个方向的关闭都需要一个FIN和一个ACK,所以总共需要四次挥手 [^1]。 ```python # 简单模拟TCP三次握手四次挥手的过程 # 三次握手 print("客户端向服务端发送SYN包,请求建立连接") print("服务端收到SYN包,向客户端发送SYN+ACK包,表示同意建立连接") print("客户端收到SYN+ACK包,向服务端发送ACK包,连接建立成功") # 四次挥手 print("客户端向服务端发送FIN包,表示请求关闭连接") print("服务端收到FIN包,向客户端发送ACK包,表示同意关闭客户端到服务端的连接") print("服务端向客户端发送FIN包,表示请求关闭服务端到客户端的连接") print("客户端收到FIN包,向服务端发送ACK包,表示同意关闭服务端到客户端的连接连接关闭完成") ```
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值