我在适度加载的系统上运行systat –tcp命令，在5秒的窗口中看到如下所示：
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 Load Average |||||||||||| TCP Connections TCP Packets 0 connections initiated 21062 total packets sent 153 connections accepted 16291 - data 153 connections established 125 - data (retransmit by dupack) 11 connections dropped 1 - data (retransmit by sack) 0 - in embryonic state 4271 - ack-only 5 - on retransmit timeout 0 - window probes 0 - by keepalive 217 - window updates 0 - from listen queue 0 - urgent data only 148 - control 0 - resends by PMTU discovery TCP Timers 21057 total packets received 9752 potential rtt updates 13471 - in sequence 12437 - successful 49 - completely duplicate 763 delayed acks sent 11 - with some duplicate data 140 retransmit timeouts 14 - out-of-order 0 persist timeouts 225 - duplicate acks 0 keepalive probes 12535 - acks 0 - timeouts 0 - window probes 80 - window updates 0 - bad checksum 为什么发送的确认号码比“延迟确认发送”号码加上接收到的重复数据号码高得多？ 除了传入的数据（应该经过延迟确认计时器）和接收到的模拟（即时确认）之外，哪些情况会生成只有确认的数据包。 Keepalive，我猜。 但是这个盒子没有长久闲置的连接。 一切都很短暂和愤怒。 还有一个keepalive行项目也说零…
我在这里丢失了什么关于TCP机器？
你似乎是推理，只有当机器得到一个愚蠢的时候，或计时器到期时，才发送只答包，但我不明白为什么这是真的。 还有一个类别，可能比其中任何一个都更为常见和重要，那就是ack窗口几乎已经满了。
如果另一台机器正在向您发送数据并发送足够的数据包以接近ack窗口，则本地机器将发送一个ack。 在没有其他数据要发回的情况下，它会发送一个ack-only包。
那么，为什么会有耽搁？ 因为我们不想确认客户端发送的每个数据包：这会产生过多的返回stream量。
假设recv窗口将允许10个传入数据包。 远程机器给我们一个。 没有必要马上就知道，因为他们知道他们可以给我们多达9个。 如果他们确实在继续发送数据包，那么当我们接近填写窗口时，我们将确认他们的传输。
另一方面，如果他们只发送一个数据包，然后停一会儿，我们至less要承认我们得到了这个数据包，这样他们就知道不要重发它，所以他们知道当前状态窗口。
延迟应答定时器区分这两种情况：让他们继续发送大量数据，而不会让数据长时间不被承认。