从这里，您可以看到从三次握手开始，此 TCP 连接的每个请求和响应。当然，这可能不够直观，可以继续点击菜单栏中的 Statistics -> Flow Graph，选择 “Limit to display filter”，将 Flow type 设置为 “TCP Flows”：

请注意，此图的左侧是客户端，而右侧是 Nginx 服务器。从这个图中可以看出，前三次握手和第一次 HTTP 请求和响应都相当快，但是第二次 HTTP 请求就比较慢了，尤其是客户端收到服务器的第一个数据包后，该 ACK 响应（图中的蓝线）在 40ms 后才被发送。

看到 40ms 的值，你有没有想到什么？事实上，这是 TCP 延迟 ACK 的最小超时。这是 TCP ACK 的一种优化机制，即不是每次请求都发送一个 ACK，而是等待一段时间（比如 40ms），看看有没有“搭车”的数据包。如果在此期间还有其他数据包需要发送，它们将与 ACK 一起被发送。当然，如果等不及其他数据包，超时后会单独发送 ACK。

由于案例中的客户端发生了 40ms 延迟，我们有理由怀疑客户端开启了延迟确认机制（Delayed Acknowledgment Mechanism）。这里的客户端其实就是之前运行的 wrk。

根据 TCP 文档，只有在 TCP 套接字专门设置了 TCP_QUICKACK 时才会启用快速确认模式（Fast Acknowledgment Mode）；否则，默认使用延迟确认机制：

TCP_QUICKACK (since Linux 2.4.4)
              Enable  quickack mode if set or disable quickack mode if cleared.  In quickack mode, acks are sent imme‐
              diately, rather than delayed if needed in accordance to normal TCP operation.  This flag is  not  perma‐
              nent,  it only enables a switch to or from quickack mode.  Subsequent operation of the TCP protocol will
              once again enter/leave quickack mode depending on internal  protocol  processing  and  factors  such  as
              delayed ack timeouts occurring and data transfer.  This option should not be used in code intended to be
              portable.