HTTP/2 是无状态协议吗? [英] Is HTTP/2 a stateless protocol?
问题描述
根据我的理解，HTTP/2 带有一个名为 HPACK 的有状态标头压缩.它不会改变 HTTP 协议的无状态语义吗?Web 应用程序将 HTTP/2 视为无状态协议是否安全?最后，HTTP/2 是否与现有的负载均衡器兼容?
HTTP/2 是无状态的.
原来的 HTTP 是无状态协议，意味着每个请求消息都可以孤立地理解.这意味着每个请求都需要包含服务器为该请求提供服务所需的详细信息，而服务器不必存储来自先前请求的大量信息和元数据.
由于 HTTP/2 没有改变这种范式，它必须以相同的方式工作，无状态.
从 官方 RFC 中也可以清楚地看到这一点.声明如下:
<块引用>超文本传输协议 (HTTP) 是一种用于分布式协作超媒体信息系统的应用程序级协议.它是一个通用的无状态协议，可用于许多任务......
HTTP/2 的定义说:
<块引用>该规范描述了超文本传输协议 (HTTP) 语义的优化表达，称为 HTTP 版本 2 (HTTP/2)...该规范是 HTTP/1.1 消息语法.HTTP 的现有语义保持不变.
结论
HTTP/2 协议在设计上是无状态的，因为与原始 HTTP 相比，语义保持不变.
混乱可能来自哪里
HTTP/2 连接是运行在 TCP 连接之上的应用层协议(顺便说一句，没有什么能阻止您使用 UDP 上的 HTTP，这是可能的，但不使用 UDP，因为它不是可靠的传输").不要将其与会话层和传输层混合使用.HTTP 协议在设计上是无状态的.加密 SSL/TLS 连接上的 HTTP 也不会改变此声明，因为 HTTPS 中的 S 与传输有关，而不是协议本身.
HPACK，HTTP/2 Header Compression，是一种压缩格式专为 HTTP/2 标头设计，并在 单独的互联网草案.它不会改变 HTTP/2 本身，所以它不会改变语义.
在 RFC for HTTP/2 中有关 HPACK 的部分中，他们声明:<块引用>
标头压缩是有状态的.一种压缩上下文和一种解压上下文用于整个连接.
这是来自 HPACK 的 RFC 的原因:
<块引用>2.2.编码和解码上下文
<块引用>
解压头块，解码器只需要维护一个动态表(参见第 2.3.2 节)作为解码上下文.没有其他需要动态状态.
<块引用>
当用于双向通信时，例如在 HTTP 中，端点维护的编解码动态表是完全独立，即请求和响应动态表是分开的.
<块引用>
HPACK 通过利用HTTP 等协议中固有的冗余.的最终目标这是为了减少发送 HTTP 所需的数据量请求或响应.
HPACK 实现不能完全无状态，因为完全独立的编码和解码表必须由端点维护.
同时，也有一些库尝试解决 HPACK 问题，例如无状态事件驱动的 HPACK 编解码器 现金回扣:
<块引用>HPACK 实现不能完全无状态，因为需要维护动态表.基于 HTTP/2 将始终解码完整 HPACK 序列的假设，无状态是使用事件驱动的 API 实现的.
From my understanding, HTTP/2 comes with a stateful header compression called HPACK. Doesn't it change the stateless semantics of the HTTP protocol? Is it safe for web applications to consider HTTP/2 as a stateless protocol? Finally, will HTTP/2 be compatible with the existing load balancers?
HTTP/2 is stateless.
Original HTTP is a stateless protocol, meaning that each request message can be understood in isolation. This means that every request needs to bring with it as much detail as the server needs to serve that request, without the server having to store a lot of info and meta-data from previous requests.
Since HTTP/2 doesn't change this paradigm, it has to work the same way, stateless.
It's clearly visible from official RFCs as well. It is stated:
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks...
and the definition of HTTP/2 says:
This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2)... This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
Conclusion
HTTP/2 protocol is stateless by design, as semantics remain unchanged in comparison to original HTTP.
From where confusion may come
An HTTP/2 connection is an application-layer protocol running on top of a TCP connection (BTW, nothing stops you to use HTTP over UDP for example, it's possible, but UDP is not used because it is not a "reliable transport"). Don't mix it with session and transport layers. HTTP protocol is stateless by design. HTTP over an encrypted SSL/TLS connection, also changes nothing to this statement, as S in HTTPS is concerned with the transport, not the protocol itself.
HPACK, Header Compression for HTTP/2, is a compression format especially crafted for HTTP/2 headers, and it is being specified in a separate internet draft. It doesn't change HTTP/2 itself, so it doesn't change the semantics.
In RFC for HTTP/2 in section about HPACK they state:
Header compression is stateful. One compression context and one decompression context are used for the entire connection.
And here's why from HPACK's RFC:
2.2. Encoding and Decoding Contexts
To decompress header blocks, a decoder only needs to maintain a dynamic table (see Section 2.3.2) as a decoding context. No other dynamic state is needed.
When used for bidirectional communication, such as in HTTP, the encoding and decoding dynamic tables maintained by an endpoint are completely independent, i.e., the request and response dynamic tables are separate.
HPACK reduces the length of header field encoding by exploiting the redundancy inherent in protocols like HTTP. The ultimate goal of this is to reduce the amount of data that is required to send HTTP requests or responses.
An HPACK implementation cannot be completely stateless, because the encoding and decoding tables, completely independent, have to be maintained by an endpoint.
At the same time, there are libraries, which try to solve HPACK issues, for example, a stateless event-driven HPACK codec CASHPACK:
An HPACK implementation cannot be completely stateless, because a dynamic table needs to be maintained. Relying on the assumption that HTTP/2 will always decode complete HPACK sequences, statelessness is achieved using an event-driven API.
这篇关于HTTP/2 是无状态协议吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
