如何理解无状态协议和状态协议？ HTTP是无状态协议，FTP是有状态协议。对于需要大量交互的Web应用程序，底层协议应该是有状态的。我的理解是对的吗？
答案 0 :(得分：40)
HTTP是无状态协议，换句话说，服务器将忘记与客户端/浏览器状态相关的所有内容。虽然Web应用程序使其几乎看起来像有状态。
无状态协议可以被强制表现为有状态。如果服务器将状态发送到客户端，并且客户端每次都将其再次发送回服务器，则可以完成此操作。
在HTTP中有三种方法可以实现：
a）一个是cookie，在这种情况下，状态在HTTP头中发送和返回。
b）第二个是URL扩展，在这种情况下，状态作为响应发送为URL的一部分。
c）第三个是“隐藏表单字段”，其中状态作为响应的一部分发送到客户端，并作为表单隐藏数据的一部分返回到服务器
可扩展性和高可用性
HTTP扩展如此之好的一个主要原因是其无状态。无状态协议简化了复制问题，因为状态本身不需要存储在服务器上。
有状态的协议在互联网上可靠地实施在逻辑上很重要。无状态服务器也很容易扩展，而对于有状态服务器，可扩展性也存在问题。无状态请求可以随时发送到任何节点，而有状态则不是这种情况。
HTTP作为无状态协议增加了无状态Web应用程序的可用性，否则将很难或无法实现。如果连接丢失，则没有丢失的状态，简单的请求重发将解决问题。无状态请求也是可缓存的。
答案 1 :(得分：13)
由于您询问的是Web应用程序，因此该协议始终是无状态的 - Web的协议是http（或https），而这就是她写的所有内容。
我认为您正在考虑的是在Web应用程序本身中提供状态机制。典型的方法是在Web应用程序中创建用户会话的唯一标识符（一种或另一种形式的会话ID是常见做法），它在浏览器和服务器之间来回传递。这通常是在一个cookie中完成的，虽然它可以完成，根据您的平台/框架，在URL上也会有一些麻烦。
您的服务器端代码存储有状态信息（同样，通常称为用户会话），但是它希望使用sessionID来查找它。 http流量只是回传sessionID。只要该标识符在那里，每个http事务完全独立于所有其他事务，因此协议流量本身是无状态的。
答案 2 :(得分：4)
Anything that forgets whatever it did in past is stateless, such as http
Anything that can keep the history is statefull, such as database
Http是一种无状态协议，这就是为什么它会忘记用户信息的原因。
我们使用 jsonWebToken（JWT）将http设置为全状态协议，即，在每个发送到服务器的请求上，服务器将首先使用 JWT 验证用户。
答案 3 :(得分：3)
http是一种无状态协议。所有基于Web的应用程序都是无状态的。当请求发送到服务器时，在客户端和服务器之间建立连接，服务器将接收请求，处理请求并发回响应，并且连接关闭。如果发送了另一个请求，则将其视为新请求，并建立新连接。 为了使http有状态。我们使用会话管理技术。 因此，它在处理当前请求时使用来自先前请求的数据。即，它对一系列客户端服务器交互使用相同的连接。 会话管理技术是： 隐藏的形式领域 2.cookie 3.session 4.url重写;
答案 4 :(得分：2)
您的问题是现实的，是的，如果您与银行的网络交易是通过有状态连接完成的，那就太棒了。唉，由于FTP中的一个奇怪的错误和1989年BSD的部分套接字表中的12个套接字限制，HTTP是无状态的.Marcus Ranum解释了这一切here。
因此，HTTP会抛弃从TCP继承的状态，并且必须以cookie的形式在应用程序层重新创建状态。结果是蹩脚的互联网安全。
Seif project建议使用“基于TCP的安全JSON”解决所有问题。不需要DNS和证书颁发机构。协议和seifnode.js已完成，并在github上获得MIT许可证。
答案 5 :(得分：1)
HTTP不会从TCP“继承”，而是将其用于传输。 HTTP使用TCP进行有状态连接，但随后断开连接。如果需要，稍后它将再次连接。因此，当您浏览网站时，您会创建许多不同的连接。这些连接中的每一个都是有状态的，但整个对话不是，因为你正在放弃与每个对话的连接。
答案 6 :(得分：0)
基本上是的，但你别无选择，只能使用HTTP，这就是服务网站的地方。所以你必须处理妥协才能使HTTP成为有状态的，即会话管理。可能性基本上是通过URL中的每个调用传递会话ID，因此您知道何时与之前谈过的人或通过cookie进行交谈，实现相同的目标而不会使网址混乱。但是，大多数现代Web开发语言都会为您处理;如果你谷歌选择你选择的语言+“会话管理”，你应该了解它是如何完成的。