标签：web websocket Web 轮询 消息 推送 服务端 客户端

随着 Web 的发展，用户对于 Web 的实时推送要求也越来越高 ，比如，工业运行监控、Web 在线通讯、即时报价系统、在线游戏等，都需要将后台发生的变化主动地、实时地传送到浏览器端，而不需要用户手动地刷新页面。本文对过去和现在流行的 Web 实时推送技术进行了比较与总结。

WEB 实时推送技术的总结

https://www.cnblogs.com/fundebug/p/real-time-communication-technologies-of-web.html

websocket与comet的性能对比

https://www.iteye.com/blog/chenkangxian-2268133

HTTP 协议有一个缺陷：通信只能由客户端发起。举例来说，我们想了解今天的天气，只能是客户端向服务器发出请求，服务器返回查询结果。HTTP 协议做不到服务器主动向客户端推送信息。这种单向请求的特点，注定了如果服务器有连续的状态变化，客户端要获知就非常麻烦。在WebSocket协议之前，有三种实现双向通信的方式：轮询（polling）、长轮询（long-polling）和iframe流（streaming）。

轮询（polling）轮询的间隔过长，会导致用户不能及时接收到更新的数据；轮询的间隔过短，会导致查询请求过多，增加服务器端的负担

长轮询（long-polling）一次请求来回，不计消息体的大小，光是请求头及响应头，就占用了542byte。

换句话说，客户端给服务端发送一条消息，并且从服务端接收一次消息，总共要花费在请求头的代价是1228byte，而实际消息体的内容可能也并不大。

对于websocket来说，情况就不太一样了，websocket的浏览器端会先发送一个HTTP请求给服务端建立连接，服务端会回一个HTTP的响应，当连接建立好之后，浏览器端与服务端将通过frame的格式通信，中间附带的header信息几乎可忽略不计。

消息推送框架

pushlet和comet4j比较火，但是pushlet在2010年已经停止维护更新了且耗性能，comet4j又因为BUG不断这几年在企业团队不是很受欢迎了。剩下的什么rabbitmq、activemq、kafuka啊之类的都是要单独在服务器安装部署然后写代码绑定的，而且上手不容易，出错也很难排查

websocket太多国企用户还在用IE8，9，而websocket对浏览器的要求较高，想用却用不上。

标签：web,websocket,Web,轮询,消息,推送,服务端,客户端
来源： https://blog.csdn.net/godflowerszzz/article/details/104792168

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。