我想主要的好处是网络开发人员

ruhul11

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

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

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

哈利：另一个问题是每个请求都有恒定的延迟。假设您请求两个大文件，往返时间为 100 毫秒，下载时间为 250 毫秒，这是 250 毫秒的两倍。如果您乘以 24 个请求，您仍然会遇到恒定的延迟，我们将其确定为 100 毫秒，所以现在您的延迟为 2400 毫秒，并且有 24 次……而不是 250 毫秒下载，我们假设它的下载时间为 25 毫秒，实际上需要更长的时间，因为延迟保持恒定，并且您只需将延迟乘以更多请求即可。因此，我会看到那些读过 H2 就是这颗灵丹妙药的客户。他们会分裂……哦！他们无法简化开发过程，我们不需要进行捆绑或串联等等。最终它会变慢，因为你已经设法分散你的请求，这是承诺，但你的延迟保持不变，所以你实际上在浏览器中得到了 n 倍的延迟。就像我说的，在没有视觉效果的情况下试图解释这一点真的很难，可能毫无意义，但与人们希望它能做到的相比，H2 的表现是值得注意的。



德鲁：分片过程是否还有好处，好吧，获取全部数据仍然需要相同的时间，但是当你在 24 日获得第一个分片的 100% 时，你就可以开始处理它并开始执行24号之前就结束了。

哈利：哦，伙计，另一个好问题。所以，绝对地，如果事情进展顺利，并且它确实以更像 H1 的响应表现出来，那么这个想法将是文件一首先返回，然后返回两个、三个、四个，然后它们可以按照到达的顺序执行。因此，您实际上可以通过确保事物同时到达来缩短总时间。如果我们查看网页而不是瀑布，并且您注意到请求是交错的，那就是坏消息。因为正如我所说，JavaScript 文件的 10% 是无用的。

哈利：如果服务器正确地完成其工作并且发送、发送、发送、发送、发送，那么它会变得更快。然后，您的缓存策略就会变得更加精细，从而带来连锁反应。所以真正烦人的是你更新日期选择器小部件上的字体大小。在 H1 世界中，您必须缓存大约 200 千瓦的站点宽 CSS。而现在，您只需缓存bust datepicker.css。所以我们有这样的分支利益，这绝对是非常有价值的。