HTTP的无状态特性如何使系统具有可伸缩性？

菲尔丁关于“体系结构风格和基于网络的软件体系结构设计”的论文在第78-79页指出，客户端和服务器之间的通信应该是无状态的。它还说，“这种约束导致了可见性、可靠性和可伸缩性的特性。” 此外，它还说，“由于不必在请求之间存储状态，服务器组件可以快速释放资源，因此可扩展性得到了改进，并且由于服务器不必跨请求管理资源使用，因此进一步简化了实现。”

现在，我们几乎在所有其他应用程序中都需要“有状态”，那么HTTP的无状态特性在可伸缩性方面如何仍然有益呢

我们非常感谢您在这方面提供的任何帮助。谢谢

如今，我们几乎在所有其他应用程序中都需要“有状态”

我们在“大多数”应用程序中确实如此。有许多应用程序只为某些持久性存储提供CRUD接口

然而，这与上述应用程序的体系结构，或者更确切地说，与它们与后端的通信方式关系不大。一个客户端，通常承载一些用户界面，它通过某个层与某个服务对话，以便让后端执行一些操作（CRUD或RPC）

这是关于与该服务之间的通信。这就是无状态。这意味着从客户端到服务的每条消息都包含足够的信息，使服务能够执行所需的操作。这就是REST的全部含义

这意味着服务器不需要知道任何关于客户机连接来源的信息。从客户端到服务器不需要永久连接。连接或此连接所需的会话中没有隐藏的“元数据”

这意味着您可以轻松地水平扩展：当您的服务器不断达到其客户端连接限制或其他资源限制时，您只需添加另一台服务器，就可以为更多的客户端提供服务

---

现在，由于HTTP本质上是无状态的（除了使用Cookie和服务器端存储的会话模拟之外），它最终成为REST服务的传输层。

这与编程几乎无关。@black这就是为什么它被发布在“HTTP”中的原因你从哪里读到HTTP是为无状态下的可伸缩性而设计的？@CodeCaster-Fielding博士论文在第78-79页指出，客户端和服务器之间的通信应该是无状态的。它还说，“这种约束导致了可见性、可靠性和可伸缩性的属性。”“可伸缩性得到了改善，因为不必在请求之间存储状态，服务器组件可以快速释放资源，并进一步简化了实现，因为服务器不必跨请求管理资源使用。”现在，我们几乎在所有其他应用程序中都需要“有状态”，那么HTTP的无状态特性如何仍然有益呢？您能将其编辑成问题吗？