HTTP是无状态的 
也就是说，浏览器和server每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。假设client浏览器訪问的某个HTML或其它类型的Web页中包括有其它的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个HTTP会话

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

假设浏览器或者server在其头信息添?了这行代码

Connection:keep-alive

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

实现长连接要client和服务端都支持长连接。

假设webserver端看到这里的值为“Keep-Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行持久连接），它就能够利用持久连接的长处，当页面包括多个元素时（比如Applet，图片），显著地降低下载所须要的时间。要实现这一点， webserver须要在返回给clientHTTP头信息中发送一个Content-Length（返回信息正文的长度）头，最简单的实现方法是：先把内容写入ByteArrayOutputStream，然 后在正式写出内容之前计算它的大小

不管client浏览器 (Internet Explorer) 还是 Web server具有较低的 KeepAlive 值，它都将是限制因素。比如，假设client的超时值是两分钟，而 Web server的超时值是一分钟，则最大超时值是一分钟。client或server都能够是限制因素

在header中添? --Connection:keep-alive 
在HTTp协议请求和响应中添?这条就能维持长连接。 
再封装HTTP消息数据体的消息应用就显的很easy易用

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:

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’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.

解释1

所谓长连接指建立SOCKET连接后无论是否使用都保持连接，但安全性较差，   
所谓短连接指建立SOCKET连接后发送后接收完数据后立即断开连接，一般银行都使用短连接

解释2

长连接就是指在基于tcp的通讯中，一直保持连接，无论当前是否发送或者接收数据。   
而短连接就是仅仅有在有数据传输的时候才进行连接，客户－server通信/数据传输完成就关闭连接。

解释3

长连接和短连接这个概念好像仅仅有移动的CMPP协议中提到了，其它的地方没有看到过。   
通信方式   
各网元之间共同拥有两种连接方式：长连接和短连接。所谓长连接，指在一个TCP连接上能够连续发送多个数据包，在TCP连接保持期间，假设没有数据包发送，须要两方发检測包以维持此连接。短连接是指通信两方有数据交互时，就建立一个TCP连接，数据发送完毕后，则断开此TCP连接，即每次TCP连接仅仅完毕一对 CMPP消息的发送。   
现阶段，要求ISMG之间必须採用长连接的通信方式，建议SP与ISMG之间採用长连接的通信方式。

解释4

短连接：比方http的，仅仅是连接、请求、关闭，过程时间较短,server若是一段时间内没有收到请求就可以关闭连接。   
长连接：有些服务须要长时间连接到server，比方CMPP，一般须要自己做在线维持。

近期在看“server推送技术”，在B/S结构中，通过某种magic使得client不须要通过轮询即能够得到服务端的最新信息（比方股票价格），这样能够节省大量的带宽。

    而推技术（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();

                Thread.sleep(3000);

          }

      }

     假设使用观察者模式则能够进一步提高性能。

     可是这样的做法的缺点在于client请求了这个servlet后，webserver会开启一个线程运行servlet的代码，而servlet由迟迟不肯结束，造成该线程也无法被释放。于是乎，一个client一个线程，当client数量添加?时，server依旧会承受非常大的负担。

     要从根本上改变这个现象比較复杂，眼下的趋势是从webserver内部入手，用nio（JDK 1.4提出的java.nio包）改写request/response的实现，再利用线程池增强server的资源利用率，从而解决问题，眼下支持这一非J2EE官方技术的server有Glassfish和Jetty（后者仅仅是听说，没实用过）。

     眼下也有一些框架/工具能够帮助你实现推功能，比方pushlets。只是没有深入研究。

     这两天准备学习一下Glassfish中对Comet（彗星：某人给server推送技术起的名字）的支持，呵呵。