为啥"三次握手"确认序号要加1?

开发 前端
即假如客户端向服务器发送连接请求,它会先发一个SYN报文。假设这个报文序号为x的话,收到请求的服务器会用ACK报文应答,并将ACK报文的确认序号赋值为x+1。意思是“收到x号报文了”。

其实加1只是表象,加长度才是本质。但是,为啥要加长度?

了解TCP三次握手的人都知道,其ACK确认报文会有一个确认序号ack_seq,这个序号的值则为SYN连接报文的序号加1。

图片图片

即假如客户端向服务器发送连接请求,它会先发一个SYN报文。假设这个报文序号为x的话,收到请求的服务器会用ACK报文应答,并将ACK报文的确认序号赋值为x+1。意思是“收到x号报文了”。

这里难免让人疑惑,既然是表达“收到x号报文”,ACK的确认序号不应该是赋值为x吗?为啥是x+1,加1的作用是什么?

正如开头所说,加1只是表象,加长度才是本质。这里1表达的是SYN连接报文的数据长度。这个长度的单位是字节,加1就表示收到了数据长度为1字节的报文,加m则表示收到数据长度为m字节的报文。

也许有人会追问,SYN作为连接请求报文,哪有什么数据,其数据长度不应该是零吗?为啥要加1?

图片图片

这是因为,虽然SYN报文的数据部分确实为空,但是它却实实在在占据了一个报文序号x,而一个报文序号是要对应一个字节的,这时即使它实际没有占用任何一个字节放数据,那一个字节也被消耗了。

所以,“ack_seq=x+1”更准确的翻译应该是“收到了起始序号为x长度为1的报文数据”。这种ack_seq=seq+length的方式其优势在于,配合序号的连续性,当需要确认的数据不止一个字节时,仍旧可以只用一个ACK报文进行应答。

不知是否有人疑惑,前文所述的SYN连接报文的编号x,一会说它是报文序号,一会又说一个报文序号对应了一个字节,那到底序号x是报文编号还是字节编号呢?

答案是,它既是报文编号也是字节编号,也就是一个编号两个身份。但这只是一个报文的数据起始字节编号才有的特权。这就像各种编程语言中的数组,其内部第一个数组项的地址,既是当前数组项的地址,也代表整个数组的地址。

责任编辑:武晓燕 来源: Web学社
相关推荐

2022-07-05 22:18:08

TCP网络

2023-09-07 16:46:54

TCP数据传递

2021-08-09 07:26:34

Blazor路由开发

2020-12-08 06:34:16

TCP握手SYN 报文

2022-10-10 07:34:36

TCP三次握手区块链

2015-10-13 09:42:52

TCP网络协议

2019-06-12 11:26:37

TCP三次握手四次挥手

2024-01-12 08:23:11

TCPACK服务器

2021-04-30 13:32:17

TCP三次握手网络协议

2021-07-03 17:47:25

TCP控制协议

2021-03-08 18:08:08

TCP Connect 协议

2022-07-25 07:07:35

TCP客户端服务器

2024-10-09 20:54:16

2021-01-29 06:11:08

TCP通信三次握手

2021-05-18 12:27:40

TCP控制协议

2019-02-01 09:38:16

2023-10-24 15:22:09

TCPUDP

2020-08-27 07:41:28

TCP协议数据

2018-10-15 08:06:33

TCP握手原理

2018-07-05 14:25:01

TCP握手原理
点赞
收藏

51CTO技术栈公众号