摘要

这份规范定义了HPACK，一个用于HTTP/2，为有效地表示HTTP首部字段而设计的压缩格式。

此备忘录的状态

这是一份互联网标准跟踪文档。

摘要

这份文档描述了一种传输层安全(TLS)扩展，即TLS握手消息里的应用层协议协商。比如在一些在相同的TCP或UDP端口上支持多种应用层协议的应用中，这个扩展允许应用层协商将在TLS连接内使用的协议。

摘要

这份规范描述了一种 超文本传输协议(HTTP) 语义的优化表达，被称为HTTP 版本 2(HTTP/2)。HTTP/2通过引入首部字段压缩，及允许在相同的连接上并发的进行多个数据交换，而使得对网络资源的使用更高效，且获得可感知的延迟降低。它还引入了服务器向客户端未经请求的推送语义。

这份规范是HTTP/1.1消息语法的替代品，但并不废弃它。HTTP既有的语义保持不变。

12.1 引用的标准

一个用于识别HTTP/2的字符串进入了由 [TLS-ALPN] 建立的 “应用层协议协商 (ALPN) 协议IDs” 注册表

本文档为帧类型，设置项，和错误码建立了一个注册表。这些新的注册表项出现在新的”Hypertext Transfer Protocol version 2 (HTTP/2) Parameters”一节。

10.1 服务器认证

HTTP/2依赖于HTTP/1.1定义的认证方式来确定提供给定响应的服务器(参见 [RFC7230]，Section 9.1) 是否是可信的。这依赖于为”http” URI scheme做的本地域名解析，及”https” scheme的身份认证服务器 [RFC2818]，Section 3)。

这一节概括了提升互操作性，降低暴露给已知的安全脆弱性，或降低潜在的实现变异的HTTP协议属性。

HTTP/2被期待着尽可能与当前使用的HTTP兼容。这意味着，从应用程序的视角来看，大部分的协议的功能不能变。为了实现这一点，而保留了所有的请求和响应的语义，尽管携带这些语义的语法已经变了。

因而，HTTP/1.1的规范和要求，Semantics and Content [RFC7231] ，Conditional Requests [RFC7232] ，Range Requests [RFC7233] ，Caching [RFC7234] ，和Authentication [RFC7235] 依然适用于HTTP/2。选中的HTTP/1.1 Message Syntax and Routing [RFC7230] 的部分，比如HTTP和HTTPS URI schemes，也适用于HTTP/2，但是对于这个协议，那些语义的表达则在下面的小节定义。

错误码是用在RST_STREAM和GOAWAY帧中的32位字段，来携带流或连接错误的原因的。

错误码共享一个共同的码空间。一些错误码只应用于流或整个连接，而在其它上下文中没有定义语义。

这份文档定义了多种帧类型，每种都由一个唯一的8位类型码标识。每种帧类型都服务于建立和管理整个连接或独立的流方面的一个不同的目的。

特定帧类型的传输可能改变连接的状态。如果终端不能维护连接状态视图的一致性，连接内成功的通信将是不可能的。因此，终端之间，关于特定帧的使用对状态所产生的影响具有相同的理解就变得非常重要。