从以上两个输出可以看出，官方 Nginx（监听 80 端口）的平均延迟为 9.19ms，而案例 Nginx（监听 8080 端口）的平均延迟为 43.6ms。从延迟分布上来看，官方 Nginx 可以在 9ms 内完成 90% 的请求；对于案例 Nginx，50% 的请求已经达到 44ms。

那么这里发生了什么呢？我们来做一些分析：

在 host1 中，让我们使用 捕获一些网络数据包：

现在，在 host2 上重新运行 命令

当 命令完成后，再次切换回 Terminal 1（host1 的终端）并按 Ctrl+C 结束 命令。然后，用 把抓到的 复制到本机（如果 VM1（host1 的虚拟机）已经有图形界面，可以跳过复制步骤），用 打开。

由于网络包的数量很多，我们可以先过滤一下。例如，选中一个包后，可以右键选择 “Follow”->“TCP Stream”，如下图：

然后，关闭弹出的对话框并返回 主窗口。这时你会发现 已经自动为你设置了一个过滤表达式 。如下图所示（图中省略了源 IP 和目的 IP）：

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

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

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

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

让我们测试一下我们的质疑：

可以看到 只设置了 选项，没有设置 。现在您可以看到为什么延迟 Nginx（案例 Nginx）响应会出现一个延迟。

在本文中，我们向您展示如何分析增加的网络延迟。网络延迟是核心网络性能指标。由于网络传输、网络报文处理等多种因素的影响，网络延迟是不可避免的。但过多的网络延迟会直接影响用户体验。

使用 和 等工具确认单个请求和并发请求的网络延迟是否正常。

使用 ，确认路由正确，并查看路由中每个网关跳跃点的延迟。

使用 和 确认网络数据包是否正常收发。

使用 等观察应用程序对网络 socket 的调用是否正常。