数据包的确认号问题

zgxowb · 发表于 2010-9-17 20:26:49

请高手指点，图中是用192.168.200.109(客户端）访问服务器(192.168.105.5)上WEB的数据抓图。问题是：图中第28个数据包的确认号是3173150199＝3173148819（第25个包的序列号）＋1438－58，这样是不是可以认为第28这个包是第25包返回确认包呢？同样第29是第27包的确认包？如是，那为什么24和26这两个包为什么没有客户端发回确认包呢？

xiaoshazi · 发表于 2010-9-18 06:08:48

28是对24，25的应答
29是对26，27的应答

你算下29和28包的序列号的差

zgxowb · 发表于 2010-9-18 13:28:57

xiaoshazi，感谢你的回答，不过我还是不明白你的说的意思啊，28怎么是24的应答包呢？因为
28的确认号不等于24的序列号＋长度（1438－56）啊？再说一个数据包能稍回两个包的应答包吗？你要我算28和29包的序列号差是什么意思呢？请指教

zgxowb · 发表于 2010-9-19 07:58:22

自己顶一下，没有回答

long_323 · 发表于 2010-9-19 09:22:18

这是TCP的累积确认功能，可以减少传输消耗。
但仍有疑问，在发送端如何识别这种积累确认和丢包呢？据说有选择确认（SACK），但没见过。

zgxowb · 发表于 2010-9-19 10:00:40

如果可以积累确认，那为什么29包不对以24、25、26、27一次性确认，还要让28包、29包分别两次对4个包进行确认？

long_323 · 发表于 2010-9-19 10:21:26

为什么不用29一次确认完成？可能是应用程序考虑效率与延迟的关系吧。具体就不清楚了，呵呵，如果允许我更想让他最后一个ACK就行。

1024 · 发表于 2010-9-19 16:30:06

我觉得楼主对tcp的3个阶段工作原理理解不是很正确。
针对楼主的这个问题，我说一下我的看法。
1.建立连接阶段（3次握手）：这个阶段的交互是逻辑上是一一对应的。即一个请求，一个回应。
2.数据传输阶段：这个阶段的交互不是一一对应的，特别是数据块流的传送。楼主说的这个问题就是窗口机制实现过程的表现：目的站可在任何时候发送确认。如果滑动窗口大小为100，在收到目的站的任何确认之前，源站可以发送一直到100个字节。但是，源站若收到对前3个字节的确认，它就将窗口向右滑动3个字节。当然这样说还有不准确之处，具体在可以参照tcp/ip详解里关于tcp的拥塞窗口机制和慢启动的部分。
3.连接关闭阶段（4次或3次挥手）：这个阶段的交互是逻辑上是一一对应的。即一个请求，一个回应。

zgxowb · 发表于 2010-9-20 07:48:27

谢谢楼上的回答，我在查查资料

zgxowb · 发表于 2010-9-20 08:08:02

8楼所说的，窗口机制，我觉得不是数据包确认的问题，而是流控的问题

xiaoshazi · 发表于 2010-9-21 10:33:34

如果可以积累确认，那为什么29包不对以24、25、26、27一次性确认，还要让28包、29包分别两次对4个包进行确认？
zgxowb 发表于 2010-9-19 10:00

协议在设计的时候要把所有的可能性都考虑进去。如果通过一个ack来应答很多包，网络运行平稳的情况下，不会有问题；如果网络运行不稳定，丢包很多就会导致大量重传。那样传输效率就会直线下降了。

xiaoshazi · 发表于 2010-9-21 10:35:38

8楼所说的，窗口机制，我觉得不是数据包确认的问题，而是流控的问题
zgxowb 发表于 2010-9-20 08:08

我理解是通过确认包来进行流控，应答速度越快服务端发送窗口也越大。

数据包的确认号问题

本帖子中包含更多资源

评分