ACM通信

实践

用HTTP 2.0让Web更快

由Ilya Grigorik
ACM通讯，2013年12月，Vol. 56 No. 12, 42-49页
10.1145/2534706.2534721
评论

超文本传输协议(Hypertext transfer protocol, HTTP)是Internet上使用最广泛的应用协议之一。自发布以来，RFC 2616 (HTTP 1.1)一直是Internet空前增长的基础:从桌面计算机到我们口袋里的微型Web设备，数以十亿计的各种形状和大小的设备每天使用HTTP传输新闻、视频，以及数以百万计的其他Web应用程序，这些应用程序是我们日常生活中所依赖的。

它最初只是一个用于检索超文本的简单单行协议(即，"GET /文档)迅速演变成一种通用的超媒体传输方式。十年后的今天，它被用于几乎任何可以想象到的用例。

然而，在其自身成功的重压下，随着越来越多的日常互动继续迁移到网络社交、电子邮件、新闻和视频，以及越来越多的我们的个人和工作工作空间，http已经开始显示出压力的迹象。用户和开发人员现在都要求HTTP 1.1接近实时的响应速度和协议性能，不做一些修改是无法满足的。

为了迎接这些新的挑战，HTTP必须继续发展，这正是HTTP 2.0出现的地方。HTTP 2.0将使应用程序更快、更简单、更健壮，通过单个连接实现高效的多路复用和低延迟交付，并允许Web开发人员消除目前用于绕过HTTP 1.1限制的许多应用程序“漏洞”。

回到顶部

现代Web应用程序的性能挑战

自HTTP 1.1 RFC发布以来的十年间发生了很多变化:浏览器继续以加速的速度发展，用户连接配置随着移动Web发生了变化，现在移动Web处于一个转折点，Web应用程序的范围、野心和复杂性都在增长。其中一些因素有助于提高性能，而另一些因素则会造成阻碍。总的来说，Web性能仍然是一个尚未解决的大问题。

首先，好消息是:现代浏览器在性能方面付出了巨大的努力。JavaScript的执行速度继续稳步攀升(例如，2008年推出的Chrome浏览器提供了20倍的改进，仅在2012年，移动设备上的性能就进一步提高了50%以上¹⁰)．改进的不仅仅是JavaScript;现代浏览器还利用GPU加速来绘图和动画(例如，CSS3动画和WebGL)，提供对本地设备api的直接访问，并利用大量推测的优化技术⁴帮助隐藏和减少网络延迟的各种来源。

同样，宽带的采用(参见表1)在过去十年中继续稳步攀升。据Akamai称，虽然目前全球平均吞吐量为3.1Mbps，但许多用户可以获得更高的吞吐量，特别是随着住宅光纤解决方案的推出。¹然而，带宽只是等式的一半。延迟是一个经常被遗忘的因素，不幸的是，它现在经常被遗忘限制因素当你浏览网页的时候。^3.

在实践中，一旦用户拥有超过5Mbps的带宽，进一步的改进只会对平均Web应用程序的加载速度带来最小的提高:来自Web的流媒体高清视频是带宽限制的;加载承载高清视频的页面，以及它所有的资产，是延迟的限制。

现代Web应用程序看起来与十年前有很大的不同。根据HTTP档案，⁵现在，一个普通的Web应用程序由90多个资源组成，这些资源来自15多个不同的主机，总共传输了超过1300 kb(压缩)的数据。因此，很大一部分HTTP数据流由几十个不同的TCP连接上的小型(小于15KB)突发数据传输组成。这就是问题所在。TCP针对长时间连接和大量数据传输进行了优化。网络RTT(往返时间)是新TCP连接吞吐量的限制因素(TCP拥塞控制的结果)，因此，延迟也是大多数Web应用程序的性能瓶颈。

如何解决这种不匹配?首先，您可以尝试通过将服务器和比特定位到更靠近用户的位置，以及使用低延迟的链接来减少往返延迟。不幸的是，虽然这些都是必要的优化，但现在整个内容分发网络(CDN)行业都专注于这个问题，他们是不够的。以全球平均RTT为例google.com在2012年，它的运行时间大约是100毫秒，不幸的是，这个数字在过去几年里没有变化。

许多现有的链接已经在一个很小的常数因子(1.2^～1.5)光速限制，虽然仍有改进的空间，特别是在“最后一英里延迟”方面，相对的增益是适度的。更糟糕的是，随着移动网络的兴起，延迟瓶颈的影响只会变得更糟。虽然最新的4G移动网络专门针对低延迟的数据传输，但宣传的和实际的性能仍然经常以数百毫秒的开销来衡量表2AT&T核心无线网络中的延迟广告²)．

如果你不能从改进底层链接中获得所需的性能步骤功能，那么随着移动通信流量的增加，有一个回归，那么你必须把你的注意力转向如何构建应用程序和调整负责其交付的底层传输协议的性能。

回到顶部

HTTP 1.1的性能限制

改进HTTP的性能是HTTP 1.1工作组的主要设计目标之一，该标准引入了许多关键的性能增强。其中最著名的包括:

• 持久连接，以允许连接重用。
• 分块传输编码以允许响应流。
• 请求管道以允许并行请求处理。
• 字节用于允许基于范围的资源请求。
• 改进和更好的指定缓存机制。

不幸的是，由于缺乏支持和部署方面的挑战，一些HTTP 1.1特性(如请求管道)实际上已经失败了;虽然现在有些浏览器将管道作为可选特性支持，但很少有浏览器默认启用它。因此，HTTP 1.1强制客户端进行严格的请求排队(图1):客户端发送请求，必须等待服务器的响应，这意味着一个大的传输或缓慢的动态资源可能会阻塞整个连接。更糟糕的是，浏览器无法可靠地预测这种行为，因此常常被迫依赖启发式来猜测它是应该等待并尝试重用现有连接，还是打开另一个连接。

鉴于HTTP 1.1的局限性，Web开发社区总是创造性地创建并推广了许多自制应用程序工作区(称之为优化会给他们太多的信任):

• 现代浏览器允许每个源最多有6个并行连接，这实际上允许最多6个并行资源传输。由于不满足6个连接的限制，许多开发者决定申请域分片，它将站点资源跨越不同的源，从而允许更多的TCP连接。回想一下，现在一个页面平均与15个不同的主机通信，每个主机可能使用多达6个TCP连接。
• 具有相同文件类型的小文件通常被连接在一起，从而创建更大的捆绑包，以最小化HTTP请求开销。实际上，这是一种多路复用的形式，但它是应用于应用层的，例如，层叠样式表(CSS)和JavaScript文件被组合成更大的捆绑包，小图像被合并成图像精灵，等等。
• 有些文件直接内联到HTML文档中，以完全避免HTTP请求。

对于许多Web开发人员来说，所有这些实际上都是熟悉的、必要的和普遍接受的优化。然而，每一种解决方案往往对应用程序的复杂性和性能都有很多负面影响:

• 主动分片通常会导致网络拥塞，并适得其反，导致:额外和不必要的DNS(域名服务)查找和TCP握手;客户端、服务器和中介上的更多套接字导致更高的资源负载;并行流之间更多的网络争用;等等。
• 连接破坏了应用程序代码的模块化，并对缓存产生了负面影响(例如，常见的做法是将所有JavaScript或CSS文件连接到大型捆绑包中，这将强制下载并在单个字节更改时使整个捆绑包失效)。类似地，JavaScript和CSS文件只有在下载整个文件时才被解析和执行，这增加了处理延迟;较大的映像精灵也会占用更多的客户端内存，并需要更多的资源来解码和处理。
• 内联资源不能单独缓存，并扩展父文档。一种常见的做法是，通过base64编码，内联小图像的大小会增加30%以上，并打破浏览器中的请求优先级。通常，浏览器会以较低的优先级获取图像，以加快页面构建。

简而言之，许多变通方法都有严重的负面性能影响。Web开发人员不应该担心连接文件、激活图像、内联资产或域分片。所有这些技术都是针对HTTP 1.1协议限制的权宜之计。因此,HTTP 2.0。

回到顶部

HTTP 2.0的设计和技术目标

开发所有Web通信基础协议的主要修订版是一项非常重要的任务，需要大量仔细的思考、试验和协调。因此，定义一个清晰的技术章程是很重要的，甚至可以说更重要的是，定义项目的边界。其目的并不是要彻底检查协议的每一个细节，而是通过增量的方式对改进Web性能做出有意义的改进。

这样，HTTPbis工作组就有了章程⁶HTTP 2.0的作用域如下:

• 在使用TCP的HTTP 1.1的大多数情况下，可以显著地、可测量地改善终端用户感知的延迟。
• 解决HTTP中的HOL(行首)阻塞问题。
• 不需要多个连接到一个服务器来启用并行性，从而提高其对TCP的使用，特别是在拥塞控制方面。
• 保留HTTP 1.1的语义，利用现有文档，包括(但不限于)HTTP方法、状态代码、uri，以及适当的报头字段。
• 明确定义HTTP 2.0如何与HTTP 1交互。X，特别是在中介中。
• 清楚地确定任何新的扩展点和适当使用它们的策略。

为了实现这些目标，HTTP 2.0在TCP上引入了一种新的分层机制，它解决了HTTP 1.x众所周知的性能限制。HTTP的应用程序语义保持不变，核心概念如HTTP方法、状态码、uri和报头字段没有发生任何变化——这些变化显式地超出了范围。考虑到这一点，让我们来看看HTTP 2.0的“内部结构”。

请求和响应复用．HTTP 2.0所有性能增强的核心是新的二进制帧层(参见图2)，它规定了HTTP消息如何封装和在客户机和服务器之间传输。HTTP语义(如动词、方法和头)不受影响，但它们在传输过程中的编码方式是不同的。

与HTTP 1。x，如果客户端想要发出多个并行请求来提高性能，那么需要多个TCP连接。这种行为是由换行分隔的明文HTTP 1直接导致的。x协议，它确保每个连接一次只能发送一个响应，更糟糕的是，这也会导致HOL阻塞和底层TCP连接的低效使用。

HTTP 2.0中新的二进制帧层消除了这些限制，并支持完全的请求和响应多路复用。以下HTTP 2.0术语将有助于理解这个过程:

• 流一个连接内的双向字节流或虚拟通道。每个流都有一个相对优先级值和一个唯一的整数标识符。
• 消息映射到逻辑消息(如HTTP请求或响应)的完整帧序列。
• 框架HTTP 2.0中最小的通信单元，每个包含一个一致的帧报头，它至少标识了帧所属的流，并携带特定类型的数据(例如，HTTP报头、负载等)。

所有HTTP 2.0通信都可以在单个连接中执行，该连接可以携带任意数量的双向连接流．每个流依次进行通信消息，由一个或多个组成帧，每一个可能是交错的(见图3)，然后通过嵌入在每一帧报头中的流标识符重新组装。

将HTTP消息分解为独立的帧、在共享连接中区分优先级并交错它们，然后在另一端重新组合它们的能力是HTTP 2.0最重要的增强。就其本身而言，这种改变是完全不显著的，因为许多HTTP下的协议已经实现了类似的机制。然而，这个“小”改变在所有Web技术的整个堆栈中引入了一系列性能优势的涟漪效应，允许开发人员做以下工作:

• 并行交错多个请求，而不阻塞任何一个请求。
• 平行交错多个响应，不阻塞任何一个响应。
• 使用单个连接并行交付多个请求和响应。
• 通过消除不必要的延迟来降低页面加载时间。
• 1.删除不必要的HTTP。应用程序代码中的X工作区。
• 和更多…

二元结构．HTTP 2.0使用一个二进制的、长度前缀的帧层，它提供了比换行分隔的明文HTTP 1更紧凑的表示。X协议，处理起来更容易也更高效。所有HTTP 2.0帧共享一个公共的8字节报头(参见图4)，它包含帧的长度、类型、标志位字段和31位流标识符。

• 16位长度的前缀显示单个帧可以携带2¹⁶1字节数据^～64kb，不包括8字节的报头大小。
• 8位类型字段决定如何解释帧的其余部分。
• 8位flags字段允许不同的帧类型定义特定于帧的消息标志。
• 1位保留字段总是设置为0。
• 31位流标识符唯一标识HTTP 2.0流。

有了共享HTTP 2.0帧头的知识，您可以编写一个简单的解析器，它可以检查任何HTTP 2.0字节流，识别不同的帧类型，并通过检查每个帧的前8个字节报告它们的标志和每个帧的长度。此外，由于每一帧都有长度前缀，解析器可以快速有效地跳到下一帧的开头。与HTTP 1.x相比，这是一个很大的性能改进。

一旦知道了框架类型，解析器就可以解释框架的其余部分。HTTP 2.0标准定义了中列出的类型表3．

对这种框架分类的全面分析超出了本文的范围，毕竟这是规范的内容⁷是for(它做得很好!)说到这里，让我们进一步看看两个最常见的工作流:启动一个新流和交换应用程序数据。

回到顶部

启动新的HTTP 2.0流

在发送任何应用程序数据之前，必须创建一个新的流，并发送适当的元数据，如HTTP头。这就是HEADERS帧的作用图5)．

注意，除了通用报头之外，还添加了一个可选的31位流优先级。因此，无论何时客户端发起一个新的流，它都可以向服务器发送该请求的相对优先级，甚至可以稍后通过发送另一个优先级帧来重新设置优先级。

客户端和服务器如何协商唯一的流id ?他们不。客户端发起的流的id为偶数，服务器发起的流的id为奇数。这种偏移消除了客户端和服务器之间的流id冲突。

最后，HTTP报头键-值对通过自定义报头压缩算法(稍后将详细介绍)进行编码，以最小化有效负载的大小，并将它们附加到帧的末尾。

注意，HEADERS帧只用于通信关于每个流的元数据。实际的应用程序负载是在帧负载中独立交付的(参见图6)，也就是说，“数据”和“控制”消息之间是分离的。

DATA帧很简单:它是普通的8字节报头，后面是实际的负载。为了减少HOL阻塞，HTTP 2.0标准要求每个数据帧不超过2¹⁴1(16,383)字节，这意味着较大的消息必须被分解成较小的块。序列中的最后一条消息设置END_STREAM标志来标记数据传输的结束。

还有一些更多的实现细节，但是这些信息足以构建一个非常基本的HTTP 2.0解析器非常基本的．流优先级、服务器推送、报头压缩和流控制(还没有提到)等特性值得进行更多的讨论，因为它们对于从HTTP 2.0获得最佳性能至关重要。

流的优先级．一旦可以将HTTP消息拆分为许多单独的帧，就可以优化帧在连接中交错和交付的确切顺序，从而进一步提高应用程序的性能。因此，可选的31位优先级值:0表示最高优先级流;2³¹1表示优先级最低的流。

在浏览器中呈现页面时，并非所有资源都具有同等的优先级:当然，HTML文档是关键的，因为它包含了其他资源的结构和引用;创建可视化呈现树需要CSS(在拥有样式表规则之前，您不能绘制像素);越来越多地，JavaScript也被要求引导页面;其余的资源(如图像)可以以较低的优先级获取。

好消息是，所有现代浏览器都已经在执行这种内部优化了，它们根据资产的类型、它们在页面上的位置、甚至从以前的访问中获得的优先级来对不同的资源请求进行排序⁴(例如，如果渲染在之前的访问中被阻止在某个资产上，相同的资产可能在未来被优先级更高)。

随着HTTP 2.0中显式流优先级的引入，浏览器可以将这些推断出的优先级传递给服务器以提高性能:服务器可以通过控制资源分配(CPU、内存、带宽)来确定流处理的优先级;一旦响应数据可用，服务器可以优先向客户端发送高优先级的帧。更好的是，客户端现在能够在发现所有请求时立即分派它们(也就是说，消除客户端请求排队延迟)，而不是根据HTTP 1.x提供的有限并行性依赖请求优先级启发式。

服务器推送．HTTP 2.0的一个强大的新特性是服务器能够为单个客户端请求发送多个响应，也就是说，除了对原始请求的响应之外，服务器还可以向客户端推送额外的资源，而无需客户端显式地请求每个资源。

为什么需要这样一个机制?典型的Web应用程序包含许多资源，客户机通过检查服务器提供的文档发现所有这些资源。因此，为什么不消除额外的延迟，让服务器提前将相关的资源推给客户端呢?服务器已经知道客户机需要哪些资源服务器推送．

事实上，虽然支持服务器推送作为一种HTTP协议特性是新的，但许多Web应用程序已经在使用它了，只是名称不同:内联．每当开发人员通过数据uri内联资产css、JavaScript或任何其他资产时，他们实际上是将资源推给客户端，而不是等待客户端请求它。与HTTP 2.0唯一的区别是，该工作流现在可以从应用程序转移到HTTP协议本身，这提供了重要的好处:推入的资源可以由客户端缓存，由客户端拒绝，跨不同页面重用，并由服务器确定优先级。

实际上，服务器推送使得在HTTP 1.x中使用内联的大多数情况都过时了。

头压缩．每个HTTP传输都携带一组用于描述传输资源的头。在HTTP中1。x，此元数据总是以明文形式发送，并且通常会为每个请求增加500到800字节的开销，如果需要HTTP cookie，则通常会增加更多。为了减少开销并提高性能，HTTP 2.0会压缩报头元数据:⁸

• HTTP 2.0在客户机和服务器上使用头表来跟踪和存储以前发送的头键值对，而不是在每个请求和响应上重新传输相同的数据。
• 头表在整个HTTP 2.0连接中持续存在，并由客户机和服务器增量更新。
• 每个新的头键-值对要么被追加到现有表，要么替换表中以前的值。

因此，HTTP 2.0连接的双方都知道已经发送了哪些报头以及它们之前的值，这就允许将一组新的报头编码为简单的差异(参见图7)。

在连接的整个生命周期中很少更改的普通键值对(例如，用户代理、接受报头等)只需要传输一次。事实上，如果请求之间没有改变报头(例如，对同一资源的轮询请求)，那么报头编码开销为零字节——所有的报头都自动从前一个请求继承。

流控制．在同一个TCP连接上复用多个流会引起共享带宽资源的争用。流的优先级可以帮助确定交付的相对顺序，但是仅仅优先级不足以控制在多个流之间如何执行资源分配。为了解决这个问题，HTTP 2.0提供了一个简单的流和连接流控制机制:

• 流量控制是逐跳控制，而不是端到端控制。
• 流量控制是基于窗口更新帧的:接收端发布它准备在流上接收多少字节的数据帧负载，以及整个连接的数据帧负载。
• 流控制窗口的大小通过指定流ID和窗口增量值的WINDOW_UPDATE帧来更新。
• 流量控制是定向的，接收端可以为每个流和整个连接设置它想要的任何窗口大小。
• 流量控制可以被接收器禁用。

TCP的经验表明，流量控制既是一门艺术，也是一门科学。对更好的算法和实现改进的研究一直持续到今天。考虑到这一点，HTTP 2.0不强制要求任何特定的方法。相反，它只是提供必要的工具来实现这样的算法，这是进一步研究和优化的重要领域。

高效的HTTP 2.0升级和发现．虽然有更多的技术和实现细节，但本文还是介绍了HTTP 2.0的重点:二进制帧、多路复用、优先级、服务器推送、报头压缩和流控制。结合起来，这些特性将在客户机和服务器上提供显著的性能改进。

说到这里，还有一个小细节:如何部署HTTP协议的重大修订?向HTTP 2.0的转换不可能在一夜之间发生。数以百万计的服务器必须更新以使用新的二进制帧协议，数以十亿计的客户端也必须更新他们的浏览器和网络库。

好消息是，大多数现代浏览器都使用高效的后台更新机制，这将快速支持HTTP 2.0，并且对大部分现有用户的干预最小。尽管如此，一些用户还是会被旧的浏览器所困，服务器和中介也必须更新以支持HTTP 2.0，这是一个更长的劳动和资本密集型过程。

HTTP 1。X至少还会存在十年，大多数服务器和客户端都必须支持1。X和2.0标准。因此，在启动新的HTTP会话时，支持HTTP 2.0的客户机必须能够发现服务器和任何及所有中间层是否支持HTTP 2.0协议。有两种情况需要考虑:

• 通过TLS启动一个新的(安全)HTTPS连接。
• 启动一个新的(未加密的)HTTP连接。

在安全HTTPS连接的情况下，新的ALPN(应用层协议协商)⁹)扩展到TLS协议允许用户协商HTTP 2.0支持作为常规TLS握手的一部分:客户端发送它支持的协议列表(例如，HTTP /2.0);服务器选择一个发布的协议，并通过将协议名称发送回客户端作为常规TLS握手的一部分来确认它的选择。

在常规的非加密通道上建立HTTP 2.0连接需要更多的工作。因为HTTP 1.0和HTTP 2.0都运行在同一个端口(80)上，在没有任何关于服务器对HTTP 2.0支持的其他信息的情况下，客户机将不得不使用HTTP Upgrade机制来协商适当的协议，如下所示图8．

使用Upgrade流，如果服务器不支持HTTP 2.0，那么它可以立即用HTTP 1.1响应响应请求。或者，它可以通过返回HTTP 1.1格式的“101交换协议”响应来确认HTTP 2.0的升级，然后立即切换到HTTP 2.0，并使用新的二进制帧协议返回响应。无论哪种情况，都不会产生额外的往返。

回到顶部

水晶球

开发所有Web通信基础协议的主要修订版是一项非常重要的任务，需要大量仔细的思考、试验和协调。因此，对HTTP 2.0时间表的预测是危险的——它准备好了就会准备好。话虽如此，HTTP工作组正在取得快速进展。其过去和预计的里程碑如下:

• 200911月spdy协议由谷歌宣布。
• 2012年3月HTTP 2.0征集提案。
• 2012年9月HTTP 2.0的第一稿。
• 2013年7月HTTP 2.0的第一个实现草案。
• 2014年4月工作组对HTTP 2.0的最后一次呼吁。
• 2014年11月将HTTP 2.0作为建议标准提交给IESG (Internet Engineering Steering Group)。

SPDY是在谷歌上开发的实验性协议，于2009年年中发布，它后来成为早期HTTP 2.0草案的基础。许多修订和改进之后，到2013年底，已经有了协议的实现草案，互操作性工作正在全面展开。最近的互操作事件中，微软开放技术、Mozilla、谷歌、Akamai和其他贡献者实现了客户端和服务器。简而言之，所有的迹象都表明计划的进度(仅此一次)步入正轨:2014年应该是HTTP 2.0年。

回到顶部

让网络更快

随着HTTP 2.0的广泛部署，我们可以放松下来并宣布胜利吗?网络会很快，对吧?与任何性能优化一样，一旦一个瓶颈被移除，下一个瓶颈就会被解锁。进一步优化的空间还很大:

• HTTP 2.0在应用层消除了HOL阻塞，但它仍然存在于传输(TCP)层。此外，既然所有流都可以在单个连接上复用，那么优化拥塞控制、缓解缓冲膨胀以及所有其他TCP优化就变得更加关键了。
• TLS是一个关键的且在很大程度上未得到优化的前沿:我们需要减少握手往返的次数，升级过时的客户端以获得更广泛的采用，并从总体上提高客户端和服务器的性能。
• HTTP 2.0为在客户端和服务器上实现头部压缩策略、优先级和流控制逻辑，以及使用服务器推送提供了新的研究机会。
• 所有现有的Web应用程序将继续在HTTP 2.0上工作——服务器将必须升级，但否则传输开关是透明的。但是，这并不是说不能通过利用服务器推送、优先级调整等新功能来调整现有和新的应用程序，使其性能优于HTTP 2.0。Web开发人员将不得不开发新的最佳实践，并恢复和取消他们今天正在使用的大量HTTP 1.1工作区。

简而言之，还有很多工作要做。HTTP 2.0是一个重要的里程碑，它将帮助使Web更快，但它不是旅程的终点。

相关文章
在queue.acm.org

提高互联网上的性能
汤姆•雷顿
http://queue.acm.org/detail.cfm?id=1466449

高性能的网站
Steve Souders
http://queue.acm.org/detail.cfm?id=1466450

你的网站有多快?
帕特里克Meenan
http://queue.acm.org/detail.cfm?id=2446236

回到顶部

回到顶部

回到顶部

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2013 ACM有限公司

---

没有发现记录