HTTP 被认为是无状态的。也就是说，它不需要为传输数据而存储信息。
但是 HTTP 使用 TCP，它是面向状态的。
如果是这样，HTTP 是如何变成无状态的？
答案1
HTTP 并不关心（并且独立于）用于传输自身的任何低级协议，尽管它本身是无状态的。
传输技术可以是 TCP、Novell 的旧 SPX、SCTP 或您能想到的任何其他技术，HTTP 仍将以相同的方式工作。HTTP 确实需要流式传输或面向连接的协议（并且依赖于 URL 是否可解析），但不关心如何实现这一点。
这就是为什么分层模型或网络堆栈存在：应用层不需要关注较低层。
仅仅因为较低级别的协议是有状态的，并不意味着其上的任何东西都会自动变为有状态的或需要是有状态的。
HTTP 本身是无状态的。这意味着应用程序必须在 HTTP 之上实现另一层来建立状态。这通常通过会话 cookie 来实现。
答案2
“HTTP 是无状态的”意味着每个 HTTP 事务（请求-响应对）都可以独立于先前的请求-响应对的任何状态进行处理。
为了传输特定的请求-响应对，您需要一个能够将任意大的块传输到那里并传回任意大的块的协议，并且要在具有有限数据包大小的层上执行此操作，TCP 必须是有状态的。
但跨事务边界则没有状态。客户端可以断开连接并为下一个请求建立新连接。事实上，这是早期版本中唯一的选项，如果客户端不包含标头，它仍然会这样工作Connection: keep-alive。
下一个请求也可以轻松地由不同的服务器处理，而客户端永远不会知道，因为服务器不需要维护任何状态（除非应用程序在 HTTP 之上添加自己的状态，通常以会话的形式；负载平衡的随之而来的复杂性是其在 HTTP 上构建有状态协议的惩罚）。这在负载平衡繁忙的服务器中得到了利用。
答案3
HTTP 的“无状态”特性意味着这层，没有创建或使用任何状态信息。
您可以在几个实例中看到这一点，例如在 HTTP 身份验证中，凭据随每个请求一起发送，而持久连接实际上只是一种优化（即，如果我发送凭据，服务器会在请求之后忘记这些凭据，即使它保持连接打开）。
相比之下，基于 cookie 的登录机制是有状态的，但不是 HTTP 的一部分。
答案4
你必须把它理解成一组俄罗斯套娃（或者如果你愿意的话可以称之为盒子），每个套娃里面都承载着另一个套娃，这就是它的工作原理：TCP 在“内部”承载着 HTTP，但它并不关心它或它的功能。
为了全面了解情况，我建议阅读OSI 模型因为这样更清晰。
在 OSI 模型中，TCP 位于 HTTP 之下几层，每一层实际上对应不同的协议。
在我们的例子中，HTTP 位于表示层和应用层，而 TCP 位于传输层。或者，如果您使用 TCP/IP 模型，则 TCP 和 IP 协议都位于网络链路层，而 HTTP 位于应用层和表示层。