PDF使用 HTTP 2.0 加速 Web
HTTP 持续演进
Ilya Grigorik
HTTP（超文本传输协议）是互联网上应用最广泛的应用协议之一。自发布以来，RFC 2616（HTTP 1.1）已成为互联网空前增长的基础：数十亿各种形状和尺寸的设备，从台式电脑到我们口袋里的小型 Web 设备，每天都在使用 HTTP 传递新闻、视频以及我们日常生活中依赖的数百万其他 Web 应用程序。
最初只是一个用于检索超文本的简单单行协议（即，"GET /resource"—Telnet 到 google.com 的 80 端口，体验 HTTP 1.0）迅速发展成为通用的超媒体传输协议。十年后的今天，它被用于支持几乎所有可以想象的用例。
然而，在其自身成功的重压下，随着越来越多的日常互动持续迁移到 Web 上——社交、电子邮件、新闻和视频，以及越来越多地，我们的个人和工作空间——HTTP 已开始显现出压力的迹象。用户和开发人员现在都要求 HTTP 1.1 具有接近实时的响应速度和协议性能，而 HTTP 1.1 在不做一些修改的情况下根本无法提供这些。
为了应对这些新挑战，HTTP 必须继续演进，这就是 HTTP 2.0 出现的原因。HTTP 2.0 将通过在单个连接上实现高效的多路复用和低延迟交付，并允许 Web 开发人员撤销当今用于规避 HTTP 1.1 限制的许多应用程序“hack”，从而使应用程序更快、更简单、更健壮。
现代 Web 应用程序的性能挑战
自从 HTTP 1.1 RFC 发布以来的十年中，发生了很大变化：浏览器加速发展，用户连接状况发生了变化，移动 Web 正处于转折点，Web 应用程序的范围、雄心和复杂性都在增长。其中一些因素有助于提高性能，而另一些则会阻碍性能。总的来说，Web 性能仍然是一个巨大且尚未解决的问题。
首先，好消息是：现代浏览器在性能方面投入了大量精力。JavaScript 执行速度持续稳步提升（例如，Chrome 浏览器在 2008 年的发布带来了 20 倍的改进，仅在 2012 年，移动设备上的性能就进一步提高了 50% 以上11）。改进不仅发生在 JavaScript 方面；现代浏览器还利用 GPU 加速进行绘图和动画（例如，CSS3 动画和 WebGL），提供对本地设备 API 的直接访问，并利用众多推测性优化技术5 来帮助隐藏和减少各种网络延迟来源。
同样，宽带普及率（表 1）在过去十年中持续稳步攀升。根据 Akamai 的数据，虽然全球平均速度现在为 3.1 Mbps，但许多用户可以访问更高的吞吐量，尤其是在住宅光纤解决方案推出后。1 然而，带宽只是等式的一半。延迟是经常被遗忘的因素，不幸的是，现在它通常是浏览 Web 时的限制因素。4
实际上，一旦用户的带宽超过 5 Mbps，进一步的改进对平均 Web 应用程序的加载速度的提升非常小：从 Web 流式传输高清视频受带宽限制；加载托管高清视频的页面及其所有资源受延迟限制。
现代 Web 应用程序与十年前相比发生了显着变化。根据 HTTP Archive6 的数据，一个平均 Web 应用程序现在由 90 多个资源组成，这些资源从 15 多个不同的主机获取，总共传输了超过 1,300 KB（压缩后）的数据。因此，大部分 HTTP 数据流由数十个不同 TCP 连接上的小型（小于 15 KB）、突发数据传输组成。问题就出在这里。TCP 针对长连接和批量数据传输进行了优化。网络 RTT（往返时间）是新 TCP 连接吞吐量的限制因素（TCP 拥塞控制的结果），因此，延迟也是大多数 Web 应用程序的性能瓶颈。
如何解决这种不匹配？首先，您可以尝试通过将服务器和比特放置得更靠近用户，以及使用更低延迟的链路来减少往返延迟。不幸的是，虽然这些是必要的优化——现在整个 CDN（内容交付网络）行业都专注于解决这个问题——但它们并不足够。例如，谷歌采用了所有这些技术，但 2012 年全球到 google.com 的平均 RTT 约为 100 毫秒，不幸的是，这个数字在过去几年中没有改变。
许多现有链路已经处于光速限制（1.2~1.5 倍）的小常数因子内，虽然仍有改进空间，尤其是在“最后一英里延迟”方面，但相对收益不大。更糟糕的是，随着移动网络的兴起，延迟瓶颈的影响变得更加严重。虽然最新的 4G 移动网络专门针对低延迟数据传输，但广告宣传和实际性能通常仍以数百毫秒的开销来衡量（有关 AT&T 核心无线电网络的广告延迟，请参见表 22,3）。
如果您无法通过改进底层链路获得所需的性能阶跃函数——如果有什么变化，随着移动流量的增加，情况反而变得更糟——那么您必须将注意力转向如何构建应用程序以及调整负责交付应用程序的底层传输协议的性能。
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 工作组7,8 的 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 技术的整个堆栈中引入了连锁反应的众多性能优势，允许开发人员执行以下操作
• 并行交错多个请求，而不会阻塞任何一个。
• 并行交错多个响应，而不会阻塞任何一个。
• 使用单个连接并行传递多个请求和响应。
• 通过消除不必要的延迟来减少页面加载时间。
• 从应用程序代码中删除不必要的 HTTP 1.x 变通方法。
• 以及更多...
二进制帧
HTTP 2.0 使用二进制、长度前缀的帧层，与换行符分隔的纯文本 HTTP 1.x 协议相比，它提供了更紧凑的表示形式，并且更易于处理且效率更高。所有 HTTP 2.0 帧共享一个通用的八字节标头（图 4），其中包含帧的长度、其类型、用于标志的位字段和 31 位流标识符。
• 16 位长度前缀表明单个帧可以携带 216-1 字节的数据 - ~64 KB，不包括八字节标头大小。
• 八位类型字段确定帧的其余部分如何解释。
• 八位标志字段允许不同的帧类型定义特定于帧的消息标志。
• 一位保留字段始终设置为 0。
• 31 位流标识符唯一标识 HTTP 2.0 流。
了解了共享的 HTTP 2.0 帧头后，您可以编写一个简单的解析器，它可以检查任何 HTTP 2.0 字节流，识别不同的帧类型，并通过检查每个帧的前八个字节来报告它们的标志和长度。此外，由于每个帧都以长度为前缀，因此解析器可以快速有效地跳到下一个帧的开头。这是对 HTTP 1.x 的重大性能改进。
一旦帧类型已知，解析器就可以解释帧的其余部分。HTTP 2.0 标准定义了表 3 中列出的类型。
对帧分类的完整分析超出了本文讨论的范围——毕竟，这就是规范7 的用途（并且它做得很好！）。话虽如此，让我们更进一步，看看两个最常见的工作流程：启动新流和交换应用程序数据。
启动新的 HTTP 2.0 流
在发送任何应用程序数据之前，必须创建新流，并且必须发送适当的元数据（例如 HTTP 标头）。这就是 HEADERS 帧（图 5）的用途。
请注意，除了通用标头外，还添加了一个可选的 31 位流优先级。因此，每当客户端启动新流时，它都可以向服务器发出该请求的相对优先级的信号，甚至可以通过发送另一个 PRIORITY 帧稍后重新确定其优先级。
客户端和服务器如何协商唯一的流 ID？它们不协商。客户端发起的流具有偶数流 ID，服务器发起的流具有奇数流 ID。此偏移消除了客户端和服务器之间流 ID 的冲突。
最后，HTTP 标头键值对通过自定义标头压缩算法（稍后会详细介绍）进行编码，以最大限度地减少有效负载的大小，并将它们附加到帧的末尾。
请注意，HEADERS 帧仅用于传达有关每个流的元数据。实际的应用程序有效负载在随后的 DATA 帧（图 6）中独立传递（即，“数据”和“控制”消息之间存在分离）。
DATA 帧很简单：它是通用的八字节标头，后跟实际的有效负载。为了减少 HOL 阻塞，HTTP 2.0 标准要求每个 DATA 帧不超过 214-1 (16,383) 字节，这意味着较大的消息必须分解为较小的块。序列中的最后一条消息设置 END_STREAM 标志以标记数据传输的结束。
还有一些实现细节，但这些信息足以构建一个非常基本的 HTTP 2.0 解析器——非常基本是重点。流优先级、服务器推送、标头压缩和流控制（尚未提及）等功能值得进一步讨论，因为它们对于充分发挥 HTTP 2.0 的性能至关重要。
流优先级
一旦 HTTP 消息可以拆分为许多单独的帧，就可以优化帧在连接内交错和传递的确切顺序，以进一步提高应用程序的性能。因此，可选的 31 位优先级值：0 表示最高优先级流；231-1 表示最低优先级流。
在浏览器中呈现页面时，并非所有资源都具有相同的优先级：HTML 文档当然至关重要，因为它包含结构和对其他资源的引用；CSS 是创建可视化呈现树所必需的（在您拥有样式表规则之前，您无法绘制像素）；JavaScript 也越来越需要引导页面；其余资源（例如图像）可以以较低的优先级获取。
好消息是，所有现代浏览器都已经执行了这种内部优化，通过根据资产类型、它们在页面上的位置，甚至从之前的访问中学习到的优先级4 来优先处理不同的资源请求（例如，如果之前的访问中渲染被某个资产阻塞，则在将来可能会为同一资产赋予更高的优先级）。
随着 HTTP 2.0 中显式流优先级的引入，浏览器可以将这些推断出的优先级传达给服务器以提高性能：服务器可以通过控制资源（CPU、内存、带宽）的分配来优先处理流；一旦响应数据可用，服务器就可以优先将高优先级帧传递给客户端。更好的是，客户端现在可以在发现所有请求后立即调度它们（即，消除客户端请求排队延迟），而不是依赖于启发式请求优先级排序，鉴于 HTTP 1.x 提供的有限的并行性。
服务器推送
HTTP 2.0 的一个强大的新功能是服务器能够为单个客户端请求发送多个回复——也就是说，除了对原始请求的响应之外，服务器还可以将额外的资源推送到客户端，而无需客户端显式请求每个资源。
为什么需要这样的机制？一个典型的 Web 应用程序由数十个资源组成，客户端通过检查服务器提供的文档来发现所有这些资源。因此，为什么不消除额外的延迟，让服务器提前将相关资源推送到客户端？服务器已经知道客户端将需要哪些资源——这就是服务器推送。
实际上，虽然作为 HTTP 协议功能的服务器推送支持是新的，但许多 Web 应用程序已经在使用它，只是名称不同：内联。每当开发人员内联资产——CSS、JavaScript 或通过数据 URI 的任何其他资产——时，实际上，他们都在将该资源推送到客户端，而不是等待客户端请求它。HTTP 2.0 的唯一区别在于，此工作流程现在可以从应用程序移出并移入 HTTP 协议本身，这提供了重要的好处：推送的资源可以由客户端缓存、由客户端拒绝、在不同页面之间重用以及由服务器确定优先级。
实际上，服务器推送使 HTTP 1.x 中使用内联的大多数情况都过时了。
标头压缩
每个 HTTP 传输都携带一组标头，这些标头用于描述传输的资源。在 HTTP 1.x 中，此元数据始终以纯文本形式发送，并且通常每个请求增加 500 到 800 字节的开销，如果需要 HTTP Cookie，则通常会更多。为了减少这种开销并提高性能，HTTP 2.0 压缩标头元数据9
• HTTP 2.0 不会在每个请求和响应上重新传输相同的数据，而是在客户端和服务器上使用标头表来跟踪和存储先前发送的标头键值对。
• 标头表在整个 HTTP 2.0 连接期间持续存在，并由客户端和服务器逐步更新。
• 每个新的标头键值对要么附加到现有表中，要么替换表中的先前值。
因此，HTTP 2.0 连接的两端都知道已发送哪些标头及其先前的值，这允许将一组新的标头编码为与先前集合的简单差异（图 7）。
在连接的整个生命周期内很少更改的常见键值对（例如，user-agent、accept 标头等）只需要传输一次。实际上，如果请求之间没有标头更改（例如，对同一资源的轮询请求），则标头编码开销为零字节——所有标头都自动从上一个请求继承。
流控制
在同一 TCP 连接上多路复用多个流会引入对共享带宽资源的争用。流优先级可以帮助确定传递的相对顺序，但仅靠优先级不足以控制多个流之间如何分配资源。为了解决这个问题，HTTP 2.0 提供了一种简单的流和连接流控制机制
• 流控制是逐跳的，而不是端到端的。
• 流控制基于窗口更新帧：接收方通告它准备在流和整个连接上接收多少字节的 DATA 帧有效负载。
• 流控制窗口大小通过 WINDOW_UPDATE 帧更新，该帧指定流 ID 和窗口增量值。
• 流控制是定向的——接收方可以选择为每个流和整个连接设置任何它想要的窗口大小。
• 流控制可以由接收方禁用。
正如 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 2.0 的客户端必须能够在启动新的 HTTP 会话时发现服务器以及任何和所有中介是否支持 HTTP 2.0 协议。需要考虑两种情况
• 通过 TLS 启动新的（安全）HTTPS 连接。
• 启动新的（未加密）HTTP 连接。
在安全 HTTPS 连接的情况下，TLS 协议的新 ALPN（应用层协议协商10）扩展允许用户将 HTTP 2.0 支持协商为常规 TLS 握手的一部分：客户端发送它支持的协议列表（例如，http/2.0）；服务器选择一个广告协议，并通过在常规 TLS 握手中将协议名称发送回客户端来确认其选择。
通过常规的未加密通道建立 HTTP 2.0 连接需要更多的工作。由于 HTTP 1.0 和 HTTP 2.0 都运行在同一端口（80）上，因此，在没有任何关于服务器对 HTTP 2.0 支持的其他信息的情况下，客户端将不得不使用 HTTP 升级机制来协商适当的协议，如图 8 所示。
使用升级流程，如果服务器不支持 HTTP 2.0，则它可以立即使用 HTTP 1.1 响应来响应请求。或者，它可以返回 HTTP 1.1 格式的“101 Switching Protocols”响应来确认 HTTP 2.0 升级，然后立即切换到 HTTP 2.0 并使用新的二进制帧协议返回响应。在任何一种情况下，都不会产生额外的往返行程。
展望未来
开发一个作为所有 Web 通信基础的协议的主要修订版是一项重要的任务，需要大量的仔细思考、实验和协调。因此，展望 HTTP 2.0 的时间表是一项危险的业务——它会在准备就绪时就绪。话虽如此，HTTP 工作组正在取得快速进展。其过去和预计的里程碑如下
• 2009 年 11 月—Google 宣布 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（互联网工程指导组）。
SPDY 是 Google 开发并在 2009 年年中发布的实验性协议，后来成为早期 HTTP 2.0 草案的基础。经过多次修订和改进后，截至 2013 年底，现在有了该协议的实现草案，互操作性工作正在全面展开——最近的互操作性活动以来自 Microsoft Open Technologies、Mozilla、Google、Akamai 和其他贡献者的客户端和服务器实现为特色。简而言之，所有迹象都表明预计的计划（这一次）步入正轨：2014 年应该是 HTTP 2.0 的一年。
让 Web (更) 快
随着 HTTP 2.0 的广泛部署，我们可以放松并宣布胜利吗？Web 会很快，对吗？嗯，与任何性能优化一样，一旦消除一个瓶颈，下一个瓶颈就会被解锁。还有很大的优化空间
• 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 更快，但这并不是旅程的终点。
参考文献
1. Akamai. 2013. State of the Internet; http://www.akamai.com/stateoftheinternet/.
2. AT&T. 2013. Average speeds for AT&T LaptopConnect Devices; http://www.att.com/esupport/article.jsp?sid=64785&cv=820&_requestid=733221#fbid=vttq9CyA2iG.
3. AT&T. 2012. Best Practices for 3G and 4G App Development; http://developer.att.com/home/develop/referencesandtutorials/whitepapers/BestPracticesFor3Gand4GAppDevelopment.pdf.
4. Belshe, M. 2010. More bandwidth doesn't matter (much); https://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2.
5. Grigorik, I. 2013. High-performance networking in Google Chrome; http://www.igvita.com/posa/high-performance-networking-in-google-chrome/.
6. HTTP Archive; http://www.httparchive.org/.
7. IETF HTTPbis Working Group. 2012. Charter; http://datatracker.ietf.org/doc/charter-ietf-httpbis/.
8. IETF HTTPbis Working Group. 2013. HTTP 2.0 specifications; http://tools.ietf.org/html/draft-ietf-httpbis-http2.
9. IETF HTTPbis Working Group. 2013. HPACK-Header Compression for HTTP/2.0; http://tools.ietf.org/html/draft-ietf-httpbis-header-compression.
10. IETF Network Working Group. 2013. Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension; http://tools.ietf.org/html/draft-friedl-tls-applayerprotoneg.
11. Upson, L. 2013. Google I/O 2013 keynote address; http://www.youtube.com/watch?v=9pmPa_KxsAM.
喜欢它，讨厌它？请告诉我们
Ilya Grigorik 是 Google 的网络性能工程师和开发者布道师，他在 Google 工作，致力于通过构建和推动在 Google 及其他地方采用性能最佳实践来加速 Web 的发展。
© 2013 1542-7730/13/1000 $10.00
最初发表于 Queue vol. 11, no. 10—
在 数字图书馆 中评论这篇文章
更多相关文章
Shylaja Nukala, Vivek Rau - 为什么 SRE 文档很重要
SRE（站点可靠性工程）是一种职位职能、一种思维模式以及一套工程方法，用于使 Web 产品和服务可靠地运行。SRE 在软件开发和系统工程的交叉点运作，以解决运营问题并设计解决方案，从而可扩展、可靠且高效地设计、构建和运行大规模分布式系统。成熟的 SRE 团队可能拥有与许多 SRE 职能相关的完善的文档体系。
Taylor Savage - 组件化 Web
在当今的软件工程中，没有哪项任务比 Web 开发更艰巨。一个典型的 Web 应用程序规范可能如下所示：该应用程序必须跨各种浏览器工作。它必须以 60 fps 的速度运行动画。它必须立即响应触摸。它必须符合一套特定的设计原则和规范。它必须在几乎所有可以想象到的屏幕尺寸上工作，从电视和 30 英寸显示器到手机和手表表面。它必须在长期内得到良好的工程设计和可维护性。
Arie van Deursen - 超越页面对象：使用状态对象测试 Web 应用程序
Web 应用程序的端到端测试通常涉及通过诸如 Selenium WebDriver 之类的框架与 Web 页面进行复杂的交互。隐藏此类 Web 页面复杂性的推荐方法是使用页面对象，但首先需要回答一些问题：在测试 Web 应用程序时，应该创建哪些页面对象？应该在页面对象中包含哪些操作？给定页面对象，应该指定哪些测试场景？
Rich Harris - 消除准入壁垒
一场战争正在 Web 开发领域展开。一方是工具制造者和工具用户的先锋，他们以摧毁糟糕的旧观念（在这个环境中，“旧”意味着任何一个月前在 Hacker News 上首次亮相的东西）和关于转译器等的热烈辩论而蓬勃发展。
© 保留所有权利。