[已解决]TCP连接时的三次握手

她与晚风

在TCP建立连接过程中报文中的一些字段:
SYN=1,seq=x;
SyN=1,ACK=1,seq=y,ack=x+1;
SYN=0,ACK=1,seq=x+1,ack=y+1;

问题:
seq不是指本报文段所发送数据的第一个字节的序号吗,连接建立请求时不是没有数据吗,那这个seq有啥用?
服务器端发送确认报文时也要用到seq吗,他不是用来确认数据的吗?为啥也变化

最佳答案

月排行榜 / 总排行榜

dolly_yos2

2023-2-13 18:54:00

她与晚风 发表于 2023-2-13 18:41
可是SYN占一个字节不影响seq和ack的值吧,SYN不是包含在TCP首部吗

是这样的，但因为连接建立（和关闭）对这个协议非常关键，尽管这些控制位不占据数据空间，也要逻辑上将它们视为占据一个字节，并分配序列号
https://www.ietf.org/rfc/rfc9293.html#section-3.4-28

跳转到最佳答案楼层

isdkz

第一次握手的 seq 是用于计算第二次握手的 ack 的

她与晚风

isdkz 发表于 2023-2-13 18:17
第一次握手的 seq 是用于计算第二次握手的 ack 的

可是这个ack为什么是+1啊
ack不是收到下一个报文段开始的序号或者说ack-1是确认发送成功
如果一个数据报一次3个字节: 1 2 3,序号为1 服务器发送的ack不该为4吗

她与晚风

isdkz 发表于 2023-2-13 18:17
第一次握手的 seq 是用于计算第二次握手的 ack 的

而此时连接建立时没有数据那seq和ack作用是什么呢

dolly_yos2

逻辑上建立连接的 SYN 占一个字节，效果上相当于是初始序列号协商，对抵御连接数据注入、连接劫持、伪造等有效

她与晚风

dolly_yos2 发表于 2023-2-13 18:37
逻辑上建立连接的 SYN 占一个字节，效果上相当于是初始序列号协商，对抵御连接数据注入、连接劫持、伪造等 ...

可是SYN占一个字节不影响seq和ack的值吧,SYN不是包含在TCP首部吗

她与晚风

                               
登录/注册后可看大图

isdkz

她与晚风 发表于 2023-2-13 18:35
可是这个ack为什么是+1啊
ack不是收到下一个报文段开始的序号或者说ack-1是确认发送成功
如果一个数据 ...

首先第一次握手时取了一个随机数字作为第一个字节的序号，假设这个随机数字是 3，

如果他要一次发3个字节的话，他是自己算好的，而不是发过去再算的，也就是说 seq 应该是 5，seq 也就是发过去的最后一个字节的序号，

而至于 ack 为什么要加一，就是因为 ack 是告诉对方多少号之前的数据都收到了，seq 是 5，那肯定要说是 6 号之前的呀

她与晚风

客户端向服务器发送一个同步数据包请求建立连接，该数据包中，初始序列号（ISN：Inital Sequence Number）是客户端随机产生的一个值，确认号是0；
服务器收到这个同步请求数据包后，会对客户端进行一个同步确认。这个数据包中，序列号（ISN）是服务器随机产生的一个值，确认号是客户端的初始序列号+1；
客户端收到这个同步确认数据包后，再对服务器进行一个确认。该数据包中，序列号是上一个同步请求数据包中的确认号值，确认号是服务器的初始序列号+1。
————————————————
版权声明：本文为CSDN博主「qq_18145605」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

isdkz

她与晚风 发表于 2023-2-13 18:37
而此时连接建立时没有数据那seq和ack作用是什么呢

seq 是告诉对方发过去的最后一个字节的序号，而 ack 是响应对方收到了多少号之前的数据

她与晚风

isdkz 发表于 2023-2-13 18:47
首先第一次握手时取了一个随机数字作为第一个字节的序号，假设这个随机数字是 3，

如果他要一次发3个 ...

seq 也就是发过去的最后一个字节的序号吗?不是第一个字节的序号吗

isdkz

她与晚风 发表于 2023-2-13 18:50
seq 也就是发过去的最后一个字节的序号吗?不是第一个字节的序号吗

不是，是发过去的最后一个字节的序号，他自己要发多少个字节自己最清楚了，所以他根据第一个字节的序号和要发的字节数就很容易算出来，

总不能发给对方然后让对方慢慢数发了多少个，然后再算吧，这是不可能的，太狗了，

更何况发送过程中还有可能有丢失的

dolly_yos2

她与晚风 发表于 2023-2-13 18:41
可是SYN占一个字节不影响seq和ack的值吧,SYN不是包含在TCP首部吗

是这样的，但因为连接建立（和关闭）对这个协议非常关键，尽管这些控制位不占据数据空间，也要逻辑上将它们视为占据一个字节，并分配序列号
https://www.ietf.org/rfc/rfc9293.html#section-3.4-28

她与晚风

isdkz 发表于 2023-2-13 18:49
seq 是告诉对方发过去的最后一个字节的序号，而 ack 是响应对方收到了多少号之前的数据

哦哦,视频里面那个人好像讲错了我人麻了...
那服务器端发送确认时里面的seq对客户端没有任何作用吧!!!只是一个确认报文
只用ack = 客户端seq+1

isdkz

她与晚风 发表于 2023-2-13 18:56
哦哦,视频里面那个人好像讲错了我人麻了...
那服务器端发送确认时里面的seq对客户端没有任何作用吧!!!只 ...

有作用的，因为他发确认的这个数据包也算他发的一个数据包，有发送就肯定会有 seq

dolly_yos2

她与晚风 发表于 2023-2-13 18:56
哦哦,视频里面那个人好像讲错了我人麻了...
那服务器端发送确认时里面的seq对客户端没有任何作用吧!!!只 ...

除了主动开启和被动开启，TCP 协议是对等的吧，处理序列号和确认号应该没有服务端/客户端的区别？

她与晚风

isdkz 发表于 2023-2-13 18:59
有作用的，因为他发确认的这个数据包也算他发的一个数据包

但服务器端发送的seq不会对客户端即将第三次握手里面的数据的有影响吧,如果有影响的是哪个字段呢

dolly_yos2

她与晚风 发表于 2023-2-13 19:01
但服务器端发送的seq不会对客户端即将第三次握手里面的数据的有影响吧,如果有影响的是哪个字段呢

ack 啊，另一方要确认自己收到了这个序列号

她与晚风

dolly_yos2 发表于 2023-2-13 18:59
除了主动开启和被动开启，TCP 协议是对等的吧，处理序列号和确认号应该没有服务端/客户端的区别？

我不知道服务器端发送确认报文中的seq对客户端即将发送的第三次握手的报文有没有影响

她与晚风

dolly_yos2 发表于 2023-2-13 19:02
ack 啊，另一方要确认自己收到了这个序列号

互相确认是吗