注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

NET START HERE

研究C/C++、网络/通信/协议编程、网络安全、软件安全

 
 
 

日志

 
 

HTTP Keep-Alive 是什么?如何工作(What's HTTP Keep-Alive, how it works?)  

2011-05-11 21:41:47|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
Http Keep-Alive seems to be massively misunderstood. Here's a short description of how it works, under both 1.0 and 1.1, with some added information about how Java handles it.

Http operates on what is called a request-response paradigm. This means that a _client_ generates a request for information, and passes it to the server, which answers it. In the original implementation of HTTP, each request created a new socket connection to the server, sent the request, then read from that connection to get the response.

This approach had one big advantage - it was simple. Simple to describe, simple to understand, and simple to code. It also had one big disadvantage - it was slow. So, keep-alive connections were invented for HTTP.
HTTP/1.0

Under HTTP 1.0, there is no official specification for how keepalive operates. It was, in essence, tacked on to an existing protocol. If the browser supports keep-alive, it adds an additional header to the request:

Connection: Keep-Alive

Then, when the server receives this request and generates a response, it also adds a header to the response:

Connection: Keep-Alive

Following this, the connection is NOT dropped, but is instead kept open. When the client sends another request, it uses the same connection. This will continue until either the client or the server decides that the conversation is over, and one of them drops the connection.
HTTP/1.1

Under HTTP 1.1, the official keepalive method is different. All connections are kept alive, unless stated otherwise with the following header:

Connection: close

The Connection: Keep-Alive header no longer has any meaning because of this.

Additionally, an optional Keep-Alive: header is described, but is so underspecified as to be meaningless. Avoid it.
Not reliable

HTTP is a stateless protocol - this means that every request is independent of every other. Keep alive doesn抰 change that. Additionally, there is no guarantee that the client or the server will keep the connection open. Even in 1.1, all that is promised is that you will probably get a notice that the connection is being closed. So keepalive is something you should not write your application to rely upon.
KeepAlive and POST

The HTTP 1.1 spec states that following the body of a POST, there are to be no additional characters. It also states that "certain" browsers may not follow this spec, putting a CRLF after the body of the POST. Mmm-hmm. As near as I can tell, most browsers follow a POSTed body with a CRLF. There are two ways of dealing with this: Disallow keepalive in the context of a POST request, or ignore CRLF on a line by itself. Most servers deal with this in the latter way, but there's no way to know how a server will handle it without testing.
Java abstraction - client side

On the client side, Java abstracts the notion of a keepalive request away from the programmer. The HttpURLConnection class implements keepalive automatically, without intervention being either required or possible on the part of the programmer. It does this through an internal cache of client connections, which is maintained as one of the implementation details of the class. Incidentally, this means that keepalive is an implementation detail of the Javasoft class library, which may or may not be available in other class libraries.
Java abstraction - server side

On the server side, Java again abstracts out the notion of a keepalive request. The HttpServlet, HttpServletRequest, and HtppServletResponse classes implement keepalive automatically. In this case, however, some intervention is possible. As mentioned in the KeepAliveServlet that comes with the JavaWebServer, the actual keepalive behavior that occurs depends on two factors: setting content length, and size of output. If content length is set as part of the response, keepalive will be used if the client supports it. If content length is not set, the servlet implementation will attempt to buffer the response to determine it's content length. If the buffering is successful, keepalive will be used. In the Javasoft implementation, a 4k buffer is used. This means that if the content length is not set, and the amount of data returned is over 4k, keepalive will not be used. As with HttpURLConnection, this is an implementation detail of the Javasoft class library, which may or may not be available in other class libraries.


--
人人都在进步,我们没有理由停止不前!


 
  评论这张
 
阅读(3508)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017