HTTP有HTTP cookie。cookie允许服务器跟踪用户状态、连接数、最后一个连接等。
HTTP具有持久连接(Keep-Alive),可以从同一个TCP连接发送多个请求。
HTTP有HTTP cookie。cookie允许服务器跟踪用户状态、连接数、最后一个连接等。
HTTP具有持久连接(Keep-Alive),可以从同一个TCP连接发送多个请求。
即使多个请求可以通过同一个HTTP连接发送,服务器也不会为它们通过同一个套接字到达附加任何特殊含义。这完全是一个性能问题,目的是尽量减少为每个请求重新建立连接所花费的时间/带宽。
就HTTP而言,它们仍然是独立的请求,并且必须包含足够的信息来满足请求。这就是“无国籍”的本质。如果没有服务器所知道的一些共享信息(在大多数情况下是cookie中的会话ID),请求将不会相互关联。
从维基百科:
HTTP is a stateless protocol. A stateless protocol does not require the server to retain information or status about each user for the duration of multiple requests. But some web applications may have to track the user's progress from page to page, for example when a web server is required to customize the content of a web page for a user. Solutions for these cases include: the use of HTTP cookies. server side sessions, hidden variables (when the current page contains a form), and URL-rewriting using URI-encoded parameters, e.g., /index.php?session_id=some_unique_session_code.
What makes the protocol stateless is that the server is not required to track state over multiple requests, not that it cannot do so if it wants to. This simplifies the contract between client and server, and in many cases (for instance serving up static data over a CDN) minimizes the amount of data that needs to be transferred. If servers were required to maintain the state of clients' visits the structure of issuing and responding to requests would be more complex. As it is, the simplicity of the model is one of its greatest features.
如果协议HTTP被指定为状态全协议,浏览器窗口将使用单一连接与web服务器通信,以便向web应用程序发送多个请求。这使浏览器窗口有机会长时间地连接浏览器窗口和web服务器,并使它们长时间处于空闲状态。这可能会导致在客户端大部分连接空闲的情况下,web服务器的连接达到最大值。
HTTP是无连接的,这是HTTP是无状态协议的直接结果。服务器和客户端只有在当前请求期间才能相互了解。后来,他们都忘了对方。由于协议的这种性质,无论是客户端还是浏览器都不能在网页上的不同请求之间保留信息。
HTTP无状态。TCP是有状态的。 没有所谓的HTTP连接,只有HTTP请求和HTTP响应。我们不需要维护任何东西来发出另一个HTTP请求。 “keep-alive”连接头意味着TCP将被后续的HTTP请求和响应重用,而不是一直断开和重新建立TCP连接。
HTTP被称为无状态协议,因为每个请求都是独立执行的,不知道在它之前执行的请求,这意味着一旦事务结束,浏览器和服务器之间的连接也会丢失。
使协议无状态的原因是,在最初的设计中,HTTP是一个相对简单的文件传输协议:
请求一个以URL命名的文件, 获取响应文件, 断开连接。
一个连接和另一个连接之间没有保持任何关系,即使来自同一个客户机。这简化了客户端和服务器之间的契约,并且在许多情况下最大限度地减少了需要传输的数据量。
什么是无状态?
一旦发出请求并将响应呈现回客户端,连接将被丢弃或终止。服务器将忘记所有关于请求者的信息。
为什么无状态? ?
web选择使用无状态协议。这是一个天才的选择,因为web的最初目标是允许文档(网页)被提供给非常大的用户。人们使用非常基本的硬件作为服务器。
维护长时间运行的连接将非常耗费资源。
如果web选择了有状态协议,那么为了维护访问者的连接,服务器上的负载将会增加。
我认为有人为无状态概念选择了一个非常不幸的名字,这就是造成整个误解的原因。它不是关于存储任何类型的资源,而是关于客户端和服务器之间的关系。
客户:我把所有的资源都保留在我这边,把所有需要处理的重要项目的“清单”发给你。做好你的工作。
服务员:好的。让我来负责筛选哪些是重要的,然后给你适当的答复。
这意味着服务器是客户端的“奴隶”,在每次请求后都必须忘记他的“主人”。实际上,STATELESS仅指服务器的状态。
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3
现代HTTP是有状态的。以前的HTTP是无状态的。
在Netscape在1994年发明cookie和HTTPS之前,HTTP可以被认为是无状态的。随着时间的推移,由于各种原因,包括性能和安全性,添加了许多有状态组件。但是有状态的添加仅仅是添加而已,所以人们仍然通俗地说HTTP是无状态的,因为核心显式地寻求无状态。
虽然HTTP/1最初寻求无状态,但许多HTTP/2组件正是有状态的定义。HTTP/2放弃了无状态目标。有状态组件不再是“附加组件”,而是在HTTP/2标准的核心中定义有状态组件。
以下是有状态HTTP/1和HTTP/2组件的有限而不详尽的列表:
Cookies, named "HTTP State Management Mechanism" by the RFC. HTTPS, which stores keys thus state. HTTP authentication requires state. Web Storage. HTTP caching is stateful. The very purpose of the stream identifier is state. It's even in the name of the RFC section, "Stream States". Header blocks, which establish stream identifiers, are stateful. Frames, which reference stream identifiers, are stateful. Header Compression, which the HTTP RFC explicitly says is stateful, is stateful. Opportunistic encryption is stateful.
HTTP/2 RFC的5.1节“流状态”是HTTP/2标准定义的有状态机制的一个很好的例子。第5.3.4节甚至被命名为“优先级状态管理”。
web应用程序将HTTP/2视为无状态协议是否安全?
HTTP/2是一个有状态的协议,但这并不意味着您的HTTP/2应用程序不能是无状态的。您可以选择不对无状态HTTP/2应用程序使用有状态的特性。
现有的需要状态的HTTP/1和HTTP/2应用程序如果试图无状态地使用它们,将会中断。例如,如果cookies被禁用,可能无法登录到一些HTTP/1.1网站,从而破坏应用程序。假设特定的HTTP/1或HTTP/2应用程序是无状态的可能是不安全的。
TL; diana:
有状态机制是后来在原始无状态标准之上添加的HTTP。虽然在实践中我们使用标准化的有状态机制,如cookie、TLS和缓存,但口头上说HTTP/1是无状态的。与HTTP/1不同,HTTP/2从一开始就在其标准中定义了有状态组件。一个特定的HTTP/2应用程序可以使用HTTP/2特性的子集来保持无状态,但是协议本身预期状态是常态,而不是异常。
错误的“HTTP是无状态的”是旧的教条,与现代HTTP的有状态现实相去甚远。