为什么连接的时候是三次握手,关闭的时候却是四次握手?

本文详细介绍了TCP连接中两个主机如何通过发送FIN和ACK信号来完成连接的关闭过程。主机甲首先发送FIN信号给主机乙表示数据发送完毕,乙收到后会发送ACK确认。之后乙在完成自身数据发送后也会发送FIN给甲,最终双方通过交换ACK信号确认连接关闭。

1,当主机甲确认发送完数据且知道乙已经接受完了,想要关闭发送数据口(当然确认信号还是可以发),就会发FIN给主机B.

2,主机乙收到甲发送的FIN,表示收到了,就会发送ACK回复。

3,但这是乙可能还在发送数据,没有想要关闭数据口的意思,所以FIN与ACK不是同时发送的,而是等到乙数据发送完了,才会发送FIN给主机A.

4,A收到B发来的FIN,知道B的数据也发送完了,回复ACK,A等待2MSL以后,没有收到B传来的任何消息,知道B已经收到自己的ACK了,A就关闭链接,B也关闭链接了。

### 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、付费专栏及课程。

余额充值