乍一看，我们的演示页面上HTTP/1.1相对于HTTP/2的潜在性能改进似乎有点难以相信。所以，我们把这个演示如何实际工作的技术解释放在一起。我们还想归功于Gophertiles演示，它是我们自己的HTTP/2演示的基础。概述网页只能通过HTTP/1.1或HTTP/2提供服务，不允许使用混合协议。我们的演示页面支持HTTP/2，因此无法在同一页面上直接加载HTTP/1.1内容。内联帧（iframes）可用于解决此问题。我们在演示页面上嵌入了两个iframe，它们都包含相同的源代码。关键区别在于一个iframe通过HTTP/1.1cdn加载，而另一个iframe通过HTTP/2cdn加载。我们选择amazoncloudfront作为HTTP/1.1cdn，因为它只能通过HTTP/1.1提供内容。对于HTTP/2cdn，我们使用自己的支持HTTP/2的网络。您可以查看单独的HTTP/1.1和HTTP/2iframe内容，它们的加载时间应该与演示页面上的并排示例相似。Iframe内容那么，这些iframe中包含了什么呢？每个页面都是一个完整的HTML页面，其中JavaScript按顺序构建

标记。为了清楚地说明HTTP/2的性能提高，在短时间内请求了200个图像块。使用一个名为ImageMagick的图像处理库，使用以下命令将单个大图像分成200个40x40块：转换-crop 40x40+repage http2.png磁贴-%d.png当JavaScript加载这些图像时，它会跟踪最后一个图像的加载时间以及所有图像的总加载时间。一旦发生这种情况，iframe需要向父窗口（演示页面本身）报告度量。由于iframe跨域安全规则，当iframe托管在另一个域上时，JavaScript无法查询iframe的DOM。但是，iframe可以使用窗口.postMessage方法。父窗口使用addEventListener或attachEvent方法侦听此消息。当两个iframe都加载了它们的内容时，性能差异将显示在演示页面上。缓存策略默认情况下，CloudFlare的CDN尝试尽可能多地缓存以获得最佳性能。这给我们的HTTP/2演示带来了一个问题，因为各种浏览器都在本地缓存图像块，使得我们的演示页面变得相当无用。为了解决这个问题，我们强制HTTP/1.1和HTTP/2cdn缓存edgeside中的所有内容，但不在本地浏览器缓存中存储任何内容。一个漂亮的Firefox缓存错误/特性如果你是一个Firefox用户，你会注意到当你点击demo页面上的Reload按钮时，完整的图像会立即显示出来，即使计时器一直在计时。这是因为Firefox不遵守我们的指示，不在浏览器中缓存图像块，即使我们明确告诉它不要。Firefox几年前决定缓存所有内容，包括没有缓存头的资产。其背后的基本原理实际上是相当合理的，它允许即时向前/向后导航和更好的离线浏览功能。除了这些类型的演示，没有真正的缺点。无论如何，如果你想在Firefox中用正确的图像加载行为重新加载演示，你可以用Cmd+Shift+R或Ctrl+Shift+R进行硬刷新。SPDY回退CloudFlare针对HTTP/2的独特价值主张之一是自动SPDY回退。当访问者的浏览器支持HTTP/2时，我们的边缘网络将使用HTTP/2。如果它支持SPDY而不支持HTTP/2，我们将在SPDY中响应。否则，我们将回到HTTP/1.1。正如在我们的HTTP/2公告博客文章中所讨论的，这使我们能够继续支持大约57%的支持SPDY但不支持HTTP/2的互联网用户。所以，如果你使用的是Safari8或Android浏览器，别担心！您可能看不到HTTP/2演示，但我们的边缘服务器将回到SPDY，它应该提供类似的结果。记住，这是演示，不是模拟我们的HTTP/2演示的目标是在真实环境中清楚地显示HTTP/2的主要好处。虽然它是由真实的cdn提供服务，并通过其他人使用的相同的互联网电缆传输，但这仍然是一个理想化的场景。大量的图像块突出了HTTP/2多路复用的效率，但它不一定代表一般的web页面。很难对任何一个单独的网站在使用HTTP/2时能够看到的性能改进提供一般性的预测，因为它在很大程度上取决于你的网页结构。如果你的网站同时加载200个小图片，那么你很可能会看到与我们的演示类似的加速。大多数web页面依赖较少的外部资产，这意味着它们的性能提升可能不那么显著。然而，HTTP/2协议是专门为减少最终用户所感知的网页加载时间而设计的。典型的网站只需切换到HTTP/2，就可以看到显著的性能提升。