CN107306282B - 一种链路保活方法及装置 - Google Patents

Abstract

本发明公开了一种链路保活方法，包括：接收来自第一终端的第一保活消息；所述第一保活消息为针对第一应用对应链路的保活消息；判断所述第一终端所归属的第一基站是否满足预设条件；所述预设条件表征所述第一基站为预设区域内的基站；当所述第一基站满足预设条件时，利用记录的第一时刻，判断是否允许发送所述第一保活消息；所述第一时刻为接入到所述预设区域内基站上的所述第一应用最后一次与应用服务器发生交互消息的时刻；根据判断结果，向所述应用服务器发送第一保活消息或者向所述第一终端返回保活响应。本发明同时还公开了一种链路保活装置。

Description

一种链路保活方法及装置

技术领域

本发明涉及移动互联领域，尤其涉及一种链路保活方法及装置。

背景技术

近些年来伴随着移动网络的升级和智能终端的普及，越来越多的终端应用程序出现了，特别是一些即时通信类、网络电话(VoIP，Voice over Internet Protocol)类的应用，这些应用对实时性要求很高，需要时刻保持与后台服务器的联系，以便于其他用户在想联系时可以实时响应，所以这些应用需要永远在线。

而目前保持在线的实现方式主要是通过建立应用和服务器之间的连接，并在一定间隔时间能和服务器之间通过发送、接收数据进行交互，而网络中数据的接收和发送都是通过使用操作系统中的套接字(SOCKET)来实现的。因此保持在线就是判断对应SOCKET是否已经断开，而如何判断对应SOCKET是否断开，主要是依靠在系统中创建的心跳机制。心跳机制的基本思想是：通过发送心跳包来保持连接。换句话说，心跳包主要用于长连接的保活和断线处理。

对于应用，一般会设置心跳包的发送间隔，然而，用户的网络接入条件不一，比如通过家里的WiFi网络、公众场合的WiFi网络、或移动网络等，加之有的网络设置有防火墙有的未设置防火墙，不同网络对数据链路的保持有不同的要求，因此大多数应用为了保持连接就会将心跳间隔设置的比较短，以便于保持在线状态。

但是，在移动网络情况下过多、过频繁的信令消息会对移动网络造成冲击。因此如何解决因应用的频繁心跳带来的信令风暴是目前亟待解决的问题。

发明内容

为解决现有存在的技术问题，本发明实施例提供一种链路保活方法及装置。

为达到上述目的，本发明实施例的技术方案是这样实现的：

本发明实施例提供了一种链路保活方法，包括：

接收来自第一终端的第一保活消息；所述第一保活消息为针对第一应用对应链路的保活消息；

判断所述第一终端所归属的第一基站是否满足预设条件；所述预设条件表征所述第一基站为预设区域内的基站；

当所述第一基站满足预设条件时，利用记录的第一时刻，判断是否允许发送所述第一保活消息；所述第一时刻为接入到所述预设区域内基站上的所述第一应用最后一次与应用服务器发生交互消息的时刻；

根据判断结果，向所述应用服务器发送第一保活消息或者向所述第一终端返回保活响应。

上述方案中，所述利用记录的第一时刻，判断是否允许发送所述第一保活消息，包括：

利用所述第一时刻及第一发送间隔，判断是否允许发送所述第一保活消息；所述第一发送间隔为针对所述第一应用的保活消息的发送间隔。

上述方案中，所述利用所述第一时刻及第一发送间隔，判断是否允许发送所述第一保活消息，包括：

将所述第一时刻与所述第一发送间隔求和，得到第二时刻；

将当前时刻与所述第二时刻进行比较，所述第二时刻小于等于当前时刻时，允许发送所述第一保活消息；

所述第二时刻大于当前时刻时，不允许发送所述第一保活消息。

上述方案中，所述方法还包括：

当向所述应用服务器发送所述第一保活消息后，更新第一时刻为发送所述第一保活消息的时刻。

上述方案中，所述更新第一时刻为发送所述第一保活消息的时刻后，所述方法还包括：

所述第一应用向所述应用服务器发送除保活消息外的其它交互消息或接收到应用服务器的交互消息后，更新所述第一时刻为最后一次与应用服务器发生交互消息的时刻。

上述方案中，当未记录所述第一时刻时，所述方法还包括：

向所述应用服务器发送所述第一保活消息，并记录所述第一时刻为发送所述第一保活消息的时刻。

本发明实施例还提供了一种链路保活装置，包括：

接收单元，用于接收来自第一终端的第一保活消息；所述第一保活消息为针对第一应用对应链路的保活消息；

位置分析单元，用于判断所述第一终端所归属的第一基站是否满足预设条件；所述预设条件表征所述第一基站为预设区域内的基站；

链路保活策略单元，用于当所述第一基站满足预设条件时，利用记录的第一时刻，判断是否允许发送所述第一保活消息；所述第一时刻为接入到所述预设区域内基站上的所述第一应用最后一次与应用服务器发生交互消息的时刻；

心跳处理单元，用于根据判断结果，向所述应用服务器发送第一保活消息或者向所述第一终端返回保活响应。

上述方案中，所述装置还包括：

更新单元，用于向所述应用服务器发送所述第一保活消息后，更新第一时刻为发送所述第一保活消息的时刻。

上述方案中，所述更新单元，还用于所述第一应用向所述应用服务器发送除保活消息外的其它交互消息后，更新所述第一时刻为最后一次向应用服务器发送所述其它交互消息的时刻。

上述方案中，所述心跳处理单元，还用于当未记录所述第一时刻时，向所述应用服务器发送所述第一保活消息；

所述装置还包括：

记录创建单元，用于记录所述第一时刻为发送所述第一保活消息的时刻。

本发明实施例提供的信令链路保活方法及装置，接收来自第一终端的第一保活消息；所述第一保活消息为针对第一应用对应链路的保活消息；判断所述第一终端所归属的第一基站是否满足预设条件；所述预设条件表征所述第一基站为预设区域内的基站；当所述第一基站满足预设条件时，利用记录的第一时刻，判断是否允许发送所述第一保活消息；所述第一时刻为接入到所述预设区域内基站上的所述第一应用最后一次与应用服务器发生交互消息的时刻；根据判断结果，向所述应用服务器发送第一保活消息或者向所述第一终端返回保活响应，同一接入区域的多个第一应用中，只需要有一个第一应用与应用服务器的链路是相通的，则其他第一应用于应用服务器的链路也是相通的，如此，能有效地降低保活消息的发送频率，从而能有效地降低保活消息对移动网络的冲击。

另外，本发明实施例提供的方案，不需要修改终端侧的应用，如此，适用范围广。

附图说明

在附图(其不一定是按比例绘制的)中，相似的附图标记可在不同的视图中描述相似的部件。具有不同字母后缀的相似附图标记可表示相似部件的不同示例。附图以示例而非限制的方式大体示出了本文中所讨论的各个实施例。

图1为典型的移动网络接入系统结构示意图；

图2为本发明实施例一链路保活的方法流程示意图；

图3为本发明实施例的网络系统结构示意图；

图4为本发明实施例保活消息的处理流程示意图；

图5为本发明实施例对保活消息的处理流程示意图；

图6为本发明实施例二链路保活装置结构示意图。

具体实施方式

下面结合附图及实施例对本发明再作进一步详细的描述。

在描述本发明实施例之前，先了解一下为什么会产生信令风暴。

在传输控制协议(TCP，Transmission Control Protocol)中已经实现了一个叫做心跳的机制。依据TCP，如果设置了心跳，就会在一定的时间(比如设置的是3秒钟)内发送预设次数的心跳(比如2次)，并且此信息不会影响自定义的协议。所谓“心跳”就是定时发送一个自定义的结构体(心跳包或心跳帧)，让对方知道自己“在线”，以确保链接的有效性。

对于应用所依靠的心跳机制，其基本思想是：通过发送心跳包来保持连接。所谓的心跳包就是应用所依托的客户端定时发送简单的信息给服务器端，以告知服务器端自身还在线。当然也可以是服务器端发送心跳包。具体地，通过代码来实现每间隔一段时间(比如每隔几分钟)向服务器端发送一个固定信息，服务器端收到后会回复一个固定信息。如果服务器端几分钟内没有收到客户端发送的信息则认为客户端已断开。

举个例子来说，有些通信软件长时间不使用，要想获知它的状态是在线还是离线，就需要通过心跳包来获知，即定时发送心跳包、接收心跳包。其中，发包方：可以是客户端也可以是服务器端，实际应用时可以根据实现方便合理性，来决定由哪方发送心跳包。一般是客户端。当然服务器端也可以定时轮询发心跳下去。

心跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器端，这个客户端还活着。事实上心跳包的作用是为了保持长连接，至于心跳包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。

在长连接下，有可能很长一段时间都没有数据往来。理论上说，这个连接是一直保持连接的。但是实际情况中，如果中间节点出现什么故障是难以知道的。而且，有的节点(防火墙)会自动把一定时间之内没有数据交互的连接给断掉。在这种情况下，就需要心跳包来获知，用于维持长连接，保活。在获知了断线之后，服务器端的逻辑可能需要做一些处理，比如断线后的数据清理、重新连接等。当然，这个是要由逻辑层根据需求去做了。总的来说，心跳包主要用于长连接的保活和断线处理。一般，应用会设置连接判定时间在30-40秒，如果实时性要求较高，可以设置在6-9秒。

图1为典型的移动网络接入结构示意图。从图1可以看出，终端通过基站接入核心网，当用户使用一个应用时，核心网需要为其分配相应的资源，以实现与应用服务器的交互。然而，由于用户的网络接入条件不一，比如通过家里的WiFi网络、公众场合的WiFi网络、或移动网络等，加之有的网络设置有防火墙有的未设置防火墙，不同网络对数据链路的保持有不同的要求，因此大多数应用为了保持连接就会将心跳间隔设置的比较短，以便于保持在线状态。此类应用的代表有微信及QQ等。每个月的活跃度都是亿级别的，可想而知每秒钟产生心跳包，将会是一个巨大的数目。而为了处理这些心跳包，需要占用核心网的大量资源，可见心跳包对移动网络的资源消耗是巨大。

因此，在移动网络情况下，过多、过频繁的心跳消息将会对移动网络造成冲击。如何解决因应用的频繁心跳带来的信令风暴，是亟待解决的一个问题。

基于此，在本发明的各种实施例中：接收来自第一终端的第一保活消息；所述第一保活消息为针对第一应用对应链路的保活消息；判断所述第一终端所归属的第一基站是否满足预设条件；所述预设条件表征所述第一基站为预设区域内的基站；当所述第一基站满足预设条件时，利用记录的第一时刻，判断是否允许发送所述第一保活消息；所述第一时刻为接入到所述预设区域内基站上的所述第一应用最后一次与应用服务器发生交互消息的时刻；根据判断结果，向所述应用服务器发送第一保活消息或者向所述第一终端返回保活响应。

实施例一

本实施例链路保活方法，是一种信令链路保活方法，应用于链路保活装置，如图2所示，该方法包括以下步骤：

步骤201：接收来自第一终端的第一保活消息；

这里，所述第一保活消息为针对第一应用对应链路的保活消息。

更具体点讲，所述第一保活消息为针对所述第一应用对应信令链路的保活消息。

链路保活是指：保持链路的连接性。

步骤202：判断所述第一终端所归属的第一基站是否满足预设条件；

这里，所述预设条件表征所述第一基站为预设区域内的基站。

实际应用时，可以根据需要来设置哪些基站位于一个区域。当然，实际应用时，预设区域内的基站的个数可以是一个，也可以是至少两个。

步骤201所接收的第一保活消息可以：所述第一终端通过第一基站所发送的第一保活消息。且实际应用时，每个基站都会有一个对应的编号，所以根据第一基站的编号可以获知其是否预设区域内的基站。

另外，实际应用时，网络侧会给每个终端分配一个IP地址，利用基站的编号并结合第一终端的IP地址等信息，可以准确判断所述第一终端是否是预设区域内的基站。

步骤203：当判断结果表征所述第一基站满足预设条件时，利用记录的第一时刻，判断是否允许发送所述第一保活消息；

这里，所述第一时刻为接入到所述预设区域内基站上的所述第一应用最后一次与应用服务器发生交互消息的时刻。

具体地，利用所述第一时刻及第一发送间隔，判断是否允许发送所述第一保活消息。

其中，所述第一发送间隔为针对所述第一应用的保活消息的发送间隔。

更具体地，将所述第一时刻与所述第一发送间隔求和，得到第二时刻；

将当前时刻与所述第二时刻进行比较，当所述第二时刻小于等于当前时刻时，允许发送所述第一保活消息；

当所述第二时刻大于当前时刻时，不允许发送所述第一保活消息。

在一实施例中，当未记录所述第一时刻时，该方法还可以包括：

向所述应用服务器发送所述第一保活消息，并记录所述第一时刻为发送所述第一保活消息的时刻。

当未记录所述第一时刻时，说明所述第一应用并没有与所述应用服务器交互过消息，所以需要记录第一时刻为发送所述第一保活消息的时刻，以便后续收到第一应用的保活消息后，据此来判断是否允许向所述应用服务器发送收到的保活消息。

实际应用时，可以建立一个策略表，表里记录有各应用的消息记录时间(各应用最后一次向对应应用服务器发送消息的时刻)，从而据此来判断是否想对应应用该服务器发送来自各应用的保活消息。策略表的具体格式可以参照表1。

应用标识(ID)	消息记录时间
		飞信	2016-02-17 10:48:50
微信	2016-02-17 10:49:50

表1

其中，在表1中，应用ID为用户需要进行链路保活的应用名称。消息记录时间为应用和应用服务器发生消息交互的时间，消息交互包括：向应用服务器发送保活消息、向应用服务器发送除常规消息，从应用服务器接收消息。当有此类消息交互时，将更新对应应用的消息记录时间。

步骤204：根据判断结果，向所述应用服务器发送第一保活消息或者向所述第一终端返回保活响应。

具体地，当判断结果表征允许发送所述第一保活消息时，向所述应用服务器发送第一保活消息；当判断结果表征不允许发送所述第一保活消息时，向所述第一终端返回保活响应。

其中，当向所述应用服务器发送所述第一保活消息后，需要更新第一时刻为发送所述第一保活消息的时刻。

更新第一时刻为发送所述第一保活消息的时刻后，当所述第一应用向所述应用服务器发送除保活消息外的其它交互消息时，仍需要更新所述第一时刻为最后一次向应用服务器发送所述其它交互消息的时刻。

换句话说，除了保活消息外，只要第一应用向所述应用服务器发送了交互消息时，就需要更新第一时刻，以便能有效地减少向应用服务器发送保活消息的次数。

举个例子来说，当根据消息记录时间判断是否允许应用发送链路保活消息时，收到该应用的保活消息后，首先检查此应用对应的消息记录时间，利用策略表中的消息记录时间+可以发送保活消息的时间间隔与当前时间进行比较，以判断是否允许该应用发送保活消息。具体地，如果消息记录时间+可以发送保活消息的时间间隔小于等于当前时间，则允许发送此应用的保活消息，如果消息记录时间+可以发送保活消息的时间间隔大于当前时间，则不允许发送此应用的保护消息。

下面以飞信为例，详细描述对保活消息的处理过程。

正常情况下飞信应用可以发送保活消息的时间间隔为5分钟，例如当前时间为10:00，同一基站下有A、B、C三个飞信客户端，10点钟的时候A成功向应用服务器发送了保活消息，此时策略表的内容如下表2所示。

应用ID	消息记录时间
		飞信	2016-03-04 10:00:00
微信	2016-03-04 09:49:50

表2

10:03:00时B向应用服务器发送保活消息，收到B的保活消息后，消息记录时间为10:00:00，再加上5分钟的发送保活消息的时间间隔，则可以得到发送保活消息至应用服务器的时间应为10:05:00以后，此时间>10:03:00，则B的保活消息将不被发送到应用服务器，而是通过基站直接回复链路保活响应。比如通过基站直接回复确认(ACK)消息等。

10:04:00时C收到一条飞信消息，此时策略记录表的内容更新如表3所示：

表3

10:05:00时A需要发送保活消息到应用服务器，收到A的保活消息后，消息记录时间为10:04:00，再加上5分钟的发送保活消息的时间间隔，则可以得到发送保活消息到应用服务器的时间应为10:09分以后，此时间>10:04:00，则A的保活消息将不被发送到应用服务器，而是通过基站直接回复链路保活响应。比如通过基站直接回复ACK消息等。

从上面的描述中可以看出，本发明实施例提供的方案，实际应用时，可以应用于如图3所示的网络系统。其中，在图3中，每个预设区域都对应有处理单元，来判断是向应用服务器保活消息还是向应用返回保活响应，并根据判断结果来向应用服务器发送保活消息或向应用返回保活响应。

结合图3，如图4所示，本发明实施例提供的方案，大致流程主要包括：应用(UA)发送保活消息(401)，收到UA的保活消息后，判断是否允许发送该保活消息(402)，如果允许，则向应用服务器发送保活消息(403)，如果不允许，则向UA返回保活响应(404)。

其中，对于步骤402的具体实现，如图5所示，主要包括以下步骤：

步骤402a：确定承载UA的终端的位置；

步骤402b：根据终端的位置，选择终端所归属的基站对应预设区域的处理单元，以执行步骤402c～402g；

步骤402c：读取预设区域对应的策略表；

步骤402d：判断策略表中是否有UA对应的消息记录时间，如果是，则执行步骤402e，否则，执行步骤402g：

步骤402e：将对应的消息记录时间+发送保活消息的时间间隔，得到的时间与当前时间进行比较；

步骤402f：判断得到的时间是否晚于当前时间，如果是，则执行步骤404，否则，执行步骤403；

步骤402g：在策略表中记录对应的消息记录时间，之后执行步骤403。

采用本发明实施例提供的方案，以同一接入区域内的基站(至少一个)为单位，接入到相同基站或者相同区域内基站上的第一应用，单位时间内如果有一个第一应用的保活消息或其它类型的消息(用户正常收发的消息)和应用服务器进行交互，其他第一应用的保活消息将通过基站进行直接回复。通过这种方式一方面减轻了移动网络的信令风暴，另一方面可以不用对相关应用进行修改，方便运营商快速部署上线。

以飞信为例，目前飞信每隔30秒向应用服务器发送保活消息，如一个基站下同时接入了100个飞信用户，那每30秒就有100个心跳消息通过移动网络发到飞信服务器上，通过本发明实施例提供的方法，30秒只有一个包活消息发到飞信服务器上，其他99个都由基站回复消息，在一个基站覆盖下，同一应用只要有一个网络是通的，其他一定是通的，如此，能偶减少不必要的尝试。

综上所述，本发明实施例提供的方案，接收来自第一终端的第一保活消息；所述第一保活消息为针对第一应用对应链路的保活消息；判断所述第一终端所归属的第一基站是否满足预设条件；所述预设条件表征所述第一基站为预设区域内的基站；当判断结果表征所述第一基站满足预设条件时，利用记录的第一时刻，判断是否允许发送所述第一保活消息；所述第一时刻为接入到所述预设区域内基站上的所述第一应用最后一次与应用服务器发生交互消息的时刻；根据判断结果，向所述应用服务器发送第一保活消息或者向所述第一终端返回保活响应，同一接入区域的多个第一应用中，只需要有一个第一应用与应用服务器的链路是相通的，则其他第一应用于应用服务器的链路也是相通的，如此，能有效地降低保活消息的发送频率，从而能有效地降低保活消息对移动网络的冲击。

同时，本发明实施例提供的方案，不需要修改终端侧的应用，如此，适用范围广。

实施例二

为实现本发明实施例的方法，本实施例提供一种链路保活装置，是一种信令链路保活装置。如图6所示，该装置包括：

接收单元61，用于接收来自第一终端的第一保活消息；所述第一保活消息为针对第一应用对应链路的保活消息；

位置分析单元62，用于判断所述第一终端所归属的第一基站是否满足预设条件；所述预设条件表征所述第一基站为预设区域内的基站；

链路保活策略单元63，用于当判断结果表征所述第一基站满足预设条件时，利用记录的第一时刻，判断是否允许发送所述第一保活消息；所述第一时刻为接入到所述预设区域内基站上的所述第一应用最后一次与应用服务器发生交互消息的时刻；

心跳处理单元64，用于根据判断结果，向所述应用服务器发送第一保活消息或者向所述第一终端返回保活响应。

其中，具体点说，所述第一保活消息为针对所述第一应用对应信令链路的保活消息。

链路保活是指：保持链路的连接性。

实际应用时，可以根据需要来设置哪些基站位于一个区域。当然，实际应用时，预设区域内的基站的个数可以是一个，也可以是至少两个。

所述接收单元61所接收的第一保活消息可以：所述第一终端通过第一基站所发送的第一保活消息。且实际应用时，每个基站都会有一个对应的编号，所以根据第一基站的编号可以获知其是否预设区域内的基站。

另外，实际应用时，网络侧会给每个终端分配一个IP地址，利用基站的编号并结合第一终端的IP地址等信息，可以准确判断所述第一终端是否是预设区域内的基站。

所述链路保活策略单元63，具体用于：

利用所述第一时刻及第一发送间隔，判断是否允许发送所述第一保活消息。

更具体地，所述链路保活策略单元63将所述第一时刻与所述第一发送间隔求和，得到第二时刻；

所述链路保活策略单元63将当前时刻与所述第二时刻进行比较，当所述第二时刻小于等于当前时刻时，允许发送所述第一保活消息；

当所述第二时刻大于当前时刻时，不允许发送所述第一保活消息。

在一实施例中，该装置还可以包括：

更新单元，用于向所述应用服务器发送所述第一保活消息后，更新第一时刻为发送所述第一保活消息的时刻。

在一实施例中，所述心跳处理单元64，还用于当未记录所述第一时刻时，向所述应用服务器发送所述第一保活消息；

该装置还可以包括：

记录创建单元，用于记录所述第一时刻为发送所述第一保活消息的时刻。其中，当未记录所述第一时刻时，说明所述第一应用并没有与所述应用服务器交互过消息，所以需要记录第一时刻为发送所述第一保活消息的时刻，以便后续收到第一应用的保活消息后，链路保活策略单元63据此来判断是否允许向所述应用服务器发送收到的保活消息。

实际应用时，可以建立一个策略表，表里记录有各应用的消息记录时间(各应用最后一次向对应应用服务器发送消息的时刻)，从而据此来判断是否想对应应用该服务器发送来自各应用的保活消息。策略表的具体格式可以参照表1。

其中，在表1中，应用ID为用户需要进行链路保活的应用名称。消息记录时间为应用和应用服务器发生消息交互的时间，消息交互包括：向应用服务器发送保活消息、向应用服务器发送除常规消息，从应用服务器接收消息。当有此类消息交互时，将更新对应应用的消息记录时间。

所述心跳处理单元64，具体用于：

当判断结果表征允许发送所述第一保活消息时，向所述应用服务器发送第一保活消息；当判断结果表征不允许发送所述第一保活消息时，向所述第一终端返回保活响应。

其中，当向所述应用服务器发送所述第一保活消息后，所述更新单元需要更新第一时刻为发送所述第一保活消息的时刻。

更新第一时刻为发送所述第一保活消息的时刻后，当所述第一应用向所述应用服务器发送除保活消息外的其它交互消息时，所述更新单元仍需要更新所述第一时刻为最后一次向应用服务器发送所述其它交互消息的时刻。

换句话说，除了保活消息外，只要第一应用向所述应用服务器发送了交互消息时，就需要更新第一时刻，以便能有效地减少向应用服务器发送保活消息的次数。

举个例子来说，当根据消息记录时间判断是否允许应用发送链路保活消息时，收到该应用的保活消息后，所述链路保活策略单元63首先检查此应用对应的消息记录时间，利用策略表中的消息记录时间+可以发送保活消息的时间间隔与当前时间进行比较，以判断是否允许该应用发送保活消息。具体地，如果消息记录时间+可以发送保活消息的时间间隔小于等于当前时间，则所述链路保活策略单元63允许发送此应用的保活消息，如果消息记录时间+可以发送保活消息的时间间隔大于当前时间，则所述链路保活策略单元63不允许发送此应用的保护消息。

下面以飞信为例，详细描述对保活消息的处理过程。

正常情况下飞信应用可以发送保活消息的时间间隔为5分钟，例如当前时间为10:00，同一基站下有A、B、C三个飞信客户端，10点钟的时候A成功向应用服务器发送了保活消息，此时策略表的内容如下表2所示。

10:03:00时B向应用服务器发送保活消息，收到B的保活消息后，消息记录时间为10:00:00，再加上5分钟的发送保活消息的时间间隔，则所述链路保活策略单元63可以得到发送保活消息至应用服务器的时间应为10:05:00以后，此时间>10:03:00，则B的保活消息将不被发送到应用服务器，而是通过基站直接回复链路保活响应。比如通过基站直接回复ACK消息等。

10:04:00时C收到一条飞信消息，此时策略记录表的内容更新如表3所示。

10:05:00时A需要发送保活消息到应用服务器，收到A的保活消息后，消息记录时间为10:04:00，再加上5分钟的发送保活消息的时间间隔，则可以得到发送保活消息到应用服务器的时间应为10:09分以后，此时间>10:04:00，则A的保活消息将不被发送到应用服务器，而是通过基站直接回复链路保活响应。比如通过基站直接回复ACK消息等。

从上面的描述中可以看出，本发明实施例提供的方案，实际应用时，可以应用于如图3所示的网络系统。而本发明实施例提供的装置位于网络侧。其中，在图3中，每个预设区域都对应有处理单元(链路保活策略单元及心跳处理单元)，来判断是向应用服务器保活消息还是向应用返回保活响应，并根据判断结果来向应用服务器发送保活消息或向应用返回保活响应。

结合图3，如图4所示，本发明实施例提供的方案，大致流程主要包括：应用(UA)发送保活消息(401)，所述接收单元61收到UA的保活消息后，由所述链路保活策略单元63来判断是否允许发送该保活消息(402)，如果允许，则由心跳处理单元64向应用服务器发送保活消息(403)，如果不允许，则由心跳处理单元64向UA返回保活响应(404)。

其中，对于步骤402的具体实现，如图5所示，主要包括以下步骤：

步骤402a：由所述位置分析单元62确定承载UA的终端的位置；

步骤402b：所述位置分析单元62根据终端的位置，选择终端所归属的基站对应预设区域的处理单元，以执行步骤402c～402g；

步骤402c：对应预设区域的所述链路保活策略单元63读取预设区域对应的策略表；

步骤402d：判断策略表中是否有UA对应的消息记录时间，如果是，则执行步骤402e，否则，执行步骤402g：

步骤402e：将对应的消息记录时间+发送保活消息的时间间隔，得到的时间与当前时间进行比较；

步骤402f：判断得到的时间是否晚于当前时间，如果是，则执行步骤404，否则，执行步骤403；

步骤402g：在策略表中记录对应的消息记录时间，之后执行步骤403。

采用本发明实施例提供的方案，以同一接入区域内的基站(至少一个)为单位，接入到相同基站或者相同区域内基站上的第一应用，单位时间内如果有一个第一应用的保活消息或其它类型的消息(用户正常收发的消息)和应用服务器进行交互，其他第一应用的保活消息将通过基站进行直接回复。通过这种方式一方面减轻了移动网络的信令风暴，另一方面可以不用对相关应用进行修改，方便运营商快速部署上线。

以飞信为例，目前飞信每隔30秒向应用服务器发送保活消息，如一个基站下同时接入了100个飞信用户，那每30秒就有100个心跳消息通过移动网络发到飞信服务器上，通过本发明实施例提供的方法，30秒只有一个包活消息发到飞信服务器上，其他99个都由基站回复消息，在一个基站覆盖下，同一应用只要有一个网络是通的，其他一定是通的，如此，能偶减少不必要的尝试。

实际应用时，所述接收单元61、心跳处理单元64可由链路保活装置中的收发机实现；所述位置分析单元62、链路保活策略单元63、更新单元、记录创建单元可由链路保活装置中的中央处理器(CPU，Central Processing Unit)、微处理器(MCU，Micro ControlUnit)、数字信号处理器(DSP，Digital Signal Processor)或可编程逻辑阵列(FPGA，Field－Programmable Gate Array)实现。

综上所述，本发明实施例提供的方案，所述接收单元61接收来自第一终端的第一保活消息；所述第一保活消息为针对第一应用对应链路的保活消息；所述位置分析单元62判断所述第一终端所归属的第一基站是否满足预设条件；所述预设条件表征所述第一基站为预设区域内的基站；当判断结果表征所述第一基站满足预设条件时，链路保活策略单元63利用记录的第一时刻，判断是否允许发送所述第一保活消息；所述第一时刻为接入到所述预设区域内基站上的所述第一应用最后一次与应用服务器发生交互消息的时刻；根据判断结果，所述心跳处理单元64向所述应用服务器发送第一保活消息或者向所述第一终端返回保活响应，同一接入区域的多个第一应用中，只需要有一个第一应用与应用服务器的链路是相通的，则其他第一应用于应用服务器的链路也是相通的，如此，能有效地降低保活消息的发送频率，从而能有效地降低保活消息对移动网络的冲击。

同时，本发明实施例提供的方案，不需要修改终端侧的应用，如此，适用范围广。

实际应用时，链路保活装置可以根据设置的预设区域范围，设置在基站，或者设置在比基站更上层的网络设备上，比如核心网设备、或者基站管理器等。举个例子来说，假设预设区域内只有一个基站，此时链路保活装置可以设置在基站上，也可以设置在比基站更上层的网络设备上。如果预设区域内有至少两个基站，此时链路保活装置可以设置在比基站更上层的网络设备上。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (10)

1.一种链路保活方法，其特征在于，所述方法包括：

接收来自第一终端的第一保活消息；所述第一保活消息为针对第一应用对应链路的保活消息；

判断所述第一终端所归属的第一基站是否满足预设条件；所述预设条件表征所述第一基站为预设区域内的基站；

当所述第一基站满足预设条件时，利用记录的第一时刻，判断是否允许发送所述第一保活消息；所述第一时刻为接入到所述预设区域内基站上的所述第一应用最后一次与应用服务器发生交互消息的时刻；

根据判断结果，向所述应用服务器发送第一保活消息或者向所述第一终端返回保活响应。

2.根据权利要求1所述的方法，其特征在于，所述利用记录的第一时刻，判断是否允许发送所述第一保活消息，包括：

利用所述第一时刻及第一发送间隔，判断是否允许发送所述第一保活消息；所述第一发送间隔为针对所述第一应用的保活消息的发送间隔。

3.根据权利要求2所述的方法，其特征在于，所述利用所述第一时刻及第一发送间隔，判断是否允许发送所述第一保活消息，包括：

将所述第一时刻与所述第一发送间隔求和，得到第二时刻；

将当前时刻与所述第二时刻进行比较，所述第二时刻小于等于当前时刻时，允许发送所述第一保活消息；

所述第二时刻大于当前时刻时，不允许发送所述第一保活消息。

4.根据权利要求1至3任一项所述的方法，其特征在于，所述方法还包括：

当向所述应用服务器发送所述第一保活消息后，更新第一时刻为发送所述第一保活消息的时刻。

5.根据权利要求4所述的方法，其特征在于，所述更新第一时刻为发送所述第一保活消息的时刻后，所述方法还包括：

所述第一应用向所述应用服务器发送除保活消息外的其它交互消息或接收到应用服务器的交互消息后，更新所述第一时刻为最后一次与应用服务器发生交互消息的时刻。

6.根据权利要求1所述的方法，其特征在于，当未记录所述第一时刻时，所述方法还包括：

向所述应用服务器发送所述第一保活消息，并记录所述第一时刻为发送所述第一保活消息的时刻。

7.一种链路保活装置，其特征在于，所述装置包括：

接收单元，用于接收来自第一终端的第一保活消息；所述第一保活消息为针对第一应用对应链路的保活消息；

位置分析单元，用于判断所述第一终端所归属的第一基站是否满足预设条件；所述预设条件表征所述第一基站为预设区域内的基站；

链路保活策略单元，用于当所述第一基站满足预设条件时，利用记录的第一时刻，判断是否允许发送所述第一保活消息；所述第一时刻为接入到所述预设区域内基站上的所述第一应用最后一次与应用服务器发生交互消息的时刻；

心跳处理单元，用于根据判断结果，向所述应用服务器发送第一保活消息或者向所述第一终端返回保活响应。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

更新单元，用于向所述应用服务器发送所述第一保活消息后，更新第一时刻为发送所述第一保活消息的时刻。

9.根据权利要求8所述的装置，其特征在于，所述更新单元，还用于所述第一应用向所述应用服务器发送除保活消息外的其它交互消息后，更新所述第一时刻为最后一次向应用服务器发送所述其它交互消息的时刻。

10.根据权利要求7所述的装置，其特征在于，所述心跳处理单元，还用于当未记录所述第一时刻时，向所述应用服务器发送所述第一保活消息；

所述装置还包括：

记录创建单元，用于记录所述第一时刻为发送所述第一保活消息的时刻。