为什么断开 TCP 连接是四次挥手?

  1. 客户端主动关闭连接时,会给服务端发送 FIN 报文,这仅表示客户端不再往服务端发送数据了,但仍能接收服务端发来的数据
    • 注意 1:只要客户端关闭 socket 的发送能力,Linux 内核就会向服务端发送 FIN 报文
    • 注意 2:如果客户端调用 close() 主动关闭连接,这表示客户端既不能再往服务端发送数据,也不能再接收服务端发来的数据,就是说,close() 同时关闭了 socket 的发送和接收能力
  2. 服务端收到客户端的 FIN 报文后,会回给客户端 ACK 报文,但此时服务端可能还有数据需要发送,等服务端没有数据再发送后,才会发送 FIN 报文给客户端,表示同意现在关闭连接

从上述过程可知,服务端通常需要等待完成数据的发送,所以服务端的第二次和第三次挥手报文一般都会分开发送,因此是四次挥手,但是在特定情况下,四次挥手是可以变成三次的,详见实战 - 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包,表示同意关闭服务端到客户端的连接连接关闭完成") ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值