期待已久的 Hypertext Transfer Protocol Version 2 (HTTP/2) 终于在 2015 年 2 月 28 日定稿啰，也有 RFC 标准文件(RFC7540)了。
HTTP 2.0 的出现，相比于 HTTP 1.x ，大幅度的提升了 web 性能。在与 HTTP/1.1 完全语义兼容的基础上，进一步减少了网络延迟。而对于前端开发人员来说，无疑减少了在前端方面的优化工作。本文将对 HTTP 2.0 协议 个基本技术点进行总结，联系相关知识，探索 HTTP 2.0 是如何提高性能的。这几天手机不断被联通劫持，用知乎日报都会被插入联通的垃圾广告，更别说在微信中访问第三方网站了。于是关注了一下防止网站被运营商劫持的技术，这里推荐Fenng之前发的文章，在流氓无下限的运营商的手段下面，我们能做的其实并不多。而HTTPS和SPDY其实是更好的技术，不仅能保证不被运营商劫持，更能保护用户的数据安全。
到底 HTTP/2 与原本的 1.1 有什么不同呢？我们来简单导览一下。
API 不用修改
HTTP/2 的多数 headers 与 1.1 是一样的，这表示 HTTP/2 可以完美的向下相容 1.1，程式无需做太大修改。也因此目前多数主流浏览器皆已支援 HTTP/2 协议。
建立在 SPDY 的基础上
几年前 Google 曾发布了令大家眼睛为之一亮的 SPDY 协议，标榜能加速 Web 的载入速度，并让网站上的多重档案可以并发下载。 SPDY因为具备优异的网页传输及处理效能，因此后来从众多HTTP/2提案版本中脱颖而出，最终成为HTTP/2标准草案的原型。其竞争对手包含微软的 HTTP Speed+Mobility 等等协议。
HTTP/2的许多关键功能也都来自于SPDY，最大的改变就是加入一个多工（Multiplexing）的功能，可以允许浏览器在同时间内对多个伺服器发送请求，并采用更高效率的标头压缩技术，整体而言，HTTP/2让用户端能以较少的连接数从伺服器端取得资料，大幅增加网路传输速度。
伺服器推送
HTTP/2 的一项新特色是加上了伺服器推送功能，伺服器可以主动推送内容到浏览器上。这增加了许多特别的新应用，例如可以在浏览器尚未发出请求前，预先推送 CSS 或页面 Layout 到浏览器上，增加之后的页面载入速度。
标头压缩与编码
HEAD 在传输的时候，有蛮多重复或冗余的资讯，这些资讯可藉由 Haffman 演算法压缩 HEAD 来增加传输速度。
流程下载控制与优先级
藉由控制下载流程的优先级，可以让 HTTP/2 的传输过程中，将最重要的内容优先下载，避免大量资讯堵在一起。
不强制采用加密传输
相较于 SPDY 强制要采用 https 协议，HTTP/2 并未强制传输要加密，不过在 HTTP/2 协议下，将更容易实现 TLS 传输加密。
如何使用 HTTP/2
基本上，主流浏览器大多已经支援。不过您可以在自己的伺服器上加装 HTTP/2 模组来支援一些新的 HTTP/2 特性，例如 NodeJS 就有 node-http2 模组可以安装，详细的支援清单请看 HTTP/2 Implemention。
1.什么是HTTP/2
HTTP/2（超文本传输协议第2版，最初命名为HTTP 2.0），是HTTP协议的的第二个主要版本，使用于万维网。HTTP/2是HTTP协议自1999年HTTP 1.1发布后的首个更新，主要基于SPDY协议。
2.与HTTP/1相比，主要区别包括
- HTTP/2采用二进制格式而非文本格式
- HTTP/2是完全多路复用的，而非有序并阻塞的——只需一个连接即可实现并行
- 使用报头压缩，HTTP/2降低了开销
- HTTP/2让服务器可以将响应主动“推送”到客户端缓存中
3.HTTP/2为什么是二进制？
比起像HTTP/1.x这样的文本协议，二进制协议解析起来更高效、“线上”更紧凑，更重要的是错误更少。
4.为什么 HTTP/2 需要多路传输?
HTTP/1.x 有个问题叫线端阻塞(head-of-line blocking), 它是指一个连接(connection)一次只提交一个请求的效率比较高, 多了就会变慢。 HTTP/1.1 试过用流水线(pipelining)来解决这个问题, 但是效果并不理想(数据量较大或者速度较慢的响应, 会阻碍排在他后面的请求). 此外, 由于网络媒介(intermediary )和服务器不能很好的支持流水线, 导致部署起来困难重重。
而多路传输(Multiplexing)能很好的解决这些问题, 因为它能同时处理多个消息的请求和响应; 甚至可以在传输过程中将一个消息跟另外一个掺杂在一起。
所以客户端只需要一个连接就能加载一个页面。
5.消息头为什么需要压缩?
假定一个页面有80个资源需要加载（这个数量对于今天的Web而言还是挺保守的）, 而每一次请求都有1400字节的消息头（着同样也并不少见，因为Cookie和引用等东西的存在）, 至少要7到8个来回去“在线”获得这些消息头。这还不包括响应时间——那只是从客户端那里获取到它们所花的时间而已。
这全都由于TCP的慢启动机制，它会基于对已知有多少个包，来确定还要来回去获取哪些包 – 这很明显的限制了最初的几个来回可以发送的数据包的数量。
相比之下，即使是头部轻微的压缩也可以是让那些请求只需一个来回就能搞定——有时候甚至一个包就可以了。
这种开销是可以被节省下来的，特别是当你考虑移动客户端应用的时候，即使是良好条件下，一般也会看到几百毫秒的来回延迟。
6.服务器推送的好处是什么？
当浏览器请求一个网页时，服务器将会发回HTML，在服务器开始发送JavaScript、图片和CSS前，服务器需要等待浏览器解析HTML和发送所有内嵌资源的请求。
服务器推送服务通过“推送”那些它认为客户端将会需要的内容到客户端的缓存中，以此来避免往返的延迟。
整个性能测试包含4个场景，使用的软件为Firefox和HttpWatch，测试网页为Google UK首页，比较的协议包括原生HTTPS、SPDY/3.1和HTTP/2协议，同时每一个测试都是在没有浏览器缓存的Firefox实例上执行的，虽然这些测试非常简单，页面也不复杂，但是这并不影响三种不同协议之间重大差异的比较。
测试#1——请求和响应头的大小
虽然大部分网站都已经在下载文本内容的时候使用压缩提升性能，但是HTTP/1.1并不支持HTTP头压缩，为此SPDY和HTTP/2应运而生， SPDY使用了通用的DEFLATE算法，而HTTP/2则使用了专门为压缩头信息而设计的HPACK算法。
第一个测试通过一个没有内容的请求生成的头信息的大小来查看三种协议的不同：
其中，“Sent”列表示请求头的大小，“Received”列表示响应头的大小，结果显示，使用HPACK算法的HTTP/2协议头信息最小。
测试#2——响应消息的大小
Web服务器的响应由响应头和编码的响应内容两部分组成。对于图片的请求，测试结果如下：
对于文本资源的请求，结果如下：
结果显示，对于图片HTTP/2协议的请求和响应信息都最小，而对于文本资源，虽然HTTP/2的请求信息依然最小，但是响应信息却比SPDY协议稍大一点。究其原因，这可能是由添加到HTTP/2数据帧中的可选内边距字节造成的，而图片资源并不会使用内边距。
测试#3——TCP连接数和页面加载时的SSL握手请求数
HTTP/1.1通过增加到每个主机的最大连接数来提高性能，而SPDY和HTTP/2则是通过使用多路复用技术在一个单独的TCP和SSL连接上支持并发，通过在一个连接上一次性发送多个请求来发送或接收数据。该场景的测试结果如下：
SPDY结果
HTTP/2结果
HTTPS结果
结果显示，SPDY和HTTP/2通过多路复用技术降低了页面下载时的连接数，而原生的HTTPS协议则需要创建更多的连接。
测试#4——页面加载时间
页面加载时间是一个比较重要的性能指标，该测试使用了HttpWatch中的“页面加载”事件来查看每种协议所需的时间，结果如下：
结果显示，由于不支持头信息压缩，并且缺少所需的额外TCP连接和SSL握手，原生HTTPS所需的时间最长，如果页面更复杂，那么差距会更明显。同时，虽然HTTP/2的响应消息比SPDY大，但是加载时间要比SPDY短。
结语
对大多数的使用者来说，HTTP/2 的影响力不是那么的大，因为浏览器很快就支援了，也不会有任何浏览网站上的影响。但对于工程师而言，就有很多眉眉角角要注意。例如前端过去常常依靠 CSS sprites 与 Assets 合并来优化页面载入速度，也许未来的影响就没有那么大。后端则要考虑是否压缩 HEAD 或采用 TLS 等等。整体而言，对网路世界依旧是好事，毕竟从 1.1 版推出以来已经 16 年没有更新了，是时候迈向新时代的网路协议了。
05/28/2016