什么时候需要回复 ACK延迟确认实际例子演示可以设置关掉延迟确认吗？当 Nagle 算法遇到延迟确认首先必须明确两个观点：
不是每个数据包都对应一个 ACK 包，因为可以合并确认。也不是接收端收到数据以后必须立刻马上回复确认包。
如果收到一个数据包以后暂时没有数据要分给对端，它可以等一段时间（Linux 上是 40ms）再确认。如果这段时间刚好有数据要传给对端，ACK 就可以随着数据一起发出去了。如果超过时间还没有数据要发送，也发送 ACK，以免对端以为丢包了。这种方式成为「延迟确认」。
这个原因跟 Nagle 算法其实一样，回复一个空的 ACK 太浪费了。
如果接收端这个时候恰好有数据要回复客户端，那么 ACK 搭上顺风车一块发送。如果期间又有客户端的数据传过来，那可以把多次 ACK 合并成一个立刻发送出去如果一段时间没有顺风车，那么没办法，不能让接收端等太久，一个空包也得发。
TCP 要求 ACK 延迟的时延必须小于500ms，一般操作系统实现都不会超过200ms。
延迟确认在很多 linux 机器上是没有办法关闭的
什么时候需要回复 ACK需要立马回复 ACK 的场景有：
如果接收到了大于一个frame 的报文，且需要调整窗口大小处于 quickack 模式（tcp_in_quickack_mode）收到乱序包（We have out of order data.）
其它情况一律使用延迟确认的方式
什么是交互式和 pingpong 呢？
有来有回的双向数据传输就叫 pingpong
延迟确认实际例子演示除了第一次，剩下的 RTT 全为 40 多毫秒。这刚好是 Linux 延迟确认定时器的时间 40ms 抓包结果如下:
可以设置关掉延迟确认吗？大部分 Linux 实现上并没有开关可以关闭延迟确认。
当 Nagle 算法遇到延迟确认Nagle 算法和延迟确认本身并没有什么问题，但一起使用就会出现很严重的性能问题了。Nagle 攒着包一次发一个，延迟确认收到包不马上回。