HTTP和会话 [英] HTTP and Sessions

查看:142
本文介绍了HTTP和会话的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我刚刚在 http://www.w3上查看了http 1.1的规范。 org / Protocols / rfc2616 / rfc2616.html 并遇到了一个关于连接的部分 http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8 表示



之间的显着差异HTTP / 1.1和早期版本的HTTP是持久连接是任何HTTP连接的默认行为。也就是说,除非另有说明,否则客户端应该假设服务器将保持持久连接,即使在服务器的错误响应之后也是如此。 / p>

持久连接提供了一种机制,通过该机制,客户端和服务器可以发出TCP连接信号的信号。此信令使用Connection头字段进行(第14.10节)。已经发出关闭信号,客户端不得再发送任何请求在那个连接上。



然后我还在 http://tools.ietf.org/html/rfc2965 在第2节中说



目前,HTTP服务器响应每个客户端请求没有将该请求与先前或后续请求相关联;



有关在RFC 2616中需要持久连接的部分也表示在每次持久连接之前客户希望获取一个网址,它必须为每个新请求建立一个新的TCP连接。



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

解决方案

基本上,是的,它会有意义,但是HTTP持久连接用于消除连接处理的管理TCP / IP开销(例如连接/断开/重新连接等)。它并不是要说明在连接中移动的数据的状态,这就是你所说的。


I just went through the specification of http 1.1 at http://www.w3.org/Protocols/rfc2616/rfc2616.html and came across a section about connections http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8 that says

" A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior of any HTTP connection. That is, unless otherwise indicated, the client SHOULD assume that the server will maintain a persistent connection, even after error responses from the server.

Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling takes place using the Connection header field (section 14.10). Once a close has been signaled, the client MUST NOT send any more requests on that connection. "

Then I also went through a section on http state management at http://tools.ietf.org/html/rfc2965 that says in its section 2 that

"Currently, HTTP servers respond to each client request without relating that request to previous or subsequent requests;"

A section about the need to have persistent connections in the RFC 2616 also said that prior to persistent connections every time a client wished to fetch a url it had to establish a new TCP connection for each and every new request.

Now my question is, if we have persistent connections in http/1.1 then as mentioned above a client does not need to make a new connection for every new request. It can send multiple requests over the same connection. So if the server knows that every subsequent request is coming over the same connection, would it not be obvious that the request is from the same client? And hence would this just not suffice to maintain the state and would this just nit be enough for the server to understand that the request was from the same client ? In this case then why is a separate state management mechanism required at all ?

解决方案

Basically, yes, it would make sense, but HTTP persistent connections are used to eliminate administrative TCP/IP overhead of connection handling (e.g. connect/disconnect/reconnect, etc.). It is not meant to say anything about the state of the data moving across the connection, which is what you're talking about.

这篇关于HTTP和会话的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆