即使多个请求可以通过同一个HTTP连接发送，服务器也不会为它们通过同一个套接字到达附加任何特殊含义。这完全是一个性能问题，目的是尽量减少为每个请求重新建立连接所花费的时间/带宽。

就HTTP而言，它们仍然是独立的请求，并且必须包含足够的信息来满足请求。这就是“无国籍”的本质。如果没有服务器所知道的一些共享信息(在大多数情况下是cookie中的会话ID)，请求将不会相互关联。

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

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

从维基百科:

HTTP是无状态协议。无状态协议不需要 服务器用于保存每个用户的信息或状态

.多个请求的持续时间 但是一些web应用程序可能需要跟踪用户的进度 页面到页面，例如当需要定制web服务器时 为用户提供的网页内容。这些情况的解决方案 包括:< / p >

• 使用HTTP cookie。
• 服务器端会话，
• 隐藏变量(当当前页面包含表单时)，以及
• 使用uri编码的参数重写url，例如/index.php?session_id=some_unique_session_code。

使协议无状态的原因是服务器不是要求来跟踪多个请求的状态，并不是说如果它想这样做就不能这样做。这简化了客户端和服务器之间的契约，并且在许多情况下(例如通过CDN提供静态数据)可以最大限度地减少需要传输的数据量。如果服务器是要求来维护客户端访问的状态，那么发出和响应请求的结构将更加复杂。事实上，模型的简单性是其最大的特点之一。

如果协议HTTP被指定为状态全协议，浏览器窗口将使用单一连接与web服务器通信，以便向web应用程序发送多个请求。这使浏览器窗口有机会长时间地连接浏览器窗口和web服务器，并使它们长时间处于空闲状态。这可能会导致在客户端大部分连接空闲的情况下，web服务器的连接达到最大值。

HTTP是无连接的，这是HTTP是无状态协议的直接结果。服务器和客户端只有在当前请求期间才能相互了解。后来，他们都忘了对方。由于协议的这种性质，无论是客户端还是浏览器都不能在网页上的不同请求之间保留信息。

HTTP无状态。TCP是有状态的。 没有所谓的HTTP connection，只有HTTP request和HTTP response。我们不需要维护任何东西来创建另一个HTTP request。 “维生”连接头意味着TCP将被后续的HTTP请求和响应重用，而不是一直断开连接并重新建立TCP连接

HTTP被称为stateless protocol，因为每个请求都是独立执行的，不知道在它之前执行的请求，这意味着一旦事务结束，浏览器和服务器之间的连接也会丢失。

使协议成为stateless的原因是，在其原始设计中，HTTP是一个相对简单的file transfer protocol:

1. 请求一个以URL命名的文件，
2. 获取响应文件，
3. 断开连接。

一个连接和另一个连接之间没有保持任何关系，即使来自同一个客户机。这简化了客户端和服务器之间的契约，并且在许多情况下最大限度地减少了需要传输的数据量。

什么是无状态?

一旦发出请求并将响应呈现回客户端，连接将被丢弃或终止。服务器将忘记所有关于请求者的信息。

为什么无状态? ?

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组件的有限而不详尽的列表:

• 名为“HTTP状态管理机制”的cookie;RFC。
• HTTPS，它存储密钥的状态。
• HTTP身份验证需要状态。
• 网络存储。
• HTTP缓存是有状态的。
• 流标识符的目的就是状态。它甚至出现在RFC部分的名称中，“Stream states”。
• 建立流标识符的报头块是有状态的。
• 引用流标识符的帧是有状态的。
• HTTP RFC明确指出的报头压缩是有状态的，也是有状态的。
• 机会加密是有状态的。

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;博士:

有状态机制是后来在原始无状态标准之上添加的HTTP。虽然在实践中我们使用标准化的有状态机制，如cookie、TLS和缓存，但口头上说HTTP/1是无状态的。与HTTP/1不同，HTTP/2从一开始就在其标准中定义了有状态组件。一个特定的HTTP/2应用程序可以使用HTTP/2特性的子集来保持无状态，但是协议本身预期状态是常态，而不是异常。

错误的“HTTP是无状态的”;是过时的教条，与HTTP的现代有状态现实相去甚远。