更有趣的是我越来越多地看

rmruhul

到的是当涉及到站点速度问题时，我们正在把自己逼入绝境所以我们实际上给自己制造了很多问题。所以这实际上意味着性能……我想它是移动的球门柱。网络的格局或地形、其构建方式和我们的工作方式变化越大，我们就会给自己带来新的挑战。因此，在客户端上做更多工作的出现带来了与五年前我们要解决的不同的性能问题，但这些性能问题仍然与浏览器内部有关，总的来说，五年来没有改变。所以很大程度上取决于......我想说它肯定有两个明确的方面......我鼓励我的客户依靠浏览器，依靠标准，因为它们不能只是改变，球门柱并没有真正移动。但是，当然，这需要与更现代、也许更有趣的开发实践相结合。所以你保留你的……好吧，我本来想说“在两个阵营中都有一只脚”，但凭借我的七英尺，我必须……四脚和三脚。

德鲁：您提到基本原理不会改变，TCP/IP 之类的东西也不会改变。其中一件事确实发生了变化……我说的是“最近几年”，这实际上可能有点回溯了，但是，HTTP 是因为我们已经建立了 HTTP 协议用于客户端和服务器之间的通信，并且 电报号码数据 发生了变化，然后我们得到了 H2，它是二进制的并且是不同的。这改变了很多......这是出于性能原因，它是为了消除一些现有的限制，但这是一个变化，我们必须优化该协议的方式发生了变化。现在稳定了吗？还是会再次改变，或者……

哈利：所以我想更多了解的一件事是问题的后半部分，再次发生变化。我需要更多地研究 QUIC 和 H3，但它对我的客户来说有点太遥远了。当谈到 H2 时，事情发生了很大的变化，但我真的认为 H2 是很多虚假的承诺，而且我确实相信它是仓促完成的，考虑到 H1 的推出，这是值得注意的……我的意思是 1.1，是 1997 年，所以我们有很多时间来研究H2。

哈利：我想主要的好处是网络开发人员了解它或认为它现在的飞行请求是无限的。因此，不是一次发送六个请求和/或六个正在进行的请求，而是可能无限的、无限的。不过，这带来了非常有趣的问题，因为……如果没有视觉辅助，很难描述，但您仍然拥有相同数量的可用带宽，无论您运行的是 H1 还是 H2，该协议都不会让您的连接速度更快。因此，您很可能会通过一次请求 24 个文件来淹没网络，但您没有足够的带宽来实现这一点。所以你实际上并没有变得更快，因为你一次只能管理其中的一小部分。



哈利：您还必须考虑文件如何响应。这是我在客户研讨会等上经历过的另一个专业技巧。人们在查看 H2 瀑布时会发现，他们可能会看到 24 个请求，而不是传统的 6 个调度请求。调度 24 个请求实际上并没有那么有用。有用的是这些响应何时返回。您会注意到，您可能会发送 24 个请求，因此瀑布的左侧看起来非常漂亮且陡峭，但它们都以相当交错的顺序方式返回，因为您需要限制带宽量，因此您无法同时完成所有响应。

哈利：好吧，另一件事是，如果您要同时完成所有响应，那么您就会交错响应。所以你晚上会得到每个文件的前 10%，而接下来的 20%……JavaScript 文件的 20% 是无用的。JavaScript 在 100% 完成之前无法使用。所以，事实上，当您查看响应时，您将看到 H2 瀑布的表现方式……无论如何，它看起来更像 H1，更加交错。所以，H2，我认为它被超卖了，或者也许工程师没有被引导相信它的有效性是有上限的。因为您会看到人们过度分割他们的资产，他们可能有 20 个……让我们保留数字 24。您可能有 24 个小包，而不是两个大 JS 文件。他们仍然会按顺序返回。它们不会同时到达，因为您没有为自己添加更多带宽。