Http 无状态web应用程序，城市传奇？

我现在正在努力理解

基于令牌的身份验证

，它声称是一种

无状态身份验证

方法。我遇到了无状态web应用程序的概念

以下是我读到的一些帖子：

• （暂时未有回应）

一开始，我对这个想法很兴奋。但是我越来越认为无状态的是一个伪命题

例如，假设我们使用客户端存储的令牌进行身份验证，我们如何统计在线用户（假设没有日志）？我们把代币存储在DB中好吗？这不意味着我们在服务器上存储状态信息吗？而且，数据库中的普通用户信息，如姓名、年龄等，是否也是某种状态信息

我认为真正的问题不是使web应用程序无状态，而是使web应用程序正确地处理状态信息，从而不会危及可伸缩性

这取决于如何解释无状态一词：

Web应用没有状态

或者web应用程序不存储状态本身

我更喜欢2，因为总有一些不可避免的全球状态（引用@deceze对其答案的评论）。无论我们将状态信息存储为HTML5Web存储、HTTP头、隐藏表单字段或Cookie，状态仍然存在。只是它存储在服务器以外的其他位置

我错过了什么好东西吗？有谁能解释一下，让我从这场精神斗争中解脱出来

添加1

只要读一下Leonard Richardson写的那本书就行了。在第4章的

无状态

一节末尾，它将状态分为

应用程序状态

和

资源状态

。因此，我前面提到的普通用户信息和数据（如图像等）可以归类为

资源状态

。而

无状态

所指的是

应用程序状态

。因此，在服务器上存储

资源状态

不会破坏无状态代码

---

但这本书也提到了这样一种场景，即

应用程序密钥用于限制用户可以调用web服务的次数。

它承认这样的信息不能存储在客户端。必须将其存储在服务器端打破了无状态代码，并引入了会话亲和性问题它声称无状态可以避免会话亲和性问题，但没有解释如何解决。我真的不知道无状态如何处理这种情况。任何人都可以在这里解释一下吗？

好的，我认为无状态web应用程序这个术语没有任何意义。有意义的是无状态协议。无状态协议是一种独立处理每个请求的协议

因此，在您的情况下，如果您在每个请求中发送一个auth令牌，那么它就是无状态的。这就是HTTP身份验证的工作原理

另一方面，如果您只发送一次身份验证令牌，并且每个连续请求不必发送（例如，因为服务器知道此TCP连接已通过身份验证），则这意味着每个请求都依赖于身份验证请求。这使协议具有状态

无状态协议更容易扩展，更容易代理，等等

现在对于web应用程序来说，这个术语可能有意义，也可能没有意义，这取决于定义。但我不知道有什么合理的理由

---

旁注：有状态/无状态与客户端和服务器之间共享数据无关。

我不认为无状态身份验证和无状态应用程序以您认为的方式相关；“无状态”一词在这里的两个不同上下文中使用

无状态身份验证是一种识别客户机身份的方法，无需携带来自先前客户机请求或交互的任何信息/状态，例如，与cookie不同

无状态web应用程序？当然，它们是可能的，但这完全取决于是否必须持久化用户数据，也就是说，这实际上取决于所讨论的应用程序。

状态实际上只是指客户端和服务器之间的状态。当然，服务器将存储数据，从技术上讲，您可以将服务器上任何数据的修改视为“改变状态”。因此，这种意义上的“无状态”应用程序绝对没有实际意义

无状态”指的是服务器在任何特定时间是否处于允许特定客户端向其发送特定请求的状态。

考虑：对于传统的基于cookie的登录会话，服务器仅处于在有限的时间窗口内接受来自客户端的请求的状态；只要当前会话有效。客户无法预测这需要多长时间。任何时候，客户端的请求都可能失败，因为服务器上的某些状态超时。在这种情况下，客户端需要通过再次登录来重置服务器的状态

这与基于令牌的身份验证形成对比。令牌必须无限期有效。它本质上是用户名和密码的替代。为了便于讨论，假设客户机在每个请求中都发送用户名和密码。这意味着每个请求都可以根据其自身的优点进行身份验证，而不需要服务器处于特定的时间“状态”

使用令牌而不是用户名和密码的原因有两个：

您可以使用同一帐户授权多个客户端，但每个客户端都具有各自管理的凭据

您不希望在每个请求中来回发送“主密码”

当然，服务器需要跟踪创建的令牌，并在每个请求中针对某个数据库进行身份验证。这是一个无关的实现细节。这不需要n