为了优化高延迟链路的使用，接收器避免确认每个单独的数据包。否则在例如 300 毫秒内，您每秒只能发送 3 个数据包。以太网链路的通常最大 MTU 为 1500 字节，您可以看到这是不可扩展的（4.5KB/秒？带回 56Kbps 调制解调器时代！）

那么这个问题是如何解决的呢？

接收器在协商三向握手时通告接收窗​​口。此接收窗口也称为 TCP 窗口。此窗口是 TCP 标头中的一个值，从 0 到 64KB。如果接收方在 300 毫秒的链路上通告一个 64KB 的接收窗口（从现在起我简称为 RWIN），则发送方可以发送 64KB 的数据包，直到不得不等待确认。这意味着您可能会看到大约 20 个发送的数据包，并且最后只有一个 ACK​​（这是不准确的）：您应该每隔一个数据包至少看到一个 ACK​​，但您会看到它们被延迟）。给定无限的链接带宽，链接延迟和 RWIN 的这种组合将使您传输文件的速度高达 192KB/秒。比以前好多了，快了 42 倍！但是对于今天的链接来说仍然不够。TCP 标头中有一个字节指定接收窗口的乘数，最高可达 256，这为您提供大约 50MB 的接收窗口。

以上实际上解释了您没有看到每个接收到的数据包一个 ACK​​ 的原因之一，但是正如您所看到的，RWIN 主题还有更多内容，而且您知道，发送方并不总是愿意发送尽可能多的数据尽可能不等待确认（例如，发送方应用程序可能没有那么多要发送的内容）；因此，分析有关此主题的特定行为可能会很棘手。

您还提到您看到一堆 ACK 在一起，正如另一个响应所说，延迟 ACK 可能是某些情况下的原因，尽管您会看到一堆 ACK 看似一起发送的另一个原因是接收方是否能够快速摄取它在接收缓冲区中的数据。接收方将在完全填充接收窗口之前确认段，提示发送方继续发送数据（因为接收窗口没有填满）。通过这种方式，您可以再次提高可以使用的最大带宽。

另一方面，如果接收方接收接收到的数据很慢，接收窗口将填满，接收方将不得不指示发送方停止发送数据。您会看到这反映在捕获期间广告接收窗口缩小，直到它达到零。

您可能会看到几个 ACK​​ 看起来在一起的另一个原因是选择性确认：

如果接收方通告了 15K 的接收窗口，则发送方将发送 10 个 1.5K 的数据包，而无需等待 ACK。假设接收器从 1 到 4 和从 6 到 10 收到数据包 - 接收器将开始确认收到的那些段，直到 #4，此时它将开始明确标记接收到的数据包的第一个和最后一个序列号，同时确认 #4对于#5 之后收到的每个数据包。发送方将意识到接收方有数据包 1 到 4 和 6 到 10，但没有数据包 5，因此它将重传这个（并且仅这个）数据包。

一些网络分析器可能会通过只查看它们的“ACK”字段（始终是最后一个接收到的数据包中的那个）而不是第一个/最后一个 seq 编号的 SLE/SRE 来将这束 ACK 标记为重复的 ACK。

我自己已经多次看到这种情况，在大多数情况下，根据我捕获流量的位置，这是传播延迟的结果。

如果您在更靠近发送方的上游某处捕获数据，特别是在高延迟链路中，您会看到大量数据包在接收方有时间接收、处理和确认数据包之前发送到接收方，并且这些数据包将其返回通过网络到达您的捕获点，导致明显的“ack 突发”。传播延迟是造成这种影响的原因。

现在，这种流量模式也可能由许多其他因素引起（例如 CPU/内存/等资源利用率低或过度使用、NIC 驱动程序不佳或接收器上的旧 NIC 硬件），但在大多数情况下，我已经处理过这个问题是良好的 'ole 传播延迟/高延迟的结果。

有时通过一个例子可以更好地理解这种效果：

假设您有一个由广域网分隔的服务器和客户端，该广域网具有 100Mbps 的带宽容量和 20 毫秒的往返时间 (RTT) 的端到端网络延迟（传播延迟）。
客户端公布了一个经典的 TCP 接收窗口 (RWIN) 值 64KB，传输是 IP，MTU 和 TCP 最大段大小分别为 1500 和 1460 字节，服务器通过 TCP 向客户端发送一个大文件。
在这种情况下，为简单起见，将忽略拥塞窗口/慢启动、选择性确认和 RWIN 缩放。

由于接收窗口的概念，TCP 发送方（在本例中为服务器）知道在客户端（接收方）确认它已收到任何数据之前，它可以发送 64KB 的 TCP 有效负载数据。对于 1460 字节的 MSS，这相当于 45 个数据包，总共大约 45 个数据包。526Kb（64KB + TCP/IP 开销/每字节 8 位）。
以 100Mbps 的速度，服务器能够以大约 526Kb 的速度发送那些 526Kb 的数据。5.3 毫秒。在客户端开始确认已发送的数据（传输中的数据）之前，服务器无法发送任何其他数据。

由于网络的传播延迟，第一个数据包到达客户端需要 10ms（20ms RTT/2 = 单向延迟）。即使客户端在每个数据包到达时立即确认（或者更有可能，由于延迟确认，确认每个其他数据包），这些确认也需要 10 毫秒才能从客户端传输回服务器。

当服务器收到第一个确认时，它已经等待了至少 14.7 毫秒，因为它向客户端发送了最后一个数据包，其余的确认在接下来的几毫秒内到达。
在服务器端捕获流量时，这将表现为来自服务器的突发数据包，然后是延迟，接着是来自客户端的突发确认，然后是（或穿插着）另一个突发数据包等，直到数据传输完成。

但是，在这里要了解的重要一点是，从客户端开始，它会在数据包到达时立即对其进行确认，实际上，如果您在客户端捕获，您会看到延迟，然后是均匀混合的数据包到达和 acks 被发送，然后是延迟等。
这就是为什么在解释它时了解流量捕获发生在哪里非常重要。

您正在寻找Delayed ACK，请参阅 4.2.3.2 何时发送 ACK 段

一般情况下，什么时候发送 ACK 什么都不能说。这是因为网络协议旨在优化发送，例如通过延迟 ACK 并将其搭载到另一个数据帧而不是立即发送它。