http2.0
http2.0最近好像又有点火起来的感觉。先简单的介绍下http/2的一些特性。其实http2.0主要是让我们的应用更快更稳定更简单。可以进行进一步的应用优化以及性能提升。还是基于tls的，所以得https的。
HTTP/2的主要目标是通过启用完整的请求和响应多路复用来降低延迟，通过有效压缩HTTP头字段来最小化协议开销，并添加对请求优先级和服务器推送的支持。 为达成这些目标，HTTP/2 还给我们带来了大量其他协议层面的辅助实现，例如新的流控制、错误处理和升级机制。上述几种机制虽然不是全部，但却是最重要的，每一位网络开发者都应该理解并在自己的应用中加以利用。
为什么不是 HTTP/1.2？
HTTP/2引入了一个新的二进制帧层，他无法与HTTP/1.x服务器和客户端向后兼容。
SPDY 与 HTTP/2 简史
SPDY是谷歌开发的一个实验性协议，主要针对HTTP/1.1中的一些性能限制。他的主要目标是：
页面加载时间 (PLT) 减少 50%。
无需网站作者修改任何内容。
将部署复杂性降至最低，无需变更网络基础设施。
与开源社区合作开发此新协议。
收集真实性能数据，验证实验性协议是否有效。
注：为了达到减少 50% 页面加载时间的目标，SPDY 引入一个新的二进制分帧层，以实现请求和响应复用、优先级和标头压缩，目的是更有效地利用底层 TCP 连接；请参阅延迟是性能瓶颈。
发布之后，google的两位工程师就对这个的结果，稳定，源码进行了分享。到了2012年，Chrome，Firefox, Opera都对其进行了支持，并且大量网站对其进行部署。观察到这一趋势后，HTTP 工作组 (HTTP-WG) 将这一工作提上议事日程，吸取 SPDY 的经验教训，并在此基础上制定了官方“HTTP/2”标准。
最终，这个过程持续了三年，期间产生了十余个中间草案：
2012 年 3 月：征集 HTTP/2 建议
2012 年 11 月：第一个 HTTP/2 草案（基于 SPDY）
2014 年 8 月：HTTP/2 草案 17 和 HPACK 草案 12 发布
2014 年 8 月：工作组最后一次征集 HTTP/2 建议
2015 年 2 月：IESG 批准 HTTP/2 和 HPACK 草案
2015 年 5 月：RFC 7540 (HTTP/2) 和 RFC 7541 (HPACK) 发布
二进制分帧层
HTTP/2 所有性能增强的 核心 在于新的二进制帧层，它定义了如何封装 HTTP 消息并在客户端与服务器之间传输。
“层”指的是在套接字接口和公开给我们的应用程序的高级HTTP API之间引入新的优化编码机制的设计选择:HTTP语义(如谓词、方法和头)不受影响，但是它们在传输过程中的编码方式不同。HTTP/1.x 协议以换行符作为纯文本的分隔符，而 HTTP/2 将所有传输的信息分割为更小的消息和帧，并采用二进制格式对它们编码。
数据流、消息和帧
数据流：已建立的连接内的双向字节流，可以承载一条或多条消息。
消息：与逻辑请求或响应消息对应的完整的一系列帧。
帧：HTTP/2 通信的最小单位，每个帧都包含帧头，至少也会标识出当前帧所属的数据流。
这些概念的关系总结如下：
所有通信都在一个 TCP 连接上完成，此连接可以承载任意数量的双向数据流。
每个数据流都有一个唯一的标识符和可选的优先级信息，用于承载双向消息。
每条消息都是一条逻辑 HTTP 消息（例如请求或响应），包含一个或多个帧。
帧是最小的通信单位，承载着特定类型的数据，例如 HTTP 标头、消息负载等等。 来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装。
HTTP/2 中新的二进制分帧层实现了完整的请求和响应复用：客户端和服务器可以将 HTTP 消息分解为互不依赖的帧，然后交错发送，最后再在另一端把它们重新组装起来。
数据流优先级
将 HTTP 消息分解为很多独立的帧之后，我们就可以复用多个数据流中的帧，客户端和服务器交错发送和传输这些帧的顺序就成为关键的性能决定因素。 为了做到这一点，HTTP/2 标准允许每个数据流都有一个关联的权重和依赖关系：
可以向每个数据流分配一个介于 1 至 256 之间的整数。
每个数据流与其他数据流之间可以存在显式依赖关系。
数据流依赖关系和权重的组合让客户端可以构建和传递“优先级树”，表明它倾向于如何接收响应。 反过来，服务器可以使用此信息通过控制 CPU、内存和其他资源的分配设定数据流处理的优先级，在资源数据可用之后，带宽分配可以确保将高优先级响应以最优方式传输至客户端。
共享相同父项的数据流（即，同级数据流）应按其权重比例分配资源。 例如，如果数据流 A 的权重为 12，其同级数据流 B 的权重为 4，那么要确定每个数据流应接收的资源比例，请执行以下操作：
将所有权重求和：
4 + 12 = 16将每个数据流权重除以总权重：
A = 12/16, B = 4/16
因此，数据流 A 应获得四分之三的可用资源，数据流 B 应获得四分之一的可用资源；数据流 B 获得的资源是数据流 A 所获资源的三分之一。
我们来看一下上图中的其他几个操作示例。 从左到右依次为：
数据流 A 和数据流 B 都没有指定父依赖项，依赖于显式“根数据流”；A 的权重为 12，B 的权重为 4。因此，根据比例权重：数据流 B 获得的资源是 A 所获资源的三分之一。
数据流 D 依赖于根数据流；C 依赖于 D。 因此，D 应先于 C 获得完整资源分配。 权重不重要，因为 C 的依赖关系拥有更高的优先级。
数据流 D 应先于 C 获得完整资源分配；C 应先于 A 和 B 获得完整资源分配；数据流 B 获得的资源是 A 所获资源的三分之一。
数据流 D 应先于 E 和 C 获得完整资源分配；E 和 C 应先于 A 和 B 获得相同的资源分配；A 和 B 应基于其权重获得比例分配。
流控制
流控制是一种阻止发送方向接收方发送大量数据的机制 ，以免超出后者的需求或处理能力：发送方可能非常繁忙、处于较高的负载之下，也可能仅仅希望为特定数据流分配固定量的资源。
上述要求会让您想到 TCP 流控制吗？您应当想到这一点；因为问题基本相同（请参阅流控制）。 不过，由于 HTTP/2 数据流在一个 TCP 连接内复用，TCP 流控制既不够精细，也无法提供必要的应用级 API 来调节各个数据流的传输。 为了解决这一问题，HTTP/2 提供了一组简单的构建块，这些构建块允许客户端和服务器实现其自己的数据流和连接级流控制：
流控制具有方向性。 每个接收方都可以根据自身需要选择为每个数据流和整个连接设置任意的窗口大小。
流控制基于信用。 每个接收方都可以公布其初始连接和数据流流控制窗口（以字节为单位），每当发送方发出
DATA帧时都会减小，在接收方发出WINDOW_UPDATE帧时增大。流控制无法停用。 建立 HTTP/2 连接后，客户端将与服务器交换
SETTINGS帧，这会在两个方向上设置流控制窗口。 流控制窗口的默认值设为 65,535 字节，但是接收方可以设置一个较大的最大窗口大小（2^31-1字节），并在接收到任意数据时通过发送WINDOW_UPDATE帧来维持这一大小。流控制为逐跃点控制，而非端到端控制。 即，可信中介可以使用它来控制资源使用，以及基于自身条件和启发式算法实现资源分配机制。
服务器推送
HTTP/2 新增的另一个强大的新功能是，服务器可以对一个客户端请求发送多个响应。 换句话说，除了对最初请求的响应外，服务器还可以向客户端推送额外资源（图 12-5），而无需客户端明确地请求。
注：HTTP/2 打破了严格的请求-响应语义，支持一对多和服务器发起的推送工作流，在浏览器内外开启了全新的互动可能性。 这是一项使能功能，对我们思考协议、协议用途和使用方式具有重要的长期影响。
推送资源可以进行以下处理：
由客户端缓存
在不同页面之间重用
与其他资源一起复用
由服务器设定优先级
被客户端拒绝
头部压缩
在 HTTP/1.x 中，此元数据始终以纯文本形式，通常会给每个传输增加 500–800 字节的开销。如果使用 HTTP Cookie，增加的开销有时会达到上千字节。 （请参阅测量和控制协议开销。） 为了减少此开销和提升性能，HTTP/2 使用 HPACK 压缩格式压缩请求和响应标头元数据，这种格式采用两种简单但是强大的技术：
这种格式支持通过静态霍夫曼代码对传输的标头字段进行编码，从而减小了各个传输的大小。
这种格式要求客户端和服务器同时维护和更新一个包含之前见过的标头字段的索引列表（换句话说，它可以建立一个共享的压缩上下文），此列表随后会用作参考，对之前传输的值进行有效编码。
作为一种进一步优化方式，HPACK 压缩上下文包含一个静态表和一个动态表：静态表在规范中定义，并提供了一个包含所有连接都可能使用的常用 HTTP 标头字段（例如，有效标头名称）的列表；动态表最初为空，将根据在特定连接内交换的值进行更新。
注：在 HTTP/2 中，请求和响应标头字段的定义保持不变，仅有一些微小的差异：所有标头字段名称均为小写，请求行现在拆分成各个 :method、:scheme、:authority 和 :path 伪标头字段。
使用
介绍了那么多，怎么使用呢？嗨，还好，之前用得是https。 怎么使用，加行配置
后面那个http2就是后面加上得。nginx reload后重启不行(安装插件查看http2)。好吧，要依赖得：
nginx版本不低于1.9.5
openssl版本不低于1.0.2
使用不低于tls1.2得协议
Last updated
