web消息推送

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

Java Web 服务器的消息推送

comet4j java服务端推送消息到web页面实例

https://blog.csdn.net/shadowsick/article/details/9014139?spm=a2c4e.10696291.0.0.634119a4ovNLyv

websocket实现消息推送

https://blog.csdn.net/StringBuff/article/details/91395434?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task

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对浏览器的要求较高，想用却用不上。