短连接与长连接
通俗来讲，浏览器和服务器每进行一次通信，就建立一次连接，任务结束就中断连接，即短连接。相反地，假如通信结束（如完成了某个HTML文件的信息获取）后保持连接则为长连接。在HTTP/1.0中，默认使用短连接。从HTTP/1.1起，默认使用长连接，这样做的优点是显而易见的，一个网页的加载可能需要HTML文件和多个CSS或者JS，假如每获取一个静态文件都建立一次连接，那么就太浪费时间了，而在保持连接的情况下，继续GET即可。
对于频繁请求资源的客户来说，较适用长连接。但连接数最好进行限制，防止建立太多连接拖累服务端。一般浏览器对一个网站的连接是有限制的几个，所以网站会将资源部署在多个域名上以实现浏览器同时请求。
短/长连接应当在TCP连接的范畴中来讨论。有人常说HTTP的短连接和长连接如何如何，但是HTTP只是一个应用层协议，又是无状态的，最终实质性的保持连接还是得靠传输层，即TCP。
举个例子，NginX作为代理的一种常见配置方式是在NginX与客户端之间的连接使用长连接，NginX与后端服务器之间的连接使用短连接。
keep-alive
我们使用浏览器的开发者工具查看网络请求和响应信息时经常在HTTP请求头部看到Connection: keep-alive，一般的浏览器都会带着个头去请求数据，假如有特殊需求可以用Connection: close断开。HTTP头部的Connection也不一定就被客户端或服务端老老实实地遵循，毕竟各有各的考虑，尤其是在HTTP/1.0这还只是个实验性的功能，而在HTTP/1.1默认长连接于是没有对长连接做特殊的规定。
长连接也不能无限期地长，服务端有可能在头部放Keep-Alive，其中timeout等于一个值来规定保持连接的秒数，还可以用max来规定多少次请求后断开。如果没有说明怎么断开，主动发起四次握手也可以实现连接的断开。
现在有一个问题就是HTTP的keep-alive与TCP的keep-alive到底是什么关系。其实这是两种不同的机制，可以认为没有什么关系。HTTP在头部的Connection中声明keep-alive可以告诉对方要长连接不立即断开，但是TCP的keep-alive则是一种检查对方是否仍旧和自己保持着连接的机制以避免自作多情半开放的连接。假如发出一个探测段，成功收到响应，这证明连接正常保持；假如发出一个探测段一段时间后，一个响应都没收到，对方可能已挂断、机器异常或网络异常；假如对方收到探测段但重置，说明原来的连接已经因为某些原因挂断，目前是因为未进行三次握手新建立连接而被挂断。
参考资料：
http://stackoverflow.com/.../relation-between-http-keep-alive-duration-and-tcp-timeout-duration