http长连接和短连接

HTTP实现长连接

HTTP是无状态的

HTTP1.1和HTTP1.0相比較而言，最大的差别就是添加�了持久连接支持(貌似最新的 http1.0 能够显示的指定 keep-alive),但还是无状态的，或者说是不能够信任的。

Connection:keep-alive

TCP连接在发送后将仍然保持打开状态，于是，浏览器能够继续通过同样的连接发送请求。保持连接节省了为每一个请求建立新连接所需的时间，还节约了带宽。

Http Keep-Alive seems to be massively misunderstood. Here's a short description of how it works, under both1.0 and 1.1

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:

ConnectionKeep-Alive

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

ConnectionKeep-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 ConnectionKeep-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’t 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应用

client用apache的commons-httpclient来运行method 。

tomcat中能够设置：maxKeepAliveRequests

The maximum number of HTTP requests which can be pipelined until the connection is closed by the server. Setting this attribute to 1 will disable HTTP/1.0 keep-alive, as well as HTTP/1.1 keep-alive and pipelining. Setting this to -1 will allow an unlimited amount of pipelined or keep-alive HTTP requests. If not specified, this attribute is set to 100.

传统的轮询技术对server的压力非常大，而且造成带宽的极大浪费。假设改用ajax轮询，能够降低带宽的负荷（由于server返回的不是完整页面），可是对server的压力并不会有明显的降低。
而推技术（push）能够改善这样的情况。但由于HTTP连接的特性（短暂，必须由client发起），使得推技术的实现比較困难，常见的做法是通过延长http连接的寿命，来实现push。
接下来自然该讨论怎样延长http连接的寿命，最简单的自然是死循环法：
【servlet代码片段】
public void doGet(Request req, Response res) {
PrintWriter out = res.getWriter();
……
正常输出页面
……
out.flush();
while (true) {
out.print("输出更新的内容");
out.flush();