通俗来讲，浏览器和服务器每进行一次通信，就建立一次连接，任务结束就中断连接，即短连接。
相反地，假如通信结束（如完成了某个HTML文件的信息获取）后保持连接则为长连接。
在HTTP/1.0中，默认使用短连接。从HTTP/1.1起，默认使用长连接，这样做的优点是显而易见的，一个网页的加载可能需要HTML文件和多个CSS或者JS，假如每获取一个静态文件都建立一次连接，那么就太浪费时间了，而在保持连接的情况下，继续GET即可。
对于频繁请求资源的客户来说，较适用长连接。但连接数最好进行限制，防止建立太多连接拖累服务端。一般浏览器对一个网站的连接是有限制的几个，所以网站会将资源部署在多个域名上以实现浏览器同时请求。
有人常说HTTP的短连接和长连接如何如何，但是HTTP只是一个应用层协议，又是无状态的，最终实质性的保持连接还是得靠传输层，即TCP。
举个例子，NginX作为代理的一种常见配置方式是在NginX与客户端之间的连接使用长连接，NginX与后端服务器之间的连接使用短连接。
长连接是为了复用。那既然长连接是指的TCP连接，也就是说复用的是TCP连接。那这就很好解释了，也就是说，长连接情况下，多个HTTP请求可以复用同一个TCP连接，这就节省了很多TCP连接建立和断开的消耗。
比如你请求了博客园的一个网页，这个网页里肯定还包含了CSS、JS等等一系列资源，如果你是短连接（也就是每次都要重新建立TCP连接）的话，那你每打开一个网页，基本要建立几个甚至几十个TCP连接，这浪费了多少资源就不用LZ去说了吧。
但如果是长连接的话，那么这么多次HTTP请求（这些请求包括请求网页内容，CSS文件，JS文件，图片等等），其实使用的都是一个TCP连接，很显然是可以节省很多消耗的。
我们使用浏览器的开发者工具查看网络请求和响应信息时经常在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则是一种检查对方是否仍旧和自己保持着连接的机制以避免自作多情半开放的连接。假如发出一个探测段，成功收到响应，这证明连接正常保持；假如发出一个探测段一段时间后，一个响应都没收到，对方可能已挂断、机器异常或网络异常；假如对方收到探测段但重置，说明原来的连接已经因为某些原因挂断，目前是因为未进行三次握手新建立连接而被挂断。