HTTP 2.0的协议内容

异步连接多路复用；

头部压缩；

请求/响应管线化；

保持与HTTP 1.1语义的向后兼容性也是该版本的一个关键目标。SPDY是一种HTTP兼容协议，由Google发起，Chrome、Opera、Firefox以及Amazon Silk等浏览器均已提供支持。HTTP实现的瓶颈之一是其并发要依赖于多重连接。HTTP管线化技术可以缓解这个问题，但也只能做到部分多路复用。此外，已经证实，由于存在中间干扰，浏览器无法采用管线化技术。SPDY在单个连接之上增加了一个帧层，用以多路复用多个并发流。帧层针对HTTP类的请求响应流进行了优化，因此运行在HTTP之上的应用，对应用开发者而言只要很小的修改甚至无需修改就可以运行在SPDY之上。SPDY对当前的HTTP协议有4个改进：

多路复用请求；

对请求划分优先级；

压缩HTTP头；

服务器推送流（即Server Push技术）；

SPDY试图保留HTTP的现有语义，所以cookies、ETags等特性都是可用的。 节选：

1。超文本传输协议（HTTP）是一个非常成功的协议。 然而，HTTP/1.1消息格式是实施简单性和可访问性的优化，而不是应用程序的性能。 因此它具有对应用程序的性能产生负面影响总体几个特点。

特别是，HTTP/1.0只允许一个请求显眼每次一个给定的连接上。 HTTP/1.1流水线只能部分地解决了并发的请求，并从线头的阻塞受到影响。 因此，需要进行多次请求客户端通常使用多个连接到服务器，以减少等待时间。

此外，HTTP/1.1的报头字段经常重复和冗长，其中，除了产生更多或更大的网络数据包，可能会导致小的初始TCP拥塞窗口来快速填充。 这可能会导致过度的延迟，当多个请求在一个新的TCP连接进行。

该文通过定义一个基础连接的HTTP的语义优化的映射来解决这些问题。 具体地，它允许对请求和响应消息交织在同一连接上，并使用高效率的编码的HTTP报头字段。 它还允许请求的优先级，让更多的重要的要求更快速的完成，进一步提高了性能。

所得到的协议被设计为更友好的网络，因为较少的TCP连接都可以使用，在比较HTTP/1.x。 这意味着与其他流和长寿命的连接，而这又导致了更有效地利用可用的网络容量竞争少。

最后，这种封装也可以通过使用二进制消息取景使信息更具扩展性的处理。

1.1文件组织：

在HTTP/2.0规范被分成三个部分：开始HTTP/2.0（ 第3节 ），它涵盖了如何一个HTTP/2.0连接启动；成帧层（ 第4节 ），其中复用单一的TCP连接成各个独立的帧类别，以及一个HTTP层（ 第8节 ），它指定了表达机制使用成帧层的HTTP交互。 虽然一些成帧层概念是从HTTP的隔离，建立一个通用成帧层一直没有一个目标。 成帧层是针对HTTP协议和服务器推送的需求。

1.2约定和术语：

中的关键字“必须”，“必须不”，“要求”，“应”，“不应”，“应该”，“不应该”，“建议”，“或许”，该文件中“可选”如中解释RFC 2119 [RFC2119]。

所有数值都是以网络字节顺序。 值是无符号，除非另有说明。 提供在十进制或十六进制文该值（如适用）。 十六进制文字的前缀为0X从十进制文本区分开来。

术语：

客户端：端点发起HTTP连接。

连接：两个端点之间传输级连接。

连接错误：对HTTP/2.0的连接错误。

端点：连接的客户端或服务器。

框架：通信的HTTP/2.0连接中的最小单元，包括根据帧类型结构的字节的报头和可变长度的序列。

同行：一个端点。 当讨论一个特定的端点，“对等”指的是遥控器来讨论的首要议题端点。

接收器：正在接收帧的端点。

发件人：被发送的帧的端点。

服务器：端点而没有主动的HTTP连接。

流：帧在跨越一个虚拟通道的双向流动的HTTP/2.0连接内。

流错误：个别HTTP/2.0流中的一个错误。

2， HTTP/2.0协议介绍：

HTTP/2.0提供的HTTP语义优化的运输。

一个HTTP/2.0连接通过一个TCP连接（上面运行的应用程序级协议[TCP] ）。 客户端是TCP连接发起者。

该文档描述了使用由三个部分组成的逻辑结构的HTTP/2.0协议：成帧，溪流，和应用程序映射。 这种结构提供了主要作为一种辅助手段，规范，实现可以自由从该结构发散是必要的。

2.1的HTTP框架：HTTP/2.0提供HTTP语义的有效序列化。 HTTP请求和响应编码为长度前缀的帧（见第4.1节 ）。

HTTP标头字段被压缩成一系列包含头块碎片帧（参见4.3节 ）。

2.2 HTTP复用：HTTP/2.0提供了在单个连接上复用HTTP请求和响应的能力。 多个请求或响应可以同时在一个连接上使用流（发送第5节 ）。 为了保持独立的流，流控制和优先级是必要的。

2.3的HTTP语义：HTTP/2.0定义HTTP请求和响应如何映射到流（参见8.1节 ），并引入了新的互动模式，服务器推送（第8.2节 ）。

3， 启动HTTP/2.0：HTTP/2.0使用相同的“http”和“https”开头使用HTTP/1.1的URI方案。 HTTP/2.0共享相同的默认端口号：80为“http”的URI和443为“https”开头的URI。

通过这对于HTTP/2.0支持的手段被确定为不同的“http”和“https”开头的URI。 发现为“HTTP”中的URI描述第3.2节 。 发现为“https”开头的URI中说明第3.3节 。

3.1 HTTP/2.0版本识别：该文档中定义的协议是使用字符串“HTTP/2.0”标识。 这种识别是用在HTTP/1.1 Upgrade头域，在TLS的应用层协议协商的扩展 [TLSALPN]字段，和其他地方的协议识别是必需的。

谈判“HTTP/2.0”表示使用该文档中描述的交通，保安，取景和消息语义。

[ rfc.comment.1 ：编者注：请移除本节之前，这份文件的最终版该发布的其余部分]

最后，公布的RFC只有实现可以认同自己是“HTTP/2.0”。

实施例和文本贯穿该文档的其余部分使用“HTTP/2.0”作为唯一的编辑便利的问题。 草稿版本的实现必须不识别使用这个字符串。 唯一的例外规则是包含在连接头中的字符串建立HTTP/2.0连接后，立即通过客户端发送的（参见3.5节 ）；的八位这个固定长度的序列不发生变化。

版本的协议草案的实现必须字符串“ - 草稿”和相应的草案号码添加到标识符分隔符之前（'/'）。 例如，草案，IETF-httpbis-http2-03使用的是字符串“HTTP-draft-03/2.0”标识。

这是基于这些版本的草案不兼容的实验，而不是必须用不同的标识符替换字符串“草案”。 例如，一个实验实施分组基于心情的编码基于草案-IETF-httpbis-http2-07可能将自身标识为“HTTP-emo-07/2.0”。请注意，任何标签必须符合所定义的“令牌”语法第3.2.6节的[HTTP-P1] 。

3.2 启动HTTP/2.0为“http”的URI：如果客户端发出请求到一个“http”的URI，没有关于对HTTP/2.0的支持先验知识使用HTTP升级机制（第6.7节的[HTTP-P1] ）。 客户端发出，其中包括一个Upgrade头域识别HTTP/2.0 HTTP/1.1请求。 在HTTP/1.1请求必须包含正好一个HTTP2 -设置（ 第3.2.1节 ）头字段。

例如：GET / default.htm的HTTP/1.1

连接方式：升级，HTTP2 - 设置

升级：HTTP/2.0

HTTP2-设置：HTTP/2.0设置的<base64url编码payload>

包含一个实体正文的请求必须在其全部被发送之前，客户端可以发送HTTP/2.0帧。 这意味着大量请求实体可以阻止使用的连接，直到它被完全发送。

如果有后续请求的初始请求的并发性是很重要的，一个小小的请求可以被用来执行升级到HTTP/2.0，需支付额外的往返费用。

不支持HTTP/2.0的服务器可以响应请求，就好像Upgrade头域缺席：

HTTP/1.1 200 OK

内容长度：243

Content-Type：text / html类型

支持HTTP/2.0的服务器可以接受一个101（切换协议）响应升级。 因此终止了101响应的空行后，服务器就可以开始发送HTTP/2.0帧。 这些框架必须包括发起升级请求的响应。

HTTP/1.1 101交换协议

连接方式：升级

升级：HTTP/2.0

[HTTP/2.0连接...

由服务器发送的第一个HTTP/2.0帧是一个设置框（ 6.5节 ）。 在收到101响应，客户端发送一个连接头（ 3.5节 ），其中包括一个设置框。

在升级之前，发送的HTTP/1.1请求分配流标识符1并分配尽可能高的优先级。 流1半隐式从封闭向服务器的客户端，因为该请求被完成HTTP/1.1请求。 起的HTTP/2.0连接后，流1被用于反应。

3.2.1 HTTP2 -设置头字段：即从升级到HTTP/1.1 HTTP/2.0请求必须完全包括一个HTTP2，设置头字段。 该HTTP2 -设置标头栏位是包括设置支配的HTTP/2.0连接，由于预期该服务器接收到升级的要求提供逐跳头字段。 服务器必须拒绝尝试升级，如果这个头域不存在。

HTTP2 -设置= token68

该HTTP2-设置标头字段的内容是一个有效载荷设置帧（ 第6.5节 ），编码为base64url字符串（即，在所描述的URL和文件名安全Base64编码第5节的[RFC4648] ，与任何尾随'='字符省略）。 该ABNF[RFC5234]生产token68是定义在2.1节的[HTTP-P7] 。

客户端必须包含值以下设置（ 第6.5.1节 ）：

SETTINGS_MAX_CONCURRENT_STREAMS

SETTINGS_INITIAL_WINDOW_SIZE作为一个逐跳头域， 连接头域必须包括HTTP2 -设置的值除了升级到HTTP/2.0何时升级 。

服务器解码和解释这些值，因为它会任何其他设置框。 在升级要求提供这些值确保协议不需要进行上述设置的默认值，并给出了一个客户端一个机会，之前接受任何帧从服务器提供的其他设置。

3.3 启动HTTP/2.0为“https”开头的URI：

如果客户端发出请求到一个“https”开头的URI没有关于对HTTP/2.0的支持先验知识采用TLS [TLS12]与应用层协议协商的扩展 [TLSALPN]。

一旦TLS协商完成后，客户端和服务器发送一个连接头（ 3.5节 ）。

3.4 开始HTTP/2.0与前置知识：

客户端可以知道某个特定的服务器通过其他方式支持HTTP/2.0。 客户端可以立即发送HTTP/2.0帧至已知支持HTTP/2.0服务器，连接头（后第3.5节 ）。 这既影响了“http”的URI的分辨率；支持HTTP/2.0的服务器都必须支持的协议谈判中的TLS [TLSALPN]为“https”开头的URI。

对于HTTP/2.0的支持之前是不是一个强烈的信号，一个给定的服务器将支持HTTP/2.0为将来的连接。这是可能的服务器的配置来改变或配置，以在群集的服务器实例之间的差异。 拦截代理（又名“透明”的代理）是变化的另一个来源。

3.5 HTTP/2.0连接接头：当建立一个TCP连接和决心HTTP/2.0将使用两个对等的，每个端点必须发送一个连接头为最终确认，并建立了HTTP/2.0连接的初始设置。

客户端连接头开始的24个字节，这在十六进制表示法是一个序列：

505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

（字符串PRI * HTTP/2.0 \ r \n \ r \ NSM \ r \ n \ r \ n）的 。 该序列后跟一个设置框（6.5节 ）。 客户端立即收到的101切换响应协议（表示成功升级），或作为一个TLS连接的第一个应用程序数据八位位组发送客户端的连接头。 如果开始对协议的服务器支持先验知识的HTTP/2.0连接，客户端连接头在连接建立发送。

·客户端连接头是这样选择的HTTP/1.1或HTTP/1.0服务器和中介机构的很大比例并不试图进一步处理框架。 请注意，这并不解决所关注的问题 。

服务器连接头只包含一个的设置框（ 6.5节 ），必须在服务器发来的HTTP/2.0连接的第一帧。

为了避免不必要的等待时间，允许客户端发送客户端的连接头，无需等待接收服务器的连接头之后立即发送额外的帧到服务器。 但是要注意，该服务器连接头是很重要的设置框架可能包括参数必然改变了客户端如何有望与服务器进行通信。 在收到设置框，在客户端有望兑现建立的任何参数。

客户端和服务器必须终止TCP连接，如果不是同行不以一个有效的连接头。 一个GOAWAY框架（ 第6.8节 ，如果它是明确表示，对不使用HTTP/2.0）可以省略。

4， HTTP框架：

一旦HTTP/2.0建立连接，端点就可以开始交换帧。

4.1 帧格式：所有的框架开始一个8字节的头，紧跟着的0和16.383个八位位组之间的有效载荷。

对于保留的2位字段。 这些位的语义是不确定的和发送时该位必须保持未设置（0）和接收时必须被忽略。

长度：帧有效载荷的长度表示为一个无符号14位整数。 的8个字节的帧头中不包含这个值。

类型：8位类型的框架。 帧类型决定了帧头和有效载荷的其余部分被解释。 实现必须忽略不受支持或无法识别类型的帧。

标志：一个8位字段保留帧类型特定的布尔标志。

旗被分配到特定的表示帧类型语义。 那些没有定义的语义为特定帧类型标志必须被忽略，并且发送时必须保持未设置（0）。

记：对于保留的1位字段。 该位的语义是不确定的，发送和接收时必须被忽略时，该位必须保持未设置状态（0）。

流标识符：A 31-bit流标识符（见第5.1.1节 ）。 值0被用于与该连接作为一个整体相联，而不是一个单独的流的帧保留。

帧有效载荷的结构和内容是完全依赖帧类型。

4.2 帧大小：一帧的有效载荷的最大尺寸由帧类型不同而不同。 一帧的绝对最大大小为2 -1（16.383）字节。 所有的实现应能接收和处理的最小帧截至最大尺寸。

某些帧类型，如中国平安 （参见6.7节 ），施加允许的有效载荷数据量的额外限制。 同样，另外的大小限制可以通过特定的应用程序的用途进行设置（见第9节 ）。

如果帧大小超过任何已定义的限制，或者是太小，无法包含强制性的帧数据，端点必须发送一个FRAME_SIZE_ERROR错误。 在影响连接级状态帧帧大小错误必须被视为一个连接错误（ 第5.4.1节）。

4.3 报头压缩和解压：在HTTP/2.0标头字段是一个名称 - 值对与一个或多个相关联的值。 他们是在HTTP请求和响应消息，以及服务器推送操作中使用（参见8.2节 ）。

头列表是有序的排列，在应用层的零个或多个头部字段的集合。 当在一个连接上传输，一个头列表序列化为使用标题块的HTTP报头压缩 [压缩]。 序列化的头块被分成一个或多个字节的序列，称为头块碎片，和标头（有效载荷内传输6.2节 ），PUSH_PROMISE（ 6.6节 ）或延续（ 第6.10节 ）帧。

该Cookie首部字段 [COOKIE]是由HTTP映射特殊处理，请参阅第8.1.3.3 。

一种接收终端通过连接各个片段重新组合的头块，然后解压缩块来重构报头组。

一个完整的头块组成之一：

·单排针或PUSH_PROMISE每个分别与END_HEADERS或END_PUSH_PROMISE标志设置框，或

·一排针或PUSH_PROMISE帧与END_HEADERS或END_PUSH_PROMISE标志清零和一个或多个点连续的帧，其中最后延帧具有END_HEADER标志集。

头块必须被发送作为帧的连续序列，以及任何其他类型，或者通过任何其他流的无交插帧。 在序列的最后一帧接针或延帧必须有END_HEADERS标志设置。 在序列的最后一帧PUSH_PROMISE或延帧必须有END_PUSH_PROMISE或END_HEADERS标志设置（分别）。

头块碎片只能作为传送的有效载荷HEADERS ， PUSH_PROMISE或存续的帧。 排针 ， PUSH_PROMISE和延帧传输数据，可以通过修改一个接收器保持压缩上下文。 一个端点接收接针 ， PUSH_PROMISE或延帧必须重新装配头块和执行解压缩，即使帧将被丢弃。 接收器必须终止与连接错误（连接第5.4.1节类型） COMPRESSION_ERROR ，如果它没有解压缩一个头块。

HTTP是基于TCP/IP的应用层协议。影响HTTP网络请求的因素主要有两个：宽带和延迟。

宽带: 现在网络基础建设已经很完善，宽带得到了极大的提升，我们不在会担心由宽带而影响网速。

延迟:

1、 浏览器阻塞：浏览器会因为一些原因阻塞请求。浏览器对于同一个域名，同时只能有4个连接（浏览器内核不同可能会有差异），当超过浏览器最大连接数限制，后续请求就会被阻塞。

2、DNS查询：浏览器需要知道目标服务器的IP才能建立连接。将域名解析为IP的这个系统就是DNS。通常可以利用DNS缓存结果达到减少这个时间的目的。

3、建立连接：HTTP是基于TCP协议的，浏览器最快也要在第三次握手时才能捎带HTTP请求报文，达到真正建立连接，但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响比较明显，慢启动对大文件类请求影响比较大。

持久链接（Persistent Connection）

HTTP1.0需要使用connection: keep-alive参数来告知服务器端要建立一个长连接，而HTTP1.1默认支持长连接。

HTTP1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP链接，服务器不跟踪每个客户记录和请求。

会话方式如下：

1、建立连接

2、发出请求信息

3、回包响应信息

4、关掉连接

小结：浏览器和web服务器连接很短，每次连接只处理一个请求和响应。对每个请求，浏览器和web服务器都要建立一次单独的链接，服务器回完包，会直接断开链接，所以他们之间的通信是完全独立分开的请求和响应对，没法做到连接状态控制。同时建立和关掉链接会占用连接时间。

HTTP1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。

HTTP1.1还允许客户端不用等待上一次结果返回，就可以发送下一次请求。但服务器的回包策略必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分每次请求的响应内容。

节约宽带

HTTP1.1支持只发送header信息（不带任何body信息），如果服务器认为客户端有权限请求服务器，则返回100，否则返回401。客户端如果接受到100，才开始把请求body发送到服务器。

当服务器返回401的时候，客户端就可以不用发送body了，节约了宽带。

Range

HTTP1.1还支持传送内容的一部分。这样当客户端已经有一部分的资源后，只需要跟服务器请求另外的部分资源即可。这是支持文件断点续传的基础。

Host头处理

HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。随着虚拟主机技术的发展，在一台屋里服务器上可以存在多个虚拟主机，并且它们共享一个IP地址。

HTTP1.1的请求消息和响应消息都支持Host头域，且请求消息中没有Host头域会报告一个错误（400 Bad Request）。

HTTP2.0

目前iOS系统网络请求框架NSURLSessionTask使用的就是HTTP2.0

新的二进制格式，HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，

要做到健壮性考虑的场景必然很多。二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便其健壮。

多路复用，既连接共享，每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个链接的request可以随机的混杂在一起，接收方可以根据request的id将request在归属到各自不同的服务端请求里面。多路复用。

header压缩，HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份 header fields表，既避免了重复header的传输，又减小了需要传输的大小。

服务端推送，同SPDY一样，HTTP2.0也具有server push功能，具体看下面提到的SPDY

链接：https://www.jianshu.com/p/8a3a8fdc3a75

  RFC： https://tools.ietf.org/html/rfc7540

RFC 中英文对照： https://github.com/fex-team/http2-spec/blob/master/HTTP2%E4%B8%AD%E8%8B%B1%E5%AF%B9%E7%85%A7%E7%89%88(06-29).md

O'Reilly : https://hpbn.co/http2/

SPDY： http://www.chromium.org/spdy/

随着Web应用日渐广泛，复杂程度和重要性也在不断的增长，也因此对开发人员和用户带来了负担，HTTP2 支持所有的HTTP/1.1的核心特征，提供了HTTP语义的传输优化，并且在各方面做到更高效。

HTTP2 是运行在TCP或者SSL协议之上，属于应用层的协议。HTTP2.0消息包以二进制帧的形式进行封装。

Stream ： 已经建立连接的双向字节流，用唯一ID标示，可以传输一个或多个消息

Message ：逻辑上的HTTP消息，请求或者响应，可以包含多个 frame

Frame：HTTP2 通信的最小单位，二进制头封装，封装HTTP头部或body

HTTP2是把一个HTTP数据包分成多个帧发送，每个帧有一个二进制头，并把HTTP分成多个独立小帧，多个帧组成一个Message在流中发送。不同流的帧有可能交错到达，帧的报文头中标示了属于哪一个流。

HTTP2的最小数据单位是帧，所有帧以9字节的帧头并跟着0-16,383字节的数据。

Length： unsigned 24-bit integer，最大值为 2^24(16384)，指的是不包括头部的部分

Type：帧的类型

Flags：为帧类型保留的8字节字段有具体的布尔标识

R：1位的保留字段

Stream Identifier：31字节的流标识符。0是保留的，标明帧是与连接相关作为一个整体而不是一个单独的流。

帧主体的结构和内容完全取决于帧类型。

HTTP2 有以下十种帧类型：

Pad Length ： 8位，可选，只在设置了PADDED标记时呈现。表示帧填充的字节为单位的长度。

Data ： 应用数据。

Padding ： 填充字节不包含任何应用语义值。填充字节在发送时设为0，接收时忽略。

DATA 帧定义了以下的 Flags:

END_STREAM (0x1): 位1，表示当前帧是相应流发送的最后一帧。设置时流进入半封闭或关闭状态。

PADDED (0x8): 位4，表示Pad Length 字段启用与否。

Pad Length：8位可选，在设置PADDED 标记时呈现。表示帧填充的字节为单位的长度。

E ： 1位可选，在优先级标记设置时呈现。表示用于标识流依赖是否是专用的。

Stream Dependency ： 31位可选，在优先级标记设置时呈现。流依赖的流的标识符。

Weight : 8位可选，在优先级标记设置时呈现。流的8位权重标记，1-256的值。

Header Block Fragment ： 报头块。

Padding ： 填充字节

HEADERS 帧定义了以下的 Flags:

END_STREAM (0x1) ： 位1，标识是此发送端对流发送的最后报头区块。设置这标记使流进入半封闭状态。

END_HEADERS (0x4) ： 位3，表示帧包含了整个的报头块，且后面没有延续帧。 END_HEADERS为0的报头帧后面必须跟着延续帧。

PADDED (0x8) ： 位4，表示Pad Length字段会呈现。

PRIORITY (0x20) ： 位6，优先级标记(E), 流依赖及权重字段将会呈现。

E : 1位标记，指示流的依赖是专有的。

Stream Dependency ： 流所依赖流的31位标识符。

Weight: 流的权重(8位)。1-256的权重值。

RST_STREAM 帧由一个32位整数标记错误码，指明流被终止的原因。

RST_STREAM 帧必须与流相关联，就是说stream id 不能为 0x0

RST_STREAM帧绝对不能在流处于“空闲”状态下发送。

载体包含0或多个参数，每个包含一个16位标识以及一个32位的值。

1）设置帧由两个终端在连接开始时发送，连接生存期的任意时间发送。

2）设置帧的参数将替换参数中现有值，不能识别的忽略。

3）设置帧总是应用于连接，而不是一个单独的流。流ID必须为0；

SETTINGS 帧定义了以下的 Flags：

ACK (0x1) ： 位1，表示设置帧被接收端接收并应用。如果设置了ACK，设置帧的载体必须为空。

SETTINGS_HEADER_TABLE_SIZE (0x1) : 发送端通知远端报头压缩表的最大承载量。初始值是4,096个字节。

SETTINGS_ENABLE_PUSH (0x2) : 用来关闭服务器推送。0时不能发送PUSH_PROMISE。1表示可以推送。

SETTINGS_MAX_CONCURRENT_STREAMS (0x3) : 标明发送端允许接收端创建的最大并发流的数量。没有限制(<100) 。 0值阻止新流的创建。

SETTINGS_INITIAL_WINDOW_SIZE (0x4) : 表示发送端流量控制的初始窗口大小(字节)。初始值是65,535。 影响所有流的窗口大小.

SETTINGS_MAX_FRAME_SIZE (0x5): 接收最大帧大小。初始值为2^14 (16,384)字节，最大值为2^24-1 or 16,777,215字节。

SETTINGS_MAX_HEADER_LIST_SIZE (0x6): 可接收的header列表长度(字节)，基于非压缩的列表大小。

1) 被推送的流并不需要按照顺序使用。

2) 接收端可以给推送端返回一个RST_STREAM拒绝接收。

Pad Length : 8位，只在PADDED标记设置时才呈现。

R : 1bit保留位。Padding : 填充字节。

Promised Stream ID : 31位整数表示终端准备发送的流标记。

Header Block Fragment : 包含请求头字段的报头区块。

PUSH_PROMISE 帧定义了以下的Flags:

END_HEADERS (0x4) : 位3, 表明帧包含了整个报头区块。

PADDED (0x8) : 位4, 表明Pad Length字段是已设置。

PING 帧定义了以下的Flags:

ACK (0x1) ： 位1表示PING帧是一个PING响应。

1）PING帧可以被任何终端任何时刻发送。

2）PING帧必须在载体中包含一个8字节长度的数据。

收到不含ACK的PING帧必须发送一个有ACK的PING响应，带相同的载荷。PING响应应设置比其他帧更高的优先级。流ID为0，不和任何流关联；

可以由客户端或服务端发送。发动端将忽略连接上流标示符大于Last-Stream-ID的流。

接收端接收到超时帧后不能在这个连接上打开新流，可以创建新连接。

终端在关闭连接之前总是应当发送一个超时帧；

适用于连接而不是特定的流。流标识符必须是0x0，否则错误处理；

连接关闭前小于或等于标识符上的流没有完全关闭的，重试请求；

小于或等于最后流标识符的流可能仍然能成功完成，保持连接在打开状态直到正在处理的流全部处理完成。

在发送超时帧后，发送端能丢弃流标识符大于最终流标识的流的帧。但任何修改流状态的帧不能被忽略。

超时帧包含一个32位错误码，包含关闭连接的原因。

1） 可以作用单独的流(ID!=0) 或 整个连接(ID==0)

2） 所有类型的流量控制都是逐跳的（hop-by-hop）， 中介端不会转发

3） 流量控制只适用于Data帧

4） 一个保留字节，一个31位整数（ 发送端被允许传输的字节数，它的大小是接收端的缓存能力的衡量）。

5） 流和连接的初始值都是65535；流的窗口大小可以用SETTING帧设置大小SETTINGS_INITIAL_WINDOW_SIZE；

6） 通过设置窗口大小，可能导致窗口大小为负数（当前有10字节数据，设置为5字节，则剩余-5字节的长度）。

只要流上前一帧是不带END_HEADERS的HEADERS帧、PUSH_PROMISE帧或者不带有END_HEADERS标记的CONTINUATION帧，可以发送任意多个延续帧。

CONTINUATION 帧定义了以下的Flags:

END_HEADERS (0x4) : 位3，指示帧是否是报头区块的终止。 如果END_HEADERS位没有被设置，这个帧必须跟着另一个延续帧。

h2：基于TLS之上构建的HTTP/2，作为ALPN的标识符，两个字节表示，0x68, 0x32，即https

h2c：直接在TCP之上构建的HTTP/2，缺乏安全保证，即http

在不知道服务器是否支持http2的情况下，可以利用http的升级机制发送试探包

1、客户端发起请求

2、服务器不支持 http2，直接按照 http/1.1响应

3、服务器支持 http2，通知客户端切换到http2

4、服务器发送的第一个http2帧，必须为SETTINGS帧做为连接序言

5、客户端接收到101响应后，也必须发送一个序言作为响应，其逻辑结构：

6、客户端可以马上发送请求帧或其它帧过去，不用等待来自服务器端的SETTINGS帧

7、任一端接收到SETTINGS帧之后，都需要返回一个包含确认标志位SETTIGN作为确认

8、其它帧的正常传输

1、客户端和服务器端TLS层协商

2、客户端发送连接序言（同上表示，PRI + SETTINGS）

3、接收到客户端连接序言之后，服务器端发送连接序言

4、双方各自确认SETTINGS帧

5、其它帧的正常传输

1、客户端必须首先发送一个连接序言，其逻辑结构：

2、发送完毕序言之后，客户端可以不用等待来自服务器端响应，马上发送HTTP/2其它帧

3、服务器端接收到客户端的连接序言之后，需要发送一个SETTINGS帧作为连接序言

4、任一端接收到SETTINGS帧之后，都需要返回一个包含确认标志位SETTIGN作为确认

5、其它帧的正常传输

1、HTTP/1.1在建立建立之后，只需要发送请求报文数据

2、HTTP/2客户端需要在连接建立之初马上发送一个连接序言过去，然后才是正常请求

3、两端（客户端+服务器端）的两次完整的连接序言+确认的交互流程，多了两次往返过程

---