【上】
一.前言
HTTP/2 于 2015 年 5 月正式推出。自诞生以来，它就一直在影响着网络性能最佳实践。在本篇文章中，我们将讨论 HTTP/2 的二进制帧、延迟削减、潜在利弊以及相应的应对措施。
超文本传输协议（简称 HTTP）正是万维网与网络空间的基石。现在，HTTP 听起来已经有些过时，毕竟该协议中使用最广泛的版本——HTTP 1.1，已快迎来它的第二十个年头。时光回溯到1997年，HTTP1.1刚刚出现的年代，当时，软驱与调制解调器还是 PC 设备的必备周边产品，Java 也仅仅是一个刚刚崭露头角的、前途一片光明的编程语言。
而今，2015 年 5 月，HTTP/2 正式亮相，致力于解决 HTTP 1.1 在现代网络时代下无法应对的某些重大性能难题。过去一年以来，越来越多的浏览器、Web 服务器、商用代理以及主要内容交付网络开始支持 HTTP/2。
遗憾的是，对于负责编写 Web 代码的开发人员而言，HTTP/2 的过渡工作并不简单，所谓的速度提升也不会自行出现，必要的 Web APM 工具和厂商仍然是当今时代不可或缺的，例如 OneAPM Browser Insight、Newrelic、APPdynamic 等等。
如何才能采用这个新协议打造高性能 Web 应用，该怎样处理那些尚不支持该协议的现有工具——例如 debug 代理工具，这些问题对所有人来说仍是一个挑战。今天的文章将向您介绍 HTTP/2，以及其如何改变 Web 性能的最佳实践。
二.二进制帧：HTTP/2的「基本单位」
HTTP 1.1 的一大优势（至少相较于非安全连接而言）在于其支持在端口 80 的telnet 会话中利用文本与 Web 服务器进行交互：在大多数 Web 服务器上输入 GET/HTTP/1.1，都能返回一个 HTML 文档。由于这是一项文本协议，因此其调试工作相对简单。
相对于 HTTP1.1 这个文本协议，HTTP/2 中的请求与响应则通过二进制帧流的形式来表现，我们将其称为 HTTP/2 RFC 中的「基本协议单位」。每一帧都拥有自己的类型，用于实现不同的作用。考虑到 HTTP 1.1 将会「永远」存在（毕竟 Gopher 协议都还在用呢！），因此 HTTP/2 的作者们要求，HTTP/2 请求的二进制帧都必须被映射到 HTTP 1.1 请求上去，从而确保其向下兼容的能力。
当然，HTTP/2 当中也有一些其他新特性，无法映射至 HTTP 1.1。例如，服务器推送（也叫“缓存推送”）和流重置都是利用二进制帧类型实现的新特性。帧也可以支持优先级排序，允许客户端向服务器发送排序，从而优先处理一部分资产类别。
除了使用 Wireshark 2.0 之外，对个别二进制帧进行查看的最简便方法就是利用谷歌 Chrome 浏览器的 net-internals 标签（在浏览器地址栏中输入chrome://net-internals/#http2）。由于理解大型网页的数据通常比较困难，Rebecca Murphey 特意编写了一款极为实用的可视化工具，从而将其显示在命令行中。
除此之外，这个用于获取资产的协议还可以显示在 Chrome Web 的开发者工具当中–只需右键点击列标题，接着选择「协议」即可：
在谷歌Chrome开发者工具中查看协议类型。
这里列出的所有 HTTP/2 请求都使用通过传输层安全（TLS）建立的安全连接。各主流浏览器都要求 HTTP/2 连接是安全的。这样做是有切实理由的：TLS 的一套称为应用层协议协商（ALPN）的扩展，让服务器知道浏览器支持 HTTP2（除了其他协议以外），从而避免了额外的数据往来。这也能保住那些无法解读 HTTP/2 的服务，例如代理——只看得见传输线路上的加密数据。
三.多路复用减少延迟
HTTP 1.1 的一大问题是延迟，换而言之就是它花在提出请求和接受响应上的时间。随着典型网页中图片数量、JavaScript 和 CSS 的使用量不断增加，这个问题日益严重。每获取一项资产，通常都得新建一个 TCP 连接。
这种需求因为两个理由很重要：每台主机能同时打开的 TCP 连接数受浏览器的限制；新建连接都会引发性能损失。如果物理服务器离用户很远（如：一位新加坡用户向美国东海岸数据中心请求一个页面），延迟会变多。这不是罕见的情况——近期一份报告表示全球 70% 以上的互联网流通都会通过北佛吉尼亚一些不知名的数据中心。
其实对于 Web 页面的优化从前端页面方面反而可能见效比较大，我们都知道页面资源对响应速度的影响是非常巨大的，常见的图片压缩、css 聚合都可以帮助我们优化 Web 性能，问题就是如何找到相应的页面慢加载元素。
这也是国内外 APM 行业兴起的最初原因之一。
拿国内的一个页面优化工具 Browser Insight 举例，这种通过页面插码来获取真实用户体验的 APM 工具，虽然部署起来有些麻烦，但是这类的工具也没有更好的部署方法，手动的反而更稳定。
HTTP 1.1 提供了多种方案以解决延迟问题，包括通道传输与 Keep-Alive header。然而，通道传输从未被广泛采纳过，而 Keep-Alive header 则饱受 head line 阻塞的困扰：只有在当前请求必须彻底完成后，下一请求才能被发送出去。
在 HTTP/2 当中，多条资产请求可以重复利用单一 TCP 连接。与使用 Keep-Alive header 的 HTTP 1.1 请求不同，HTTP/2 的请求与响应二进制帧以交错方式进行，线头阻塞问题也不复存在。建立连接的成本（即著名的的‘三方握手’）在每台主机上只进行一次。多路复用对于安全连接来说尤为重要，因为多次 TLS 协商方案的性能成本将会得到显著提高。
在 HTTP/2 中，单一主机内的多资产请求只使用单一 TCP 连接。
四.总结
其实 Web 性能优化已经不是一个新的话题了，从 21 世纪初期直到现在，很多成熟的互联网公司已经开始关注除了产品、研发之外的工作，例如用户体验、性能优化等与产品使用者息息相关的事情，伴随着的就是 APM 行业的全面兴起。
本文主要和大家聊了一些关于 http1 和 http2 有关的基础内容，之后还会有一篇，预计与大家分享一些 http2 使用利弊、以及正在进行的相关工作等等。
Browser Insight 是一个基于真实用户的 Web 前端性能监控平台，能够帮大家定位网站性能瓶颈，网站加速效果可视化；支持浏览器、微信、App 浏览 HTML 和 HTML5 页面。想阅读更多技术文章，请访问 OneAPM 官方技术博客。
本文转自 OneAPM 官方博客
【下】
一.前言
我们在 HTTP/2 对 Web 性能的影响（上）已经和大家分享了一些关于 Http2 的二项制帧、多用复路以及 APM 工具等，本文作为姊妹篇，主要从 http2 对 Web 性能的影响、http2 使用的利弊以及一些正在进行中的相关工作等方面与大家进行分享。
二.Web 性能影响：与内联、级联及图像精灵说再见？
HTTP/2 多路复用对前端 Web 开发人员造成了深远的影响。长久以来，人们用尽方法，试图通过捆绑相关资产来削减连接的数量，而现在这一切都不需要了。人们曾经尝试过的方法包括：
- JavaScript 与 CSS 文件级联：将多个小文件合成一个大文件，从而降低总体请求数量。
- 图像精灵：将多个小图像合成一张大图像。
- 域名分片：在多个域之间发送静态资产请求，从而增加浏览器所能允许的总体开放 TCP 连接数量。
- 内联资产：将资产同 HTML 文档源绑定，包括 base-64 编码图片，以及直接写入 script 标签的 JavaScript 代码。
因为不需要再绑定资产，我们就有了更多机会将 Web 应用程序中的小片段加以缓存。举个例子可以帮我们更好的理解这一点：
一个级联且指纹验证型 CSS 文件被解绑为四个较小的指纹验证文件。
常见的级联模式是将一个应用程序内不同页面的样式表文件进行绑定，形成单一的 CSS 文件，以减少资产请求的数量。这个大文件随后会通过文件名内的 MD5 哈希值进行指纹校验，确保其能够被浏览器主动缓存。遗憾的是，这样的解决方案意味着，当站点的可视化布局中出现了任何一点小的改变，如标题字体的改变，都需要重新下载整个级联文件。
当对小型资产文件进行指纹校验时，相当一部分的 JavaScript 与 CSS 组件都不会频繁产生变动，因此可以被浏览器缓存 –也就是说，任何一个单一功能的小型重构，不会再导致大量的 JavaScript 应用程序代码或者 CSS 失效。
最后，级联机制的消失能够降低前端构建基础的复杂性。与以往通过一系列预置步骤来级联资产不同，现在它们作为小型文件，可以直接被放入 HTML 文档中。
三.实际使用 HTTP/2 的潜在弊端
仅仅针对支持 HTTP/2 客户端而做出的各类优化，意味着那些不支持 HTTP/2 的浏览器可能因此陷入不利境地。那些“有年头”的浏览器们仍然倾向于绑定资产，以此降低连接数量。截至 2016 年 2 月，caniuse.com 网站报道称，全球浏览器中能够支持 HTTP/2 的占比 71%。与之前浏览器们决定放弃支持 IE 8.0 时一样，支持 HTTP/2 或采取某种混合作业的方式——这样的决定只能根据各个网站自身的相关数据来做出。
但是我们相信大规模支持肯定是不可避免的，就像一开始只有 Chrome 浏览器支持 window.performance 接口，方便一些 Web 工具进行数据的采集，像上面说过的Browser Insight ，我曾经和他们的技术支持聊过，就是靠这种方式来实时的采集用户对网站的访问信息等。之后，大势所趋，各个浏览器厂商都纷纷开放了相关接口
正如可汗学院的博文所述，他们曾分析其网站上的 HTTP/2 流量，事实上，拆分大量资产会增加所传输字节的总量。而使用zlib压缩单一大型文件，比压缩多个小型文件要更有效率。对于拥有成百上千解绑资产的 HTTP/2 站点来说，这种效应更为显著。
在浏览器中使用 HTTP/2 还要求我们通过 TLS 进行资产传递。对于菜鸟们来说，设置 TLS 证书就是个烦人的活儿。幸运的是，诸如 Let’s Encrypt 的开源项目正努力让证书注册工作变得更加便捷。
四.仍在进行中的工作
大部分用户并不在意你的站点用了啥协议——他们只想要它速度快，运行如人预期。虽然 HTTP/2 已经获得正式批准快一年了，开发人员还在学习如何利用它来建立更快速网站的最优实践。换用 HTTP/2 的好处更多取决于具体站点的架构情况以及使用现代浏览器的用户比率。再有就是，调试新协议很有挑战性，更易用的开发工具还在研制中。
虽然有这些挑战，HTTP/2 的采纳度仍在增加。根据研究人员扫描流行网站属性的结果，排名前列的站点中使用 HTTP/2 的一直在增加，特别是 CloudFlare 和WordPress 在 2015 年宣布提供支持之后。在考虑转换到新协议时，很重要的一点是利用 Browser insight 和 NewRelic 之类的 APM 工具，仔细测量资源和页面在不同环境下的加载时间。
如下图所示，可以看到每一次慢加载的详细情况，非常方便。
供应商和专业网站人员都熟悉这一转换背后的含义，从真实用户数据中做出判断才是关键的。在网站臃肿危机的当下，无论何种协议，都应该以削减资源数量为目标。
在此 HTTP/2 系列的第二部分中，我们会聚焦于如何在服务器上实现 HTTP/2 和调试真实网络通信的具体实现细节。
本文作者为 Clay Smith，由 OneAPM 产品运营进行翻译编辑
原文地址：https://dzone.com/articles/how-http2-is-changing-web-performance-best-practic
Browser Insight 是一个基于真实用户的 Web 前端性能监控平台，能够帮大家定位网站性能瓶颈，网站加速效果可视化；支持浏览器、微信、App 浏览 HTML 和 HTML5 页面。想阅读更多技术文章，请访问 OneAPM 官方技术博客。
本文转自 OneAPM 官方博客