这篇文章翻译自 FastMail 官方博客 原文：https://blog.fastmail.com/2016/12/21/what-we-talk-about-when-we-talk-about-push/ 这是 2016 FastMail Advent Calendar 系列的第 21 篇文章。敬请期待明天的更新。 当一些人考虑注册成为我们的用户时经常会问我们：“你们的产品支持推送吗？”。简单地回答是“支持”，但令人疑惑的当他们问这个问题的时候他们到底是什么意思？这点让这个问题变得有点复杂了。 当说起电子邮件的时候，大多数人通常理解的“推送”是新的邮件到达一台移动设备的时候他们获得几乎实时（ near-realtime ）的通知。这看起来是一个相当简单的概念，但实现起来却需要电子邮件服务器（比如 FastMail ）和客户端/软件（ iOS 邮件客户端，FastMail 移动客户端或者是 Thunderbird（雷鸟）之类的桌面客户端）之间的精心协作，而且依赖于所使用的机制，设备所使用的操作系统（比如 iOS 或 安卓）和操作系统的供应商（苹果，谷歌）。没有这些环节的配合，实时通知是不能实现的。 所有的这些意思是说没有一个简单的回答“你们支持推送吗？”囊括的这些所有情况。我们通常说“支持”是因为对我们的大多数客户来说这就是他们想要的答案。 邮件客户端可以使用各种机制来通知用户新邮件来了，每种都有各自的优缺点。 IMAP 单纯的传统意义上的 IMAP 客户端（桌面客户端和移动客户端）有较少的几个消息通知机制。 Polling 迄今为止对客户端来说最简单的查看是否有新邮件的方式是不断地去查询服务器。如果客户端每分钟都查询一次服务器的话则看起来和实时消息通知差不多。 这种方法最大的缺点就是网络负载和（除过像台式机这种总是插着电源的设备）电池寿命。 如果查询服务器过程很复杂的话网络负载就是一个大问题。最差的情况下，你必须查询服务器上整个信箱的状态并且和设备上保存的上次查询得到的记录做对比。较新的 IMAP 有一些机制（比如 CONDSTORE and QRESYNC ）可以让客户端获得当前服务器上的收件箱编码后的令牌（token）。下一次当客户端查询服务器的时候，客户端可以对令牌说“把从我上次离开后的变更”。如果客户端和服务器都支持这个特性的话，通常情况下没有什么改变的话网络负载不会有压力。 电池寿命是个大问题由于系统要定期唤醒并且使用网络去向服务器查询变化情况。这其实是一种对电能的浪费因为大多数情况下你都不会有新邮件，然后设备又转而休眠了，这其实没有多大实际的意义。 IDLE 为了避免上面说所的这种不必要的轮询（定时多次向服务器查询状态），IMAP 有一种叫做 IDLE 的机制。客户端可以在服务上打开一个文件夹并在其中“idle”。这样可以保持和服务器的连接而且可以让客户端进入休眠状态。当服务器上有了需要变化需要通知的话，服务器通过这个连接给客户端发送一条消息，这将从休眠状态激活设备以便客户端查询服务器上的变更。 通常会出现的情况是对一些没有指定推送渠道或是推送机制的设备来说， IDLE 是可用的但仍存在一些问题使得它的效果不是那么理想。 主要的是 IDLE 只允许客户端请求对单个文件夹的变动。如果客户端需要通知多个文件夹的变动那么则必须有多个 IMAP 连接，每个文件夹分别一个。如果有些服务器同时限制单个用户的连接数的话对导致许多问题而且会使客户端变得复杂起来。 还有个问题，特别是移动设备来说， IDLE 是工作在 TCP 协议栈之上的。当设备网络情况发生改变的时候（这可能包括在移动基站之间的切换）会导致问题出现，可能会破坏连接。由于 TCP 协议栈的工作机制，不可能总能让一个设备判断连接是否还在继续，客户端依靠定期去“ping”（通常需要定期唤醒）或当网络发生变化的时候指望设备通知已经不那么可靠了。 很多情况下 IDLE 是靠谱的而且兼容大多数的 IMAP 客户端，但这是最基本的推送通知的做法。 NOTIFY 为了解决上述的一个文件夹对应一个连接的问题（one-folder-per-connection problem），IMAP 引进了另一种叫做 NOTIFY 的机制。它允许客户端请求它感兴趣的一组复杂的内容（包括文件夹列表和变更类型列表，比如“新邮件”或者是“已删除的邮件”）然后一次性通知这些内容。 这是推送机制发展的正确一步，但是还是存在使用 TCP 协议栈会遇到的那个问题。它是一个相当复杂的协议而且难于和当前的需求兼容，这就是我期望没有客户端或服务器支持它的原因。Cyrus（FastMail 使用的邮件服务器软件）不兼容它而且可能一直不会兼容。