Direct Push技术原理

简介:

微软Exchange Server一直以来都有给移动设备发送消息的能力,但是基于SMS的同步进程是昂贵的,而且用户也不能立即收到有新电子邮件的消息。在Exchange Server 2003升级维护包2(SP2)中,微软新引进了一种改进的名为直接推送(Direct Push)的同步技术来解决这些问题。它还提供了将安全策略应用到移动设备的能力。在这个教程里,Exchange的“最有价值专家”(MVP) Brien Posey解释了直接推送技术工作的原理和如何在Exchange 2003 SP2电子邮件环境中配置并实现直接推送技术。
如果你对此处介绍的信息有任何评论或问题,请发送电子邮件至editor@searchexchange.com。
在SP2以前,Exchange Server 2003在有新邮件到达时会发送SMS消息告诉移动设备。然后移动设备启动与Exchange Server的同步进程来下载电子邮件。
这种与移动设备的同步方法有以下几个缺点:
● 尽管无限制通知的费率计划变得越来越普遍,但是一些移动通讯提供商仍然按每条消息进行收费。如果你把消息的数量与费率乘起来,再与用户拥有的移动设备数量相乘,你可以看到这种服务费用增长的速度是非常迅速的。
● 基于SMS的同步过程,移动设备必须进行周期性检查来查看是否有新的消息到达(Exchange服务器发送的SMS消息是对设备检查的响应)。移动设备用户收到新电子邮件消息的频率完全取决于其移动设备检查新消息的频率是如何设置的。举例来说,一旦有新消息到达,用户就会马上收到随随时间变化的电子邮件消息。
● 频繁的基于SMS的同步过程对移动设备的电池寿命有消极影响。
为了解决这些问题,微软开发了一种新的名为直接推送的同步技术。该技术首先在Exchange Server 2003 Service Pack 2中引进,但也用于Exchange Server 2007中。在这个教程里,所有配置说明都是关于Exchange 2003 SP2 Direct Push以及Windows Mobile 5.0和Windows Mobile 6.0设备的。

第一部分:微软Exchange Direct Push技术的工作原理
微软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知道超时只会出现在用户正在通话的情况下,因此不会调整“心跳”间隔。

Direct Push“心跳”注册表项
Direct Push“心跳”由以下四个注册表项控制:

● HeartbeatDefault
● HeartbeatIncrement
● HeartbeatMin
● HeartbeatMax

这些值在注册表储存的位置如下:
HKEY_LOCAL_MACHINE\Software\Microsoft\ActiveSync
记住,编辑注册表是危险的,因为错误修改容易摧毁Windows和/或应用系统。在进行任何注册表修改前都要对系统进行完全备份。
HeartbeatDefault是指调整前的初始心跳间隔。默认情况下,注册表项的这个值被设置成480秒,或8分钟。
HeartbeatMin的注册表项表示“心跳”间隔时间的最小量。最小的“心跳”间隔与微软默认的心跳间隔相同,即480秒。微软推荐不要调整这个值,因为减小它会引起更多数量的心跳发生,这就会使移动设备消耗更多的电力。微软声称,减小这个值带来的性能提高远远不及对电池寿命造成的负面影响。
HeartbeatMax是指“心跳”间隔时间的最大值。正如我前面所说,当移动设备证明它能处理更长的“心跳”间隔而没有超时,Exchange Server会动态增加“心跳”间隔时间。
然而,为了防止Direct Push不确定地增加“心跳”间隔,应该有一个截止点。微软设置“心跳”间隔默认的最大值为1680秒(28分钟)。研究这个教程时,我发现因特网上有管理员声称能把HeartbeatMax值增加到45分钟,但微软建议不要超过默认值。

默认值设为正好低于大多数网络的网络超时周期。如果你设置HeartbeatMax的值太高,移动设备会逐渐增加“心跳”周期到“心跳”超时临界点附近。这种情况下,Exchange Server会减小“心跳”间隔到一个可接受的水平,但是数据只有达到这个临界点才能被同步。所以最好是保留默认值不动,首先防止超时发生。
这4个注册表项中最有趣的是HeartbeatIncrement。这一项决定了一次“心跳”间隔调整量的多少。默认情况下,HeartbeatIncrement值被设置为300秒(5分钟)。这也是微软的建议值。
你可以调整HeartbeatIncrement注册表项,但有一点棘手。如果你“心跳”增量设置得太高,Exchange Server会对“心跳”间隔做大的调整,这样可能会导致超时的出现(如果网络超时门限未知,或者HeartbeatMax值没有做相应设置)。
第二部分:在Exchange Server 2003 SP2中配置Direct Push
要在Exchange Server 2003 SP2中配置Direct Push技术,你显然必须运行Exchange 2003和升级维护包SP2。下面的步骤还假设你安装了SSL认证。技术上来说,这个配置在没有安装SSL的时候也是有效的,但用户的证书却是用明文发送的。
为Exchange Server配置Direct Push
1. 打开Exchange System Manager,在控制台树形目录中导航至Global Settings->Mobile Services。
2. 右键单击Mobile Services容器选择Properties(属性)
3. 列表上第一个复选框是允许用户发起同步的选项。这允许用户采用以前的基于SMS的技术手动同步他们的移动设备。
4. 下一个选项是“允许通过SMTP和文本消息发送最新通知”。这个复选框允许AUTD通知。使用Direct Push时,你不需要选择这个复选框。
5. 第三个复选框是“允许发送通知给用户指定的SMTP地址”。这个复选框是为以前的AUTD技术而设计的,使用Direct Push时用不到。(设计这一特性的目的是让你直接发送AUTD通知给移动设备的SMS地址--即使Exchange Server没有配置为与设备相关的移动运营商协同工作。)

6. 在Exchange ActiveSync部分的最后一个选项允许你通过HTTPS使用Direct Push。你必须选择这个复选框使Direct Push生效。
我花了一些时间来解释那些非Direct push选项的用途,因为很多机构都存在新旧移动设备混合的情况。你也许会发现不是所有移动设备都支持Direct Push,因此你必须结合AUTD使用Direct Push以支持你所有的移动用户。
7. 现在单击Device Security(设备安全)按钮来查看Device Security Settings(设备安全设置)对话框,如图B所示。Direct Push技术好处之一是允许你在移动设备上施加一个安全策略。你可以用这个对话框来为移动用户配置安全策略。
值得注意的是,Exchange Server 2003对每个移动用户使用同样的安全策略,但微软在Exchange Server 2007中改变了这一点。Exchange Server 2007允许你为每个用户配置移动设备安全设置。
Exchange Server 2003不像Exchange Server 2007那样允许你配置每个用户的移动设备安全策略。但如果你再看看图B的话,你会注意到有一个Exceptions(例外)按钮。点击这个按钮,你会进入一个免除安全策略的用户列表。但是,通常情况下,从安全的角度来讲,免除任意一个用户的安全策略都不是一个好主意。
8. 在Device Security对话框中,选择Enforce Password on Device复选框。
你能配置的其它安全设置包括Minimum Password Length (最小密码长度,按字符计算)和Require Both Numbers and Letters (要求数字和字母)选项,从字面意思就能很容易理解,但如果你不是很了解Direct Push的安全能力,那么其它设置就不是那么明显了。
下面是保留的安全设置列表及其功能:
● Inactivity Time (以分钟为单位)在指定的休止时间后自动锁定移动设备。
● Wipe the Device After Failed (以尝试次数为单位)防止对丢失或被盗设备的强力攻击。如果有人重复输入不正确的密码,移动设备会“硬”重启,恢复到工厂默认设置。管理员可以指定设备在重启之前密码允许出错的次数。
● Refresh Settings on the Device (以小时为单位) 强制移动设备周期性检查Exchange Server移动安全策略的改变。
● Allow Access to Devices that do not Fully Support Password Settings允许用户使用移动设备,即使他们缺乏实现安全性的必要软件。
第三部分:在Windows Mobile设备上配置Direct Push
一旦你在Exchange 2003 SP2服务器上配置了Direct Push技术,并选择了你的安全设置,下一步就该在你的移动设备上配置Direct Push了。
这些指导都是假设你手持移动设备运行的是带有消息和安全特性包(MSFP)的Windows Mobile 5.0或Windows Mobile 6.0。
如果你的移动设备运行的是Windows Mobile 5.0,继续之前你必须确定是否安装了MSFP包。要确定这一点,点击Start button(开始按钮)->Settings(设置)->About(关于)来查看移动设备的版本号信息。


仿真器运行的是Windows Mobile 6.0。但如果运行的是Windows Mobile 5.0,你要查看构建号以确定是否安装了MSFP。如果构建号的最后三位数字是2.0.0或更高,则移动设备安装了MSFP。如果MSFP没有安装,在继续下面的配置步骤前你得联系设备的生产商以获得更新。
在Windows Mobile设备上配置Direct Push
1. 配置Direct Push过程的第一步是进入移动设备的Start menu(开始菜单)->Programs(程序)->ActiveSync,可以看到如图D所示的消息。
2. 点击Set up Your Device to Sync With It链接,你将会被带到图E所示的屏幕。屏幕上询问服务器的地址,输入你OWA服务器的URL,减去HTTP或HTTPS的前缀。
     3. 在这个屏幕上,也有一个复选框告诉移动设备Exchange服务器要求一个HTTPS连接。如果你决定使用HTTPS,要确保你的SSL证书有效,并与你输入URL的域名相匹配。否则Direct Push不会配置成功。

4. 输入必要的URL和HTTPS信息后,按Next(下一步)按钮。
5. 这个屏幕简单地询问用户的验证证书。这里,要确保你选择了Save Password(保存密码)的复选框。如果没有选择这个复选框,移动设备就没有办法与Exchange Server进行身份验证。(当用户改变他们的域密码时,他们得手动改变存储在移动设备上的密码以求匹配。密码不会自动同步。)
6. 现在不要担心点击Advanced(高级)按钮。高级配置选项允许你简单地配置事件记录,如果有多个连接可选的话,选择你想使用的连接。
7. 点击Next(下一步)来确定你想同步的数据类型,如图G所示。你可以通过选择相应的复选框来使同步联系人,日程表,电子邮件和任务选项生效。
8. 先不要点击Finish来完成配置过程,现在选择Email选项,点击Settings按钮来选择与移动设备同步的email数量。你在这里还可以设置消息大小的限制,控制是否下载附件。
    9. 点击屏幕上的Advanced(高级)按钮,设置加密或标记出站电子邮件的选项。但是为了使用这些设置,你必须拥有能在该移动设备使用上的证书。
10. 点击Finish,移动设备会启动同步进程。在这个过程中,你可能会被提示输入移动设备的密码。
11. 当同步过程完成时,你需要做的最后一件事是设置ActiveSync,使其正常工作。在ActiveSync屏幕上,点击Menu按钮(在屏幕右下角),选择Schedule选项,如图I所示。默认情况下,移动设备在高峰时段每10分钟同步一次,在非高峰时段每4个小时同步一次。为了设置Direct Push正常工作,这两个选项都应该改为As Items Arrive。

Direct Push

Push是相对Pull来说的,传统的Email实际上就是一种Pull的方式,主动权在用户,用户在他们登陆邮箱的时候,会询问邮件服务器是否有新的邮件,如果有新的邮件,用户端会去查收(下载)新的Email至收件箱。可以这么认为:

Pull==User Request + Server Push

不过,既然邮件本身就是从发件方到收件方的讯息,为什么不能像短消息(SMS)一样直接Push给用户呢?其实这也就是传统的Pull方式存在的意义:

客户端是灵活的

邮件服务器存在的一个必要性就是它总是连接到网络的,而用户是随机接入的。邮件服务器不可能也不必要给用户定址,因为用户只是偶尔接入而且可能每次接入的网络都不一样。当新的邮件到达的时候,邮件服务器无法确定新的邮件应该被派送到哪个地址。所以只能是以用户主动请求。常见的Post Office Protocol(POP3),就是这样一种基于Pull方式的邮件协议。

Internet Message Access Protocol (IMAP)则提供了对邮件提醒(询问)功能的支持,当邮件客户端收到一个来自Server的提醒时,它可以选择是否去Server获取新数据。能够选择是否获取新邮件,这是IMAP的一个主要特性。这种方式显然要比纯Pull的系统要灵活一些。不过另一方面,这种带提醒的消息方式无疑增加了往返的交互次数,这稍稍显得有些繁琐。

下面该谈谈本文的主角了---Direct Push

Direct PushExchange Server 2007中内建的一个特征。它是用来使移动设备通过运营商的蜂窝网络连接,与特定的Server保持一个总是更新着(Always-Up-To-Date)的状态。

 



 Tips
事实上在Exchange Server 2003 SP2的时候就引入了Direct Push的概念:可以参考http://msdn2.microsoft.com/en-us/library/aa446486.aspx

Direct Push引入了一个主动提醒的机制,你可以称它为“主动的IMAPJ,这种机制使得每当有新的内容待同步到设备上的时候,设备会收到一个提示(信息)。

Direct Push的条件

1 移动设备

首先,你的移动设备必须是支持Direct Push的,一般来说OEM会把这点明显强调一些。比如我的i718开机的时候会有一个“Direct Push Technology”的Logo。这种支持说得详细一些就是要满足以下条件之一

Ø         一台具有电话功能并带有Messaging & Security Feature Pack (MSFP)Windows Mobile 5.0设备(当然更高版本的亦可)。

Ø         一台具有电话功能,由Microsoft Exchange ActiveSync授权并专为兼容Direct Push而设计的移动设备(不一定是Windows Mobile的设备)。

2)服务器

Exchange Server 2007

Direct Push概述

下面来看看一个典型的Push Mail的工作过程是怎样的。默认情况下,Direct PushExchange2007中是被启用的。那些支持Direct Push的移动设备向Exchange Server发起一个HTTPS的长连接请求。同时,Exchange Server对它的用户们的邮箱活动进行监视,并能够在邮箱状态变化的时候给移动设备发送一个回应。

这里说的“邮箱状态变化”的范围是很广的,可能是新邮件到来,可能是删除了邮件,也可能是日程表或者联系人的任何变化。

如果这样一些改变发生在那个HTTPS长连接请求的生命周期内,Exchange Server会立即发起一个回应给用户的移动终端,提醒该移动设备有了新的变化,须要重新同步移动设备到Exchange Server以获取更新的信息,然后移动设备会发起一个同步的请求给server。同步完成以后,一条新的长连接HTTPS的请求又会生成,如此反复。这样反复的请求,保证了用户的Email,日历,联系人和任务等信息都会相对及时地被PushMobile设备,使得用户即便不在PC机前也可以与Exchange server保持一个同步更新的状态。

Direct Push 拓扑结构

2描述了一个典型的Exchange Server 2007Direct Push配置的拓扑结构。



 图
2 Direct Push的网络模型

下面我们对照图2来看看Direct Push的运作方式:

1)     一台已经配置为与某Exchange Server 2007同步的移动设备发起一个HTTPS的请求给服务器。这个请求就是我们通常所说的Ping。这个请求告诉服务器,请它在接下来的15分钟内,当邮件服务器上用户的任何文件夹发生任何改变的时候给我们的移送设备发送一个提醒。接下来的时间我们的移动设备就处于待命状态,等待消息。这里的15分钟的间隔,就是所谓的心跳(heartbeat)间隔。

2)     如果在这15分钟内,没有任何条目发生改变,服务器会返回一个HTTP 200ok消息。我们的移动设备收到这个消息,返回到活动状态,并重新发起请求。

3)     15分钟的heartbeat中,如果有任何改变或者收到新的条目,服务器会发送一个响应通知移动设备有新邮件或者邮箱的某些条目改变了,并告诉移动设备发生改变的文件夹的名字。移动设备收到这条消息之后,它会发起一个与有变动的文件夹同步的请求,与服务器上的更新内容同步。在同步完成的时候,移动设备又会发起一个新的ping请求,于是又开始一段新的heartbeat

Direct Push的校正机制

Direct Push依赖于一个支持HTTPS长连接的网络环境。如果移动设备的网络或者防火墙不支持长连接的HTTPS请求会怎么办呢?下面来看看Direct Push在传输网络超时时间小于heartbeat时间的情况下是如何工作的:

(我们先假设移动设备所在网络超时时间为13分钟)

1)     移动设备发起一个HTTPS的长连接请求给服务器。希望在接下来的15分钟内,邮件服务器上用户的文件夹有任何变化的时候能得到一个提醒。如果没有变化,服务器就应返回一个HTTP 200OK消息,这一步跟前面是完全一样的。

2)     如果在这15分钟内,服务器没有任何回应给移动设备,移动设备会推断出可能是到服务器的连接超时了。它会重新发起一个HTTPS的请求,但是这一次它会使用一个只有8分钟的heartbeat的请求。

3)     8分钟之后,服务器发送一个HTTP 200 OK的消息。然后设备又会尝试发起一个更长些(12分钟)HTTPS请求给服务器。

4)     如果在这12分钟的时间内,收到了一条新的邮件,服务器会发送给移动设备一个提醒,提示有新内容待同步了。然后,设备会与服务器进行同步,并重新发起这个12分钟的请求。

5)     如果在12分钟后,没有收到任何新的或者变化的内容,服务器会回复一个HTTP 200OK消息。然后设备会推断出当前的网络状况是支持12分钟heartbeat的,它会继续尝试使用更长(16分钟)的连接。

6)     16分钟后,又没有任何回应了。这时,移动设备会推断出当前的网络不支持16分钟的heartbeat。因为这次超时发生在设备尝试增加heartbeat间隔之后,移送设备知道已经达到了当前网络的最大超时间隔,设备不会又减少间隔时间来重复操作,而是会取上一次成功的heartbeat时间(12分钟),重新发起12分钟的heartbeat

总而言之,移动设备保存了它的Ping请求的日志,它会以某种算法尝试使用允许的最长的heartbeat间隔来发起连接请求。这一方面增加了待机时间(每一个请求后,如果用户没有其他的操作设备会挂起),一方面减少了网络流量。

心跳连接的时间可以在移动设备的注册表中找到

配置跨越防火墙工作的Direct Push

几乎没有哪个企业的内部网是直接接入到Internet的,通常都会有一台服务器充当着防火墙的角色。为了让Direct Push的工作不受防火墙的阻挠,你必须先打开TCP 端口 443,这是SSL的需要。必须保证在用户访问服务器和internet之间该端口是打开的。

除了在防火墙打开必要的端口之外,为了提高Direct Push的性能,应当增加防火墙超时时间值,如果防火墙关闭会话(Session),邮件就不会被投递出去,直到下一次连接。所以防火墙会话(Session)时间应当被设置为比运营商的网络空闲超时时间隔大一些的范围。一般在1530分钟之间。从前面的分析我们可以得知,很显然,越短的超时时间会导致移动设备更加频繁的连接请求,这会降低待机时间,增加网络流量。



本文转自sucre03 51CTO博客,原文链接:http://blog.51cto.com/sucre/382234,如需转载请自行联系原作者

相关文章
|
23天前
|
编译器 程序员 C++
【C/C++ 容器操作】C++高效编程:掌握emplace_back与push_back的使用和机制
【C/C++ 容器操作】C++高效编程:掌握emplace_back与push_back的使用和机制
63 0
|
8月前
|
芯片
clock oscillator,generator,buffer选型杂谈
clock oscillator,generator,buffer选型杂谈
|
11月前
|
机器学习/深度学习 Ubuntu 数据挖掘
带你读《Elastic Stack 实战手册》之60:——3.5.16.4.Data frame analytics(4)
带你读《Elastic Stack 实战手册》之60:——3.5.16.4.Data frame analytics(4)
|
11月前
|
机器学习/深度学习 安全 测试技术
带你读《Elastic Stack 实战手册》之60:——3.5.16.4.Data frame analytics(1)
带你读《Elastic Stack 实战手册》之60:——3.5.16.4.Data frame analytics(1)
|
11月前
|
定位技术 索引
带你读《Elastic Stack 实战手册》之60:——3.5.16.4.Data frame analytics(2)
带你读《Elastic Stack 实战手册》之60:——3.5.16.4.Data frame analytics(2)
|
11月前
|
机器学习/深度学习 索引
带你读《Elastic Stack 实战手册》之60:——3.5.16.4.Data frame analytics(3)
带你读《Elastic Stack 实战手册》之60:——3.5.16.4.Data frame analytics(3)
|
11月前
|
API 索引
带你读《Elastic Stack 实战手册》之28:——3.4.2.13.Rollover API(4)
带你读《Elastic Stack 实战手册》之28:——3.4.2.13.Rollover API(4)
110 0
|
11月前
|
API 索引
带你读《Elastic Stack 实战手册》之28:——3.4.2.13.Rollover API(5)
带你读《Elastic Stack 实战手册》之28:——3.4.2.13.Rollover API(5)
|
11月前
|
API 索引
带你读《Elastic Stack 实战手册》之28:——3.4.2.13.Rollover API(3)
带你读《Elastic Stack 实战手册》之28:——3.4.2.13.Rollover API(3)
|
存储 安全 Cloud Native
Back to Basic,定义下一代的云
2022年6月13日举办的2022阿里云峰会上,阿里云宣布今年最重要策略是“B2B”,也就是“Back to Basic”,回到云计算的本质,坚持在技术的长征路上,不断取得新的突破。如今云计算已经进入了一个关键的突破期,如果我们定义好下一代的云,那么中国云计算就有超车机会。
955 11
Back to Basic,定义下一代的云