http长轮询&短轮询
http 协议是请求/响应范式的, 每一个 http 响应都是由一个对应的 http 请求产生的; http 协议是无状态的, 多个 http 请求之间是没有关系的.
目前 http 协议普遍使用的是 1.1 版本, 之前有个 1.0 版本, 两者之间的一个区别是?1.1 支持http 长连接, 或者叫持久连接.1.0 不支持 http 长连接, 每次一个 http 请求响应后都关闭 tcp 连接, 下个 http 请求会重新建立 tcp 连接.
所谓 http 长连接, 就是多个 http 请求共用一个 tcp 连接; 这样可以减少多次临近 http 请求导致 tcp 建立关闭所产生的时间消耗. http 1.1 中在请求头和相应头中用 connection字段标识是否是 http 长连接,?connection: keep-alive, 表明是 http 长连接;?connection:closed, 表明服务器关闭 tcp 连接
与 connection 对应的一个字段是?keep-live, http 响应头中出现, 他的格式是 timeout=30, max=5, timeout 是两次 http 请求保持的时间(s), , max 是这个 tcp 连接最多为几个 http 请求重用
http 长轮询是服务器收到请求后如果有数据, 立刻响应请求; 如果没有数据就会 hold 一段时间, 这段时间内如果有数据立刻响应请求; 如果时间到了还没有数据, 则响应 http 请求;浏览器受到 http 响应后立在发送一个同样 http 请求查询是否有数据;
http 长轮询的局限:
http端轮询是服务器收到请求不管是否有数据都直接响应 http 请求; 浏览器受到 http 响应隔一段时间在发送同样的 http 请求查询是否有数据;
http 短轮询的局限是实时性低;
两者相同点:
可以看出 http 长轮询和 http 短轮询的都会 hold 一段时间;
两者不同点
间隔发生在服务端还是浏览器端: http 长轮询在服务端会 hold 一段时间, http 短轮询在浏览器端 “hold” 一段时间;
长轮询一般用在 web im, im 实时性要求高, http 长轮询的控制权一直在服务器端, 而数据是在服务器端的, 因此实时性高;
像新浪微薄的im, 朋友网的 im 以及 webQQ 都是用 http 长轮询实现的;
NodeJS 的异步机制貌似可以很好的处理 http 长轮询导致的服务器瓶颈问题, 这个有待研究.
http 短轮询一般用在实时性要求不高的地方, 比如新浪微薄的未读条数查询就是浏览器端每隔一段时间查询的.
关于 http 长连接一个误解就是服务器主动推送数据, 这个在 http 协议下是无法实现的, 因为 http 请求/响应范式决定的,?http 中服务器返回数据必须要有一个浏览器端的请求对应, 服务器无法主动推送给浏览器数据.
不管 http 长轮询还是 http 短轮询 保证同一个用户在多 tab 下只存在一个定时查询是有好处的, 这可以通过在浏览器端缓存数据解决,?在 http 响应后在浏览器端缓存数据, 并设置一个有效期, 然后在每次发送 http 请求时检查是否有有效数据, 没有则发送请求获取