为什么说"HTTP是无状态协议"?

Jos*_*ile 159 http stateless

HTTP有HTTP Cookie.Cookie允许服务器跟踪用户状态,连接数,最后连接数等.

HTTP具有持久连接(Keep-Alive),其中可以从同一TCP连接发送多个请求.

cHa*_*Hao 121

即使可以通过同一HTTP连接发送多个请求,服务器也不会通过同一个套接字附加任何特殊含义.这仅仅是一种性能问题,旨在最大限度地减少为每个请求重新建立连接所花费的时间/带宽.

就HTTP而言,它们仍然是单独的请求,并且必须包含足够的信息以满足请求.这就是"无国籍"的本质.如果没有服务器知道的某些共享信息,请求将不会彼此关联,这在大多数情况下是cookie中的会话ID.

  • @Andrew:HTTP不是"建立在"TCP上,而TCP的状态不是HTTP.这两个是堆栈中不同层的完全独立的协议.如果你愿意,你可以在命名管道上提供HTTP,或者甚至通过发送文件,如果你有足够的masochists同意这样做,它可以正常工作,因为HTTP是与传输协议无关的.在那个级别,它只是请求和响应.这使得HTTP本身无状态,无论较低级别或更高级别的协议可以使用/维护/要求什么状态. (9认同)
  • @NurShomik:有关会话通常如何工作的说明,请参阅http://stackoverflow.com/a/3521393/319403. (2认同)

dim*_*414 96

来自维基百科:

HTTP是无状态协议.无状态协议不要求服务器在多个请求期间保留关于每个用户的信息或状态.

但是,一些Web应用程序可能必须跟踪用户在页面之间的进度,例如,当需要Web服务器为用户定制Web页面的内容时.这些案件的解决方案包括:

  • 使用HTTP cookie.
  • 服务器端会话,
  • 隐藏变量(当前页面包含表单时),和
  • 使用URI编码的参数进行URL重写,例如/index.php?session_id=some_unique_session_code.

使协议无状态的原因是服务器不需要跟踪多个请求的状态,而不是如果它想要的话它不能这样做.这简化了客户端和服务器之间的合同,并且在许多情况下(例如通过CDN提供静态数据)最小化了需要传输的数据量.如果要求服务器维护客户端访问的状态,则发出和响应请求的结构将更加复杂.实际上,模型的简单性是其最大的特征之一.


Rah*_*thi 21

因为无状态协议不要求服务器在多个请求期间保留关于每个通信伙伴的会话信息或状态.

HTTP是无状态协议,这意味着一旦事务结束,浏览器和服务器之间的连接就会丢失.

  • 在服务器上保存信息并不意味着连接始终存在. (17认同)
  • 看看这篇文章: - http://www.ecst.csuchico.edu/~amk/foo/advjava/notes/servlets/Cookies.html (3认同)
  • 但是,HTTP可以使用cookie在服务器中保存信息.HTTP wih keep-alive不会在每个请求上关闭连接. (2认同)

Zam*_*col 10

现代 HTTP 是有状态的。旧时代的 HTTP 是无状态的。

在 1994 年 Netscape 发明 cookies 和 HTTPS 之前,HTTP 可以被认为是无状态的。随着时间的推移,出于性能和安全性等多种原因,正式添加了许多有状态组件。但有状态的添加只是添加,所以仍然通俗地说 HTTP 是无状态的,因为原始核心明确寻求无状态。

虽然 HTTP/1 最初寻求无状态,但许多 HTTP/2 组件正是有状态的定义。 HTTP/2 放弃了无状态目标。有状态组件不再是“添加”,而是在 HTTP/2 标准的核心中定义有状态组件。在HTTP/2 规范 (RFC 7540)中,有125 次引用“状态”零次引用“无状态”

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

  • HTTP/2 RFC 明确指出“标头压缩是有状态的。
  • HTTP/2流标识符的目的是状态。(整个部分专门针对不同的状态。)
  • 建立流标识符的HTTP/2标头是有状态的。(仅来自 RFC 的一个示例:“HEADERS 帧可以在处于“空闲”、“保留(本地)”、“开放”或“半关闭(远程)”状态的流上发送 ”)
  • HTTP/2帧是有状态的。RFC 中的一个例子是:“特定帧类型的传输可以改变连接的状态。”
  • Cookie 是有状态的,该规范的标题是“HTTP状态管理机制”(RFC 6265)
  • HTTPS 存储密钥状态,是有状态的。另请注意,HTTPS 所需的 CA 系统的全部要点是状态管理。
  • HTTP 身份验证需要状态。(这一点太明显了,以至于被忽视了。)
  • Web 存储是有状态的。(这一点太明显了,以至于被忽视了。)
  • HTTP 缓存是有状态的。根据定义,缓存是有状态的。(这一点太明显了,以至于被忽视了。)
  • 机会加密是有状态的。
  • URL 参数是有状态的。这就是 1994 年第一个正式的有状态机制(Cookie)之前应用程序完成状态的方式。即使不使用任何其他有状态 HTTP 功能,如果有状态地使用 URL 参数,该 HTTP 应用程序也是有状态的。

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

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

HTTP/2 是一种有状态协议,但您的 HTTP/2 应用程序可以忽略有状态功能以保持无状态性。

如果尝试无状态地使用需要状态的现有 HTTP/1 和 HTTP/2 应用程序,它们将会崩溃。例如,如果禁用 cookie,则可能无法登录某些 HTTP/1.1 网站,从而破坏应用程序。假设特定的 HTTP/1 或 HTTP/2 应用程序是无状态的可能并不安全。

长话短说:

有状态机制是后来在原始无状态标准之上添加的 HTTP 内容。HTTP/1 通俗地说是无状态的,尽管在实践中我们使用标准化的有状态机制,例如 cookies 和缓存。与 HTTP/1 不同,HTTP/2 从一开始就在其标准中定义了有状态组件。特定的 HTTP/2 应用程序可以使用 HTTP/2 功能的子集来维持无状态性,但协议本身预期状态是常态,而不是例外。错误的“HTTP 是无状态的”是古老的教条,与 HTTP 的现代有状态现实和理论相去甚远,实际上,您在日常生活中使用有状态的 HTTP。


小智 5

如果协议 HTTP 被指定为 State full 协议,则浏览器窗口使用单个连接与 Web 服务器进行通信,以获取给予 Web 应用程序的多个请求。这使浏览器窗口有机会长时间参与浏览器窗口和 Web 服务器之间的连接并保持它们长时间处于空闲状态。这可能会导致即使客户端中的大部分连接都处于空闲状态,但仍会达到 Web 服务器的最大连接数。


小智 5

HTTP是无国籍的。TCP是有状态的。没有所谓的HTTP connection,只有HTTP requestHTTP response。我们不需要维护任何东西来制作另一个HTTP request. “保持活动”的连接标头意味着TCP将被后续请求和响应重用,而不是始终HTTP断开连接并重新建立连接。TCP


Mob*_*war 5

HTTP之所以称为无状态协议,是因为每个请求都是独立执行的,无需知道之前执行过的请求,这意味着一旦事务结束,浏览器与服务器之间的连接也会丢失。

使协议成为无状态的原因在于,在其原始设计中,HTTP是一种相对简单的文件传输协议:

  1. 请求以URL命名的文件,
  2. 得到文件作为响应,
  3. 断开。

即使在同一客户端,一个连接与另一个连接之间也没有保持任何关系。这简化了客户端和服务器之间的合同,并且在许多情况下使需要传输的数据量最小化。