默认情况下，Google AMP 缓存通过 HTTP/2 提供最大 12 MB 的文件。尽管 AMP 并不局限于在移动设备上使用，但它们是 AMP 背后的主要动机。
我刚刚阅读了一篇关于蜂窝网络上 HTTP/2 性能的论文。虽然他们发现 HTTP/2 对于小文件 (2 MB) 比 HTTP/1.1 更快，但他们还发现 8 MB 或更大文件的包丢失对 HTTP/2 的影响比 HTTP/1.1 更大，导致更高的页面加载时间（即在这种情况下 HTTP/1.1 比 HTTP/2 快）。在他们的研究中，32% 的移动连接都经历过包裹丢失。
因此，我一直想知道 HTTP/2 是否真的是（Google）AMP 缓存的最佳选择。
HTTP/2主要目的是性能，第一，为什么不是HTTP/1.1
HTTP/1.1 引入了官方 IETF 标准；不幸的是，实现的简单性也以应用程序性能为代价：
这些限制并不是致命的，但随着 Web 应用程序在我们日常生活中的范围、复杂性和重要性不断增长，它们给 Web 的开发人员和用户带来了越来越大的负担，这正是 HTTP/ 2 旨在解决：
来源： https ://developers.google.com/web/fundamentals/performance/http2/
现在，引用我在开始实施 AMP 时阅读的关于 HTTP/2 上的数据包丢失的研究：
丢包、高 RTT 链接和 HTTP/2 性能 等等，我听到你说，我们列出了每个源使用一个 TCP 连接的好处，但没有一些潜在的缺点吗？是的，有。
我们已经从 HTTP 中消除了行头阻塞，但在 TCP 级别仍然存在行头阻塞（请参阅行头阻塞）。
如果禁用 TCP 窗口缩放，带宽延迟产品的影响可能会限制连接吞吐量。
当发生丢包时，TCP 拥塞窗口大小会减小（参见拥塞避免），从而降低整个连接的最大吞吐量。
此列表中的每一项都可能对 HTTP/2 连接的吞吐量和延迟性能产生不利影响。然而，尽管有这些限制，迁移到多个连接会导致其自身的性能权衡：
由于不同的压缩上下文，头部压缩效率较低
由于不同的 TCP 流，请求优先级的效率较低
由于更多竞争流，每个 TCP 流的利用率较低，拥塞的可能性较高
由于更多 TCP 流而增加了资源开销
上述优点和缺点并不是一个详尽的列表，并且始终可以构建一个或多个连接可能被证明是有益的特定场景。然而，在野外部署 HTTP/2 的实验证据表明，单连接是首选的部署策略：
在迄今为止的测试中，线头阻塞的负面影响（尤其是在存在数据包丢失的情况下）被压缩和优先化的好处所抵消。
超文本传输协议第 2 版，草案 2
与所有性能优化过程一样，一旦您消除了一个性能瓶颈，您就可以解锁下一个性能瓶颈。在 HTTP/2 的情况下，可能是 TCP。这就是为什么服务器上经过良好调整的 TCP 堆栈再次成为 HTTP/2 的关键优化标准的原因。
正在进行研究以解决这些问题并总体上提高 TCP 性能：TCP 快速打开、成比例的速率降低、增加的初始拥塞窗口等等。话虽如此，重要的是要承认 HTTP/2 与其前身一样，并不强制使用 TCP。当我们展望未来时，其他传输，例如 UDP，并没有超出可能的范围。
对于大多数网站，HTTP/2 的一致性已被证明更快。是否有某些情况更糟 - 绝对！- 但是你应该阻止为少数人改进大多数网站吗？在我看来没有。
但是，即便如此，我认为您还需要考虑其他因素：
AMP 页面旨在提高性能，我想说，尤其是对他们来说，8mb 页面应该是例外而不是常态。因此，虽然在某些情况下对较大的页面使用 HTTP/1.1 可能更有效，但对于大多数较小的页面来说，使用 HTTP/2会更有效。
对于更大的页面，您应该回退到 HTTP/1.1 吗？也许，但这更复杂，因为在您知道页面之前首先协商协议，并且降级将需要重定向或类似的，并且肯定会减慢页面速度。
AMP 和 AMP 缓存是否应该限制为 8Mb 而不是 12Mb，因为它们使用 HTTP/2 并且本文建议这可能是一个更好的限制？也许——但话又说回来，它们并不是不能在 HTTP/2 上工作，它们会优雅地回退，但加载速度可能不像在 HTTP/1.1 上那样快。
此外，大多数 AMP 页面本身应该很小，并逐渐加载非必要资产（例如图像或视频）。因此，即使存在数据包丢失，大文件（可能是图像或视频）也可能不会阻止 AMP 页面的关键呈现。
是否所有移动页面都通过移动网络加载？是否有人通过 WiFi 网络使用手机，包丢失应该更少（我知道我知道！）。该论文不清楚 32% 的数字是蜂窝连接（即不通过 WiFi）还是所有移动连接（即蜂窝和 WiFi）
谷歌还在试验基于 HTTP/2 而不是 TCP 的 QUIC——这解决了单个 HTTP/2 连接速度慢的主要原因（即单个 TCP 数据包丢失将阻止所有 HTTP/2 流，而不仅仅是流该数据包也属于）。当然，这目前仅适用于 Chrome，因此其他浏览器尚无法从中受益，但 Chrome 再次拥有庞大的用户群。
所以基于这一切，我认为 HTTP/2 绝对是要走的路——尤其是对于 AMP 页面。正如我在一开始所说的那样，它并不完美，在某些情况下，有些页面可能会比它慢，但绝大多数页面应该比它快，因此应该使用它。