猿创征文|TCP三次握手详解

本文详细解析了TCP三次握手的过程,包括SYN和ACK标志位的作用,以及序号和确认号的含义。三次握手确保了客户端和服务器端都能发送和接收数据的能力,验证了双方的通信可靠性。简而言之,第一次握手验证客户端的发送能力,第二次握手验证服务器的发送和接收能力,第三次握手验证客户端的接收能力。两次握手无法确保双方的接收能力,而四次握手则是冗余。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

三次握手中的关键字段解读

在这里插入图片描述

  • 1.SYN:同步。在建立连接时用来同步序号。SYN=1,ACK=0时代表连接请求报文段。同意连接后,则SYN=1,ACK=1。SYN=1代表为连接请求或连接接收报文。
  • 2.ACK:确认。仅当ACK=1时确认号ack才有效,ACK=0时确认字段无效。
  • 3.seq:序号。在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。其实就是准备发送的报文段的起始字节序号。假如一台主机目前发送的报文段起始字节序号为101,报文长度为100.当前的seq显而易见是101,下次该主机就该发送起始字节序号为201的报文了。
  • 4.ack:确认号。是期望对方下一个报文段的第一个数据字节的序号。

三次握手过程做了些什么

在这里插入图片描述
在三次握手前面,客户端和服务端都创建了传输控制模块TCB。
第一次握手:由客户对服务器发起连接请求。SYN=1,seq=x。这里的话其实还有ACK=0,因为SYN=1,ACK=0是代表连接请求报文段的。seq=x代表本机的报文段的字节序号轮到了x。然后这里的话是没有ack的,因为还没建立起连接,没有收到服务器端的要发送的一个报文段的起始字节号和它的长度,所以自然没有期望的对方下一个报文段的第一个字节的序号,并且ACK=0的时候确认号ack是无效的。
第二次握手:SYN=1,ACK=1代表这是一个连接接受报文。此刻由于服务器收到了客户的一个报文段的起始位置,所以服务器给客户发的报文有ack字段,期待对方发送的下一个报文段的第一个字节序号是x+1。而服务器本机的报文段的序号是从y开始,这里由于客户和服务器是两台主机,所以两台主机发送的伊始报文段的起始字节序号并无联系,故x和y无关系。
第三次握手:ACK=1代表确认号有效,由于客户接收到的服务器端的报文段起始字节序号为y,故希望下次收到的字节序号为y+1。客户端这边由于第一次连接发送了字节序号为x的报文段,由于报文长度为1,所以这一次应该发送的报文段的起始字节序号为x+1。也刚好与第二次握手的ack对应起来。
注意:这里的第二次握手第三次握手中的ack都是对前一次握手中的seq进行加1,因为第一次握手第二次握手TCP规定不能携带数据,所以就是消耗掉一个序号,并不会像前面所讲seq时要加上数据报的长度。第三次握手ACK报文段可以携带数据。

为什么不能两次握手或者四次握手建立起连接

因为进行连接之前,我们都得确认服务器端和客户端都有接收信息和发送信息的能力,那么最少三次才能验证双方都有接收信息和发送信息的能力。只有这样都确认了,我们才能安心的进行通信。就比如下上图左边是client也是一开始的发送端,然后上图右边是sever接收端,那么第一次握手,客户端给服务器端发信息,发TCP包头含有SYN=1的,然后如果服务器端接收到了,就说明服务器端有接收信息的能力。综上,第一次握手验证了客户端的发送能力。然后服务器端接收到了之后,给客户端发送一个标志位ACK=1,SYN=1的包,ACK=1说明确认收到了,SYN=1是服务器端向客户端发送的询问连接的,只有服务器端接收到了第一次握手的数据它才会回应出相应的应答,且会发送个请求连接的确认。综上,第二次握手验证了服务器端的发送能力和服务器端的接收能力。第三次握手主要就是在第二次服务器端给客户端发送数据的基础上,客户端接收到了信息就会发个确认的信息给服务器端。综上,第三次握手验证了客户端的接收能力
故两次握手不至于证明服务器端和客户端都有接收信息和发送信息的能力,三次握手能做好的事,自然也用不到四次握手了。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值