HTTP/2是无状态协议吗？

据我所知，

HTTP/2

附带了一个称为

HPACK

的有状态头压缩。它不会改变HTTP协议的无状态语义吗？对于Web应用程序来说，将代码> HTTP／2 作为无状态协议是安全的吗？最后，

HTTP/2

是否与现有的负载平衡器兼容？

HTTP/2是无状态的。 原始HTTP是一种无状态协议，这意味着每个请求消息都可以单独理解。这意味着每一个请求都需要包含服务器为该请求提供服务所需的尽可能多的细节，而服务器不必存储以前请求中的大量信息和元数据

由于HTTP/2没有改变这种模式，它必须以同样的方式工作，无状态

它也清晰可见。据说：

超文本传输协议（HTTP）是用于分布式、协作、超媒体信息系统的应用程序级协议。它是一个通用的、无状态的协议，可用于许多任务

而这个词的定义是：

本规范描述了超文本传输协议（HTTP）语义的优化表达，称为HTTP版本2（HTTP/2）。。。本规范是HTTP/1.1消息语法的替代品，但并不过时HTTP的现有语义保持不变。

结论 HTTP/2协议在设计上是无状态的，因为与原始HTTP相比，语义保持不变

---

混乱可能来自哪里 HTTP/2连接是运行在TCP连接之上的应用层协议（顺便说一句，没有任何东西阻止您使用，例如，它是可能的，但UDP不被使用，因为它不是“可靠的传输”）。不要将其与会话层和传输层混合使用HTTP协议在设计上是无状态的。 通过加密SSL/TLS连接的HTTP也不会更改此语句，因为HTTPS中的S与传输有关，而与协议本身无关

，Header Compression for HTTP/2，是一种专门为HTTP/2头编写的压缩格式，并在中指定。它不会改变HTTP/2本身，因此不会改变语义

在关于HPACK的部分中，他们指出：

头压缩是有状态的。一个压缩上下文和一个 解压上下文用于整个连接

以下是原因：

2.2。编码和解码上下文

要解压缩头块，解码器只需要维护 动态表（见第2.3.2节）作为解码上下文。没有别的 需要动态状态

当用于双向通信时，例如在HTTP中 对端点维护的动态表进行编码和解码是必要的 完全独立，即请求和响应动态表 它们是分开的

---

HPACK通过利用 HTTP等协议固有的冗余。最终目标 这是为了减少发送HTTP所需的数据量 请求或响应

HPACK实现不能完全无状态，因为编码表和解码表完全独立，必须由端点维护

同时，还有一些库试图解决HPACK问题，例如，无状态事件驱动的HPACK编解码器：

HPACK实现不能完全无状态，因为需要维护动态表。基于HTTP/2总是解码完整的HPACK序列的假设，使用事件驱动API实现无状态。

现代HTTP，包括HTTP/2，是一种有状态协议。旧的HTTP是无状态的。 许多HTTP/2组件正是有状态的定义

没有一个通情达理的人能够阅读HTTP/2 RFC并认为它是无状态的。错误的“HTTP是无状态的”旧教条是错误的，它并不代表HTTP的当前现实

以下是有状态HTTP/1和HTTP/2组件的有限但并非详尽的列表：

• Cookie，（RFC将其命名为“HTTP状态管理机制”）
• HTTPS，它存储密钥，从而
• HTTP身份验证需要状态
• 网络存储
• HTTP缓存是有状态的
• 流标识符的目的就是状态
• 建立流标识符的头块是有状态的
• 引用流标识符是有状态的帧
• HTTP RFC明确表示有状态的头压缩是有状态的
• 机会加密是有状态的

HTTP/2 RFC是HTTP/2标准定义的有状态机制的一个很好的例子

Web应用程序将HTTP／2视为无状态协议是否安全？

HTTP/2是一种有状态协议，但这并不意味着HTTP/2应用程序不能是无状态的。通过仅使用HTTP/2功能的一个子集，您可以选择不对无状态HTTP/2应用程序使用某些有状态功能

Cookie和其他一些有状态机制，或不太明显的有状态机制，是后来HTTP的补充。尽管在实践中我们使用标准化的有状态机制与HTTP/1.0不同，HTTP/2在其标准中定义了有状态组件，因此是有状态的。特定的HTTP/2应用程序可以使用HTTP/2功能的子集来维护无状态

如果试图无状态地使用需要状态的现有应用程序，即使是HTTP 1应用程序，也会中断。如果禁用Cookie，则无法登录某些HTTP/1.1网站，从而中断应用程序。假设某个特定的HTTP 1应用程序不使用状态可能不安全。这与HTTP/2没有什么不同。在Netscape发明cookies和HTTPS之前