Algorithm 纳格尔'；s算法、ACK延迟和Rlogin回波

有人建议我也在这里提问，因为关于协议的具体问题都在这个主题上，但如果有人感兴趣，这个问题也有一点好处

我正在读关于TCP数据流、延迟ACK和Nagle算法的书

到目前为止，我了解到：

TCP上的延迟ACK实现会在接收到的段的确认上产生延迟，从而使应用程序有机会随确认一起写入一些数据，从而避免发送空ACK数据包并导致网络拥塞

Nagle的算法实现声明，当另一个小段仍未确认时，您不能发送一个小段TCP。这避免了使用多个TinyGram加载流量

在一些交互式应用程序上，例如Rlogin，Nagle的算法和延迟的ACK可能会“冲突”：

当我们键入键盘输入时，Rlogin将键盘输入发送到服务器，一些键（如F1）会生成多个字节（F1=转义+左括号+M）。如果将这些字节逐个发送到TCP，则可以将它们发送到不同的段中

服务器在完成整个序列之前不会回复回显，因此所有ACK都会延迟（需要应用程序提供一些数据）。另一方面，客户机将等待第一个字节确认，然后再发送下一个字节确认（根据Nagle的算法）。这种组合最终会产生一个“laggy”Rlogin

在Rlogin上发送的F1和F2键的

tcpdump

如下所示：

    type Fl key
1   0.0                 slip.1023 > vangogh. login: P 1:2(1) ack 2
2   0.250520 (0.2505)   vangogh.login > slip.1023: P 2:4(2) ack 2
3   0.251709 (0.0012)   slip.1023 > vangogh.login: P 2:4(2) ack 4
4   0.490344 (0.2386)   vangogh.login > slip.1023: P 4:6(2) ack 4
5   0.588694 (0.0984)   slip.1023 > vangogh.login: . ack 6
    type F2 key
6   2.836830 (2.2481)   slip.1023 > vangogh.login: P 4:5(1) ack 6
7   3.132388 (0.2956)   vangogh.login > slip.1023: P 6:8(2) ack 5
8   3.133573 (0.0012)   slip.1023 > vangogh.login: P 5:7(2) ack 8
9   3.370346 (0.2368)   vangogh.login > slip.1023: P 8:10(2) ack 7
10  3.388692 (0.0183)   slip.1023 > vangogh.login: . ack 10

现在的疑问是：尽管我读到的页面声明服务器在拥有整个密钥序列之前没有用回音回复，但通过

tcpdump

捕获的数据包显示密钥在各自的ack上被回音（第一个回音是2字节长，因为ESC的回音是两个字符-插入符号+左括号）

如果数据从应用程序发送到TCP（回显响应），为什么ACK会延迟？根据所述，关于服务器在回显之前等待完整序列，ACK不应该在最后一个ACK之前不包含回显，而这将包含整个序列回显吗

编辑： 以下是修改后的Rlogin的

tcpdump

输出，不带Nagle算法（TCP_NODELAY标志）：

在第4段可以注意到~0.2ms的延迟，即使Nagle的算法被关闭（因此所有特殊密钥字节一起到达，可以一起处理）。在段6上，我们无法确定~0.2ms的延迟，因为服务器需要一段时间来重新处理和重新打包某些丢失段的重新传输，但该延迟超过2s

在F2关键示例中，在第11段中，我们还可以注意到~0.2ms延迟。我们无法在第12段识别它，因为它可能是在第11段之后发送的

这确实表明@MattTimmersans的答案是正确的，这可能是因为这本书对这些片段做出了错误的解释。它们可能确实是网络媒体的一个特征，而不是因为数据没有发送到TCP堆栈而导致ACK延迟

参考：

---

由于段2、4、5、7中的ACK带有数据，因此它们不是延迟ACK（不是由ACK计时器超时启动的）

我相信与这些相关的0.25秒延迟只是主机之间的往返时间。我注意到这些数据是在1993年记录的。如果我没记错的话，我认为250毫秒的ping在当时并不少见

如果tcpdump是在

vangogh

而不是

slip

上运行的，它看起来会看到回声在

ESC

和

[M

数据包之后快速出现

---

该示例显示，Nagle的算法甚至可以在没有ACK延迟的情况下执行，因为它为交换增加了额外的往返时间。

如果是这样的话，这本书在这个主题中有点误导。看看在禁用Nagle算法的Rlogin上相同示例的

tcpdump

输出，似乎服务器上的延迟也大于0.2ms，因此可能确实是连接的RTT。回到家后，我会仔细看看，并在问题上发布带有TCP_NODELAY的版本输出。我刚刚编辑了问题，以便在修改后的Rlogin连接上有

tcpdump

的输出（没有Nagle算法）.经过思考后，我相信你的答案是正确的。虽然这确实意味着这本书在这一章上是错误的，但这是一种可能性，特别是在我遇到这个问题的最后几个月里，我找不到任何其他解释来解释发送回显字符延迟确认超时。我差点忘了。我It’为了遵守“禁止交叉问题”规则，我将关闭ServerFault问题，但我不能删除带有赏金的问题。因此，如果您在ServerFault上有帐户并想申请赏金，我也会在那里接受您的回答。赏金从8月14日起就一直存在。@IanC谢谢您的考虑，但我没有关于赏金的帐户谢谢，干杯

        type Fl key
1   0.0     slip.1023 > vangogh.login: P 1:2(1) ack 2
2   0.002163 (0.0022)   slip.1023 > vangogh.login: P 2:3(1) ack 2
3   0.004218 (0.0021)   slip.1023 > vangogh.login: P 3:4(1) ack 2
4   0.280621 (0.2764)   vangogh.login > slip.1023: P 5:6(1) ack 4
5   0.281738 (0.0011)   slip.1023 > vangogh.login: . ack 2
6   2.477561 (2.1958)   vangogh.login > slip.1023: P 2:6(4) ack 4
7   2.478735 (0.0012)   slip.1023 > vangogh.login: . ack 6
        type F2 key
8   3.217023 (0.7383)   slip.1023 > vangogh.login: P 4:5(1) ack 6
9   3.219165 (0.0021)   slip.1023 > vangogh.login: P 5:6(1) ack 6
10  3.221688 (0.0025)   slip.1023 > vangogh.login: P 6:7(1) ack 6
11  3.460626 (0.2389)   vangogh.login > slip.1023: P 6:8(2) ack 5
12  3.489414 (0.0288)   vangogh.login > slip.1023: P 8:10(2) ack 1
13  3.640356 (0.1509)   slip.1023 > vangogh.login: . ack 10