去年年底，据国际互联网工程任务组（ IETF ）消息，HTTP－over－QUIC 实验性协议将被重命名为 HTTP／3，即有望成为 HTTP 协议的第三个正式版本，也就是说HTTP／3可能要来了。 该消息是如此的惹人注目，是因为HTTP是我们身边的协议，Web应用都离不开它。

温故知新，梳理一下过往，或许更能够理解未来。

HTTP1．x的过往

HTTP协议大约诞生在我上大一的时候，好像是HTTP0．9，客户端请求和服务器响应都是ascii码，客户端以回车符结尾，服务器返回HTML。后来的HTTP1．0，服务器响应增加了很多状态，请求和响应也多了很多的header，响应的内容也不再局限于纯文本了。

HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型，是一个无状态的协议。HTTP是建立在TCP之上的，每个请求都要经历三次握手和慢启动。客户端是依据域名来向服务器建立连接，一般PC端的浏览器支持同域6～8个连接，手机端的连接数则一般控制在4～6个。连接数不是越多越好，资源开销和整体延迟都会随之增大。

HTTP 1．1 导致了2000年的互联网热潮。HTTP1．1 支持只发送header信息（不带任何body信息），如果服务器认为客户端有权限请求服务器，则返回100，否则返回401。客户端如果接受到100，才开始把请求body发送到服务器。这样当服务器返回401的时候，客户端就可以不用发送请求body了，节约了带宽。

另外HTTP还支持传送内容的一部分。这样当客户端已经有一部分的资源后，只需要跟服务器请求另外的部分资源即可。RANGE：bytes是HTTP／1．1新增内容，HTTP／1．0每次传送文件都是从文件头开始，即0字节处开始。RANGE：bytes＝XXX表示要求服务器从文件XXX字节处开始传送，这大概就是平时所说的断点续传。

相关的部分协议标准如下：

协议编号 协议名称简要描述RFC7230 HTTP／1．1： Message Syntax and Routing底层消息解析和连接管理等RFC7231HTTP／1．1： Semantics and Content方法、状态码和header等RFC7232HTTP／1．1： Conditional Requests例如If－Modified－SinceRFC7233HTTP／1．1： Range Requests获取部分内容等RFC7234HTTP／1．1： Caching浏览器和中介缓存等RFC7235HTTP／1．1： AuthenticationHTTP 的一个authentication框架等

现如今，Web应用不再单纯是web 网页，还有支持多设备和多媒体。 一个SPA的应用可能有上百的连接，模块拆分导致了更多的请求，大部分时间都消耗在网络上。HTTP 1．x header 往往较大，且无法压缩。TCP协议利用过低，不可复用连接，连接数限制且协议过于庞大。

[page][/page]

HTTP1．x遇到的问题和解决方案

HTTP1．x主要存在连接无法复用和head of line blocking这两个问题。在第一个请求没有收到回复之前，后续从应用层发出的请求只能排队。网络通畅的时候性能影响不大，一旦第一个请求没有抵达服务器，或者response因为网络阻塞没有及时返回，就会影响所有后续请求。

HTTP1．0协议头里可以设置Connection：Keep－Alive。在header里设置Keep－Alive可以在一定时间内复用连接，具体复用时间的长短可以由服务器控制，一般在15秒左右，这与运营商蜂窝网络的linger time相关。HTTP1．1之后Connection的默认值就是Keep－Alive，如果要关闭连接复用需要显式的设置Connection：Close。这对PC端浏览器的体验帮助很大，因为大部分的请求在集中在一小段时间以内。但移动app的请求比较分散且时间跨度相对较大，一般会从应用层寻求其它解决方案，长连接方案或者伪长连接方案。

为了解决HTTP连接复用，可以采用长轮询，HTTP streaming和websocket等方式。

和传统的HTTP短链接相比，长连接轮询会在用户增长的时候极大的增加服务器压力。移动端网络环境复杂，像wifi和4g的网络切换等，这些场景都需要考虑重建连接。长轮询方式稳定性并不好，需要做好数据可靠性的保证，比如重发和ack机制。而且，response有可能会被中间代理cache住，要处理好业务数据的过期机制。

HTTP streaming是通过在server response的头部里增加＂Transfer Encoding： chunked＂来告诉客户端后续还会有新的数据。如果永远不会结束，客户端就会一直处于等待response的过程中。代理服务器会等待服务器的response结束之后才会将结果推送到请求客户端。对于streaming这种业务数据无法按照请求来做分割，所以客户端每收到一块数据都需要自己做协议解析。显然这个数据通道也是单向的，还有个缺陷就是不会产生重复的header数据。

websocket提供双向的数据通道，优势在于提供了message的概念，比基于字节流的tcp socket使用更简单，同时又提供了传统的HTTP所缺少的长连接功能。但代价相对较高，基于tcp的socket编程技术难度相对复杂很多，而且需要自己制定协议。

HTTP／2 要点

HTTP2．0是以SPDY为原型进行讨论和标准化的，采用二进制格式传输数据，而非 HTTP／1．x 的文本格式。请求和响应都统一为流，对消息头采用 HPACK 进行压缩传输，能够节省消息头占用的网络的流量。多路复用，就是所有的请求都是通过一个 TCP 连接并发完成，并支持Server Push和基于优先级的流量控制。

HTTP／2 中的帧

帧（frame）是HTTP2中最小的通信单位，每个帧都会有帧header，每个帧用来承载HTTP header 或负荷数据，或其他特定类型的帧。帧是遵循二进制编码的。帧格式如下：

length定义了整个帧的长度，type定义帧主要有10种的类型：

帧类型
codeDATA0x0HEADERS0x1PRIORITY0x2
RSTSTREAM0x3PUSHPROMISE0x4S
ETTINGS0x5PING0x6GOAWAY0x7WIN
DOW＿UPDATE0x8CONTINUATION0x9

flags用位定义了一些重要的参数，stream id用作流控制，而payload才是请求的正文。

虽然协议的格式和HTTP1．x完全不同了，但并没有改变HTTP1．x的语义，只是把原来HTTP1．x的header和body部分用frame重新封装了一层而已。调试的时候浏览器甚至会把HTTP2．0的frame自动还原成HTTP1．x的格式。HTTP2．0与HTTP1．0的对比如下：

[page][/page]

HTTP／2 中的header 压缩

HTTP1．x的header由于cookie和user agent很容易变得较大，而且每次都要重复发送。HTTP／2使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。高效的压缩算法可以很大的压缩header，减少发送包的数量从而降低延迟。

HTTP／2中的HPACK使用一份索引表来定义常用的 HTTP Header，保留原有的header list的顺序，通过索引键值压缩。 静态表中包含了一些预定义的header字段，动态表默认是空的，会在头部解压缩的时候确定是否添加entry。客户端和服务器端使用header表来跟踪和存储之前发送的每一个键值对。在tcp连接期间，二者共同维护和更新。对于无法用索引替代的字符，有的会采用哈夫曼编码压缩。

HTTP／2 中的多路复用

把HTTP 消息分解为独立的帧，交错发送，然后在另一端根据Stream ID 重新组装是HTTP 2．0 最重要的一项增强。每个 Frame Header 都有一个 Stream ID。每次请求／响应使用不同的 Stream ID。通过 Stream ID 标识，所有的请求和响应都可以同时跑在一个TCP 连接上了。 下图是 HTTP 和 spdy的并发模型对比：

和一般TCP连接释放一样，如果客户端没有数据要请求，或服务端数据发送完毕后，会主动发送关闭连接的报文。或者是服务端连续发送探测报文，客户端无响应，服务端就关闭了这个连接。

当流并发时，就会涉及到流的优先级和依赖。优先级高的流会被优先发送。每个HTTP／2流里面可以带有优先级（31位，0为优先级最高）的值，这个值确定着客户端和服务器处理不同的流采取不同的优先级策略，高优先级的流都应该优先发送。图片请求的优先级要低于CSS和SCRIPT脚本，这可以确保重要的东西可以被优先加载。，但又不会绝对的，绝对地遵守可能又会引入队列阻塞的问题：高优先级的请求慢导致阻塞其他资源交付。

从tcp连接和网络来看，优先级使得网络拥塞得到改善，慢启动时间减少，拥塞和丢包恢复速度变快。

HTTP／2 中的Push

Server Push 就是服务器向客户端推送资源而无需客户端明确地请求，或者服务器可以对一个客户端请求发送多个响应。

当服务端需要主动推送某个资源时，便会发送一个 Frame Type 为 PUSH＿PROMISE 的 帧，里面带了 PUSH 需要新建的 Stream ID。客户端解析 帧时，发现它是一个 PUSH＿PROMISE 类型，便会准备接收服务端要推送的流。

HTTP／2连接建立后，客户端与服务器交换SETTINGS 帧，以此来限定双向并发流的最大数量。因此，客户端可以限定推送流的数量，或者通过把这个值设置为0，完全禁用服务器推送，而且，所有推送的资源都遵守同源策略。服务器不能随便将第三方资源推送给客户端，而必须是经过双方确认才行。

所有服务器推送流都由PUSH＿PROMISE 发起，PUSH＿PROMISE 帧必须在返回响应之前发送，以免客户端出现竞态条件。客户端接收到PUSH＿PROMISE 帧之后，可以视自身需求选择拒绝这个流。

[page][/page]

基于HTTP／2的开发

HTTP／2 已经得到了较为广泛的支持，服务器的支持包括：

Apache HTTP Server 2．4．17＋

Apache Tomcat 8．5＋

NGINX 1．9．5＋

面向PHP的Swoole

面向Python 的Twisted

．．．

支持HTTP／2的客户端包括：

Chromium

Mozilla Firefox

curl and libcurl

OkHTTP （java ，Android）

面向Obj－C／swift 的 WKWebView

．．．

客户端与服务器同时支持HTTP／2的包括：

Jetty／Netty

lua－HTTP

Node．js 8．4．0＋

面向perl 的 Protocol：：HTTP2

面向Go 的HTTP2

．．．

支持HTTP／2的代理中介包括：

HAProxy

ngHTTP2

GFE

．．．

详情可以参考HTTPs：／／github．com／HTTP2／HTTP2－spec／wiki／Implementations。

调试工具可以使用chrome的浏览器以及Wireshark等等。

在开发中使用了HTTP／2 并不是万事大吉了，在HTTP1．X 中的一些优化还需要继续使用，例如减少DNS查询和重定向，CDN的使用，对代码、图片等资源的压缩，对文本开启GZip，以及使用HTTP的缓存机制（Expires／Cache－Control和Last－Modified ／ ETag）等等。对于那些可以感知缓存的资源内联或者Push 消息，可以利用cookie 协助用户标记。

由于HTTP／2基于单个TCP连接，容易受到 Head of Line Blocking 的影响，从而导致传输速度受限，还会受到TCP丢包的影响，所以HTTP／2在资源数量较少的网站可能效果不明显。TCP协议的升级依赖于操作系统内核的升级，尤其是网络操作系统的升级往往不可控，因此业界开始重新审视UDP， HTTP／3 所使用的QUIC 就是基于UDP协议的。

HTTP／3 何时才能实施呢？整个互联网支持HTTP／3 可能还需要一段不短的时间吧！

参考资料：

《HTTP 权威指南》

RFC 7540 － Hypertext Transfer Protocol Version 2 （HTTP／2）

RFC 7541 － HPACK： Header Compression for HTTP／2