Seq和Ack
http://blog.csdn.net/bytebai/article/details/21752925
握手阶段:
序号 方向 seq ack
1 A->B 0 0
2 B->A 0 0+1=1
3 A->B 1 0+1=1
解释:
1:A向B发起连接请求,以一个随机数初始化A的seq,这里假设为0,此时ACK标记为0,也就是如果抓包的话是看不到ack标记的。
2:B收到A的连接请求后,也以一个随机数初始化B的seq,这里假设为0,意思是:你的请求我已收到,我这方的数据流就从这个数开始。B的ACK是A的seq加1,即0+1=1
3:A收到B的回复后,它的seq是它的上个请求的seq加1,即0+1=1,意思也是:你的回复我收到了,我这方的数据流就从这个数开始。A此时的ACK是B的seq加1,即0+1=1
数据传输阶段:
序号 方向 seq ack size
23 A->B 40000 70000 1514
24 B->A 70000 40000+1514-54=41460 54
25 A->B 41460 70000+54-54=70000 1514
26 B->A 70000 41460+1514-54=42920 54
解释:
23:B接收到A发来的seq=40000,ack=70000,size=1514的数据包。
24:于是B向A也发一个数据包,告诉A,你的上个包我收到了。B的seq就以它收到的数据包的ACK填充,ACK是它收到的数据包的SEQ加上数据包的大小(不包括以太网协议头,IP头,TCP头),以证实B发过来的数据全收到了。
25:A在收到B发过来的ack为41460的数据包时,一看到41460,正好是它的上个数据包的seq加上包(应用层纯数据)的大小,就明白,上次发送的数据包已安全到达。于是它再发一个数据包给B。这个正在发送的数据包的seq也以它收到的数据包的ACK填充,ACK就以它收到的数据包的seq(70000)加上包的size(54)填充,即ack=70000+54-54(全是头长,没数据项)。
其实,在握手和结束时确认号应该是对方序列号加1,传输数据时则是对方序列号加上对方携带应用层数据的长度。如果从以太网包返回来计算所加的长度,就嫌走弯路了。
另外,如果对方没有数据过来,则自己的确认号不变,序列号为上次的序列号加上本次应用层数据发送长度。
最新文章
- jdk安装问题--javac不是外部命令
- cordova插件开发注意事项
- svn更改分支名字,move命令
- ftl文件格式化jsp形式显示
- IT外包行业与职业发展
- 草珊瑚的css基础
- The Karting 2017ccpc网络赛 1008
- 20175317 MyCP(课下作业,必做)
- Angular四大核心特性
- 【转】Qt之JSON保存与读取
- processjs Documentation
- SpringMVC,Controller的返回页面类型以及路径设置默认值
- Lua------------------unity关于lua的使用
- linux的子进程调用exec( )系列函数
- C++从静态对象的初始化顺序理解static关键字
- 定制自己的动画 View 控件(Canvas 使用)
- 【MySQL】日期与字符串间的相互转换
- FastDFS安装配置过程中出现错误提示";/home/yuqing/fastdfs"; can't be accessed, error info: No such file or directory
- Ajax验证用户名
- I wrote a JSONHelper extension