偷窥 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 内容一览吧！
