HTTP 和会话答案

【问题标题】：HTTP and SessionsHTTP 和会话
【发布时间】：2012-12-07 14:11:23
【问题描述】：

我刚刚在http://www.w3.org/Protocols/rfc2616/rfc2616.html 浏览了http 1.1 的规范，并遇到了一个关于连接http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8 的部分，上面写着

" HTTP/1.1 和早期版本的 HTTP 之间的一个显着区别是持久连接是任何 HTTP 连接的默认行为。也就是说，除非另有说明，客户端应该假设服务器将保持持久连接，即使在服务器的错误响应之后。

持久连接提供了一种机制，通过该机制客户端和服务器可以发出 TCP 连接关闭的信号。该信令使用 Connection 头字段（第 14.10 节）进行。一旦发出关闭信号，客户端不得在该连接上发送任何更多请求。 "

然后我还浏览了https://www.rfc-editor.org/rfc/rfc2965 上有关 http 状态管理的部分，该部分在其第 2 部分中说

“目前，HTTP 服务器响应每个客户端请求，而不将该请求与先前或后续请求相关联；”

RFC 2616 中关于需要建立持久连接的部分还说，在每次客户端希望获取 url 时，在持久连接之前，它必须为每个新请求建立一个新的 TCP 连接。

现在我的问题是，如果我们在 http/1.1 中有持久连接，那么如上所述，客户端不需要为每个新请求建立新连接。它可以通过同一连接发送多个请求。因此，如果服务器知道每个后续请求都来自同一个连接，那么该请求是否来自同一个客户端不是很明显吗？因此这是否不足以维持状态，这是否足以让服务器了解请求来自同一个客户端？在这种情况下，为什么还需要一个单独的状态管理机制呢？

【问题讨论】：

标签： http session web session-state stateful

【解决方案1】：

没有。例如，请求路径中可能有一个中间（例如代理或反向代理），用于聚合来自多个 TCP 连接的请求。

见http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-21.html#intermediaries。

【讨论】：

能否请您详细说明一下.. 可以举个例子。

【解决方案2】：

基本上，是的，这是有道理的，但 HTTP 持久连接用于消除连接处理的管理 TCP/IP 开销（例如连接/断开连接/重新连接等）。这并不是要说明通过连接移动的数据的状态，这就是您所说的。

【讨论】：

好的，谢谢您的回复。我理解您的意思。但实际上这本身就是我的问题，“为什么不能说明数据在连接中移动的状态？”看看数据是否是通过同一个连接发送的，这显然意味着它是由实际打开连接的同一个客户端发送的。因此，现在对于每个后续请求（通过相同的连接），都知道该请求来自同一个客户端。如果我没记错的话，正是出于这个原因，我们实际上需要有单独的状态管理机制，而 http 是一个无状态协议。
那么，客户端将如何通知主机正在发送新数据？ HTTP 不是流数据协议，它是基于连接的。因此，根据定义，每个连接（即使它纯粹是持久物理连接上的逻辑连接）都需要以标头、主体和结尾开头。我知道你要做什么，并且无论如何，推出你自己的协议来做到这一点。但就目前而言，系统中已经没有太多开销，这就是人们不使用其他任何东西的原因：因为这种方式工作得很好。
谢谢它现在更有意义了。我得从现在开始处理它。再次感谢。