所以,当我遇到Nagle的算法时,我正在经历TCP的事情,并且延迟了针对小型数据包(1字节数据)的ACK.原因是,避免在网络上发送大量小数据包(Nagle)和捎带数据(延迟ACK).然而,对于批量数据没有提及这些算法,即我写了> 8000字节.4个问题:
这些算法是否仅适用于小型数据包?
例如,当我们执行写操作(8000)时,TCP首先发送1500个字节(假设1500为MSS并且发生慢速启动),在收到第一个ACK之前,它可以发送另外1500个字节的数据,然后是不违反Nagle的?
接收方是等待超时发送延迟的ACK还是在收到1500字节数据后立即发送?
它如何知道何时延迟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进入了,这从未修复过.现在为时已晚.
约翰纳格尔
| 归档时间: |
|
| 查看次数: |
2297 次 |
| 最近记录: |