CN105939374A - 在线用户下线的处理方法及装置 - Google Patents

Abstract

本申请提供一种在线用户下线的处理方法及装置，所述方法应用在框式设备上，所述框式设备上包括主控板和业务板，所述主控板存储已通过认证的用户的用户信息，并将所述用户信息下发至所述业务板据以转发用户流量；所述方法包括：所述业务板根据所述用户信息，检测到在预定时间内无流量通过的在线用户时，通过预设的通信方式，向主控板发送下线通知报文，所述下线通知报文包括所述在线用户的用户信息；所述主控板接收到所述下线通知报文后，删除所存储的所述用户信息，以将所述在线用户下线。应用本申请实施例，实现了有效地利用框式设备的性能，且安全地将在线用户下线。

Description

在线用户下线的处理方法及装置

技术领域

本申请涉及网络通信技术领域，尤其涉及在线用户下线的处理方法及装置。

背景技术

为了保障内网(例如，企业网)的安全性，可以对接入内网的用户进行身份认证，例如，对请求接入内网的用户进行Portal认证，检查用户名和密码，检查通过，则该用户通过认证，即该用户上线。在用户数量较多的场景中，可以使用框式设备启用Portal认证，该框式设备包括主控板和业务板。当用户通过认证后，该框式设备可以将该用户的用户信息(例如用户IP地址、用户名等)存放在主控板的用户态中，以表示该用户在线。主控板将在线用户的用户信息下发到业务板，由业务板根据用户信息对接收到的用户流量进行识别，放行在线用户的流量。当在线用户下线时，可以将该用户的用户信息从主控板上删除。

为了维护已认证用户的上下线，现有技术中，可以由主控板根据在用户态中记录的在线用户的用户信息，定期去业务板查询该在线用户是否有流量通过，比如，主控板可以通过系统调用将用户信息由用户态下发到内核态，内核态再通过主控板和业务板之间的板间通道，到业务板上查询该用户信息所对应的用户是否有流量通过，并将查询结果返回到用户态，以使用户态根据该查询结果维护已认证用户的上下线，例如，若获取到在线用户已无流量通过，则将该在线用户下线，即将该在线用户的用户信息删除。

然而，上述将在线用户下线的处理方法浪费了框式设备的性能，而且不安全。例如，当在线用户数量较多时，框式设备的用户态将频繁调用系统调用，从而浪费了框式设备的性能；且由于主控板和业务板之间频繁地进行数据交互，将占用板间通道的带宽，有可能造成板间通道上的其他数据丢失，例如路由、ARP(Address Resolution Protocol，地址解析协议)表项等数据，造成网络中断。

发明内容

有鉴于此，本申请提供一种在线用户下线的处理方法及装置，以实现有效地利用框式设备的性能，且安全地将在线用户下线。

具体地，本申请是通过如下技术方案实现的：

根据本申请实施例的第一方面，提供一种在线用户下线的处理方法，所述方法应用在框式设备上，所述框式设备上包括主控板和业务板，所述主控板存储已通过认证的用户的用户信息，并将所述用户信息下发至所述业务板据以转发用户流量；所述方法包括：

所述业务板根据所述用户信息，检测到在预定时间内无流量通过的在线用户时，通过预设的通信方式，向主控板发送下线通知报文，所述下线通知报文包括所述在线用户的用户信息；

所述主控板接收到所述下线通知报文后，删除所存储的所述用户信息，以将所述在线用户下线。

在一个实施例中，所述业务板根据所述用户信息，检测到在预定时间内无流量通过的在线用户，包括：

所述业务板根据预配置的用户老化时间，分别记录在线用户在间隔所述用户老化时间前后的两个流量值；

若所记录的两个流量值相等，则确定所述在线用户在预定时间内无流量通过。

在另一个实施例中，所述通过预设的通信方式，向主控板发送下线通知报文，包括：

通过socket通信方式，由业务板作为socket客户端，封装UDP报文作为所述下线通知报文，将所述下线通知报文通过交换芯片发送至作为另一个socket客户端的主控板。

在另一个实施例中，所述通过预设的通信方式，向主控板发送下线通知报文，包括：

所述业务板通过与主控板之间的板间通道，将所述下线通知报文发送至所述主控板。

在另一个实施例中，所述用户信息包括：用户IP地址、用户名；

所述下线通知报文，还包括：随机码、第一校验码，所述第一校验码由业务板按照预设的算法，将所述下线通知报文中的用户IP地址、用户名以及随机码行运算生成；

所述主控板接收到所述下线通知报文后，删除所存储的所述用户信息，包括：

所述主控板接收到所述下线通知报文后，按照所述预设的算法，将所述下线通知报文中所包括的随机码、以及所述查找到的在主控板中所保存的用户IP地址、用户名进行运算，生成第二校验码；

若所述第二校验码与所述第一校验码相同，则将所述用户信息删除。

根据本申请实施例的第二方面，提供一种在线用户下线的处理装置，其特征在于，所述装置应用在框式设备上，所述框式设备上包括主控板和业务板，所述主控板存储已通过认证的用户的用户信息，并将所述用户信息下发至所述业务板据以转发用户流量；所述装置包括：

通知单元，用于所述业务板根据所述用户信息，检测到在预定时间内无流量通过的在线用户时，通过预设的通信方式，向主控板发送下线通知报文，所述下线通知报文包括所述在线用户的用户信息；

处理单元，用于所述主控板接收到所述下线通知报文后，删除所存储的所述用户信息，以将所述在线用户下线。

在一个实施例中，所述通知单元，包括：

记录子单元，用于所述业务板根据预配置的用户老化时间，分别记录在线用户在间隔所述用户老化时间前后的两个流量值；

确定子单元，用于在所记录的两个流量值相等时，确定所述在线用户在预定时间内无流量通过。

在另一个实施例中，所述通知单元，用于所述业务板在根据所述用户信息，检测到在预定时间无流量通过的在线用户时，通过socket通信方式，由业务板作为socket客户端，封装UDP报文作为所述下线通知报文，将所述下线通知报文通过交换芯片发送至作为另一个socket客户端的主控板。

在另一个实施例中，所述通知单元，用于所述业务板在根据所述用户信息，检测到在预定时间无流量通过的在线用户时，所述业务板通过与主控板之间的板间通道，将所述下线通知报文发送至所述主控板。

在另一个实施例中，所述用户信息包括：用户IP地址、用户名；

所述下线通知报文，还包括：随机码、第一校验码，所述第一校验码由业务板按照预设的算法，将所述下线通知报文中的用户IP地址、用户名以及随机码行运算生成；

所述处理单元，包括：

生成子单元，用于所述主控板接收到所述下线通知报文后，按照所述预设的算法，将所述下线通知报文中所包括的随机码、以及所述查找到的在主控板中所保存的用户IP地址、用户名进行运算，生成第二校验码；

删除子单元，用于在所述第二校验码与所述第一校验码相同时，将所述用户信息删除。

应用本实施例在线用户下线的处理方法，由于业务板可以通过检测确定已无流量通过的在线用户，并主动将该在线用户的用户信息发送至主控板，由主控板删除自身所保存的该在线用户的用户信息，以将该在线用户下线。从而，当在线用户数量较多时，主控板可以不用频繁调用系统调用，主动去业务板查询在线用户是否还有流量通过，从而节省了框式设备的性能，且主控板和业务板也可以不再频繁地利用板间通道进行数据交互，从而不过多的占用板间通道的带宽，不影响板间通道上其它数据的传输，实现了安全可靠地将在线用户下线。

附图说明

图1A为本申请实施例实现在线用户下线的处理方法的应用场景示意图。

图1B示例了框式设备的内部结构图。

图2示例了本申请在线用户下线的处理方法的一个实施例流程图。

图3示例了本申请在线用户下线的处理方法的另一个实施例流程图。

图4为本申请在线用户下线的处理装置所在框式设备的一种硬件结构图。

图5示例了本申请在线用户下线的处理装置的一个实施例框图。

图6示例了本申请在线用户下线的处理装置的另一个实施例框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

框式设备相较于盒式设备，具有可用性高、性能高、高端口密度等优点，因此框式设备经常被应用于网络较复杂的场合，例如，在内网(例如，企业网)的接入用户数量较多时，需要性能较高的框式设备对请求接入内网的用户进行认证，并维护已通过认证，即在线用户的上下线。

为了有效地利用框式设备的性能，且实现安全可靠地将在线用户下线，本申请提出了一种在线用户下线的处理方法及装置。如下的图1A所示，为本申请实施例实现在线用户下线的处理方法的应用场景示意图。

图1A中包括，框式设备11、企业服务器12、用户13至用户1n。其中，框式设备11可以开启Portal认证功能，对请求接入的用户进行认证，维护用户的上下线，并可以控制用户向企业服务器12发送的流量。例如，用户13可以向框式设备11请求进行认证，认证通过后，框式设备11可以使用户13处于在线状态；当用户13向企业服务器12发送流量时，该流量先传输至框式设备11，由于用户13在线，则框式设备11可以放行该流量，将该流量转发至企业服务器12；当用户13在一定条件下，例如，在预定的时间内，无流量通过时，框式设备11可以将用户13下线。

为了详细说明框式设备11如何实现在线用户下线，本申请中，先对框式设备的内部结构作出介绍，如下的图1B所示，示例了框式设备的内部结构图，该图1B在上述图1A所示的应用场景示意图的基础上，以图1A中的框式设备11为例，进行说明。

该框式设备11上可以包括主控板111和业务板112，其主控板111上又可以包括用户态1111和内核态1112，另外，主控板111和业务板112之间存在板间通道113，且该框式设备11中还包括交换芯片114，主控板111和业务板112之间，既可以通过板间通道113进行数据交互，也可以通过某种技术手段实现通过交换芯片114进行数据交互。当用户，例如用户13，通过认证时，该框式设备11可以在用户态1111中，保存用户13的用户信息，例如，用户IP地址、用户名等，以表示用户13已通过认证，即用户13处于在线状态。

主控板111可以将用户态1111中所保存的在线用户的用户信息，先发送至内核态1112，再由内核态1112将其发送至业务板112，业务板112可以保存接收到的用户信息。当业务板112接收到用户向企业服务器12发送的流量时，可以根据所保存的用户信息，确定该用户是否在线，以确定如何处理该用户所发送的流量，例如，当接收到用户13发送的流量，且确定用户13在线，则放行该流量。业务板112可以记录在线用户通过的流量，当业务板112确定某个在线用户已无流量通过时，可以通知主控板111，例如，业务板112向主控板111发送携带该已无流量通过的在线用户的用户信息的下线通知报文，该下线通知报文先传输至内核态1112上，再由内核态1112将其发送至用户态1111，以使主控板111将该在线用户的用户信息从用户态1111中删除，以表示该在线用户下线。

下面，在上述图1B所示结构图的基础上，详细说明本申请如何实现在线用户下线的，如图2所示，示例了本申请在线用户下线的处理方法的一个实施例流程图，以框式设备11执行本实施例的方法为例，包括以下步骤：

步骤S201：所述业务板根据所述用户信息，检测到在预定时间内无流量通过的在线用户时，根据预设的通信方式，向主控板发送下线通知报文，所述下线通知报文包括所述在线用户的用户信息。

以图1B中所示的业务板112为例，业务板112在接收到在线用户发送的流量时，可以对该流量值进行记录，以方便之后可以根据所记录的流量值，检测在线用户在预定的时间内，例如，5分钟内，是否还有流量通过。若根据检测结果，确定某个在线用户，例如用户13，已无流量通过时，业务板112可以按照预设的通信方式，例如socket通信方式，向主控板111发送携带用户13的用户信息的下线通知报文，以通知主控板111，该用户13已无流量通过。

步骤S202：所述主控板接收到所述下线通知报文后，删除所存储的所述用户信息，以将所述在线用户下线。

当主控板111接收到下线通知报文后，可以根据该下线通知报文中所携带的用户信息，将本地所保存的该用户信息删除，以表示该在线用户已下线，从而实现在线用户的下线处理。

应用本实施例在线用户下线的处理方法，由于业务板可以通过检测确定已无流量通过的在线用户，并主动将该在线用户的用户信息发送至主控板，由主控板删除自身所保存的该在线用户的用户信息，以将该在线用户下线。从而，当在线用户数量较多时，主控板可以不用频繁调用系统调用，主动去业务板查询在线用户是否还有流量通过，从而节省了框式设备的性能，且主控板和业务板也可以不再频繁地利用板间通道进行数据交互，从而不过多的占用板间通道的带宽，不影响板间通道上其它数据的传输，实现了安全可靠地将在线用户下线。

为了更详细的说明本申请是如何实现将在线用户下线的，下面，结合图3所示的实施例，对本申请在线用户下线的处理方法做出更详细的说明，该图3在上述图2所示实施例的基础上，以图1B所示的框式设备11执行本实施例的方法为例，如下的图3，示例了本申请在线用户下线的处理方法的另一个实施例流程图，包括以下步骤：

步骤S301：所述业务板根据预配置的用户老化时间，分别记录在线用户在间隔所述用户老化时间前后的两个流量值。

本实施例中，业务板112可以为在线用户设置老化时间，例如为5分钟，即当在线用户在5分钟内，无流量通过框式设备11，则框式设备11可以将该在线用户下线。

业务板112可以根据该老化时间，记录在线用户的流量值，具体地，例如，用户13在线，则业务板112每隔该老化时间，分别记录用户13的流量值，例如，所记录的当前流量值为100M，该老化时间之前的流量值为50M。

步骤S302：若所记录的两个流量值相等，则确定所述在线用户在预定时间内无流量通过。

在一个例子中，业务板112可以预先设置一个定时器，该定时器包括预定时间，该预定时间可以与上述老化时间相同。当定时器达到该预定时间时，业务板112可以遍历所记录的在线用户所对应的两个流量值，若该两个流量值相同，可以说明，在预定时间内，该在线用户并无流量通过。

步骤S303：通过socket通信方式，由业务板作为socket客户端，封装UDP(User Datagram Protocol，用户数据报协议)报文作为下线通知报文，将所述下线通知报文通过交换芯片发送至作为另一个socket客户端的主控板。

当执行完步骤S302，确定某个在线用户在预定时间内已无流量通过时，业务板112可以向主控板111发送一个下线通知报文，该下线通知报文携带所述已确定无流量通过的在线用户的用户信息。此外，本实施例中，业务板还可以将所保存的该在线用户的用户信息删除，以使得当再次收到该用户的流量时，根据未保存该用户的用户信息，从而选择阻断该用户的流量。

在一个例子中，可以模拟socket通信方式，即将主控板111和业务板112分别作为一个socket端，业务板112向主控板111发送该下线通知报文时，即可以基于socket通信方式，业务板112作为一个socket端，可以将该下线通知报文通过交换芯片114，发送至作为另一个socket端的主控板111。

具体地，为了实现模拟socket通信方式，业务板111可以构造一个UDP报文，该UDP报文携带已确定无流量通过的在线用户的用户信息，例如用户IP地址、用户名，且该UDP报文的目的IP地址可以是框式设备11的IP地址，目的端口可以是主控板112的端口。在本实施例中，该UDP报文中还可以携带随机码和第一校验码，其中，随机码是由业务板112随机生成的，例如，该随机码的大小为16字节，第一校验码则是由业务板112按照预设的算法，例如，MD5(Message Digest Algorithm 5，信息摘要算法5)算法，将UDP报文中所携带的随机码、用户IP地址、用户名，进行运算生成的。本实施例中，将该UDP报文即可以作为下线通知报文。

由于模拟socket通信方式，主控板111和业务板112之间进行通信时，所传输的数据，例如，传输下线通知报文，可以不再通过板间通道113，而是通过交换芯片114进行传输，从而不会占用板间通道113的带宽，不影响板间通道113上其它数据，例如路由、ARP表项等数据的传输。

此外，在本申请实施例中，主控板111和业务板112之间进行通信时，例如，业务板112向主控板111发送所述下线通知报文时，还可以使用板间通道113，即可以采用现有的板间通信方式传输所述下线通知报文，且主控板111接收到该下线通知报文后，可以采用现有的netlink socket通信方式将该下线通知报文从内核态1112发送至用户态1111，以通知用户态1111将某个在线用户的用户信息删除，板间通信方式及netlink socket通信方式的具体原理可以参见现有技术，本申请对此不做详述。

由于通常不会出现大量的在线用户同时下线情况，则很可能不会出现业务板112频繁地向主控板111发送下线通知报文，相比较于现有技术中，当在线用户数量较多时，主控板111将频繁地调用系统调用，且频繁地通过板间通道，主动向业务板查询在线用户是否还有流量通过，本方法也有效地减少了主控板调用系统调用的次数，从而节省了框式设备11的性能；且减小了主控板与业务板之间通过板间通道进行数据交互，占用板间通道带宽的频率，从而降低了影响板间通道上其它数据传输的可能性。

步骤S304：主控板接收到所述下线通知报文后，按照所述预设的算法，将所述下线通知报文中所包括的随机码、以及所述查找到的在主控板中所保存的用户IP地址、用户名进行运算，生成第二校验码。

当主控板111接收到下线通知报文后，可以根据该下线通知报文中携带的用户信息，例如用户IP地址、用户名，查找到自身所保存的相同的用户IP地址和用户名。之后，主控板将所查找到的用户IP地址、用户名，以及该下线通知报文中所携带的随机码，进行与步骤S303中相同的运算，例如MD5运算，生成一个校验码，将该校验码作为第二校验码。

步骤S305：若所述第二校验码与所述第一校验码相同，则将所述用户信息删除。

当通过执行步骤S304所得的的第二校验码与下线通知报文中所携带的第一校验码相同时，主控板111可以将步骤S304中所查找到的用户信息从本地存储中删除，以实现将该用户信息所对应的用户下线。

采用校验码这种方式，可以避免主控板111所接收到的下线通知报文并不是由业务板112所发送的，例如，是恶意攻击者通过技术手段所发送的，可以通过匹配校验码，确定所接收到的下线通知报文是业务板112所发送的可靠的下线通知报文，从而可以避免将实际仍有流量通过的在线用户下线，影响在线用户的体验，提高了将在线用户下线的处理方法的可靠性。

此外，本申请实施例中，业务板112向主控板111所发送的下线通知报文中，还可以只携带用户信息，当主控板111接收到该下线通知报文后，可以根据其所携带的用户信息查找到自身所保存的用户信息，删除所存储的该用户信息，以实现将该用户信息所对应的在线用户下线。

应用本实施例在线用户下线的处理方法，由于业务板可以根据预先配置的老化时间记录在线用户的流量，根据所记录的流量，确定出已无流量通过的在线用户，并可以通过模拟socket通信方式，使用交换芯片，主动将该在线用户的用户信息发送至主控板，由主控板删除自身所保存的该在线用户的用户信息，以将该在线用户下线。从而，当在线用户数量较多时，主控板可以不用频繁调用系统调用，去业务板查询在线用户是否还有流量通过，从而节省了框式设备的性能；且主控板和业务板之间可以不再频繁地利用板间通道进行通信，从而，不过多的占用板间通道的带宽，不影响板间通道上其它数据的传输，实现了安全可靠地将在线用户下线。

与前述在线用户下线的处理方法的实施例相对应，本申请还提供了在线用户下线的处理装置的实施例。

本申请在线用户下线的处理装置的实施例可以应用在框式设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在框式的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4所示，为本申请在线用户下线的处理装置所在框式设备的一种硬件结构图，除了图4所示的处理器41、内存42、网络接口43、以及非易失性存储器44之外，实施例中装置所在的框式设备通常根据该框式设备的实际功能，还可以包括其他硬件，对此不再赘述。

请参考图5，示例了本申请在线用户下线的处理装置的一个实施例框图，所述装置可以应用在框式设备上，所述框式设备上包括主控板和业务板，所述主控板存储已通过认证的用户的用户信息，并将所述用户信息下发至所述业务板据以转发用户流量；所述装置可以包括：通知单元51、处理单元52。

其中，所述通知单元51，用于所述业务板根据所述用户信息，检测到在预定时间内无流量通过的在线用户时，通过预设的通信方式，向主控板发送下线通知报文，所述下线通知报文包括所述在线用户的用户信息；

所述处理单元52，用于所述主控板接收到所述下线通知报文后，删除所存储的所述用户信息，以将所述在线用户下线。

请参考图6，示例了本申请在线用户下线的处理装置的另一个实施例框图，所述装置在图5所示的装置的基础上，所述通知单元51，可以包括：记录子单元511、确定子单元512。

其中，所述记录子单元511，可以用于所述业务板根据预配置的用户老化时间，分别记录在线用户在间隔所述用户老化时间前后的两个流量值；

所述确定子单元512，可以用于在所记录的两个流量值相等时，确定所述在线用户在预定时间内无流量通过。

在一个例子中，所述通知单元51，可以用于所述业务板在根据所述用户信息，检测到在预定时间无流量通过的在线用户时，通过socket通信方式，由业务板作为socket客户端，封装UDP报文作为所述下线通知报文，将所述下线通知报文通过交换芯片发送至作为另一个socket客户端的主控板。

在另一个例子中，所述通知单元51，可以用于所述业务板在根据所述用户信息，检测到在预定时间无流量通过的在线用户时，所述业务板通过与主控板之间的板间通道，将所述下线通知报文发送至所述主控板。

所述用户信息可以包括：用户IP地址、用户名；

所述下线通知报文，还可以包括：随机码、第一校验码，所述第一校验码由业务板按照预设的算法，将所述下线通知报文中的用户IP地址、用户名以及随机码行运算生成；

所述处理单元52，可以包括：生成子单元521、删除子单元522。

其中，所述生成子单元521，可以用于所述主控板接收到所述下线通知报文后，按照所述预设的算法，将所述下线通知报文中所包括的随机码、以及所述查找到的在主控板中所保存的用户IP地址、用户名进行运算，生成第二校验码；

所述删除子单元522，可以用于在所述第二校验码与所述第一校验码相同时，将所述用户信息删除。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种在线用户下线的处理方法，其特征在于，所述方法应用在框式设备上，所述框式设备上包括主控板和业务板，所述主控板存储已通过认证的用户的用户信息，并将所述用户信息下发至所述业务板据以转发用户流量；所述方法包括：

所述业务板根据所述用户信息，检测到在预定时间内无流量通过的在线用户时，通过预设的通信方式，向主控板发送下线通知报文，所述下线通知报文包括所述在线用户的用户信息；

所述主控板接收到所述下线通知报文后，删除所存储的所述用户信息，以将所述在线用户下线。

2.根据权利要求1所述的方法，其特征在于，所述业务板根据所述用户信息，检测到在预定时间内无流量通过的在线用户，包括：

所述业务板根据预配置的用户老化时间，分别记录在线用户在间隔所述用户老化时间前后的两个流量值；

若所记录的两个流量值相等，则确定所述在线用户在预定时间内无流量通过。

3.根据权利要求1所述的方法，其特征在于，所述通过预设的通信方式，向主控板发送下线通知报文，包括：

通过socket通信方式，由业务板作为socket客户端，封装用户数据报协议UDP报文作为所述下线通知报文，将所述下线通知报文通过交换芯片发送至作为另一个socket客户端的主控板。

4.根据权利要求1所述的方法，其特征在于，所述通过预设的通信方式，向主控板发送下线通知报文，包括：

所述业务板通过与主控板之间的板间通道，将所述下线通知报文发送至所述主控板。

5.根据权利要求1所述的方法，其特征在于，所述用户信息包括：用户IP地址、用户名；

所述下线通知报文，还包括：随机码、第一校验码，所述第一校验码由业务板按照预设的算法，将所述下线通知报文中的用户IP地址、用户名以及随机码行运算生成；

所述主控板接收到所述下线通知报文后，删除所存储的所述用户信息，包括：

所述主控板接收到所述下线通知报文后，按照所述预设的算法，将所述下线通知报文中所包括的随机码、以及所述查找到的在主控板中所保存的用户IP地址、用户名进行运算，生成第二校验码；

若所述第二校验码与所述第一校验码相同，则将所述用户信息删除。

6.一种在线用户下线的处理装置，其特征在于，所述装置应用在框式设备上，所述框式设备上包括主控板和业务板，所述主控板存储已通过认证的用户的用户信息，并将所述用户信息下发至所述业务板据以转发用户流量；所述装置包括：

通知单元，用于所述业务板根据所述用户信息，检测到在预定时间内无流量通过的在线用户时，通过预设的通信方式，向主控板发送下线通知报文，所述下线通知报文包括所述在线用户的用户信息；

处理单元，用于所述主控板接收到所述下线通知报文后，删除所存储的所述用户信息，以将所述在线用户下线。

7.根据权利要求6所述的装置，其特征在于，所述通知单元，包括：

记录子单元，用于所述业务板根据预配置的用户老化时间，分别记录在线用户在间隔所述用户老化时间前后的两个流量值；

确定子单元，用于在所记录的两个流量值相等时，确定所述在线用户在预定时间内无流量通过。

8.根据权利要求6所述的装置，其特征在于，所述通知单元：

用于所述业务板在根据所述用户信息，检测到在预定时间无流量通过的在线用户时，通过socket通信方式，由业务板作为socket客户端，封装UDP报文作为所述下线通知报文，将所述下线通知报文通过交换芯片发送至作为另一个socket客户端的主控板。

9.根据权利要求6所述的装置，其特征在于，所述通知单元：

用于所述业务板在根据所述用户信息，检测到在预定时间无流量通过的在线用户时，所述业务板通过与主控板之间的板间通道，将所述下线通知报文发送至所述主控板。

10.根据权利要求6所述的装置，其特征在于，所述用户信息包括：用户IP地址、用户名；

所述下线通知报文，还包括：随机码、第一校验码，所述第一校验码由业务板按照预设的算法，将所述下线通知报文中的用户IP地址、用户名以及随机码行运算生成；

所述处理单元，包括：

生成子单元，用于所述主控板接收到所述下线通知报文后，按照所述预设的算法，将所述下线通知报文中所包括的随机码、以及所述查找到的在主控板中所保存的用户IP地址、用户名进行运算，生成第二校验码；

删除子单元，用于在所述第二校验码与所述第一校验码相同时，将所述用户信息删除。