为什么第一个网络通话比后续的通话花费更多的时间？

Question

我正在尝试理解这种行为，其中第一个网络呼叫所花费的时间比后续网络呼叫的两倍还多。我知道DNS解析不会花费超过5-50ms的时间，并且仅在初始调用中发生。考虑到此信息，第一次通话和后续通话所花费的时间应该不会有太大差异。

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

注意：读数是在全速Internet连接中获取的

预先感谢

Answer 1

经过几次实验，我发现请求的Content Download（browser request steps）部分加快了1.5-2倍 这似乎是TCP Slow Start algorithm

的原因

声明：

  

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

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

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

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

Answer 2

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

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

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

  

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

那么在传统的HTTP / 1.1方案中，第一个请求和后续请求之间有什么区别？

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

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

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