我理解的push mail

最近刚好在关注push mail的问题
首先来说说push和pull
其实所有的手机email严格来说都是pull方式，只是区别是主动pull还是被动pull
举例来说：
电脑上的outlook就是主动pull方式。每隔固定的时间，去邮件服务器比对，查询是否有新的邮件。在规定时间之外，即使有新邮件也不会提示。
而被动方式的pull也可以分为两种：sms方式和https方式
139邮箱是采用sms方式。sms方式需要手机号码和邮箱捆绑才行实现（手机号码与ip地址并没有对应）。当邮箱里出现新邮件以后，服务器会发送一个特定的sms到手机端，手机端启动客户端（139邮箱你安装的那个软件），客户端启动，上网收取邮件，断线。
微软exchange服务器采用的是https长联方式。客户端（手机端）和服务器端按照一定的频率定时进行联系，称之为"心跳"连接。这样也是因为没有手机号码与邮箱对应的服务器所采取的不得已的办法。

终上所述呢，除非是运营商，任何人都不可能提供真正的省电的实时的push mail

要不要附上一篇比较深度的技术文章呢？节选一些吧：
" 微软Direct Push技术不是使用SMS消息，而是靠在移动设备和Exchange Server之间维持一个常HTTPS连接来发挥作用的。因为这个连接总是处于可用状态，所以有新电子邮件的消息就几乎能即时转发给移动设备。
　　Direct Push HTTPS连接的优缺点
　　保持常HTTPS连接有一些顾虑。对于发起者来说，数据发送接收时某些移动设备不能接收到语音呼叫。另一个普遍的顾虑是发送和接收数据消耗了与语音呼叫同样的电力。
　　虽然这是一些严重的问题，微软仍采取措施来最小化发送接收数据的影响。直接推送不会在几个小时内就完全消耗掉移动设备的电力。移动设备维持与Exchange Server的常HTTPS连接，但不会一直发送或接收数据。
　　这种情况是可能的，因为HTTP和HTTPS协议是为分布式网络设计的，所以HTTP和HTTPS消息的发送和响应不是既时的。

　　解决办法是设置一个与HTTP和HTTPS会话相联系的超时值。当发送者发送一个包时，要隔多久收到响应并不重要，只要响应在会话超时前到达即可。Direct Push通过设置超时值就可使移动设备在包间隙时间内处于休眠状态。

　　Direct Push"心跳"消息

　　Direct Push使用"心跳消息"(heartbeat messages)来保持Exchange服务器与移动设备之间的会话连接。所谓"心跳"，仅仅是指周期性发送一些消息来保持会话连接，允许移动设备检查同步过程是否有必要。
　　当移动设备开始与Exchange Server的会话时，这一过程就开始了。在这一过程中，移动设备以预先定义的间隔发送"心跳"消息给服务器。此时，有以下3种情况之一发生。
　　1. Exchange服务器以新的同步数据作为响应。这种情况下，新的数据与存储在移动设备中的数据进行同步。
　　2. Exchange服务器以HTTP 200 OK消息作为响应。这意味着没有同步新的数据。更为重要的是，这还表示会话没有超时。
　　当移动设备收到这个响应时，也许会尝试动态调整它的"心跳"间隔，因此心跳间隔的时间周期会变长。要知道，"心跳"间隔时间越长，电池消耗越低。更长的"心跳"间隔也减少了"心跳"被潜在语音呼叫打断的可能性。
　　3. 会话在"心跳"间隔时间到来前超时。这种情况发生时，为了防止Direct Push会话超时，Exchange会自动减小"心跳"间隔。
　　我们可以很清楚地看到Direct Push会话是如何通过发送"心跳"消息并等待响应来保持的。然而，根据我上面的描述，还似乎有很多未解决的偶然性。举例来说，Exchange Server如何知道"心跳"间隔调整的幅度为多大?或者如果有中断通信过程的意外事件发生会怎样呢?
　　但是在实际过程中，却没有这么多的偶然性。微软在动态调整Direct Push"心跳"技术中积聚了很多人的才智。
　　微软明白那些引起"心跳"异常的因素。举例来说，如果Exchange服务器突然比预期繁忙，于是服务器就不太可能在超时之前对心跳消息进行响应。如果是这种情况，Exchange Server设计了在调整好直接推送"心跳"间隔之前必须出现连续往返"心跳"的机制。
　　微软在Direct Push中凝聚集体智慧的另一个表现是Exchange Server很聪明地知道，如果已知心跳超时的原因，它就不应该调整"心跳"间隔。
　　比如，如果用户正在电话上通话，这时Exchange Server发送了一个"心跳"响应，那么移动设备将永远不会收到这个响应，于是"心跳"就会超时。然而，Exchange Direct Push知道超时只会出现在用户正在通话的情况下，因此不会调整"心跳"间隔。"