TCP/IP三次握手的过程,为什么要3次?

一:过程

第一次(SYN):

客户端发送一个带有SYN标志的TCP报文段给服务器,设置SYN=1,并携带初始序列号Seq=x(随机值),进入SYN_SENT状态。等待服务器相应。

第二次(SYN+ACK):

服务器收到客户端发送的SYN报文段后,如果同意建立连接,会发送报文段给客户端:

设置SYN=1,携带服务器的初始序列号Seq=y(随机值)。

设置ACK=1,确认号Ack=x+1,表示已收到客户端的Seq=x。

服务器进入SYN_RVCD状态。

第三次(ACK):

客户端收到服务器发送的SYN+ACK报文段后,会发送报文段给服务器:

设置ACK=1,确认号Ack=y+1,表示已收到服务器的Seq=y。

序列号Seq=x+1,继续之前的序列。

客户端进入ESTABLISHED状态。

收到客户端的ACK后,服务器也进入ESTABLISHED状态,连接建立成功,可以开始进行数据传输。

二:为什么要3次?

1.确认双方都能发送和接收数据:

第一次握手确认客户端的发送能力和服务器的接受能力。

第二次握手确认服务器的发送能力和客户端的接受能力。

第三次握手确认客户端的发送能力和服务器的接受能力。

2.防止旧的连接请求误导对方:

通过三次握手,双方都能确认对方的状态是最新的,有效避免了网络中旧的、延迟的SYN包造成的错误连接。

3.防止重复数据包干扰:

三次握手确保双方都能有效处理重复的数据包,并建立一个唯一的连接。

三:为什么不是2次?

无法确认双向通信

TCP是全双工协议,需要确保客户端和服务器都能发送和接收数据。

两次握手过程:客户端->SYN->服务器 服务器->ACK->客户端

问题

服务器发送ACK后,认为连接已建立,但客户端可能未收到ACK(比如网络丢包)。

服务器无法确认客户端是否收到ACK。

后果

服务器单方面认为连接成功,可能开始发送数据,而客户端未准备好,导致数据丢失。

无法同步服务器的序列号

TCP使用序列号确保数据按序传输。

两次握手中,服务器的ACK只确认了客户端的序列号(x),但未发送自己的序列号(y)。

问题:客户端无法知道服务器的初始序列号,后续数据传输可能因为序列号不同步而混乱。

后果:缺乏双向序列号同步,无法保证可靠传输。

无法防止旧连接干扰

网络中可能存在延迟的旧数据包,比如之前的SYN。

两次握手时:

客户端发送旧SYN,服务器收到后返回ACK。

服务器认为连接建立,但客户端未发送新连接。

问题:两次握手无法区分新旧连接,服务器可能误处理旧包。

后果:旧数据干扰新连接,导致不可靠性。

四:为什么不是四次握手?

四次也可以,但是多余,效率低。

相关推荐
Antonio9152 小时前
【音视频】HLS简介与服务器搭建
运维·服务器·音视频
kfepiza2 小时前
Debian的`/etc/network/interfaces`的`allow-hotplug`和`auto`对比讲解 笔记250704
linux·服务器·网络·笔记·debian
无妄-20243 小时前
软件架构升级中的“隐形地雷”:版本选型与依赖链风险
java·服务器·网络·经验分享
R.X. NLOS3 小时前
VS Code远程开发新方案:使用SFTP扩展解决Remote-SSH连接不稳定问题
运维·服务器·ssh·debug·vs code
群联云防护小杜4 小时前
构建分布式高防架构实现业务零中断
前端·网络·分布式·tcp/ip·安全·游戏·架构
轩情吖7 小时前
Qt的第一个程序(2)
服务器·数据库·qt·qt creator·qlineedit·hello world·编辑框
岸边的风7 小时前
无需公网IP的文件交互:FileCodeBox容器化部署技术解析
网络·网络协议·tcp/ip
世事如云有卷舒7 小时前
Ubunt20.04搭建GitLab服务器,并借助cpolar实现公网访问
linux·服务器·gitlab
Zonda要好好学习7 小时前
Python入门Day4
java·网络·python
Little-Hu8 小时前
QML TextEdit组件
java·服务器·数据库