HTTP中的Keep-Alive

ep-Alive通俗地讲，就是所谓的持久连接，对于http这种大量的短连接的服务来说，开启持久连接的好处可以节省大量的TCP连接过程的开销，据apache的官方文档称对包含大量图片的HTML文档造成的延时起到50%的加速作用。而同时现有操作系统越来越先进，建立连接的开销越来越小，像linux 2.6的epoll，freebsd的kqueue，可以让程序不产生新进程或新线程的情况就能同时服务N多连接。与此同时，客户端比如IE，Firefox也可以同时开多个线程取内容，如果开了Keep alive，反而有可能使服务器端管理大量的等待超时的tcp连接，使服务器端资源耗尽，而导致响应速度变慢。 那么http的Keep-Alive到底是启用还是关闭呢？
说到Keep-Alive这个参数不得不说说这个参数在HTTP/1.0跟HTTP/1.1的一些区别，HTTP/1.0的默认情况下，是不会使用Keep-Alive的，仅当客户端的头指定使用持久连接这个参数而且是要服务器预先知道传输内容的长度时才会与HTTP/1.0的客户端建立持久连接，这意味着那些长度不定的内容，诸如php等动态页面内容、SSI页面、以及服务器端生成的目录列表等内容一般来说将无法使用与HTTP/1.0客户端建立的持久连接。而对于HTTP/1.1的客户端来说，如果没有进行特殊指定，持久连接将是默认的连接方式。如果客户端请求的是未知长度的内容时将使用分块编码的方式进行传输，也就是大家在http头中看到的chunked。
由于http协议基于tcp协议，当然http协议也需要tcp的3次握手的过程，而对于一个完整的HTTP/1.0的请求和响应它有以下的一个请求过程
建立tcp连接 (syn; ack, syn2; ack2; 三个分组握手完成)
请求
响应
关闭连接 (fin; ack; fin2; ack2 四个分组关闭连接)
而对于一个完整的HTTP/1.1的请求和响应:
建立tcp连接 (syn; ack, syn2; ack2; 三个分组握手完成)
请求
响应
…
…
请求
响应
关闭连接 (fin; ack; fin2; ack2 四个分组关闭连接)
如果请求和响应都只有一个分组，那么HTTP/1.0至少要传输11个分组，才拿到一个分组的数据。而Keep-Alive可以更充分的利用这个已经建立的连接，避免的频繁的建立和关闭连接，减少网络拥塞。虽然Keep-Alive可以节约分组，提升响应速度，但是一旦超出某个平衡点，由于为了保持过多的连接，创建了太多的进程，导致系统不堪重负，系统响应变慢，而对于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的情况下关闭Keep-Alive可以充分利用浏览器默认最大并发连接数的好处实现不增加额外的开销页面快速的展示（目前淘宝的列表页已经把响应的Connection设置为："close"）。