HTTP协议中的短轮询、长轮询、长链接和短链接

今天开始本身研究nodejs，看见轮询，研究下

http 协议介绍：

http 协议是请求/响应范式的, 每个 http 响应都是由一个对应的 http 请求产生的; http 协议是无状态的, 多个 http 请求之间是没有关系的.

在长链接的应用场景下，client端通常不会主动关闭它们之间的链接，Client与server之间的链接若是一直不关闭的话，会存在一个问题，随着客户端链接愈来愈多，server迟早有扛不住的时候，这时候server端须要采起一些策略，如关闭一些长时间没有读写事件发生的链接，这样能够避免一些恶意链接致使server端服务受损；若是条件再容许就能够以客户端机器为颗粒度，限制每一个客户端的最大长链接数，这样能够彻底避免某个蛋疼的客户端连累后端服务。

长链接和短链接的产生在于client和server采起的关闭策略，具体的应用场景采用具体的策略，没有十全十美的选择，只有合适的选择

应用场景区别： 
1. 通常长链接（追求实时性高的场景）用于少数client-end to server-end的频繁的通讯，例如：数据库的链接用长链接， 若是用短链接频繁的通讯会形成socket错误，并且频繁的socket 建立也是对资源的浪费。
2. 而像WEB网站的http服务通常都用短连接（追求资源易回收场景），由于长链接对于服务端来讲会耗费必定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的链接用短链接会更省一些资源。

短轮询和长轮询

和短链接和长链接有本质区别 
1. 短轮询：重复发送Http请求，查询目标事件是否完成，优势：编写简单，缺点：浪费带宽和服务器资源 
2. 长轮询：在服务端hold住Http请求（死循环或者sleep等等方式），等到目标时间发生，返回Http响应。优势：在无消息的状况下不会频繁的请求，缺点：编写复杂

应用：

长轮询通常用在 web im, im 实时性要求高, http 长轮询的控制权一直在服务器端, 而数据是在服务器端的, 所以实时性高;
像新浪微薄的im, 朋友网的 im 以及 webQQ 都是用 http 长轮询实现的;
NodeJS 的异步机制貌似能够很好的处理 http 长轮询致使的服务器瓶颈问题, 这个有待研究.

http 短轮询通常用在实时性要求不高的地方, 好比新浪微薄的未读条数查询就是浏览器端每隔一段时间查询的.