深度剖析WinPcap之(二)――网络分析与嗅探的基础知识(3)

　　当今信息爆炸的时代，人们对于充斥在身边的各种信息几乎有些麻木了。大量无关的信息不断骚扰人们的神经，因此个性化、社交化的应用也是大行其道。比如一些新闻客户端，会根据用户的使用习惯或订阅要求向用户发送指定的新闻内容；再比如常用的一些即时通讯软件如微信、GTalk、个信等，都是可以实时地将私密信息送到用户的终端。这背后用到的技术就是消息的推送。

　　本文讨论的消息推送特指从服务器端向移动终端设备进行特定格式信息流传递的过程。 与传统服务器端到服务器端通讯最大的区别就在于移动终端的不确定性。举个生活中的例子，服务器端好比是北京的"水立方"游泳馆，闻名遐迩，有明确而且固定的地址（IP或域名），大家要游览（访问）"水立方"可以很方便的找到她。但是反过来，"水立方"要想找到某个具体的"游客"就很难了，因为每个"游客"没有确定的地址（每次登录网络都可能变更IP）。

　　怎样才能随时找到散落各处的"游客"呢？移动运营服务商提供了一个有效的途径-SMS。通过移动终端的唯一标识（手机号码），随时随地找到某个终端用户。可是有两座大山挡在了开发者面前。其一，号码资源作为运营商的垄断资本不会轻易开放出来，事实上在android手机上要想绕开运营商获得手机号码绝不容易；其二，短信内容的拦截、解析与匹配本身技术门槛较高，对于开发者来说实在不是一种合适的选择。

　　有没有其他便捷的选择呢？答案是肯定的，既然服务器端找到客户端不容易，而客户端找到服务器端很容易，那么就可以让消息推送的过程反转过来。首先由客户端来定时访问服务器端，建立某种联系（通常为http请求）。之后，服务器端就可以轻松地将信息通过这种联系通道发给客户端了。这就是通常说的轮询模式。这种模式具体到移动终端设备上，却存在致命缺陷：高频的轮询导致流量和电量消耗极高，低频的轮询又会导致消息的及时性很差。

　　有没有更好一些的实现方式呢？的确是有的，而且苹果已经很好地实现了这种方式-持久化连接。苹果信息推送服务（Apple Push Notification Service）提供了苹果移动终端与服务器端的长连接。同样地，在android系统上也可以实现类似苹果APNS的推送机制。目前主流的实现协议包括：C2DM、XMPP和XQTT等。同时，一些技术公司也看准了android信息推送的广阔市场，将这些协议进行封装、改造，形成了各具特色的android推送解决方案。

　　国内的推送技术解决方案有个推，据说新浪微博android上的推送也是他们做的，并发量达到5000tps（每秒钟可以处理5000个事务），日分发消息据说超过1亿条，消息到达率在96%以上，延时小于250ms，换句话说消息会在1/4秒内到达。同时对于消息都有详细的报表数据，可以用于做数据分析挖掘和用户体验的改善，总体来说是开发成本最低的。
个推平台有两种接入模式：

　　群发模式

　　 提供群发管理后台，满足消息群发需求

　　 无需设备部署，当天开通账号，客户端集成SDK发布即可使用

　　 业务整合模式

　　如果希望推送与业务深度结合，还可以使用其提供的业务整合模式。

　　提供服务端API接口，可以与客户已有业务系统深度整合

　　客户一般经过1-2周开发改造即可实现新功能的上线

　　第三方推送接入相对最简单，开发也比较容易。无论是从消息的到达率、集成开发成本、并发量还是统计报表的完善程度，个推都表现的非常出色。