状态探测方法、装置及网络服务器与流程

本公开涉及互联网技术领域，具体而言，涉及一种状态探测方法、装置及网络服务器。

背景技术

随着互联网技术的快速发展，网络运营商大都采用用户认证接入的方式实现用户上线，用户上线之后，将给用户分配相应的业务资源，以使用户可以正常使用相应业务。然而，经研究发现，用户在使用业务的过程中，可能不按照常规方式发送下线请求，如直接拔掉网线，导致无法准确地判断用户状态，及时回收用户占用的资源，造成资源的浪费。

技术实现要素：

有鉴于此，本公开提供一种状态探测方法、装置及网络服务器。

第一方面，本公开提供了一种状态探测方法，应用于网络服务器，所述方法包括：

接收数据报文；

解析所述数据报文，得到所述数据报文包括的用户特征信息；

查找是否记录有与所述用户特征信息匹配的用户，若记录有与所述用户特征信息匹配的用户，则判定该用户的状态为在线；

在设定周期内，检测是否存在未接收到包括其特征信息的数据报文的目标用户，若存在所述目标用户，判断所述目标用户的状态是否为下线。

可选地，若存在所述目标用户，判断所述目标用户的状态是否为下线的步骤，包括：

若存在所述目标用户，直接判定所述目标用户的状态为下线；或者

若存在所述目标用户，向所述目标用户对应的终端发送探测用户状态的协议报文；

检测是否接收到所述终端反馈的响应报文，若未接收到所述终端反馈的响应报文，判定所述目标用户的状态为下线；若接收到所述终端反馈的响应报文，判定所述目标用户的状态为在线。

可选地，所述方法还包括：

在下一个设定周期内，针对上一设定周期判定为在线的用户，重新执行接收数据报文至判断所述目标用户的状态是否为下线的步骤。

可选地，所述方法还包括，

将状态为下线的用户进行标识；

在判定用户的状态为下线之后的下一个设定周期，将分配给该用户的资源进行回收。

可选地，所述方法还包括：

将状态为下线的用户进行标识；

在判定用户的状态为下线之后的下一个设定周期，将分配给该用户的资源进行回收。

可选地，所述用户特征信息包括源网际协议sip地址、源媒体访问控制smac地址、数据报文的入接口中的至少一种；

所述查找是否记录有与所述用户特征信息匹配的用户，若记录有与所述用户特征信息匹配的用户，则判定用户的状态为在线的步骤，包括：

根据所述用户特征信息查找预先存储的用户表；

若在所述用户表中查找到与所述用户特征信息匹配的用户，判定该用户的状态为在线。

第二方面，本公开提供一种状态探测装置，应用于网络服务器，所述状态探测装置包括：

报文接收模块，用于接收数据报文；

报文解析模块，用于解析所述数据报文，得到所述数据报文包括的用户特征信息；

状态确认模块，用于查找是否记录有与所述用户特征信息匹配的用户，若记录有与所述用户特征信息匹配的用户，则判定该用户的状态为在线；在设定周期内，检测是否存在未接收到包括其特征信息的数据报文的目标用户，若存在所述目标用户，判断所述目标用户的状态是否为下线。

可选地，所述状态确认模块用于，若存在所述目标用户，直接判定所述目标用户的状态为下线；或者，若存在所述目标用户，向所述目标用户对应的终端发送探测用户状态的协议报文，检测是否接收到所述终端反馈的响应报文，若未接收到所述终端反馈的响应报文，判定所述目标用户的状态为下线；若接收到所述终端反馈的响应报文，判定所述目标用户的状态为在线。

可选地，所述状态确认模块还用于，将状态为下线的用户进行标识，在判定用户的状态为下线之后的下一个设定周期，将分配给该用户的资源进行回收。

可选地，所述状态确认模块用于，根据所述用户特征信息查找预先存储的用户表，若在所述用户表中查找到与所述用户特征信息匹配的用户，判定该用户的状态为在线。

第三方面，本公开提供一种网络服务器，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述的状态探测方法。

第四方面，本公开提供一种计算机可读存储介质，所述计算机可读存储介质包括计算机程序，所述计算机程序运行时控制所述计算机可读存储介质所在网络服务器执行上述的状态探测方法。

本公开提供的状态探测方法、装置及网络服务器，通过用户所传递的数据报文，提取得到用户特征信息，根据用户特征信息判断用户的状态，实现较为便捷。

为使本公开的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本公开的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本公开的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本公开提供的一种网络服务器的方框示意图。

图2为本公开提供的一种状态探测方法的流程示意图。

图3为本公开提供的一种状态探测方法的另一流程示意图。

图4为本公开提供的一种状态探测方法的另一流程示意图。

图5为本公开提供的一种状态探测方法的另一流程示意图。

图6为本公开提供的一种状态探测方法的逻辑示意图。

图7为本公开提供的另一种状态探测方法的逻辑示意图。

图8为本公开提供的又一种状态探测方法的逻辑示意图。

图9为本公开提供的一种状态探测装置的方框示意图。

图标：20-网络服务器；21-存储器；22-处理器；23-网络模块；24-状态探测装置；241-报文接收模块；242-报文解析模块；243-状态确认模块。

具体实施方式

为了改善因用户在使用业务的过程中，不按照常规方式发送下线请求所导致的无法准确地判断用户状态，进而造成的无法及时回收用户占用的资源，造成资源浪费的问题，需对占用资源的用户的状态进行探测。

为了探测用户状态，网络运营商接入侧的网络服务器，如网络服务器可以每间隔一定的时间向用户对应的终端发送探测用户状态的协议报文，如地址解析协议(addressresolutionprotocol，arp)报文。若用户的状态为在线，终端收到探测用户状态的协议报文，并响应该协议报文，网络服务器收到对应的响应报文后，认为该用户的状态为在线。若用户的状态为下线，终端不响应该协议报文，网络服务器不会收到对应的响应报文，从而认为该用户的状态为下线。网络服务器针对分配有业务资源的各用户均通过协议报文进行状态探测，从而可以确定出已下线的用户，进而回收分配给已下线的用户的资源，提高资源利用率。然而，经调查发现，采用该种方式进行用户状态探测使用规模有限。

经研究发现，导致该种方式使用规模有限的主要原因包括：在很多场景中，分配有资源的用户数量较大，向每个用户分别发送探测用户状态的协议报文，处理各用户对应的终端反馈的响应报文会占用网络服务器较多的处理资源，如网络服务器的中央处理器(centralprocessingunit，cpu)资源。另外，分配有资源的各用户对应的网络状态有差异，在某些用户对应的网络拥塞时，探测用户状态的协议报文在传输过程中有可能被丢弃，导致误将相应用户的状态判定成下线，导致用户误下线，影响用户体验。

有鉴于此，本公开提供一种状态探测方法、装置及网络服务器，通过活跃用户所传递的数据报文，提取得到用户特征信息，根据用户特征信息确定用户的状态。采用本公开中的状态探测方案，在不发送探测用户状态的协议报文的情况下，感知用户的状态是否为在线，显著降低了网络服务器的处理资源占用量，实现较为便捷。直接通过用户所传递的数据报文判断用户状态，还能够有效规避因网络拥塞、呆滞等造成的探测用户状态的协议报文丢失所导致的用户状态误判断，提升用户状态探测的准确性，进而实现对资源的准确分配，提高用户体验。

针对以上方案所存在的缺陷，均是发明人在经过实践并仔细研究后得出的结果，因此，上述问题的发现过程以及下文中本公开针对上述问题所提出的解决方案，都应该是发明人在本公开过程中对本公开做出的贡献。

下面将结合本公开中附图，对本公开中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本公开的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

如图1所示，是本公开提供的网络服务器20的一种方框示意图。本公开中的网络服务器20可以为网络运营商接入侧的网络服务器，如交换机、路由器等能够对用户通过终端发送的数据报文进行处理的设备。如图1所示，网络服务器20包括：存储器21、处理器22、网络模块23及状态探测装置24。

所述存储器21、处理器22以及网络模块23相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。存储器21中存储有状态探测装置24，所述状态探测装置24包括至少一个可以软件或固件(firmware)的形式存储于所述存储器21中的软件功能模块，所述处理器22通过运行存储在存储器21内的软件程序以及模块，如本公开中的状态探测装置24，从而执行各种功能应用，即实现本公开中的状态探测方法。

其中，所述存储器21可以是，但不限于，随机存取存储器(randomaccessmemory，ram)，只读存储器(readonlymemory，rom)，可编程只读存储器(programmableread-onlymemory，prom)，可擦除只读存储器(erasableprogrammableread-onlymemory，eprom)，电可擦除只读存储器(electricerasableprogrammableread-onlymemory，eeprom)等。其中，存储器21用于存储程序，所述处理器22在接收到执行指令后，执行所述程序。

所述处理器22可能是一种集成电路芯片，具有数据的处理能力。上述的处理器22可以是通用处理器，包括中央处理器(centralprocessingunit，cpu)、网络处理器(networkprocessor，np)等。可以实现或者执行本公开中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

网络模块23用于通过网络建立网络服务器20与外部通信终端如用户对应的终端之间的通信连接，实现网络信号及数据的收发操作。上述网络信号可包括无线信号或者有线信号。

可以理解，图1所示的结构仅为示意，网络服务器20还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。图1中所示的各组件可以采用硬件、软件或其组合实现。

在上述基础上，本公开还提供一种计算机可读存储介质，所述计算机可读存储介质包括计算机程序，所述计算机程序运行时控制所述计算机可读存储介质所在网络服务器20执行下述状态探测方法。

请结合参阅图2，本公开提供一种状态探测方法，该方法可以由图1中的网络服务器20执行。

所述方法包括以下步骤。

步骤s11，接收数据报文。

步骤s12，解析所述数据报文，得到所述数据报文包括的用户特征信息。

其中，用户特征信息为能够反应发送数据报文的用户身份的信息。例如，用户特征信息可以包括源网际协议(sourceinternetprotocol，sip)地址、源媒体访问控制(sourcemediaaccesscontrol或者mediumaccesscontrol，smac)地址、数据报文的入接口中的至少一种。

步骤s13，查找是否记录有与所述用户特征信息匹配的用户，若记录有与所述用户特征信息匹配的用户，执行步骤s14。

步骤s14，判定该用户的状态为在线。

根据实际需求，可以设定网络服务器20仅对来自于设定的入接口，如用户对应的终端接入的入接口的数据报文执行步骤s13的查找操作。又例如，可以在出厂时默认设置，或者由用户自定义设置对来自于哪些入接口的数据报文执行步骤s13的查找操作。

为了实现对需要进行状态探测的用户，如分配有资源的用户的状态探测，网络服务器20中预先记录有需要进行状态探测的用户信息。通过用户特征信息，网络服务器20可以查找是否记录有与该用户特征信息匹配的用户，若记录有，表明数据报文为需要进行状态探测的用户所发送的，用户在发送数据报文，从而可以确定该用户的状态为在线，进而实现对用户状态的探测。

需要进行状态探测的用户信息可以通过多种方式记录。例如，可以通过用户表的形式，记录各需要进行状态探测的用户与各用户特征信息的匹配关系。相应地，步骤s13可以通过以下方式实现：根据所述用户特征信息查找预先存储的用户表，若在所述用户表中查找到与所述用户特征信息匹配的用户，判定该用户的状态为在线，将所述数据报文进行正常转发。若在所述用户表中未查找到与所述用户特征信息匹配的用户，将所述数据报文进行正常转发。

鉴于网络服务器20在对数据报文进行转发过程中，原本便会解析数据报文，得到数据报文的sip地址、smac地址、入接口等信息，因而，本公开中只需将在数据报文转发过程中解析得到的信息，与预先记录的需要进行状态探测的用户信息进行匹配，即可实现对需要进行状态探测的用户状态探测，实现较为便捷。网络服务器20查找是否记录有与用户特征信息匹配的用户实现较快，用时基本上可以忽略不计，耗费的处理资源亦较少，实现较为便捷，适用场景较广。

在记录有与接收到的数据报文包括的用户特征信息匹配的用户的情况下，判定该用户的状态为在线。

请结合参阅图3，网络服务器20还执行以下步骤。

步骤s21，在设定周期内，检测是否存在未接收到包括其特征信息的数据报文的目标用户，若存在所述目标用户，执行步骤s22。

其中，可以从记录的用户中检测是否存在未接收到包括其特征信息的数据报文的目标用户。

步骤s22，判断所述目标用户的状态是否为下线。

其中，设定周期可以灵活设定。例如，在会频繁进行数据交互的场景中，设定周期可以设定为相对短的时长，以确保能及时探测到用户的状态，及时实现资源的合理分配。又例如，在数据交互较少的场景中，设定周期可以设定为相对长的时长，以确保探测的准确性，避免对用户状态的误判和资源的误回收。设定周期可以在出厂时进行默认设定，也可以提供多种选择方案，供用户自行选择。还可以由用户自定义设置，本公开对此不作限制。

通过对设定周期的巧妙设置，若需要进行状态检测的用户的状态为在线，那么，在设定周期内用户发送数据报文的几率较大，接收到用户发送的数据报文后，解析数据报文得到用户特征信息，便可查找出记录的与该用户特征信息匹配的用户，从而判定用户的状态为在线。相应地，若需要进行状态检测的用户的状态为下线，那么，在设定周期内用户不会发送数据报文，从而无法得到用户特征信息，无法查找出该用户。

判断目标用户的状态是否为下线的方式有多种，例如，若存在未接收到包括其特征信息的数据报文的目标用户，可以直接判定所述目标用户的状态为下线。又例如，请结合参阅图4，为了进一步提高探测准确性，避免对用户状态的误判和资源的误回收，在设定周期内，在记录的各用户中，检测到存在未接收到包括其特征信息的数据报文的目标用户之后，还可以向目标用户发送探测其状态的协议报文，通过“双重”探测，确保状态判定的准确性。

如图4所示，包括以下步骤。

步骤s221，向所述目标用户对应的终端发送探测用户状态的协议报文。

步骤s222，检测是否接收到所述终端反馈的响应报文。若未接收到所述终端反馈的响应报文，执行步骤s223。若接收到所述终端反馈的响应报文，执行步骤s224。

步骤s223，判定所述目标用户的状态为下线。

步骤s224，判定所述目标用户的状态为在线。

鉴于用户在线的情况下，大都会发送数据报文，因而，通过对数据报文的分析，可以探测出大部分在线的用户，相应地，初步认为不在线的目标用户数量较为有限，再向经过初步“筛选”的目标用户发送探测用户状态的协议报文，并进行相应的响应报文处理工作量较小，不会造成处理资源的大量占用。

为了实现对用户状态的及时探测，确保资源的合理分配，针对状态为在线的用户，可以按设定周期进行判定。若探测得出用户的状态为在线，表明用户在该设定周期中在线，在下一个设定周期内，针对上一设定周期判定为在线的用户，重新执行图2和图3所示步骤，从而重新检测是否接收到包括其用户特征信息的数据报文，若接收到包括其用户特征信息的数据报文，判定该用户的状态为在线，若未接收到包括其用户特征信息的数据报文，判断该用户的状态是否为下线。以此类推，针对分配有资源且状态为在线的用户，各设定周期均会进行状态探测，在用户下线后，及时探测到用户状态，进行资源回收。

请结合参阅图5，为了提高资源重新分配的便捷性，可选地，所述方法还包括以下步骤。

步骤s31，将状态为下线的用户进行标识。

步骤s32，在判定用户的状态为下线之后的下一个设定周期，将分配给该用户的资源进行回收。

其中，对用户进行标识的方式有多种，例如，可以通过状态设置的方式进行标识。又例如，可以通过标签的形式进行标识。本公开对此不做限制。

以下述场景为例，对实现资源回收的实现流程进行举例说明。

用户a初始上线时，网络服务器20给用户a分配资源，并设置用户a的状态为在线。启动状态探测处理流程后，网络服务器20开始在第一设定周期内检测用户a的状态，由于用户a初始状态为在线，表示用户a在线，在第一设定周期不回收分配给用户a的资源。

在第一设定周期内，第二设定周期之前(第二设定周期为第一设定周期之后的下一个设定周期)，网络服务器20接收到数据报文后，根据数据报文的sip地址、smac地址、入接口等特征信息，查找是否接收到包括的特征信息与用户a匹配的数据报文，如果接收到包括的特征信息与用户a匹配的数据报文，判定用户a在第一设定周期在线，将用户a的状态设置成在线状态。如果未接收到包括的特征信息与用户a匹配的数据报文，判定用户a在第一设定周期下线，将用户a的状态设置成检测状态。以此类推，实现对各分配有资源的用户的状态设置。

在第二设定周期内，遍历各分配有资源的用户的状态，如果用户的状态设置为在线状态，判定第二设定周期内，用户活跃，依然在线，在第二设定周期不回收分配给用户的资源。如果用户的状态设置为检测状态，判定第二设定周期内，用户已经下线，从而回收分配给用户的资源。

本公开中，分配给用户的资源包括但不限于分配给用户对应的终端的ip地址、业务流量、上线时间信息等。

应当理解，网络服务器20中记录的为需要进行状态探测的用户信息，若探测得出用户的状态为下线，相应地，删除记录的该用户信息，若探测得出用户的状态为在线，相应地，保留记录的该用户信息，从而在下一个设定周期再次探测记录的在线的用户状态。在对资源进行重新分配之后，若存在新的用户被分配到资源，相应地，将该新的用户的用户信息进行记录，从而在下一个设定周期探测其状态。

为了更为清楚地阐述本公开的实现原理和优越性，现以下述场景为例，对直接采用协议报文进行状态探测的实现流程与本公开中采用数据报文进行状态探测的实现流程进行对比性的举例说明。

网络服务器20为路由器，路由器包括进行资源分配、报文构造等的中央处理器(centralprocessingunit，cpu)和进行报文转发的报文转发芯片。各分配有资源的用户与各用户特征信息的匹配关系记录在用户表中。采用定时器统计设定周期。

请结合参阅图6，直接采用协议报文进行状态探测的情况下，包括以下实现步骤。

步骤s41，定时器启动发送探测报文的进程。

步骤s42，cpu遍历用户表中的用户，针对用户表中的每个用户，判断上一个设定周期，如5分钟内是否接收到该用户反馈的响应报文，如果未接收到该用户反馈的响应报文，执行步骤s43，如果接收到该用户反馈的响应报文，执行步骤s44。

步骤s43，判定该用户在上一个设定周期内的状态为下线，从而回收分配给用户的资源。

步骤s44，判定该用户在上一个设定周期内的状态为在线，在本设定周期中，构造探测用户状态的协议报文并发送至报文转发芯片，根据协议报文生成转发表项下发到报文转发芯片。

步骤s45，报文转发芯片接收到协议报文和转发表项之后，根据转发表项将协议报文转发到对应的出接口。用户的状态为在线时，用户对应的终端接收到协议报文后反馈响应报文，用户的状态为下线时，用户对应的终端不反馈响应报文。

步骤s46，报文转发芯片若接收到针对探测用户状态的协议报文的响应报文，将响应报文发送至cpu。

步骤s47，cpu接收到响应报文之后，检测是否向反馈响应报文的用户发送过探测用户状态的协议报文，若发送过协议报文，执行步骤s48，若未发送过协议报文，则执行步骤s49。

步骤s48，判定接收到用户的响应报文，用户在线。

步骤s49，判定该响应报文为误发送，丢弃该报文。

分析上述步骤s41至步骤s49可知，直接采用协议报文进行状态探测的情况下，大部分步骤，如步骤s42至步骤s44，以及步骤s47至步骤s49均由cpu执行，针对用户表中的每个用户，在每个设定周期，cpu均需执行相应操作，会占用大量的cpu资源。仅依赖于协议报文探测用户状态，在协议报文丢失后，将导致用户状态误检测。

请结合参阅图7，采用本公开中的实现方案，根据数据报文进行状态探测的情况下，包括以下实现步骤。

步骤s51，报文转发芯片接收到数据报文之后，解析数据报文，得到数据报文包括的用户特征信息；

步骤s52，报文转发芯片查找用户表中是否存在与用户特征信息匹配的用户，如果存在，执行步骤s53和步骤s54。如果不存在，直接执行步骤s54。

步骤s53，判定查找到的用户的状态为在线。

步骤s54，转发数据报文。

请结合参阅图8，进一步地，按设定周期对用户表中用户的状态进行探测的情况下，报文转发芯片和cpu分别执行以下步骤。

步骤s61，定时器启动发送探测报文的进程。

步骤s62，报文转发芯片遍历用户表中的用户，针对用户表中的每个用户，判断在上一个设定周期，按照图6所示流程，是否判定该用户的状态为在线，如果用户的状态为下线(在上一个设定周期内，未接收到包括该用户特征信息的数据报文)，则执行步骤s63。若用户的状态为在线，则执行步骤s64。

步骤s63，判定用户已经下线，可以回收资源，从而构造回收资源的消息发送至cpu。

步骤s64，判定用户在上一个设定周期在线，从而根据是否在本设定周期内接收到包括该用户特征信息的数据报文，判定该用户在本设定周期内的状态为在线还是下线。

步骤s65，cpu根据回收资源的消息，回收分配给该用户的资源。

分析上述步骤s51至步骤s54，以及步骤s61至步骤s65可知，本公开中根据数据报文进行状态探测的情况下，大部分步骤，如步骤s51至步骤s54，以及步骤s62至步骤s64均由报文转发芯片执行。需cpu执行的步骤如上述步骤s65较少，因而，可以显著降低cpu资源占用量。

鉴于即使在网络拥塞的状态下，用户发送的数据报文全部丢失的几率极低，因而，采用本公开中的方案可以提高状态探测准确性，避免用户的状态误检测。

应当理解，针对用户表中的用户，若在上一个设定周期内，未接收到包括该用户特征信息的数据报文，为了确保状态探测的准确性，还可以按照图6所示流程，向该用户发送探测其状态的协议报文，若接收到用户针对该协议报文反馈的响应报文，判定用户的状态为在线，否则判定用户的状态为下线。通过“双重”检测的方式，确保状态探测的准确性，避免资源误回收。鉴于通过对数据报文的分析，可以探测出大部分在线的用户，相应地，基于数据报文初步认为不在线的用户数量较为有限，因而再向经过初步“筛选”的用户发送探测用户状态的协议报文，并进行相应的响应报文处理工作量较小，不会造成网络服务器20的cpu资源的大量占用。

请参阅图9，本公开还提供一种状态探测装置24，包括：报文接收模块241、报文解析模块242和状态确认模块243。

其中，报文接收模块241用于接收数据报文。

关于报文接收模块241的实现方式可以参阅图2中步骤s11的相关描述，在此不作赘述。

报文解析模块242用于解析所述数据报文，得到所述数据报文包括的用户特征信息。

关于报文解析模块242的实现方式可以参阅图2中步骤s12的相关描述，在此不作赘述。

状态确认模块243用于查找是否记录有与所述用户特征信息匹配的用户，若记录有与所述用户特征信息匹配的用户，则判定该用户的状态为在线；在设定周期内，检测是否存在未接收到包括其特征信息的数据报文的目标用户，若存在所述目标用户，判断所述目标用户的状态是否为下线。

关于状态确认模块243的实现方式可以参阅图2中步骤s13和步骤s14，以及图3中步骤s21和步骤s22的相关描述，在此不作赘述。

可选地，所述状态确认模块243用于，若存在所述目标用户，直接判定所述目标用户的状态为下线；或者，若存在所述目标用户，向所述目标用户对应的终端发送探测用户状态的协议报文，检测是否接收到所述终端反馈的响应报文，若未接收到所述终端反馈的响应报文，判定所述目标用户的状态为下线；若接收到所述终端反馈的响应报文，判定所述目标用户的状态为在线。

可选地，所述状态确认模块243还用于，将状态为下线的用户进行标识，在判定用户的状态为下线之后的下一个设定周期，将分配给该用户的资源进行回收。

可选地，状态确认模块243用于，根据所述用户特征信息查找预先存储的用户表，若在所述用户表中查找到与所述用户特征信息匹配的用户，判定该用户的状态为在线。

本公开中，状态探测装置24的实现原理与前述状态探测方法的实现原理类似，相应内容可以参阅前述方法实施例，因而在此不作赘述。

本公开中的状态探测方法、装置及网络服务器，通过活跃用户所传递的数据报文，提取得到用户特征信息，从而根据用户特征信息匹配确定用户的状态，实现较为便捷。

在本公开所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置和方法实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本公开的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本公开各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，网络服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅为本公开的可选实施例而已，并不用于限制本公开，对于本领域的技术人员来说，本公开可以有各种更改和变化。凡在本公开的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。