互联网消息推送的发展过程

大概的内容：

a.web年代的推送

b.flash和js制作推送

c.ajax轮训，ajax长轮训，对服务器的改造

d.websocket推送

e.APP socket tcp 推送

1.首先讲讲推送的场景

       淘宝网的网页聊天、手机扫描微信二维码、支付宝支付通知、QQ等等这些都是推送的场景，推送的主要特性是 低延时、可以快速触达到用户。在推送的早期，就有工程师尝试各种办法做各种推送方案。

2.web的推送

       大家在玩新浪微博或者人人网的时候，或者在淘宝网页和卖家聊天的时候，这个时候每次有新消息过来，服务器就把数据推送到网页上面给你。但是web有个问题，http协议（不带websocket的时代）是不能通过服务器主动发送数据给浏览器的。大家想想浏览器的数据发送方式是，浏览器主动发起一个请求，服务器接收这个请求后，然后返回数据，浏览器解析这个数据。这个是浏览器的固定的访问模式，所以这个模式下不能做推送。

这个时候有3种方案可以选：  

      第一种：web年代的推送

       就是网页用js配合（xmlhttprequest对象，这个对象如果不知道，请百度，它可以用js发起一个后台的http访问并获取数据）ajax，启动一个定时器不停的死循环的访问，服务器没有信息就返回空，如果有数据就返回字符串或者json。这种每次发起一次访问，服务器立马返回，叫做短轮训。 但是这个定时器的时间间隔非常有哲学，如果定的时间太长 ,那么消息获取到的延时会非常大，如果定时器定的时间间隔很短，对服务器非常密集的访问时压力又很大。所以一般定时2秒钟。这个方案主要是新浪微博在用，每次有新的微博他都提醒你，就是通过这个方案来实现的。

      第二种：flash和js制作推送

        早期网页非常流行flash，flash可以通过JS通讯。所以网页可以加载一个flash，这个flash里面创建一个TCP的套接字，这个TCP链接服务器，当服务器有信息就推送给这个flash这套接字，flash再把数据回调给JavaScript，这样数据就到网页上面了。这个方案有好处就是，性能很好、不用一直轮训、对服务器的压力也很小、消息及时性也非常好。但是可惜flash慢慢走下神坛，而且那个时候手机很多不支持flash，所以pc站点可以用。这个方案短暂的出现在一个 微信 PC的站点上面。微信pc登录，当你手机扫描pc上的二维码，就能登录网页版本的微信。这个https://wx.qq.com/ 网站早期这个步骤中，服务器通知网页就是用flash的方案，现在已经下线了。

      还有第三种：ajax轮训，ajax长轮训，对服务器的改造

       这是在第一种方案的基础上面改造的，第一种是网页用JavaScript不停的轮训服务器，但是服务器不管有没有信息都直接返回。在这个部分可以稍微做点修改，当网页的请求过来，服务器如果有信息就直接返回，如果没有信息就不返回，什么数据都不返回。这个时候网页这边的链接会处于pending的状态，这个状态就是在等待服务器返回数据，如果在这个状态中服务器收到了信息，就利用这个链接发送过去，如果一直没有信息就一直不返回，网页到达一定的时间后会超时。所以网页这边有两个返回，1.收到信息了  2.超时了。当出现1的情况，就处理信息。当出现2的情况就忽略，然后在启动一个新的请求，重复上面的过程。这个超时时间最少有几分钟，所以如果没有消息，这个链接会一直不断开。这个过程比推送的第一个方案少了很多信息的处理，所以对服务器压力少了很多。同时由于网页这边 一直在等待信息，及时性也高效了很多。缺点就是，需要对服务器进行改造，一般需要自己写http服务器，现有的tomcat或者nginx都不能完成这个工作，所以难度会比较大。目前已知 采用这个方案的网站只有人人网。

      人人当年的聊天和 timeline的推送都是走这个方案的，性能比新浪微博的好不少。

3.websocket推送

但是————————————————

      随着浏览器的发展，在http的协议提升下有了websocket，浏览器已经可以创建套接字了。所以上面的方案都不及这个方案来的更加直接，这个方案是最直接效率最高的解决方案，而且也是标准很多开源工具都会慢慢支持这个。
       但是可惜的是 这个对浏览器要求比较高，国内网络环境复杂，不是所有的用户都在用支持 websocket的浏览器。或者大部分用户都还不能上这个方案，现阶段还是靠 http短轮训在做需求。但是可以预知websocket是未来。

4.APP socket tcp 推送

       最后一种是  APP的推送，典型的是手机QQ和微信这类的。

      手机推送 iOS和安卓不太一样，但是本质都是走的socket的方案，手机启动的时候拉取一个套接字到服务器，服务器有信息就推送给手机就好了。

      但是iOS，当软件后台运行的时候，会关闭你的网络链接，这个时候服务器就推送不过来，改成走apple的 APN推送。

      android 可以后台运行，但是可能会被杀毒软件干掉，导致信息推送过不来。所以大厂商都抱团取暖，采用互相拉起的方案。所以安卓的推送尤其是app后台的情况下的推送，最好选用第三方专业做推送的的公司的SDK。你自己做的就算技术完善，但是到达率也是很低。

PS：所谓的抱团取暖呢，就是：安卓是单独拉一个进程来推送的，当时你一个app可能会被360之类的杀死，这样信息就到达不了了。  但是比如你用了又盟的推送SDK或者个推的已经有很多app都集成了这个sdk，即使你的程序被杀了，只要有一个集成了这个sdk的app被运行了，就能帮你拉起来推送。比如有10个app在你手机上面， 都用了个推的推送。这个时候个推的进程被杀死了，所有的app都收不到推送了了，只有有一个app打开了，个推的推送的进程就被拉起来 这十个app的推送就又可以推送到了。

好了  整个互联网的信息的推送的发展过程大概就这么多。

原创作品，如需转载，请与作者联系，否则将追究法律责任。