Push Technology概述 （二）
接上文：http://blog.csdn.net/historyasamirror/archive/2010/02/22/5316473.aspx
Mobile上的Push Tech和Apple Push Notification Service
其实，在Twitter推出之前，有一个公司已经利用Push Tech大大风光了一把，这个公司就是BlackBerry。BlackBerry推出的邮件推送服务（Push Email）使得它获得了很多企业级客户的信赖，同时也在手机市场上抢下了一块地盘。
普通的邮件，当sender发送了一封邮件，该邮件会被push到对应的MDA（mail delivery agent，就是server端），但是，只有client通过MCA（mail client agent）主动的到MDA上poll时，client才能够获取最新邮件。BlackBerry做的事情其实很简单，一方面它会反复的轮询client邮箱所在的MDA，检查是否有新邮件到达，另一方 面，它和运营商合作，一旦发现client有新邮件，就将这个新邮件从MDA获取出来，然后发送到client手上的BlackBerry手机中。
在BlackBerry之后，其它厂商的手机也陆续推出了Push Email的解决方案【6】。在日本，貌似支持Push Email服务已经成为了手机的基本功能要求了。
手机端的Push Tech另一个我个人非常推崇的技术就是apple提供的Apple Push Notification Service（APNS）【7】【8】。这项服务已经集成进了Iphone OS 3.0。APNS不仅仅可以提供邮件的主动推送服务，实际上，这是一个整体的Push Tech解决方案，它提供了一般意义的Push Tech，可以Push多种形式的notification。可以说，它比BlackBerry的邮件推送服务又向real-time web进了一步。不论是推送最新的新闻，或者是好友的Message，都可以通过APNS实现。
APNS的基本架构如图：
第三方的service如果想向某个client推送一个notification，就将这个client的识别ID和notification的内容告诉APNS，APNS会将这个notification送到client端。
再来根据Apple公布的资料分析一下APNS：
“When the iPod touch screen is on and has a Wi-Fi connection, push notifications are received at any time. If the iPod touch screen is asleep, it will check every 15 minutes for a notification.”
“If the device is connected over Wi-Fi and is still unable to receive notifications, the Wi-Fi network you're using might have a firewall that is blocking port 5223. This port must be open to TCP traffic for notifications to work.”
“Most of the heavy lifting is handled between your servers and ours, so there’s less impact on battery life and performance than there would be if you ran the app in the background. The service maintains a persistent IP connection so that it can notify users even when your app isn’t running.”
从资料中可以看出，当iphone处于工作状态时，并且连接wifi，那么手机端和APNS的server端应该是维持了一个持久的长链接，这时，notification才能够在任意时间被接收。而当iphone处于asleep状态时，手机端每隔15秒主动连接一次server，获取最新的notification。
资料中表明手机与APNS之间的通信走的是TCP链接，端口号是5223，可以从中解读出很多东西。一般来说，5222端口是XMPP协议的标准端口，而5223常用于XMPP的SSL加密。并且，前面提到过，XMPP是最常用于实现Push Tech的协议。所以，APNS采用的协议应该就是XMPP协议，在信道中采用SSL进行了加密。
虽然大多数人都不知道APNS，但是我个人相信APNS会是未来的一个方向，将来的各大手机商或者移动互联网服务商都会提供类似的service，因为push tech在未来的移动互联网业务中会应用得越来越广泛。
Push Tech的性能
在文献【9】中，对于web下的Pull Tech和Push Tech的性能进行了对比。Pull Tech就是每隔一定间隔client访问请求一次server，结果立即返回。Push Tech则包括了Long Polling等。这篇文章的实验所获得的最意外的一个结果就是当采用Push Tech时，比如Long Polling，server端的CPU使用率要高很多（push brings some scalability issues; the server application CPU usage is 7 times higher as in pull）。实验中，当并发用户数量达到350+人时，Push Tech的服务器CPU占用率就达到了100%。
当我看到这个实验结果时，第一反应就是实验采用的web server使用的是multi-thread architecture。从Long polling的原理可以看出，对于每一个client，server端可以假想成维持了一个持久链接，所以，如果是multi-thread的架构，那么相当于有多少个client，就维持了多少个thread，client数量一旦过多，那么server端的大部分计算资源都会用在大量thread的切换上。但细读论文，发现实验采用的是JAVA NIO和event-driven的架构，所以，这里没有多线程上下文切换什么事。那么，这样的实验结果只能说明，类似Long Polling这样的Push Tech确是会比普通的Pull占用更多的资源。事实也如此，pull只是简单的一个request-response，而long polling则要维持链接一段时间。（With push, when the number of clients is increased to 350, the server is practically saturated, i.e., CPU is running at almost 100%. This is mainly due to the fact that the push server has to maintain all the state information about the clients and also manage the corresponding threads and connections. A push server based on long polling also needs to generate numerous re-quest/response cycles to keep the connection alive, which impact the resources. With pull only the publish interval has a direct measurable effect on the performance）
更详细的实验配置和结果自己看论文吧。
文献【9】侧重于分析server端和网络的性能，但其实我对另外一个课题更感兴趣，就是client端的性能。如果是在手机上使用Push Tech，哪种方式最能够省电呢？目前为止我还没找到相关的资料，这应该是个很有意思的研究方向。
参考文献：
【 1】 Push Technology is the Core of the Real Time Web
【 2】 Wiki： Push Tech
【 3】 Wiki： Comet
【 4】 Comet：基于 HTTP 长连接的 “服务器推 ”技术
【 5】 Wiki： BOCH
【 6】 Wiki： Push e-mail
【 7】 iPhone and iPod touch: About Apple Push Notification Service
【 8】 apple push notification service
【 9】 Technical Report： A Comparison of Push and Pull Techniques for AJAX