长连接

 长连接应该翻译为keep-alive connection，或者是 persistent connection，而不是我们直译为Long Connection，否则你在英文文档中不好查到这方面的资料的，以下是维基百科针对长连接的说明：
    http://en.wikipedia.org/wiki/HTTP_persistent_connection
    以下是我的部分翻译：

     HTTP长连接（持久化连接）
        以下是一张连接与接连接的区别

               
HTTP长连接，英文的说话有这么几种：HTTP persistent connection、HTTP keep-alive或者 HTTP connection reuse，是用来在一个TCP连接的基础之上，发送多个HTTP请求以及接收多个HTTP响应，这是为了避免每一次请求都去打开一个新的连接。
在HTTP 1.0标准的时候，关于如何保持是没有官方标准支持长连接，这个时候客户端和服务端如果需要建立长连接，那客户端的发起请求的时候，就需要在请求头中带一个表示长连接请求头：
Connection: Keep-Alive
如果服务端同意长连接请求，那么服务端在返回头中增加响应头：
Connection: Keep-Alive
这样就建立了一个长连接，当客户端与服务端的某一方或者同时关闭连接的时候，或者网络原因，这个连接才会断掉。
在HTTP 1.1标准中，所有的请求都认为是长连接，这个时候HTTP长连接的建立不再需要标识单独的长连接信息。然而，在apache2.0中默认的连接超时时间是15秒，而2.2中默认是5秒，减少超时时间是为了服务器能够响更多的请求。
长连接的优点：
1、减少CPU及内存的使用，因为不需要经常的建立及关闭连接，当然高峰并发时CPU及内存也是比较多的；
2、2、允许HTTP pipelining（HTTP 1.1中支持）的请求及响应模式：
为了便于理解HTTP pipelining，参见下图：


3、减少网络的堵塞，因为减少了TCP请求；
4、减少后续请求的响应时间，因为此时不需要建立TCP，也不需要TCP握手等过程；
5、当发生错误时，可以在不关闭连接的情况下进行提示；
根据RFC 2616 (page 46)的标准定义，单个客户端不允许开启2个以上的长连接，这个标准的目的是减少HTTP响应的时候，减少网络堵塞。
长连接的缺点：可能会损害服务器的整体性能，如apache的长连接时间的长短，直接影响到服务器的并发数。
长连接在浏览器中的使用情况：
Netscape从4.05开始支持，Netscape不是通过timeout来关闭长连接，它是将空闲连接放置到一个队列中，当有需要向其它服务端建立长连接时，这个时候，它根据LRU(Least Recently Used)算法进行处理，即将最使少使用的空闲连接KILL掉；
IE从4.0.1开始支持，IE6、7只支持两个长连接，IE8支持6个，IE 60秒为默认的超时时间，这个值可以在注册表中修改；
FF类似IE通过timeout管理长连接，不过，默的是115秒，这个是可能通过配置进行更改的；
Opera从4.0开始支持长连接，长连接数可以自定义；

一、什么是HTTP Keep Alive
 
HTTP Keep-Alive 很大程序上被误解了，下面介绍一下它在HTTP/1.0和HTTP/1.1版本下是如何工作的，以及其在JAVA中的运行原理及优化建议。
HTTP是一个请求<->响应模式的典型范例，即客户端向服务器发送一个请求信息，服务器来响应这个信息。在老的HTTP版本中，每个请求都将被创建一个新的客户端->服务器的连接，在这个连接上发送请求，然后接收请求。这样的模式有一个很大的优点就是，它很简单，很容易理解和编程实现；它也有一个很大的缺点就是，它效率很低，因此Keep-Alive被提出用来解决效率低的问题。
 
 
具体说，HTTP构建在TCP之上。在HTTP早期实现中，每个HTTP请求都要打开一个socket连接。这种做效率很低，因为一个Web 页面中的很多HTTP请求都指向同一个服务器。例如，很多为Web页面中的图片发起的请求都指向一个通用的图片服务器。持久连接的引入解决了多对已请求服务器导致的socket连接低效性的问题。它使浏览器可以再一个单独的连接上进行多个请求。浏览器和服务器使用Connection头ilai指出对Keep-Alive的支持。
 
HTTP/1.0
 
 在HTTP/1.0版本中，并没有官方的标准来规定Keep-Alive如何工作，因此实际上它是被附加到HTTP/1.0协议上，如果客户端浏览器支持Keep-Alive，那么就在HTTP请求头中添加一个字段 Connection: Keep-Alive，当服务器收到附带有Connection: Keep-Alive的请求时，它也会在响应头中添加一个同样的字段来使用Keep-Alive。这样一来，客户端和服务器之间的HTTP连接就会被保持，不会断开（超过Keep-Alive规定的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接
 
HTTP/1.1
 
在HTTP/1.1版本中，官方规定的Keep-Alive使用标准和在HTTP/1.0版本中有些不同，默认情况下所在HTTP1.1中所有连接都被保持，除非在请求头或响应头中指明要关闭：Connection: Close  ，这也就是为什么Connection: Keep-Alive字段再没有意义的原因。另外，还添加了一个新的字段Keep-Alive:，因为这个字段并没有详细描述用来做什么，可忽略它
 
 
二、HTTP Keep Alive的注意点
 
Not reliable（不可靠）
 
HTTP是一个无状态协议，这意味着每个请求都是独立的，Keep-Alive没能改变这个结果。另外，Keep-Alive也不能保证客户端和服务器之间的连接一定是活跃的，在HTTP1.1版本中也如此。唯一能保证的就是当连接被关闭时你能得到一个通知，所以不应该让程序依赖于Keep-Alive的保持连接特性，否则会有意想不到的后果
 
 
Keep-Alive和POST
 
在HTTP1.1细则中规定了在一个POST消息体后面不能有任何字符，还指出了对于某一个特定的浏览器可能并不遵循这个标准（比如在POST消息体的后面放置一个CRLF符）。而据我所知，大部分浏览器在POST消息体后都会自动跟一个CRLF符再发送，如何解决这个问题呢？根据上面的说明在POST请求头中禁止使用Keep-Alive，或者由服务器自动忽略这个CRLF，大部分服务器都会自动忽略，但是在未经测试之前是不可能知道一个服务器是否会这样做。
 
 
三、闲聊Java实现
 
Java实现--客户端
 
在客户端，Java抽象了Keep-Alive，和程序员分享离开来，HttpURLConnection类自动实现了Keep-Alive，如果程序员没有介入去操作Keep-Alive，Keep-Alive会通过客户端内部的一个HttpURLConnection类的实例对象来自动实现。也就是说，在java中keep-alive是由一个Java类库来实现的，但在其他类库中不一定可用。
 
 Java实现--服务器端
 
在服务器端，Java依然是将Keep-Alive抽象出来，HttpServlet、HttpServletRequest、和HttpServletResponse类自动实现 了Keep-Alive。这种情况下一些由第三方控制的操作是可能的，如在KeepAliveServlet中提到的JavaWebServer，Keep-Alive是否启用由两个因素决定，内容长度和输出大小，如果内容长度是响应的一部分（即这段内容长度输出后还有内容需要输出），则Keep-Alive被启用（当然需要客户端支持的情况下）；如果内容长度未设定，则Servlet会试着计算响应缓冲区长度以确定内容长度，在Javasoft实现中，使用一个4KB的缓冲区（相当于上面说的响应）。也就是说如果内容长度未设定，并且返回数据超过4KB，此时相当于内容长度大于响应长度，而不是响应长度一部分，Keep-Alive就不会被启用 。
 
四、HTTP Keep Alive 优化例子与总结
 
4.1 例子分析
 
问题现象： 一个JSP页面，居然要耗时40多秒。网页中有大量的图片的CSS
 问题解决： 原因也找了半天，原来Apache配置里面，把Keep-Alive的开关关闭了。这个是个大问题，工程师为什么要关闭它，原来他考虑的太简单了，我们知道Apache适合处于短连接的请求，处理时间越短，并发数才能上去，原来他是这么考虑，但是没有办法，只能这样了，还是打开Keep-Alive开关吧。
 
 当然，不是所有的情况都设置KeepAlive为On，下面的文字总结比较好：
 
【在使用apache的过程中，KeepAlive属性我一直保持为默认值On，其实，该属性设置为On还是Off还是要具体问题具体分析的，在生产环境中的影响还是蛮大的。
 
KeepAlive选项到底有什么用处？如果你用过Mysql ，应该知道Mysql的连接属性中有一个与KeepAlive 类似的Persistent Connection，即：长连接(PConnect)。该属性打开的话，可以使一次TCP连接为同一用户的多次请求服务，提高了响应速度。
 
比如很多网页中图片、CSS、JS、Html都在一台Server上，当用户访问其中的Html网页时，网页中的图片、Css、Js都构成了访问请求，打开KeepAlive 属性可以有效地降低TCP握手的次数(当然浏览器对同一域下同时请求的图片数有限制，一般是2 见下文章节 减少域名解释的开销)，减少httpd进程数，从而降低内存的使用(假定prefork模式)。MaxKeepAliveRequests 和KeepAliveTimeOut 两个属性在KeepAlive =On时起作用，可以控制持久连接的生存时间和最大服务请求数。
 
不过，上面说的只是一种情形，那就是静态网页居多的情况下，并且网页中的其他请求与网页在同一台Server上。当你的应用动态程序(比如：php )居多，用户访问时由动态程序即时生成html内容，html内容中图片素材和Css、Js等比较少或者散列在其他Server上时，KeepAlive =On反而会降低Apache 的性能。为什么呢？
 
前面提到过，KeepAlive =On时，每次用户访问，打开一个TCP连接，Apache 都会保持该连接一段时间，以便该连接能连续为同一client服务，在KeepAliveTimeOut还没到期并且MaxKeepAliveRequests还没到阈值之前，Apache 必然要有一个httpd进程来维持该连接，httpd进程不是廉价的，他要消耗内存和CPU时间片的。假如当前Apache 每秒响应100个用户访问，KeepAliveTimeOut=5，此时httpd进程数就是100*5=500个(prefork 模式)，一个httpd进程消耗5M内存的话，就是500*5M=2500M=2.5G，夸张吧？当然，Apache 与Client只进行了100次TCP连接。如果你的内存够大，系统负载不会太高，如果你的内存小于2.5G，就会用到Swap，频繁的Swap切换会加重CPU的Load。
 
现在我们关掉KeepAlive ，Apache 仍然每秒响应100个用户访问，因为我们将图片、js、css等分离出去了，每次访问只有1个request，此时httpd的进程数是100*1=100个，使用内存100*5M=500M，此时Apache 与Client也是进行了100次TCP连接。性能却提升了太多。
 
4.2 总结
 
1、当你的Server内存充足时，KeepAlive =On还是Off对系统性能影响不大。
 2、当你的Server上静态网页(Html、图片、Css、Js)居多时，建议打开KeepAlive 。
 3、当你的Server多为动态请求(因为连接数据库，对文件系统访问较多)，KeepAlive 关掉，会节省一定的内存，节省的内存正好可以作为文件系统的Cache(vmstat命令中cache一列)，降低I/O压力。
 PS：当KeepAlive =On时，KeepAliveTimeOut的设置其实也是一个问题，设置的过短，会导致Apache 频繁建立连接，给Cpu造成压力，设置的过长，系统中就会堆积无用的Http连接，消耗掉大量内存，具体设置多少，可以进行不断的调节，因你的网站浏览和服务器配置 而异。
 
4.3 减少域名解释的开销
 
对于HTTP/1.0来说可以充分利用浏览器默认最大并发连接数比HTTP/1.1多的好 处，实现不增加新域名的开销而更高的并行下载，减少域名解释的开销（注：IE 6,7在HTTP/1.0中默认最大并发连接数为4，在HTTP/1.1中默认最大并发连接数为2，IE8都为6，Firefox2在HTTP/1.0中 默认最大并发连接数为2 在HTTP/1.1中默认最大并发连接数为8，firefox 3默认都是6），根据10年7月Google索引的42亿个网页的统计报告，每张网页里包含29.39个图片，7.09个外部脚本，3.22个外部CSS 样式表，如果设置了Keep-Alive并且合理控制Keep-Alive TimeOut这个参数可以大量的节约连接的开销，提高相应速度。如果设置不好，在大并发的情况小，因维持大量连接而使服务器资源耗尽，而对于目前国内大 部分的用户使用的还是IE6，7的情况