虽然这种方法非常有用并且通常“足够好”以了解慢速

网络的影响，但测试低级协议差异不够现实。由于浏览器无法直接访问 TCP 堆栈，因此它仍然会在正常网络上下载页面，然后人为地延迟数据到达必要的浏览器逻辑。例如，这意味着Lighthouse 仅模拟延迟和带宽，而不模拟数据包丢失（正如我们所见，

这是 /3 可能与 /2 不同的一个主要点）。另外，Lighthouse使用高度先进的模拟模型来猜测真实的网络影响，因为，例如，Google Chrome 具有一些复杂的逻辑，如果检测到网络速度较慢，就会调整页面加载的多个方面。据我所知，这个模型，尚未调整以处理 IETF QUIC 或 /3。

因此，如果您今天使用 Lighthouse 的唯一目的 手机号数据库列表 是比较 /2 和 /3 性能，那么您可能会得到错误或过于简化的结果，这可能会导致您对 /3 可以为您做什么做出错误的结论。网站在实践中。一线希望是，从理论上讲，这在未来可以得到大规模改进，因为浏览器确实可以完全访问 QUIC 堆栈

因此 Lighthouse 可以为 /3 下行添加更高级的模拟（包括数据包丢失！）线。不过目前，虽然 Lighthouse 理论上可以通过 /3 加载页面，但我建议不要这样做。

网页测试

其次，有WebPageTest。这个令人惊叹的项目可以让您从世界各地的真实设备通过真实网络加载页面，它还允许您在顶部添加数据包级网络模拟，包括数据包丢失等方面！因此，WebPageTest 在概念上处于用于比较 /2 和 /3 性能的首要位置。然而，虽然它确实已经可以通过

新协议加载页面，但/3 尚未正确集成到工具或可视化中。例如，目前没有简单的方法来强制通过 QUIC 加载页面，以轻松查看如何Alt-Svc实际使用过，甚至可以看到QUIC握手细节。在某些情况下，甚至查看响应是使用 /3 还是 /2 也可能具有挑战性。不过，在 4 月份，我能够使用 WebPageTest 运行相当多的测试查看 /3 的实际情况，我现在将对此进行介绍。

首先，我运行了默认测启用“重复视图”选项。如上所述，我希望第一页加载使用 /2，其中将包含响应Alt-Svc标头。因此，重复视图应该从一开始就使用 /3。在Firefox 89 版本中，或多或少会发生这种情况。然而，当查看各个响应时，我们发现即使在第一个页面加载期间，Firefox 也会切换

到使用 /3 而不是 /2！正如您在图 2 中看到的，这种情况从第 20 个资源开始发生。这意味着 Firefox 一看到该连接就会建立一个新的 QUIC 连接Alt-Svcheader，一旦成功就会切换到它。如果向下滚动到连接视图，似乎还显示 Firefox 甚至打开了两个

QUIC 连接：一个用于有凭据的 CORS 请求，另一个用于无 CORS 请求。这是预料之中的，因为正如我们上面所讨论的，即使对于 /2 和 /3，浏览器也会出于安全考虑而打开多个连接。但是，由于 WebPageTest 在此视图中没有提供更多详细信息，因此如果不手动挖掘数据就很难确认。查看重复视图（第二次访问），正如预期的那样，它首先直接使用 /3 进行第一个请求。

666厉害厉害