代码之家  ›  专栏  ›  技术社区  ›  saitho

Google AMP缓存和HTTP/2–通过HTTP/2在移动设备上交付内容?

  •  1
  • saitho  · 技术社区  · 8 年前

    默认情况下,Google AMP缓存通过HTTP/2提供最大为12 MB的文件。尽管AMP不一定要在移动设备上使用,但它们是AMP背后的主要动机。

    我刚读过 a paper about the performance of HTTP/2 on cellular networks . 虽然他们发现,对于小文件(2 MB),HTTP/2比HTTP/1.1快,但他们还发现,对于8 MB或更大的文件,包丢失对HTTP/2的影响比HTTP/1.1更大,导致页面加载时间更长(即,在这种情况下,HTTP/1.1比HTTP/2快)。在他们的研究中,32%的移动连接经历了数据包丢失。

    因此,我一直想知道HTTP/2是否真的是(谷歌)AMP缓存的发展方向。

    3 回复  |  直到 8 年前
        1
  •  2
  •   Barry Pollard    8 年前

    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)

    谷歌还正在试验基于QUIC的HTTP/2而非TCP,这解决了单一HTTP/2连接速度慢的主要原因(即单个TCP数据包丢失将占用所有HTTP/2流,而不仅仅是数据包所属的流)。当然,这目前只在Chrome中起作用,所以其他浏览器还不能从中受益,但Chrome的用户群还是相当大的。

    因此,基于所有这些,我认为HTTP/2绝对是一条出路,尤其是对于AMP页面。正如我在一开始所说的,它并不完美,在某些情况下,有些页面可能会比它慢,但绝大多数页面应该比它快,因此应该使用它。

        2
  •  2
  •   Luis Franco    8 年前

    HTTP/2的主要目的是性能,首先,为什么不是HTTP/1.1

    HTTP/1.1引入了IETF官方标准;不幸的是,实现的简单性也以应用程序性能为代价:

    • HTTP/1。x客户端需要使用多个连接来实现并发并减少延迟;
    • HTTP/1。x不压缩请求和响应头,导致不必要的网络流量;
    • HTTP/1。x不允许有效的资源优先级划分,导致底层TCP连接使用不当;等等

    这些限制并不是致命的,但随着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)也不在可能的范围之外。

    资料来源: https://hpbn.co/http2/

        3
  •  1
  •   abielita    8 年前

    基于此 documentation ,Google AMP缓存执行优化和修改,它通过安全通道(HTTPS)提供服务,并使用最新的web协议(SPDY, HTTP/2 ). 也是从这个 blog ,Google AMP Cache是一个基于代理的内容交付网络,用于交付所有有效的AMP文档。它提取AMP HTML页面,缓存它们,并自动提高页面性能。 当使用Google AMP缓存时,文档、所有JS文件和所有图像都从使用HTTP 2.0的同一来源加载,以获得最大效率。