根据我的理解，HTTP/2附带一个名为HPACK的有状态标头压缩。它不会改变HTTP协议的无状态语义吗？ Web应用程序将HTTP/2视为无状态协议是否安全？最后，HTTP/2会与现有的负载均衡器兼容吗？
答案 0 :(得分：16)
原始HTTP是无状态协议，这意味着可以单独理解每个请求消息。这意味着每个请求都需要带来与服务器提供该请求所需的详细信息，而服务器不必存储来自先前请求的大量信息和元数据。
由于HTTP / 2并没有改变这种范式，因此它必须以同样的方式工作，无状态。
从oficial RFCs也可以清楚地看到它。据说：
超文本传输协议（HTTP）是用于分布式协作超媒体信息系统的应用程序级协议。它是一种通用的无状态协议，可用于许多任务......
和HTTP/2的定义说：
此规范描述了超文本传输协议（HTTP）语义的优化表达式，称为HTTP版本2（HTTP / 2）...此规范是HTTP /的替代，但未废弃1.1消息语法。 HTTP的现有语义保持不变。
HTTP / 2协议在设计上是无状态的，因为与原始HTTP相比，语义保持不变。
HTTP / 2连接是在TCP连接之上运行的应用程序层协议（顺便说一下，没有什么能阻止你使用HTTP over UDP，例如，它是可能的，但是没有使用UDP，因为它不是一个可靠的运输＆＃34;）。不要将它与会话和传输层混合在一起。 HTTP协议按设计无状态。 通过加密的SSL / TLS连接的HTTP也不会对此语句进行任何更改，因为HTTP S 中的S与传输有关，而与协议本身无关。
HPACK，HTTP / 2的标头压缩是一种专为HTTP / 2标头设计的压缩格式，它在separate internet draft中指定。它不会改变HTTP / 2本身，因此它不会改变语义。
在关于HPACK的RFC for HTTP/2部分中，他们说：
标头压缩是有状态的。一个压缩上下文和一个 解压上下文用于整个连接的 。
这就是为什么来自HPACK's RFC：
<强> 2.2。编码和解码上下文
要解压缩标头块，解码器只需要维护一个 动态表（参见第2.3.2节）作为解码上下文。没有其他 需要动态。
当用于双向通信时，例如在HTTP中 编码和解码由端点维护的动态表 完全独立，即请求和响应动态表 是分开的。
HPACK 通过利用来减少头字段编码的长度 HTTP等协议中固有的冗余。最终的目标 这是为了减少发送HTTP所需的数据量 请求或回复。
HPACK实现不能完全无状态，因为完全独立的编码和解码表必须由端点维护。
同时，有些库试图解决HPACK问题，例如，无状态事件驱动的HPACK编解码器CASHPACK：
HPACK实现不能完全无状态，因为需要维护动态表。依赖于HTTP / 2将始终解码完整HPACK序列的假设，使用事件驱动的API实现无状态。
答案 1 :(得分：-1)
HTTP / 2是无状态协议吗？
否即可。某些HTTP / 2组件旨在维护状态。
HTTP / 2 RFC的Section 5.1是HTTP / 2标准定义的有状态机制的一个很好的例子。
Web应用程序将HTTP / 2视为无状态协议是否安全？
HTTP / 2是一种有状态协议，但这并不意味着您的HTTP / 2应用程序无法成为无状态。您可以通过仅使用HTTP / 2功能的子集来选择不对无状态HTTP / 2应用程序使用某些有状态功能。
Cookie和其他有状态机制是后来在单独的RFC中定义的HTTP添加。它们不是原始HTTP / 1.0规范的一部分，并且在HTTP 1.1 RFC中没有提及。 HTTP 1 is said to be stateless虽然在实践中我们使用标准化的有状态机制。 与HTTP / 1.0不同，HTTP / 2在其标准中定义了有状态组件，因此是有状态的。特定的HTTP / 2应用程序可以使用HTTP / 2功能的子集来维护无状态。
现有的应用程序，即使是HTTP 1应用程序，如果试图无状态地使用它们，也会破坏状态。如果禁用cookie，则无法登录某些HTTP / 1.1网站，从而破坏了应用程序。假设特定HTTP 1应用程序不使用状态可能不安全。这与HTTP / 2没有什么不同。