CN105897439A - 一种消息推送的方法与设备 - Google Patents

Abstract

本申请的目的是提供一种消息推送的方法与设备。与现有技术相比，本申请中服务器在向用户设备推送新消息之前，会先向用户设备发送取消息的通知信息，而这个取消息的通知信息相对于消息本身来说就会短小很多，因而消耗系统资源也较小，而且不必保证到达性或者进行确认，可以重复发送，优化了网络流量和资源消耗的问题，降低了应用于移动设备和移动网络环境中的流量消耗。同时，本申请需要用户设备基于通知信息发送确认信息，服务器再根据所述确认信息向所述用户设备推送所述消息，保证了连接与内容的完整性，避免了漏消息情况的发生。

Description

一种消息推送的方法与设备

技术领域

本申请涉及计算机领域，尤其涉及一种消息推送的技术。

背景技术

随着互联网，特别是移动互联网的高速发展，消息推送的技术层出不穷。在现今移动互联应用中实现消息推送的方法一般有：

(1)基于XMPP的开源解决方案来实现消息推送。XMPP是以XML方式描述的及时消息通讯开放标准协议，直接采用该开源方案实现消息推送，比如Tigase等。

(2)基于Socket的TCP/IP长链接的自定义协议来实现消息推送。用户使用的客户端通过Socket和服务器建立TCP/IP的长链接，采用自定义的通讯协议，实现和服务器端的双向及时通讯。

(3)基于网络的推送服务来实现消息推送。采用在互联网上提供的推送服务，无需实现服务端，下载客户端的SDK集成到APP应用中，连接到指定的互联网上的服务器，就可以进行消息推送。

这三种方法虽然都可以实现对移动设备的消息推送，但在应用于具体产品开发以及项目实施上时都有一定的局限性，局限性主要有：

(1)XMPP采用的是XML文本表示，由于协议本身很庞杂，产生的网络流量比较大，因而在移动设备和移动网络环境下不占优势。用户集成、功能扩展、管理能力等定制化功能的实现上都需要在代码级进行修改，开源虽有提供源代码，但是在此基础上进行修改的工作量和难度很大。另外，在Tigase的开源实现中，在网络不稳定的环境中，存在漏消息的情况。

(2)基于Socket的TCP/IP长链接的自定义协议实现消息推送的方法等于完全自己开发，但是使用的是Socket连接开发的通讯协议，此种情况下对于传递参数、断网重连等细节的开发，容易产生错误。另外，后台服务器需要维护每一个Socket连接，在大并发的情况下，系统消耗就会比较大。

(3)基于网络的推送服务实现消息推送的方法中，存在功能扩展和定制化的瓶颈，并且推送的内容要在第三方服务器上保存，安全性难以得到保障。

发明内容

本申请的一个目的是提供一种消息推送的方法与设备。

根据本申请的一个方面，提供了一种在服务器端实现消息推送的方法，其中，该方法包括：

向用户设备发送取消息的通知信息；

接收所述用户设备基于所述通知信息发送的确认信息；

根据所述确认信息向所述用户设备推送所述消息。

根据本申请的一个方面，还提供了一种在用户设备端实现消息推送的方法，其中，该方法包括：

接收由服务器发送的取消息的通知信息；

基于所述通知信息向所述服务器发送确认信息；

接收所述服务器根据所述确认信息推送的所述消息。

根据本申请的另一方面，还提供了一种在服务器端实现消息推送的设备，其中，该设备包括：

第一装置，用于向用户设备发送取消息的通知信息；

第二装置，用于接收所述用户设备基于所述通知信息发送的确认信息；

第三装置，用于根据所述确认信息向所述用户设备推送所述消息。

根据本申请的另一方面，还提供了一种在用户设备端实现消息推送的设备，其中，该设备包括：

第六装置，用于接收由服务器发送的取消息的通知信息；

第七装置，用于基于所述通知信息向所述服务器发送确认信息；

第八装置，用于接收所述服务器根据所述确认信息推送的所述消息。

与现有技术相比，本申请中服务器在向用户设备推送新消息之前，会先向用户设备发送取消息的通知信息，而这个取消息的通知信息相对于消息本身来说就会短小很多，因而消耗系统资源也较小，而且不必保证到达性或者进行确认，可以重复发送，优化了网络流量和资源消耗的问题，降低了应用于移动设备和移动网络环境中的流量消耗。同时，本申请需要用户设备基于通知信息发送确认信息，服务器再根据所述确认信息向所述用户设备推送所述消息，保证了连接与内容的完整性，避免了漏消息情况的发生。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1示出一种消息推送系统的通信拓扑图；

图2示出根据本申请一个方面的一种消息推送的方法流程图；

图3示出根据本申请一个优选实施例的一种消息推送的方法流程图；

图4示出根据本申请另一方面的一种消息推送的设备示意图；

图5示出根据本申请另一优选实施例的一种消息推送的设备示意图。

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本申请作进一步详细描述。

在本申请一个典型的配置中，终端、服务网络的设备和可信方均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

图1示出一种消息推送系统的通信拓扑图。该系统中，服务器1与一个或者多个作为客户端的用户设备2之间相互通信，以实现消息的推送。具体地，服务器1向用户设备2发送取消息的通知信息；用户设备2接收由服务器1所发送的取消息的通知信息，并基于所述通知信息向所述服务器1发送确认信息；随后，服务器1接收所述用户设备2基于所述通知信息发送的确认信息，并根据所述确认信息向所述用户设备2推送所述消息；接着，用户设备2接收所述服务器1根据所述确认信息推送的所述消息。

在此，用户设备包括但不限于电脑、智能手机、PDA等客户端设备；所述服务器其包括但不限于计算机、网络主机、单个网络服务器、多个网络服务器集或多个网络服务器构成的云；在此，云由基于云计算(CloudComputing)的大量计算机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个虚拟超级计算机。这些用户设备或服务器可单独运行来实现本申请，也可接入网络并通过与网络中的其他设备的交互操作来实现本申请。

需要说明的是，所述用户设备和服务器等仅为举例，其他现有的或今后可能出现的计算机设备如可适用于本申请，也应包含在本申请保护范围以内，并以引用方式包含于此。

图2示出根据本申请一个方面的一种消息推送的方法流程图。

具体地，在步骤S11中，服务器1向用户设备2发送取消息的通知信息；在步骤S21中，用户设备2接收由服务器1发送的取消息的通知信息；在步骤S22中，用户设备2基于所述通知信息向所述服务器1发送确认信息；在步骤S12中，服务器1接收所述用户设备2基于所述通知信息发送的确认信息；在步骤S13中，服务器1根据所述确认信息向所述用户设备2推送所述消息；在步骤S23中，用户设备2接收所述服务器1根据所述确认信息推送的所述消息。

在步骤S11中，服务器1向用户设备2发送取消息的通知信息。

在此，所述服务器1如果有新消息需要推送给所述用户设备2的话，所述服务器1首先会向所述用户设备2发送一个简短的取消息的通知信息，比如说，所述服务器1有一个文档消息需要推送给所述用户设备2的话，那么在服务器1推送所述文档消息之前，所述服务器1会先发送一个类似于“您有一文档消息，是否获取？”的简短的通知信息给所述用户设备2。

在步骤S21中，用户设备2接收由服务器1发送的取消息的通知信息。

在此，当所述服务器1存储有新消息需要推送给所述用户设备2的时候，所述服务器1会先向所述用户设备2发送取消息的通知信息来告知所述用户设备2其有新消息待获取，所述用户设备2就会接收到一个取消息的通知信息。

在步骤S22中，用户设备2基于所述通知信息向所述服务器1发送确认信息。

在此，所述用户设备2在接收到所述服务器1发送的取消息的通知信息后，如果所述用户设备2选择获取所述消息的话，所述用户设备2就可以向所述服务器1发送确认信息，表明其想要获取所述消息。比如说，所述通知信息为“您有新消息，是否获取？”，如果所述用户设备2选择获取所述消息的话，其可以通过回复“是/yes”来向所述服务器1发送确认信息；再比如说，所述用户设备2在接收到服务器1所发送的通知信息后，也可以直接点击获取所述消息，这种直接点击获取同样属于用户设备2向服务器1发送确认信息的一种形式。

优选地，在步骤S11中，服务器1若未接收到所述用户设备2基于所述通知信息发送的确认信息，则每隔预设时间向用户设备2发送取消息的通知信息。

在此，在所述服务器1向所述用户设备2发送取消息的通知信息后，如果所述用户设备2想要获取所述信息，所述用户设备2即会向所述服务器1发送确认信息，并取走所述消息。如果，所述服务器1没有收到所述用户设备2所发送的确认信息，则说明所述用户设备2没有获取所述消息，所述消息仍然存储于所述服务器1中，而并没有被所述用户设备2取走，此时所述服务器1就会每隔预设时间向所述用户设备2发送取消息的通知信息，直到所述服务器1中的所述消息已被所述用户设备2所获取。假设预设时间为30秒的话，如果说所述用户设备2并没有获取所述消息、所述消息仍储存于所述服务器1的话，则所述服务器1每隔30秒就会向所述用户设备2发送一个取消息的通知信息，若在此期间所述用户设备2获取了所述消息，则所述服务器1就会删除所述消息，并停止所述消息的取消息的通知信息的发送。

优选地，在取消息的通知信息的发送上，服务器1尤其通过udp协议(UserDatagram Protocol的简称，中文名是用户数据报协议)发送所述通知信息，即在步骤S11中，服务器1通过udp协议向用户设备2发送取消息的通知信息。在此，因为udp协议是一种无连接的协议，适合于在移动设备和大并发的环境下使用，同时，也因为udp协议是一个轻量级的通讯协议，其可以实现在移动类型设备应用时降低能耗，优化了能耗的问题，因而，在取消息的通知信息的发送上，服务器1尤其是通过udp协议发送所述通知信息。

在步骤S12中，服务器1接收所述用户设备2基于所述通知信息发送的确认信息。

在此，所述服务器1在向所述用户设备2发送取消息的通知信息后，如果所述用户设备2需要获取所述消息且向所述服务器1发送了获取所述消息的确认信息的话，所述服务器1即会接收到所述用户设备2发送的所述确认信息。

在步骤S13中，服务器1根据所述确认信息向所述用户设备2推送所述消息。

在此，所述服务器1接收到所述用户设备2发送的确认信息之后，即说明所述用户设备2向所述服务器1表明其想要获取所述消息，因而所述服务器1就会向所述用户设备2推送所述消息，并在消息推送完成以后，也就是所述用户设备2已经获取了所述消息之后，所述服务器1就会将所述消息从服务器1中移除。

优选地，在推送所述消息时，服务器1尤其通过http协议、https协议将所述消息推送给所述用户设备2，即在步骤S13中，服务器1通过http协议或https协议，根据所述确认信息向所述用户设备2推送所述消息。

在步骤S23中，用户设备2接收所述服务器1根据所述确认信息推送的所述消息。

在此，在所述服务器1完成消息的推送之后，所述用户设备2就可以接收到所述服务器1推送的所述消息。

优选地，该方法还包括步骤S14和S26(图中均未示出)；在步骤S14中，用户设备2每隔预设时间向服务器1发送心跳包。

在此，所述用户设备2每隔预设时间通过传输协议，尤其是通过如udp协议，向所述服务器1发送心跳包(心跳包就是在用户设备和服务器间定时通知对方自己状态的一个自己定义的命令字)来判断双方是否处于连接状态。比如说，预设的时间间隔为5秒的话，则所述用户设备2每隔5秒就会向所述服务器1发送一个心跳包，根据所述服务器1的回复情况来确认自己与所述服务器1之间的连接关系是否断开。

在步骤S26中，服务器1接收所述用户设备2发送的心跳包。

在此，所述服务器1会接收所述用户设备2每隔预设时间通过传输协议，尤其是通过udp协议所发送的心跳包，并基于此做出相应的回复。

图3示出根据本申请一个优选实施例的一种消息推送的方法流程图。

在该实施例中，该方法还包括步骤S10’、步骤S24’和步骤S25’。以下参照该优选实施例进行详细描述：具体地，在步骤S10’中，服务器1从第三方设备获取待推送的消息；在步骤S11’中，服务器1向用户设备2发送取消息的通知信息；在步骤S21’中，用户设备2接收由服务器1发送的取消息的通知信息；在步骤S22’中，用户设备2基于所述通知信息向所述服务器1发送确认信息；在步骤S12’中，服务器1接收所述用户设备2基于所述通知信息发送的确认信息；在步骤S13’中，服务器1根据所述确认信息向所述用户设备2推送所述消息；在步骤S23’中，用户设备2接收所述服务器1根据所述确认信息推送的所述消息；在步骤S24’中，用户设备2将当前获取的消息的消息序号与前一次所获取的消息的消息序号进行比对，得到比对结果信息；在步骤S25’中，用户设备2在若所述比对结果信息为所述当前获取的消息的消息序号大于前一次所获取的消息的消息序号，则保存所述当前获取的消息；否则，丢弃所述当前获取的消息。其中，步骤S11’、步骤S12’、步骤S13’、步骤S21’、步骤S22’、步骤S23’与图2中所述步骤S11、步骤S12、步骤S13、步骤S21、步骤S22、步骤S23相同或基本相同，故此处不再赘述，并通过引用的方式包含于此。

其中，在步骤S10’中，服务器1从第三方设备获取待推送的消息。

在此，在所述服务器1向所述用户设备2发送取消息的通知之前，所述服务器1需要先获取需要推送给所述用户设备2的新消息，并将所述新消息保存于所述服务器1中。比如说，第三方设备，尤其指另一个用户设备，需要发送消息给所述用户设备2的话，该第三方设备会先通过传输协议，尤其通过http协议、https协议或者自定义的socket协议，将所述新消息保存于所述服务器1中，然后再由所述服务器1将所述新消息推送给所述用户设备2。

在步骤S24’中，用户设备2将当前获取的消息的消息序号与前一次所获取的消息的消息序号进行比对，得到比对结果信息。

在此，所述消息包括消息序号，即用户设备所获取的消息包括消息序号和消息内容。在用户设备2获取消息之后，会将当前所获取的消息的消息序号与用户前一次所获取的消息的消息序号进行比对，得到一个当前所获取的消息的消息序号与前一次所获取的消息的消息序号大小关系的比对结果。

在步骤S25’中，用户设备2在若所述比对结果信息为所述当前获取的消息的消息序号大于前一次所获取的消息的消息序号，则保存所述当前获取的消息；否则，丢弃所述当前获取的消息。

具体的，经过比对后，如果得到的比对结果为当前所获取的消息的消息序号大于前一次所获取的消息的消息序号的话，则说明当前所获取的消息属于新消息，所述用户设备2之前没有获得过该消息，因而所述用户设备2就存储当前所获取的消息；如果得到的比对结果为当前所获取的消息的消息序号等于或者小于前一次所获取的消息的消息序号的话，则说明所述用户设备2已经获取过当前所获取的消息，即当前所获取的消息对于所述用户设备2来说已经不是新消息了，因而所述用户设备2就会丢弃该消息，不再进行储存。

比如说，当前所获取的消息的消息序号为9，而前一次所获取的消息的消息序号为8，因当前所获取的消息的消息序号9大于前一次所获取的消息的消息序号8，则说明当前所获取的消息序号为9的消息所述用户设备2之前并没有获取过，其对于所述用户设备2来说属于新消息，因而所述用户设备2就会存储当前所获取的消息序号为9的消息；再比如说，当前所获取的消息的消息序号为8，而前一次所获取的消息的消息序号为8，因当前所获取的消息的消息序号8等于前一次所获取的消息的消息序号8，也就是说，当前所获取的消息序号为8的消息所述用户设备2已经获取过，其对于所述用户设备2来说不是新消息，因而所述用户设备2就会丢弃当前获取的序号为8的消息，不再进行保存。

图4示出根据本申请一个方面的一种消息推送的设备示意图。

其中，服务器1包括第一装置11、第二装置12和第三装置13；用户设备2包括第六装置21、第七装置22和第八装置23。

其中，服务器1中的第一装置11向用户设备2发送取消息的通知信息。

在此，所述服务器1如果有新消息需要推送给所述用户设备2的话，所述服务器1中的第一装置11首先会向所述用户设备2发送一个简短的取消息的通知信息，比如说，所述服务器1有一个文档消息需要推送给所述用户设备2，那么在推送所述文档消息之前，所述服务器1中的第一装置11就会先发送一个类似于“您有一个文档消息，是否获取？”的简短的通知信息给所述用户设备2。

用户设备2中的第六装置21接收由服务器1发送的取消息的通知信息。

在此，当所述服务器1存储有新消息需要推送给所述用户设备2的时候，所述服务器1中的第一装置11会先向所述用户设备2发送取消息的通知信息来告知所述用户设备2其有新消息待获取，所述用户设备2中的第六装置21就会接收到一个取消息的通知信息。

用户设备2中的第七装置22基于所述通知信息向所述服务器1发送确认信息。

在此，所述用户设备2中的第七装置22在接收到所述服务器1中的第一装置11发送的取消息的通知信息后，如果所述用户设备2选择获取所述消息的话，所述用户设备2中的第七装置22可以向所述服务器1发送确认信息，表明其想要获取所述消息。比如说，所述通知信息为“您有新消息，是否获取？”，如果所述用户设备2选择获取所述消息的话，其可以通过回复“是/yes”来向所述服务器1发送确认信息；再比如说，所述用户设备2在接收到服务器1所发送的通知信息后，也可以直接点击获取所述消息，这种直接点击获取同样属于用户设备2向服务器1发送确认信息的一种形式。

优选地，服务器1中的第一装置11若未接收到所述用户设备2基于所述通知信息发送的确认信息，则每隔预设时间向用户设备2发送取消息的通知信息。

在此，在所述服务器1中的第一装置11向所述用户设备2发送取消息的通知信息后，如果所述用户设备2想要获取所述信息，所述用户设备2即会向所述服务器1发送确认信息，并取走所述消息。如果，所述服务器1中的第一装置11没有收到所述用户设备2所发送的确认信息，则说明所述用户设备2没有获取所述消息，所述消息仍然存储于所述服务器1中，并没有被取走，此时所述服务器1中的第一装置11就会每隔预设时间向所述用户设备2发送取消息的通知信息，直到所述服务器1中的所述消息已被所述用户设备2所获取。假设预设时间为30秒的话，如果说所述用户设备2并没有获取所述消息、所述消息仍储存于所述服务器1的话，则所述服务器1中的第一装置11每隔30秒就会向所述用户设备2发送一个取消息的通知信息，若在此期间所述用户设备2获取了所述消息，则所述服务器1就会删除所述消息，并停止所述消息的取消息的通知信息的发送。

优选地，在取消息的通知信息的发送上，服务器1尤其通过udp协议(UserDatagram Protocol的简称，中文名是用户数据报协议)发送所述通知信息，即服务器1中的第一装置11通过udp协议向用户设备2发送取消息的通知信息。在此，因为udp协议是一种无连接的协议，适合于在移动设备和大并发的环境下使用，同时，也因为udp协议是一个轻量级的通讯协议，其可以实现在移动类型设备应用时降低能耗降，优化了能耗的问题，因而，在取消息的通知信息的发送上，服务器1中的第一装置11尤其是通过udp协议发送所述通知信息。

服务器1中的第二装置12接收所述用户设备2基于所述通知信息发送的确认信息。

在此，所述服务器1中的第一装置11在向所述用户设备2发送取消息的通知信息后，如果所述用户设备2需要获取所述消息且向所述服务器1发送了获取所述消息的确认信息的话，所述服务器1中的第二装置12即会接收到所述用户设备2所发送的所述确认信息。

服务器1中的第三装置13根据所述确认信息向所述用户设备2推送所述消息。

在此，所述服务器1中的第二装置12接收到所述用户设备2所发送的确认信息之后，即说明所述用户设备2向所述服务器1表明其想要获取所述消息，因而所述服务器1中的第三装置13就会向所述用户设备2推送所述消息，并在消息推送完成以后，也就是所述用户设备2已经获取了所述消息之后，所述服务器1就会将所述消息从服务器1中移除。

优选地，在推送所述消息时，服务器1中的第三装置13尤其通过http协议或者https协议将所述消息推送给所述用户设备2，即服务器1中的第三装置13通过http协议或者https协议，根据所述确认信息向所述用户设备2推送所述消息。

用户设备2中的第八装置23接收所述服务器1根据所述确认信息推送的所述消息。

在此，在所述服务器1中的第三装置13完成消息的推送之后，所述用户设备2中的第八装置23就可以接收到所述服务器1中的第三装置13所推送的所述消息。

优选地，服务器1还包括第五装置14(图中未示出)；用户设备2还包括第十一装置26(图中未示出)；具体地，用户设备2中的第十一装置26每隔预设时间向服务器1发送心跳包。

在此，所述用户设备2中的第十一装置26每隔预设时间通过传输协议，尤其是通过udp协议，向所述服务器1发送心跳包(心跳包就是在用户设备和服务器间定时通知对方自己状态的一个自己定义的命令字)来判断双方是否处于连接状态。比如说，预设的时间间隔为5秒的话，则所述用户设备2中的第十一装置26每隔5秒就会向所述服务器1发送一个心跳包，根据所述服务器1的回复情况来确认自己与所述服务器1之间的连接关系是否断开。

服务器1中的第五装置14接收所述用户设备2中的第十一装置26发送的心跳包。

在此，所述服务器1中的第五装置14会接收所述用户设备2中的第十一装置26每隔预设时间，通过传输协议，尤其是通过udp协议所发送的心跳包，并基于此做出相应的回复。

图5示出根据本申请一个优选实施例的一种消息推送的方设备示意图。

在该实施例中，服务器1还包括第四装置10’；用户设备2还包括第九装置14’和第十装置15’。以下参照该优选实施例进行详细描述：具体地，服务器1中的第四装置10’从第三方设备获取待推送的消息；服务器1中的第一装置11’向用户设备2发送取消息的通知信息；用户设备2中的第六装置21’接收由服务器1中的第一装置11’发送的取消息的通知信息；用户设备2中的第七装置22’基于所述通知信息向所述服务器1发送确认信息；服务器1中的第二装置12’接收所述用户设备2中的第七装置22’基于所述通知信息发送的确认信息；服务器1中的第三装置13’根据所述确认信息向所述用户设备2推送所述消息；用户设备2中的第八装置23’接收所述服务器1中的第三装置13’根据所述确认信息推送的所述消息；用户设备2的第九装置24’将当前获取的消息的消息序号与前一次所获取的消息的消息序号进行比对，得到比对结果信息；用户设备2中的第十装置25’在若所述比对结果信息为所述当前获取的消息的消息序号大于前一次所获取的消息的消息序号，则保存所述当前获取的消息；否则，丢弃所述当前获取的消息。其中，服务器1中的第一装置11’、第二装置12’及第三装置13’，用户设备2中的第六装置21’、第七装置22’及第八装置23’与图4中的对应装置相同或基本相同，故此处不再赘述，并通过引用的方式包含于此。

其中，服务器1中的第四装置10’从第三方设备获取待推送的消息。

在此，在所述服务器1向所述用户设备2发送取消息的通知之前，所述服务器1需要先获取需要推送给所述用户设备2的新消息，并将所述新消息保存于所述服务器1中。比如说，第三方设备，尤其是另一个用户设备，需要发送消息给所述用户设备2的话，该第三方设备会先通过传输协议，尤其通过http协议、https协议或者自定义的socket协议，将所述新消息保存于所述服务器1中的第四装置10’，然后再由所述服务器1将所述新消息推送给所述用户设备2。

用户设备2中的第九装置24’将当前获取的消息的消息序号与前一次所获取的消息的消息序号进行比对，得到比对结果信息。

在此，所述消息包括消息序号，即用户设备2所获取的消息包括消息序号和消息内容。在用户设备2获取消息之后，会将当前所获取的消息的消息序号与用户前一次所获取的消息的消息序号进行比对，得到一个当前所获取的消息的消息序号与前一次所获取的消息的消息序号大小关系的比对结果。

用户设备2中的第十装置25’在若所述比对结果信息为所述当前获取的消息的消息序号大于前一次所获取的消息的消息序号，则保存所述当前获取的消息；否则，丢弃所述当前获取的消息。

具体的，经过比对后，如果得到的比对结果为当前所获取的消息的消息序号大于前一次所获取的消息的消息序号的话，则说明当前所获取的消息属于新消息，所述用户设备2之前没有获得过该消息，因而所述用户设备2中的第十装置25’就存储当前所获取的消息；如果得到的比对结果为当前所获取的消息的消息序号等于或者小于前一次所获取的消息的消息序号的话，则说明所述用户设备2已经获取过当前所获取的消息，即当前所获取的消息对于所述用户设备2来说已经不是新消息了，因而所述用户设备2中的第十装置25’就会丢弃该消息，不再进行储存。

比如说，当前所获取的消息的消息序号为9，而前一次所获取的消息的消息序号为8，因当前所获取的消息的消息序号9大于前一次所获取的消息的消息序号8，则说明当前所获取的消息序号为9的消息所述用户设备2之前并没有获取过，其对于所述用户设备2来说属于新消息，因而所述用户设备2中的第十装置25’就会存储当前所获取的消息序号为9的消息；再比如说，当前所获取的消息的消息序号为8，而前一次所获取的消息的消息序号为8，因当前所获取的消息的消息序号8等于前一次所获取的消息的消息序号8，也就是说，当前所获取的消息序号为8的消息所述用户设备2已经获取过，其对于所述用户设备2来说不是新消息，因而所述用户设备2中的第十装置25’就会丢弃当前获取的序号为8的消息，不再进行保存。

与现有技术相比，本申请中服务器在向用户设备推送新消息之前，会先向用户设备发送取消息的通知信息，而这个取消息的通知信息相对于消息本身来说就会短小很多，因而消耗系统资源也较小，而且不必保证到达性或者进行确认，可以重复发送，优化了网络流量和资源消耗的问题，降低了应用于移动设备和移动网络环境中的流量消耗。同时，本申请需要用户设备基于通知信息发送确认信息，服务器再根据所述确认信息向所述用户设备推送所述消息，保证了连接与内容的完整性，避免了漏消息情况的发生。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (18)

1.一种在服务器端实现消息推送的方法，其中，该方法包括：

向用户设备发送取消息的通知信息；

接收所述用户设备基于所述通知信息发送的确认信息；

根据所述确认信息向所述用户设备推送所述消息。

2.根据权利要求1所述的方法，其中，向用户设备发送取消息的通知信息之前，还包括：

从第三方设备获取待推送的消息。

3.根据权利要求1所述的方法，其中，向用户设备发送取消息的通知信息，包括：

若未接收到所述用户设备基于所述通知信息发送的确认信息，则每隔预设时间向用户设备发送取消息的通知信息。

4.根据权利要求1至3中任一所述的方法，其中，所述向用户设备发送取消息的通知信息，包括：

通过udp协议向用户设备发送取消息的通知信息。

5.根据权利要求1至3中任一所述的方法，其中，根据所述确认信息向所述用户设备推送所述消息，包括：

通过http协议或https协议，根据所述确认信息向所述用户设备推送所述消息。

6.根据权利要求1至3中任一所述的方法，其中，该方法还包括：

接收所述用户设备发送的心跳包。

7.一种在用户设备端实现消息推送的方法，其中，该方法包括：

接收由服务器发送的取消息的通知信息；

基于所述通知信息向所述服务器发送确认信息；

接收所述服务器端根据所述确认信息推送的所述消息。

8.根据权利要求7所述的方法，其中，所述消息包括消息序号；

接收所述服务器端基于所述确认信息发送的所述消息之后，还包括：

将当前获取的消息的消息序号与前一次所获取的消息的消息序号进行比对，得到比对结果信息；

若所述比对结果信息为所述当前获取的消息的消息序号大于前一次所获取的消息的消息序号大于前一次所获取的消息的消息序号，则保存所述当前获取的消息；否则，丢弃所述当前获取的消息。

9.根据权利要求7或者8中任一所述的方法，其中，该方法还包括：

每隔预设时间向服务器发送心跳包。

10.一种在服务器端实现消息推送的设备，其中，该设备包括：

第一装置，用于向用户设备发送取消息的通知信息；

第二装置，用于接收所述用户设备基于所述通知信息发送的确认信息；

第三装置，用于根据所述确认信息向所述用户设备推送所述消息。

11.根据权利要求10所述的设备，其中，该设备还包括：

第四装置，用于从第三方设备获取待推送的消息。

12.根据权利要求10所述的设备，其中，所述第一装置，用于若未接收到所述用户设备基于所述通知信息发送的确认信息，则每隔预设时间向用户设备发送取消息的通知信息。

13.根据权利要求10至12中任一所述的设备，其中，所述第一装置，用于通过udp协议向用户设备发送取消息的通知信息。

14.根据权利要求10至12中任一所述的设备，其中，所述第三装置，用于通过http协议或https协议，根据所述确认信息向所述用户设备推送所述消息。

15.根据权利要求10至12中任一所述的设备，其中，该设备还包括：

第五装置，用于接收所述用户设备发送的心跳包。

16.一种在用户设备端实现消息推送的设备，其中，该设备包括：

第六装置，用于接收由服务器发送的取消息的通知信息；

第七装置，用于基于所述通知信息向所述服务器发送确认信息；

第八装置，用于接收所述服务器端根据所述确认信息推送的所述消息。

17.根据权利要求16所述的设备，其中，该设备还包括：

第九装置，用于将当前获取的消息的消息序号与前一次所获取的消息的消息序号进行比对，得到比对结果信息；

第十装置，用于若所述比对结果信息为所述当前获取的消息的消息序号大于前一次所获取的消息的消息序号，则保存所述当前获取的消息；否则，丢弃所述当前获取的消息。

18.根据权利要求16或者17中任一所述的设备，其中，该设备还包括：

第十一装置，用于每隔预设时间向服务器发送心跳包。