Nagle算法和延迟ACK用于批量数据吗?

Nik*_*hil 4 networking tcp

所以,当我遇到Nagle的算法时,我正在经历TCP的事情,并且延迟了针对小型数据包(1字节数据)的ACK.原因是,避免在网络上发送大量小数据包(Nagle)和捎带数据(延迟ACK).然而,对于批量数据没有提及这些算法,即我写了> 8000字节.4个问题:

  1. 这些算法是否仅适用于小型数据包?

  2. 例如,当我们执行写操作(8000)时,TCP首先发送1500个字节(假设1500为MSS并且发生慢速启动),在收到第一个ACK之前,它可以发送另外1500个字节的数据,然后是不违反Nagle的?

  3. 接收方是等待超时发送延迟的ACK还是在收到1500字节数据后立即发送?

  4. 它如何知道何时延迟ACK?它是基于接收缓冲区中的字节吗?

谢谢!

Joh*_*gle 12

Nagle算法的想法是防止多个小型数据包一次传输.延迟ACK(来自伯克利)的想法是避免在通过远程回声的Telnet连接进行键入时为每个字符发送单独的ACK,等待一段固定的时间用于反向的流量,在该方向上可以捎带ACK .

两种算法的相互作用很糟糕.如果你做大发送,大发送,大发送,这工作正常.如果你发送,得到回复,发送,得到回复,这是正常的.如果你做小发,小发,得到回复,会有一个短暂的停顿.这是因为第二个小发送被Nagle算法延迟,直到ACK返回,并且延迟的ACK算法在发生之前增加0.5秒左右.

延迟的ACK是一个赌注.TCP实现打赌将很快发送数据,并且不必发送单独的ACK.每次实际发送延迟的ACK时,该投注都会丢失.TCP规范允许实现每次丢失该赌注而不关闭延迟的ACK.恰当地,延迟的ACK应当仅在可能已经捎带的一些不必要的ACK已经连续发送时才开启,并且任何时候实际发送延迟的ACK,应该再次关闭延迟的ACK.应该有一个反击.

不幸的是,在1986年我退出网络之后,延迟的ACK进入了,这从未修复过.现在为时已晚.

约翰纳格尔

  • 是的,我是"那个"John Nagle.为每个完整大小的数据包发送回复ACK的开销并不是那么糟糕,并且保持流量不断流动.大量的小型数据包会破坏事物.如果你关闭"Nagle算法"(我称之为"tinygram预防")并对TCP套接字进行单字节写操作,则每个字节都会在一个单独的数据包中出现.开销上升了40倍.防止这是算法的目的. (3认同)