HTTP 2.0的协议内容

发布网友 发布时间：2022-04-20 07:01

我来回答

共2个回答

懂视网 时间：2022-04-12 16:40

云计算时代，浏览器和移动APP成为云端资源的主要入口。 HTTP 1.1已经成为这个生态环境的瓶颈。 SPDY协议是Google开发的一种基于TCP的应用层协议，旨在替换当前的HTTP 1.1。 据说SPDY协议的性能比HTTP 1.1快1倍。 SPDY保留了HTTP 1.1的语义，但是在传输方式上

云计算时代，浏览器和移动APP成为云端资源的主要入口。

HTTP 1.1已经成为这个生态环境的瓶颈。

SPDY协议是Google开发的一种基于TCP的应用层协议，旨在替换当前的HTTP 1.1。

据说SPDY协议的性能比HTTP 1.1快1倍。

SPDY保留了HTTP 1.1的语义，但是在传输方式上与HTTP 1.1截然不同。就是说，现有的Web应用基本无需任何修改就可以从HTTP 1.1迁移到SPDY协议。

SPDY协议和HTTP 1.1一样都是基于TCP，但是它与HTTP 1.1的区别在于，HTTP 1.1与TCP是紧耦合的，HTTP 1.1的Message是直接通过TCP的packet发送的；而SPDY协议则在TCP之上定义了一个framing layer，也可以称之为HTTP Layer。

framing layer的连接叫做stream，区别于TCP的connection。每个connection对应多个stream。每个stream对应的是一个请求/响应。多个stream可以并行的进行发送/接受数据。

HTTP 2.0据说将在今年正式Release，SPDY协议可以说是HTTP 2.0标准的一个参考。

想知道SPDY协议具体解决了HTTP 1.1的哪些问题？请参考 http://www.slideshare.net/ihower/a-brief-introduction-to-spdy-http20

另外，如果你想了解SPDY协议的实现细节，请参考 http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1

热心网友 时间：2022-04-12 13:48

异步连接多路复用；
头部压缩；
请求/响应管线化；
保持与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 ，如果它没有解压缩一个头块。