TCP协议中的seq/ack序号是如何变化的?-阿里云开发者社区

开发者社区> geekartt> 正文

TCP协议中的seq/ack序号是如何变化的?

简介:
+关注继续查看

这里提供了截取出来的一次client端和server端TCP包的交互过程。建议将图单独放到一台设备、或者打印出来查看,以便不断核对下述内容。

TCP数据包交换过程

再开始分析之前,还需要论述一下seq、ack表示什么意思,应该以什么样的角度去理解这两个序列号。

  • sequence number:表示的是我方(发送方)这边,这个packet的数据部分的第一位应该在整个data stream中所在的位置。(注意这里使用的是“应该”。因为对于没有数据的传输,如ACK,虽然它有一个seq,但是这次传输在整个data stream中是不占位置的。所以下一个实际有数据的传输,会依旧从上一次发送ACK的数据包的seq开始)
  • acknowledge number:表示的是期望的对方(接收方)的下一次sequence number是多少。
  • 注意,SYN/FIN的传输虽然没有data,但是会让下一次传输的packet seq增加一,但是,ACK的传输,不会让下一次的传输packet加一。

上面这几条原则第一次读会有些抽象,可以先继续往下读分析过程,再回过头来查看这个三个原则。

1、

  • seq:client端第一次发送packet,即:first-way handshake。所以按照上面的准则,它的数据应该从第一个开始,也即是第0位开始,所以seq为0。
  • ack:而server端之前并未发送过数据,所以期望的是server端回传时的packet的seq应该从第一个开始,即是第0位开始,所以ack为0。

2、

  • seq:server端第一次发送packet,即:second-way handshake。所以,这个packet的seq为0。
  • ack:由于在【1】中接收到的是client端的SYN数据包,且它的seq为1,所以client端会让它自己的seq增加1。由此可预计(expect),client端的下一次packet传输时,它的seq是1(0增加1)。所以,ACK为1。

3、

  • seq:third-way handshake。上一次发送时为【1】,【1】中seq为0且为SYN数据包,所以这一次的seq为1(0增加1)。
  • ack:上次接收到时为【2】,【2】中seq为0,且为SYN数据包(虽然在flag上同时设定为SYN/ACK,但只要flag是SYN,就会驱使seq加一),所以可预计,server端下一次seq为1(0增加1)。

4、

  • seq:上一次发送时为【1】,【1】中seq为0且为SYN数据包,所以这一次的seq为1(0增加1)。
  • ack:上次接收到时为【2】,【2】中seq为0,且为SYN数据包,所以可预计,server端下一次seq为1(0增加1)。

5、

  • seq:上一次发送时为【2】,【2】中seq为0,且为SYN数据包,所以这一次的seq为1(0增加1)。
  • ack:上一次接收时为【4】,【4】中的seq为1,数据包的长度为725,所以可以预计,下一次client端的seq为726(1+725)。

6、

  • seq:上一次发送时为【5】,【5】中seq为1,但【5】为ACK数据包,所以数据长度为0且不会驱使seq加1,所以这一次的seq为1(1+0)。
  • ack:上一次接收时为【4】,【4】中的seq为1,数据包的长度为725,所以可以预计,下一次client端的seq为726(1+725)。

7、

  • seq:上一次发送时为【4】,【4】中seq为1,数据包长度为725,所以这一次的seq为726(1+725)。
  • ack:上一次接收时为【6】,【6】中seq为1,且数据长度为1448,所以可以预计,下一次server端的seq为1449(1+1448)。

8、

  • seq:上一次发送时为【6】,【6】中seq为1,数据包长度为1448,所以这一次的seq为1449(1+1448)。
  • ack:上一次接收时为【7】,【7】中seq为726,数据包为ACK、即数据为0,所以可以预计,下一次client端的seq为726(726+0)。

9、

  • seq:上一次发送时为【7】,【7】中seq为726,数据包为ACK、即长度为0, 所以这一次seq为726(726+0)。
  • ack:上一次接收时为【8】,【8】中seq为1449,数据包长度为1448,所以可以预计,下一次server端的seq为2897(1449+1448)。

10、

  • seq:上一次发送时为【8】,【8】中seq为1449,且数据包长度为1448,所以这一次seq为2897(1449+1448)。
  • ack:上一次接收时为【9】,【9】中seq为726,数据包为ACK、即数据为0,所以可以预计,下一次client端的seq为726(726+0)。

剩下的7个packet可以留作练习题自己分析。可以看到的是,从【7】开始,client端这边就只负责做响应,发送ACK数据包,而并没有实际的数据发送到server端。所以,从【7】开始,所有的ACK数据包的seq都是相同的726,因为ACK不像SYN/FIN可以让seq增加,所以发送再多的ACK包都只能让seq原地踏步。

丢包验证

由此可以看到,无论对于client端还是server端,这一次刚收到的对方的packet的seq,一定要和最后一次发送时的packet的ack相等。

因为最后一次发送时的packet的ack,是对下一次接收的packet的seq做的预测。如果两者不等,则表明中途有数据包丢失了!

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里云服务器怎么设置密码?怎么停机?怎么重启服务器?
如果在创建实例时没有设置密码,或者密码丢失,您可以在控制台上重新设置实例的登录密码。本文仅描述如何在 ECS 管理控制台上修改实例登录密码。
9474 0
python+soket实现 TCP 协议的客户/服务端中文(自动回复)聊天程序
【吐槽】 网上的代码害死人,看着都写的言之凿凿,可运行就是有问题。 有些爱好代码、喜欢收藏代码的朋友,看到别人的代码就粘贴复制过来。可是起码你也试试运行看啊大哥   【正文】 昨日修改运行了UDP协议的C/S聊天程序,可是TCP协议的怎么都不行。
1168 0
TCP协议 及 TCP粘包现象
TCP协议 及 TCP粘包现象 TCP,Transmission Control Protocol,传输控制协议。这是一个面向连接的传输层协议。 与之相对的无连接协议为UDP,用户数据报协议。 传输层的基本数据单位为——报文。网络层——包。数据链路层为——帧。物理层——比特。 TCP提供面向连接的可靠服务,传送数据之前必须先建立连接,传送完毕要释放链接。 服务器端使用的端口号:熟
1270 0
tcp协议timestamp字段导致问题分析
1.现象 不同主机C1,C2上的相同模块(开启timestamp),通过NAT网关(1个出口ip)访问同一服务S,主机C1 connect成功,而主机C2 connect失败 2.分析 根据现象上述问题明显和tcp timestmap有关;查看linux 2.6.32内核源码,发现tcp_tw_recycle/tcp_timestamps都开启的条件下,60s(timewa
1467 0
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
10840 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,阿里云优惠总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系.
13157 0
ZigBee TI ZStack CC2530 8.4 如何用高版本IAR打开低版本协议栈
(配套源码、软件、开发板等资源,可移步博客同名QQ群/TB店铺:拿破仑940911) (配套源码、软件、开发板等资源,可移步博客同名QQ群/TB店铺:拿破仑940911)
1142 0
+关注
5
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载