为什么第一次网络调用比后续网络调用花费更多时间？

Question

我试图理解这种行为，其中第一个网络调用需要后续网络调用的两倍以上。我知道 DNS 解析不会超过 5-50 毫秒，并且只发生在初始调用中。考虑到此信息，第一次呼叫和后续呼叫所花费的时间应该不会有太大差异。

我已经在单独的隐身窗口中使用一些著名的 URL 测试了这种行为，每个 URL 都禁用了缓存，并附上了一些屏幕截图来支持我在下面的观察。谁能帮助我理解这种行为？

注意：读数是在全速互联网连接下获取的

Answer 1

经过几次实验，我发现

Content Download

（浏览器请求步骤）部分请求速度加快了1.5-2倍 这看起来像是

TCP Slow Start algorithm

的原因

正如它所说：

现代浏览器要么同时打开多个连接，要么对从特定 Web 服务器请求的所有文件重复使用一个连接

这可能是第一个请求比其他请求慢的原因

此外，@Vishal Vijay 做了一个很好的补充：

与服务器进行初始连接握手需要时间（DNS 查找 + 初始连接 + SSL）。浏览器正在为 HTTP 请求创建持久连接并使其保持打开状态一段时间。如果在此时间内有任何请求来自同一域，浏览器将尝试重用相同的连接以获得更快的响应。

Answer 2

在某些情况下，可能是服务器端缓存机制导致后续请求处理得更快，但我们只讨论浏览器端的东西。

当您将鼠标悬停在瀑布“块”上时，您将获得时间详细信息：

以下是每个阶段的快速参考（来自 Google Developers）：

• 排队。浏览器在以下情况下对请求进行排队：
  • 有更高优先级的请求。
  • 已为此源打开 6 个 TCP 连接，这是限制。仅适用于 HTTP/1.0 和 HTTP/1.1。
  • 浏览器正在短暂分配磁盘缓存空间
• 停滞。由于排队中描述的任何原因，请求可能会被停滞。
• DNS 查找。浏览器正在解析请求的 IP 地址。
• 代理协商。浏览器正在与代理服务器协商请求。
• 请求已发送。请求正在发送。
• ServiceWorker 准备。浏览器正在启动 Service Worker。
• 向 ServiceWorker 请求。请求正在发送给服务人员。
• 等待（TTFB）。浏览器正在等待响应的第一个字节。 TTFB 代表第一个字节的时间。这个时间包括 1 往返延迟和服务器准备数据所花费的时间 回应。
• 内容下载。浏览器正在接收响应。
• 接收推送。浏览器正在通过 HTTP/2 服务器推送接收此响应的数据。
• 阅读推送。浏览器正在读取之前接收到的本地数据。

那么传统 HTTP/1.1 场景下，第一次请求和后续请求有什么区别？

• DNS 查找：第一次请求解析 DNS 可能需要更多时间。使用浏览器 DNS 缓存可以更快地解决后续请求。
• 等待（TTFB）：第一个请求必须与服务器建立 TCP 连接。由于 HTTP keep-alive 机制，对同一服务器的后续请求将重用现有的 TCP 连接，以防止再次 TCP 握手，从而与第一个请求相比减少了三个往返时间。
• 内容下载：由于TCP启动缓慢，第一个请求将需要更多时间来下载内容。由于后续请求将重用 TCP 连接，因此当 TCP 窗口放大时，下载内容的速度将比第一个请求快得多。

因此，通常后续请求应该比第一个请求快得多。实际上，这导致了一个常见的网络优化策略：为您的网站使用尽可能少的域名。

HTTP/2 甚至引入了多路复用以更好地重用单个 TCP 连接。这就是为什么 HTTP/2 将在现代前端世界中提供性能提升，我们在 CDN 服务器上部署大量小型资产。

Answer 3

我迟到了，但是为了添加上面的答案，客户端和服务器之间的初始连接握手由阿德里安·坎特里尔（Adrian Cantrill）在视觉上很好地解释了-