无状态协议和有状态协议

Question

如何理解无状态协议和有状态协议？ HTTP是一种无状态协议，FTP是一种有状态协议。对于需要大量交互的Web应用程序，基础协议应该是有状态的。我的理解是正确的吗？

Answer 1

由于您在询问Web应用程序，因此该协议将始终为无状态 - Web协议为http（或https），这就是她写的全部内容。

我想你在想什么是在你的Web应用程序本身提供一个状态机制。典型的方法是在Web应用程序中为用户的会话创建一个唯一的标识符（一种或另一种形式的会话ID是常用的），它在浏览器和服务器之间来回切换。这通常是在一个cookie中完成的，尽管它可以完成，根据你的平台/框架，在URL上也有一些麻烦。

您的服务器端代码存储有状态信息（再次，通常称为用户的会话），但它希望使用sessionID来查找它。 http流量只是回传sessionID。只要该标识符存在，每个http事务就完全独立于所有其他事务，因此协议流量本身是无状态的。

Answer 2

基本上可以，但是你别无选择，只能使用HTTP服务于其中的网站。因此，你必须处理妥协以实现HTTP有状态，即会话管理。可能性基本上是通过URL中的每个呼叫传递一个会话ID，以便您知道何时与您之前讨论过的人聊天，或通过实现相同目标而不会混乱网址的Cookie。但是，大多数现代Web开发语言都会为您提供帮助;如果你的谷歌选择的语言+“会话管理”，你应该了解它是如何完成的。

Answer 3

HTTP是一种无状态协议，换句话说，服务器将会忘记与客户端/浏览器状态相关的所有内容。尽管Web应用程序使它看起来像有状态。

可以强制无状态协议表现得好像它是有状态的一样。如果服务器将状态发送给客户端，并且客户端每次都将其发送回服务器，则可以完成此操作。

有三种方法，这可能在HTTP来完成：

a）一个是Cookie，在这种情况下，状态发送和HTTP标头中返回。

b）第二个是URL扩展，在这种情况下，状态作为URL的一部分作为响应发送。

c）第三个是“隐藏的表单字段”，其中状态被发送到客户端作为响应的一部分，并且返回到服务器高可用性表单的隐藏数据的一部分

可扩展性和

HTTP变得如此之好的主要原因之一是其无状态。无状态协议简化了复制问题，因为状态本身不需要存储在服务器上。

有状态协议在逻辑上很重，可以可靠地在Internet中实现。无状态服务器也很容易扩展，而对于有状态服务器来说，可伸缩性是有问题的。无状态请求可以随时发送到任何节点，而Stateful则不是这种情况。

HTTP作为无状态协议增加了无状态Web应用程序的可用性，否则这些应用程序很难或不可能实现。如果有连接丢失，没有丢失的状态，简单的请求重新发送将解决问题。无状态请求也是可缓存的。

see more here

Answer 4

HTTP是一个无protocol.all基于Web的应用程序是无状态的。当向服务器发送请求时，客户端和服务器之间建立连接时，服务器将收到请求，处理该请求并返回响应，并关闭连接。如果发送了另一个请求，那么它将被视为新的请求，并建立新的连接。 为了使http有状态。我们使用会话管理技术。 ，以便它在处理当前request.i.e时使用来自先前请求的数据，例如，它为一系列客户端服务器交互使用相同的连接。 会话管理技术为： 1.隐式表单域 2.cookie 3.session 4.url-rewriting;

Answer 5

你的问题是现货，是的，如果你的银行网络交易是通过有状态连接完成的，那将是非常好的。唉，由于FTP中存在一个奇怪的错误，并且在BSD的部分套接字表中有12个套接字的限制，所以HTTP是无状态的。Marcus Ranum解释了这一切。here。

因此，HTTP抛弃了它从TCP继承的状态，并且必须以cookie的形式在应用程序层重新创建状态。结果是糟糕的互联网安全。

该Seif project建议修复所有使用“安全的JSON over TCP”。 DNS和证书颁发机构不是必需的。该协议和seifnode.js已完成，并在Github上获得了MIT许可证。

Answer 6

HTTP不会从TCP“继承”，而是将其用于传输。 HTTP使用TCP进行有状态连接，但会断开连接。稍后，如果需要，它将再次连接。所以，当你浏览一个网站时，你创建了许多不同的连接。这些连接中的每一个都是有状态的，但整个对话不是，因为你正在放弃与每个对话的连接。

From this link