nagle算法问题请教

曾经曾经 · 发表于 2010-6-6 11:07:50

有个问题不明白：
在tcp/ip详解卷1第19章，19.4中，
“报文段1 4和1 5看起来似乎是与 N a g l e算法相违背的,但我们需要通过检查序号来观察其中的真相.因为确认序号是 5 4,因此报文段 1 4是报文段 1 2中确认的应答.但客户在发送该报文段之前,接收到了来自服务器的报文段 13,报文段15中包含了对序号为 56的报文段 13的确认. 因此即使我们看到从客户到服务器有两个连续返回的报文段,客户也是遵守了 Nagle算法的”

以上说法看不明白
发了14后，马上又发15，书上解释为15是对13的ack，但是这样，就有两个未ack的packet在网络中，是不是与nagle冲突呢？

按我的理解：
服务器用12ack了11，然后发了13；到这里是正常的。
客户端发14同时ack了12。
现在服务器有一个未被ack的13，客户端有一个未被ack的14,那么现在无论哪方发数据包似乎都不对，违背nagle。例子中的15就是这样。
正常似乎应该是14之后，服务器或客户端发一个纯ack确认14或13，然后双方继续？
想不明白。
请指教。
谢谢。

曾经曾经 · 发表于 2010-6-7 13:42:53

看的很多都没回复啊
又想了还是没想明白

曾经曾经 · 发表于 2010-6-7 15:29:49

短数据报的解决方案
显然,一个自适应的方法是不难想到的。我们期望为自适应交互包的时限提出一个建议方案，这个时限是在TCP所观察到的往返时间延迟的基础上的。然而虽然这样一个机制确实能被实现，但它是不必要的。我们发现了一个简单且优化的解决方案。

这个解决方案是，如果任何先前在连接上传输的数据仍没有被确认，那么来自用户的输出数据到来时，禁止传输TCP数据段。这个限制是无条件的，没有定时器，不需要测试收到的数据的大小，不需要其他条件。典型的实现只需要TCP程序中的一两行程序。

乍看，这个解决方案好象意味着TCP行为的剧烈改变。但并非如此。最终它很好地工作。让我们看看为什么是这样。

当一个用户向一个TCP连接写数据时,TCP收到一些数据。它可以保持这些数据以便以后传送或者也可以立即送出一个数据包。如果它不立即传送，它将在一个传入的数据包到来且改变了系统状态之后传送数据。可以有两种方式之一来改变这种状态；这个到来的数据包确认远端主机收到数据，或者通告远端主机为新数据提供的可用缓冲空间大小。（后者指“更新窗口”）。每次，此连接上的数据到来时，TCP必须重新检查它的当前状态并可能会送出一些数据包。这样，当我们忽略送出来自用户端的数据时，我们只是简单地延迟传输直到下一个来自远端的主机的报文到来。报文总是很快就到来，除非这条连接之前是空闲的或者与另一端的通信丢失。在第一种情况，即空闲连接，我们的方案将使用户在任何时候向TCP连接写数据时送出数据包。这样，我们就不会在空闲连接时死锁。第二种情况，远端主机失败，传送更多的数据都是无效的。注意，我们没有采取任何措施来禁止正常的TCP重传逻辑，因此，丢失报文不是问题。

曾经曾经 · 发表于 2010-6-7 15:31:14

看来人rfc896，感觉是：
客户端收到12，发出14，收到13，因为窗口更新，发出15
不知道理解对不对

感谢long_323兄提供rfc文档

nagle算法问题请教

本帖子中包含更多资源

评分