错觉与突然的察觉
大多数人都知道HTTP1.0不支持长连接，知道HTTP1.1支持长连接。
这是业界的一个常识。
然而这样的描述导致了一些不做网络底层开发的开发者都下意识的认为HTTP1.1是一个可以建立长连接的的协议。
小弟之前也是如此认为的。
这边是一个很多人都存在的错觉。
偶然在一篇文章中发现了字眼“HTTP是一种应用层的网络协议”，突然想起，长连接是存在于网络层的一种连接状态，而实现它则需要在传输层进行开发，因为它是基于对真实数据的收发，需要在底层进行管控。那么作为应用层的HTTP协议，如何能实现“长连接呢“？
探索
经过一些查阅，才了解到，HTTP作为应用层协议，其实它的生命周期在服务器返回结果时就已经结束了，而所谓的支持长连接，其实是基于'Keep-Alive'请求头所约定，从而向下进行长连接发起的一种机制。该长连接依然是基于TCP的。
因此：
所谓HTTP1.1及以上支持长连接，并不是HTTP1.1可以建立长连接，而是它支持以请求头的方式进行长连接发起（并且要求客户端与服务端都要具备 ‘Keep-Alive: true’ ）。
So?这都是些什么？
那么就再来理一理这几个概念的思路吧
短连接
所谓短连接，及连接只保持在数据传输过程，请求发起，连接建立，数据返回，连接关闭。它适用于一些实时数据请求，配合轮询来进行新旧数据的更替。长连接
长连接便是在连接发起后，在请求关闭连接前客户端与服务端都保持连接，实质是保持这个通信管道，之后便可以对其进行复用。
它适用于涉及消息推送，请求频繁的场景（直播，流媒体）。连接建立后，在该连接下的所有请求都可以重用这个长连接管道，避免了频繁了连接请求，提升了效率。
容易混淆的长短连接长短轮询
所谓轮询，即是在一个循环周期内不断发起请求来得到数据的机制。只要有请求的的地方，都可以实现轮询，譬如各种事件驱动模型。它的长短是在于某次请求的返回周期。
短轮询
短轮询指的是在循环周期内，不断发起请求，每一次请求都立即返回结果，根据新旧数据对比决定是否使用这个结果。长轮询
而长轮询及是在请求的过程中，若是服务器端数据并没有更新，那么则将这个连接挂起，直到服务器推送新的数据，再返回，然后再进入循环周期。
由上可以看到，长短轮询的理想实现都应当基于长连接，否则若是循环周期太短，那么服务器的荷载会相当重；当然，即便是在长连接下，访问人数过多，长短轮询都有可能造成服务器的瞬时访问量庞大，这就需要一些相应的优化实践了。
