偷窥iPhone Push Notification的幕后

iPhone Push Notification，一个吹得天花乱坠，却又不断跳票的功能，终于在OS3.0上实现。虽然体验糟糕（Tweetie和IM+之间反复切换，每次都需要等待这两个软件加载数据，这种脑残的使用方式能代替多任务？)，但是我终于可以在使用Tweetie的同时，挂着MSN了。

既然BB，Nokia，Palm都先后支持了Push，那么它们之间的比较不可避免。Handspring兄有一篇文章详尽的分析了现有Push方式和他们的优缺点。

不清楚苹果的Push方式，就让我们很难把iPhone Push Notification，与其他几个厂家作横向比较。

苹果的Push到底是怎么实现的？

是哪种Push方式？

有何优缺点？

本文，将带你到iPhone Push Notification的幕后，去偷窥一下Push剧中，登场演员的香艳大腿。

—-

苹果的Push Notification是哪一种？

目前流行的Push方式有三种。

短信触发

2G时代长时间的数据连接会影响电话接入的可靠性，所以Pushmail用短信的方式触发。推过来一个你看不到的短信，让系统去连接邮件服务器。

长连接心跳查询

3G时代，语音和数据分离，手机长时间的保持网络连接成为可能。于是可以建立一个连接，设定一定时间间隔，让手机不断的检查服务器的邮件。

长连接IMAP IDLE

网络进步的同时，邮件推送的协议也在不断改进。IMAP开始支持IDLE特性。让手机不需要总去访问服务器。手机的请求过来，邮件服务器可以把回复挂起，有新邮件近来时再发出。

苹果的呢？吝啬的苹果从来不解释这些技术选择的问题，万能的Google也没个所以然。但我手里的iPhone上，一定有Push实现方式的蛛丝马迹。

最终，我定位到了苹果的Push Notification服务器。

IP是17.149.xxx.xxx。 如果你想知道为什么Push Notification有20到30秒的延迟，这个IP就是答案：一台位于美国的主机。没错，日本3G网络下的手机，Push一下，需要横穿整个太平洋！（中美之间的网络通讯恐怕不会快过日美。）

Push方式？答案就在这个TCP连接使用的端口上:5223

使用这个端口的协议源于Jabber后来发展为XMPP。如果这两个词你不知所谓，那么Google Talk你一定知道。

没错，是个IM协议使用的端口！

—-

幕后

5223这个数字就是通向iPhone Push Notification 幕后的大门。他指向一个用XML格式传递消息的开放IM协议。由此，我们可以猜测苹果Push Notification的构架。

服务器和手机上跑着的都是基于Jabber/XMPP协议的类IM程序。手机加服务器为好友，而服务器加所有使用Push的手机为好友(数量一定非常惊人，所以稳定性是问题。这应该也是Push Notification反复跳票的原因。)。

一次Push，就是那个位于美国的服务器中的IM软件，在长长的好友列表中找到你的手机，然后和他说句话。

当然，手机和服务器之间的对话和我们不同。他们不传递牢骚和笑话，传XML文件。

用XMPP和Push Notification为关键字Google一下，很容易就找到这个XML文件的例子。这是可读的明码，我们可以从项目名称和值来猜测苹果大概都传了些什么。实际传输中，这个XML应该加过密。

手机端的类IM程序应是名为notifyd的后台进程（拥有root权限），他根据收到的XML文件的内容动作。显示一个Popup出来的消息框，或者，清空你手机的所有数据。

—-

回到前台

洞悉苹果Push Notification的幕后可以回答很多现实的疑问。 比如。。。

是否费电？

看苹果的优化程度，个人的主观体验是耗电增加明显。可类比的是Android后台跑一个Gtalk。两者增加的耗电应该差不多。(用同样协议实现的IM客户端)

为什么有延迟？

因为你在日本的邮件服务器要联络在美国的Push服务器，然后，他再给你发一个跨洋消息。

WIFI和3G下皆可Push？

没错。完全没区别。WIFI下没准还快点。参考Gtalk或者MSN的使用经历。

IMAP IDLE呢？

mail.app支持IDLE，但似乎意义不大。mail.app可能因为内存不足给释放掉。(至少在OS 3.0以前) 而iPhone上的那个IM客户端，似乎总是跑在后台的。

Nokia，BB，还有苹果的，哪个最好？

3G下，似乎还是Nokia的方式理想些。

短信触发也不错。短信的接收非常省电。3G下的数据连接，一旦建立，不会轻易断开。你也不会每封信都去连接邮件服务器。所以这仍然是可靠有效的，久经考验的Push方式。

苹果的也不错。后台多跑个Gtalk而已。只不过Push程序一直保持在后台，TCP连接一旦建立，也不会改变状态。（从来不会出现IMAP连接的close and wait状态。）所有这些应该导致更多耗电。相信这就是苹果在宣传Push耗电时，很保守的使用Preserves（维持，保存）这个词的原因吧。微言大义。：）

Pushmail之外的可能性？

iPhone和Push服务器之间传递的是一个XML文件。这个是一种跨平台，并且可以自定义格式的数据文件。

灵活的Push方式带来无限的可能性。看苹果想赋予iPhone后台的那个IM客户端什么功能了。强制升级，删除程序都是小菜一碟。

越狱之后如果有高人感兴趣，给这个IM进程加个UI，iPhone手机之间能互相加好友也有可能。

安全性？

iPhone和Push服务器之间是通过Internet传输XML文件的。那么威胁来自于两方面：

1 劫持XML并修改。

个人不太担心这个。信息应该是加过密的。破解起来似乎得不偿失。（这意味着别人想要检查Push的内容也比较困难。实时的解密加关键字过滤应该是不可能的任务。除非。。。苹果把密钥交出来。）

2 修改iPhone指向的Push服务器。

越狱的iPhone可能在任何地方装软件，而iPhone的root密码是固定的。让iPhone指向一个非苹果的Push服务器，似乎是更现实的威胁。

—-

偷窥了半天，似乎也没有什么特别的快感？

的确，苹果的大腿，没有想象中香艳。不过，技术上的事情往往如此，少有天才的解法，更多是一层层的现有方案的封装和整合。用户体验的好与不好，其实不关他的事。

既然苹果利用IM协议，查看历史纪录肯定不是问题，早日给我们Palm Pre那种Push内容一览吧！