CN114124314A

CN114124314A - 控制客户端上线的方法、网络设备及客户端

Info

Publication number: CN114124314A
Application number: CN202010880200.6A
Authority: CN
Inventors: 赵晖; 李威; 陈运雷; 胡雪明; 蔡宇
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-08-27
Filing date: 2020-08-27
Publication date: 2022-03-01
Anticipated expiration: 2040-08-27
Also published as: EP4195539A4; WO2022041692A1; US20230198940A1; EP4195539A1; CN114124314B

Abstract

本申请提供了一种控制客户端上线的方法、网络设备及客户端，属于通信领域。本申请提供了一种支持网络侧控制客户端重传上线请求报文的方法，通过由网络设备为客户端确定上线请求报文的发送时间间隔，将发送时间间隔通过通告报文传递给客户端，有助于客户端按照网络侧指定的时间间隔重传上线请求报文。本技术方案中，网络侧的角色从被动地响应客户端的上线请求发送行为演变至主动地控制客户端的上线请求发送行为。因此，显著加强了网络侧对重传机制的干预，有助于避免雪崩效应等问题，有助于提升整个系统的效率和鲁棒性。

Description

控制客户端上线的方法、网络设备及客户端

技术领域

本申请涉及通信领域，特别涉及一种控制客户端上线的方法、网络设备及客户端。

背景技术

上线流程通常涉及客户端与服务器的交互。具体而言，客户端会生成和发送上线请求报文，从而请求接入网络所需的参数。服务器会对上线请求报文进行响应，返回应答报文。客户端根据应答报文携带的参数接入网络。此外，在部署了中继的场景下，会由中继在客户端与服务器之间转发上线请求报文或应答报文，从而保证客户端与服务器能够正常交互。

在上线流程中，上线请求报文的重传是一个重要的环节。具体而言，客户端发送上线请求报文后，上线请求报文具有被服务器或中继延时处理或丢弃的概率，导致服务器或中继并没有返回对上线请求报文的应答报文。在目前的上线流程中，在客户端没有收到应答报文的情况下，客户端会确定预先配置的固定时长；或者，客户端对初始时长进行指数衰减，从而确定时长。客户端确定出一定的时长后，会每隔该时长，重新发送一次上线请求报文，直到收到服务器或中继返回的应答报文为止。

然而，目前上线请求报文的重传依赖于客户端独立实现，网络侧(如服务器或者中继)缺乏对重传机制的干预。由此可见，目前的方法存在局限性。

发明内容

本申请实施例提供了一种控制客户端上线的方法、网络设备及客户端，能够加强网络侧对重传机制的干预，从而一定程度上解决目前方法的局限性。所述技术方案如下：

第一方面，提供了一种控制客户端上线的方法，以该方法从网络设备一侧的角度描述，网络设备确定第一时长；所述网络设备生成通告报文，所述通告报文携带所述第一时长；所述网络设备向第一客户端发送所述通告报文，所述通告报文用于指示所述第一客户端将上线请求报文的发送时间间隔调整为所述第一时长。

以上提供了一种支持网络侧控制客户端重传上线请求报文的方法，通过由网络设备为客户端确定上线请求报文的发送时间间隔，将发送时间间隔通过通告报文传递给客户端，有助于客户端按照网络侧指定的时间间隔重传上线请求报文。相对于由客户端自行确定发送时间间隔以重传上线请求报文的机制而言，网络侧的角色从被动地响应客户端的上线请求发送行为演变至主动地控制客户端的上线请求发送行为。因此，本技术方案显著加强了网络侧对重传机制的干预，一定程度上解决目前客户端上线方法的局限性，有助于避免客户端按照自行确定的发送时间间隔进行无控制重传而触发的雪崩效应等问题，有助于提升整个系统的效率和鲁棒性。

在一种可能的实现方式中，所述网络设备为动态主机配置协议服务器(dynamichost configuration protocol server，DHCP server，即DHCP服务器)或动态主机配置协议中继(dynamic host configuration protocol Relay，DHCP relay，即DHCP中继)，所述第一客户端为动态主机配置协议客户端(dynamic host configuration protocolclient，DHCP client，即DHCP客户端)。

上述实现方式能够复用DHCP的组网架构，因此提高本技术方案的可用性。

在一种可能的实现方式中，所述通告报文为动态主机配置协议(dynamic hostconfiguration protocol，DHCP)报文，所述DHCP报文包括重传选项，所述重传选项包括所述第一时长。

通过扩展DHCP中的选项来携带上线请求报文的发送时间间隔，实现复杂度较小，因此提高了可用性。

在一种可能的实现方式中，所述DHCP报文还包括DHCP消息类型字段，所述DHCP消息类型字段用于标识DHCP报文为通告报文。

通过新增一种新类型的DHCP消息作为通告报文，降低对DHCP已有通信流程的影响，实现复杂度较小，因此提高了可用性。

在一种可能的实现方式中，所述网络设备确定第一时长之前，所述方法还包括：所述网络设备接收所述第一客户端发送的第一上线请求报文，所述第一上线请求报文包含有所述第一客户端的源地址。

在一种可能的实现方式中，所述网络设备确定第一时长包括：所述网络设备根据所述第一客户端的源地址确定所述第一客户端的级别；所述网络设备根据所述第一客户端的级别确定第一时长，所述第一客户端的级别越高所述第一时长越小。

由于网络设备在指定重传间隔时考虑了客户端的级别，为不同级别的客户端指定不同大小的第一时长，使得处理上线请求报文的系统资源向高级别的用户倾斜分配，从而提升高级别用户的用户体验。

在一种可能的实现方式中，所述网络设备确定第一时长包括：所述网络设备根据所述第一客户端的上线信息确定第一时长，所述上线信息表示所述第一客户端是否为首次上线的客户端。

由于网络设备在指定重传间隔时考虑了客户端是否首次上线，为非首次上线的客户端指定更长的发送时间间隔，从而抑制非首次上线的客户端重传上线请求的行为，避免非首次上线的客户端频繁重传上线请求加剧系统负担而触发雪崩效应。

在一种可能的实现方式中，所述网络设备确定第一时长包括：所述网络设备根据能力数据确定第一时长，所述能力数据表示所述网络设备的报文处理能力，所述报文处理能力越弱，所述第一时长越大。

由于网络设备在指定重传间隔时考虑了自身处理能力，在自身处理能力弱的情况下指定更长的重传间隔，从而避免网络设备的处理能力不足导致重传的上线请求仍无法被处理，进而避免客户端需要再次重传上线请求导致触发雪崩效应、浪费客户端的处理开销、浪费传输上线请求的网络开销等问题；同时，在自身处理能力强的情况下指定更短的重传间隔，从而避免网络设备的处理资源闲置，并有助用户的上线请求得到更及时地处理，有助于用户更快上线。

在一种可能的实现方式中，所述能力数据包括所述网络设备的中央处理器(central processing unit，CPU)利用率，所述网络设备根据能力数据确定第一时长，包括：所述网络设备根据所述CPU利用率确定第一时长，所述CPU利用率越高，所述第一时长越大。

由于网络设备在指定重传间隔时考虑了CPU利用率，一方面，在CPU利用率高的情况下指定更长的重传间隔，从而避免CPU的算力不足导致上线请求无法被处理；另一方面，在CPU利用率低的情况下指定更短的重传间隔，从而避免CPU的算力闲置。

在一种可能的实现方式中，所述能力数据包括所述网络设备已缓存的报文数量，所述网络设备根据能力数据确定第一时长，包括：所述网络设备根据所述已缓存的报文数量确定所述第一时长，所述已缓存的报文数量越多，所述第一时长越大。

由于网络设备在指定重传间隔时考虑了已缓存的报文数量，在已缓存的报文数量多的情况下指定更长的重传间隔，从而避免网络侧已经积压大量没有处理的报文而客户端仍继续重传上线请求而触发雪崩效应。

在一种可能的实现方式中，所述网络设备确定第一时长，包括：若所述网络设备的负载大于或等于阈值，所述网络设备对上线请求报文的发送时间间隔增加第二时长，得到所述第一时长。

由于网络设备在过载的情况下增大重传时长，使得网络设备负载大时重传时长变大，有助于重传时长随着网络侧的负载情况而自适应地调整，提高了灵活性。

在一种可能的实现方式中，所述网络设备确定第一时长，包括：若所述网络设备的负载小于阈值，所述网络设备对上线请求报文的发送时间间隔减小第三时长，得到所述第一时长。

由于网络设备在未过载的情况下减少重传时长，使得网络设备负载小时重传时长变小，有助于重传时长随着网络侧的负载情况而自适应地调整，提高了灵活性。

在一种可能的实现方式中，所述网络设备向第一客户端发送所述通告报文之后，所述方法还包括：所述网络设备在黑名单中创建第一表项，所述第一表项包括所述第一客户端的源地址，所述第一表项的存活时长与所述第一时长相同，所述存活时长为所述第一表项的创建时间点至删除时间点之间的时长；所述网络设备接收第三上线请求报文，所述第三上线请求报文包含有所述第一客户端的源地址；响应于所述第三上线请求报文命中所述第一表项，所述网络设备丢弃所述第三上线请求报文。

通过上述方式，如果客户端没有按照服务器指定的时间间隔重传上线请求报文，上线请求报文传输到网络侧时，会由于黑名单中表项的存活时长与通告报文携带的时长相同，黑名单中客户端对应的表项还处于存活状态，使得上线请求报文命中黑名单从而被网络侧丢弃，因此达到抑制上线请求报文的目的，避免客户端频繁重传上线请求对系统的影响，有助于保证系统处理能力。

在一种可能的实现方式中，所述方法还包括：所述网络设备在黑名单中创建第二表项，所述第二表项包括第二客户端的源地址；所述网络设备接收第二上线请求报文，所述第二上线请求报文包含有所述第二客户端的源地址；响应于所述第二上线请求报文命中所述第二表项，所述网络设备丢弃所述第二上线请求报文。

通过上述方式，由于上线请求报文命中黑名单后被丢弃，因此节省了处理上线请求报文带来的CPU开销以及缓存上线请求报文占用的存储空间，从而减少上线请求报文对网络侧产生的影响，有助于保证网络侧的处理能力。

第二方面，提供了一种控制客户端上线的方法，以该方法从网络设备一侧的角度描述，网络设备在黑名单中创建第二表项，所述第二表项包括第二客户端的源地址；所述网络设备接收第二上线请求报文，所述第二上线请求报文包含有所述第二客户端的源地址；响应于所述第二上线请求报文命中所述第二表项，所述网络设备丢弃所述第二上线请求报文。

在一种可能的实现方式中，所述第二表项的存活时长与第一时长相同，所述存活时长为所述第二表项的创建时间点至删除时间点之间的时长，所述网络设备在黑名单中创建第二表项之前，所述方法还包括：

网络设备确定第一时长；

所述网络设备生成通告报文，所述通告报文携带所述第一时长；

所述网络设备向第二客户端发送所述通告报文，所述通告报文用于指示所述第二客户端将上线请求报文的发送时间间隔调整为所述第一时长。

在一种可能的实现方式中，所述网络设备确定第一时长包括：

所述网络设备根据所述第二客户端的源地址确定所述第二客户端的级别；

所述网络设备根据所述第二客户端的级别确定第一时长，所述第二客户端的级别越高所述第一时长越小。

所述网络设备根据所述第二客户端的上线信息确定第一时长，所述上线信息表示所述第二客户端是否为首次上线的客户端。

所述网络设备根据能力数据确定第一时长，所述能力数据表示所述网络设备的报文处理能力，所述报文处理能力越弱，所述第一时长越大。

在一种可能的实现方式中，所述能力数据包括所述网络设备的CPU利用率，所述网络设备根据能力数据确定第一时长，包括：

所述网络设备根据所述CPU利用率确定第一时长，所述CPU利用率越高，所述第一时长越大。

在一种可能的实现方式中，所述能力数据包括所述网络设备已缓存的报文数量，所述网络设备根据能力数据确定第一时长，包括：

所述网络设备根据所述已缓存的报文数量确定所述第一时长，所述已缓存的报文数量越多，所述第一时长越大。

在一种可能的实现方式中，所述网络设备确定第一时长，包括：

若所述网络设备的负载大于或等于阈值，所述网络设备对上线请求报文的发送时间间隔增加第二时长，得到所述第一时长。

若所述网络设备的负载小于阈值，所述网络设备对上线请求报文的发送时间间隔减小第三时长，得到所述第一时长。

在一种可能的实现方式中，所述网络设备为DHCP server或DHCP relay，所述第二客户端为DHCP client。

在一种可能的实现方式中，所述通告报文为DHCP报文，所述DHCP报文包括重传选项，所述重传选项包括所述第一时长。

第三方面，提供了一种客户端上线的方法，以该方法从客户端一侧的角度描述，客户端接收通告报文，所述通告报文用于指示所述客户端将上线请求报文的发送时间间隔调整为所述第一时长；所述客户端获得所述通告报文携带的所述第一时长；所述客户端每隔所述第一时长，发送上线请求报文。

在一种可能的实现方式中，所述客户端每隔所述第一时长，发送上线请求报文包括：所述客户端每隔所述第一时长，向网络设备发送上线请求报文，所述通告报文是由所述网络设备发送的。

第四方面，提供了一种网络设备，用于执行上述第一方面或第一方面任一种可能实现方式或第二方面或第二方面任一种可能实现方式中的方法。具体地，该网络设备包括用于执行上述第一方面或第一方面任一种可能实现方式或第二方面或第二方面任一种可能实现方式中方法的单元。

在一些实施例中，网络设备中的单元通过软件实现，网络设备中的单元是程序模块。在另一些实施例中，网络设备中的单元通过硬件或固件实现。第四方面提供的网络设备的具体细节可参见上述第一方面或第一方面任一种可能实现方式或第二方面或第二方面任一种可能实现方式，此处不再赘述。

第五方面，提供了一种客户端，用于执行上述第三方面或第三方面任一种可能实现方式中的方法。具体地，该客户端包括用于执行上述第三方面或第三方面任一种可能实现方式中方法的单元。

在一些实施例中，客户端中的单元通过软件实现，客户端中的单元是程序模块。在另一些实施例中，客户端中的单元通过硬件或固件实现。第五方面提供的客户端的具体细节可参见上述第三方面或第三方面任一种可能实现方式，此处不再赘述。

第六方面，提供了一种网络设备，该网络设备包括处理器和通信接口，该处理器用于执行指令，使得该网络设备执行上述第一方面或第一方面任一种可能实现方式或第二方面或第二方面任一种可能实现方式所提供的控制客户端上线的方法，所述通信接口用于接收或发送报文。第六方面提供的网络设备的具体细节可参见上述第一方面或第一方面任一种可能实现方式或第二方面或第二方面任一种可能实现方式，此处不再赘述。

第七方面，提供一种网络设备，所述网络设备包括：主控板和接口板，进一步，还可以包括交换网板。所述网络设备用于执行第一方面或第一方面任一种可能实现方式或第二方面或第二方面任一种可能实现方式中的方法。具体地，所述网络设备包括用于执行第一方面或第一方面任一种可能实现方式或第二方面或第二方面任一种可能实现方式中的方法的单元。

第八方面，提供了一种客户端，该客户端包括处理器和通信接口，该处理器用于执行指令，使得该客户端执行上述第三方面或第三方面任一种可能实现方式所提供的方法，所述通信接口用于接收或发送报文。第八方面提供的客户端的具体细节可参见上述第三方面或第三方面任一种可能实现方式，此处不再赘述。

第九方面，提供了一种计算机可读存储介质，该存储介质中存储有至少一条指令，当所述至少一条指令在网络设备上执行时，使得所述网络设备执行上述第一方面或第一方面任一种可能实现方式或第二方面或第二方面任一种可能实现方式所提供的方法。

第十方面，提供了一种计算机可读存储介质，该存储介质中存储有至少一条指令，当所述至少一条指令在客户端上执行时，使得所述客户端执行上述第三方面或第三方面任一种可能实现方式所提供的方法。

第十一方面，提供了一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。网络设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该网络设备执行上述第一方面或第一方面任一种可能实现方式或第二方面或第二方面任一种可能实现方式所提供的方法。

第十二方面，提供了一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。客户端的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该客户端执行上述第三方面或第三方面任一种可能实现方式所提供的方法。

第十三方面，提供了一种芯片，当该芯片在网络设备上运行时，使得网络设备执行上述第一方面或第一方面任一种可能实现方式或第二方面或第二方面任一种可能实现方式所提供的方法。

第十四方面，提供了一种芯片，当该芯片在客户端上运行时，使得客户端执行上述第三方面或第三方面任一种可能实现方式所提供的方法。

第十五方面，提供了一种网络系统，该网络系统包括网络设备以及客户端，该网络设备用于执行上述第一方面或第一方面任一种可能实现方式或第二方面或第二方面任一种可能实现方式所述的方法，该客户端用于执行上述第三方面或第三方面任一种可能实现方式所述的方法。

附图说明

图1是本申请实施例提供的一种DHCP组网架构的示意图；

图2是本申请实施例提供的一种DHCP组网架构的示意图；

图3是本申请实施例提供的一种DHCP客户端上线过程的流程图；

图4是本申请实施例提供的一种DHCP客户端上线场景的示意图；

图5是本申请实施例提供的一种DHCP服务器或DHCP中继的逻辑功能架构的示意图；

图6是本申请实施例提供的一种DHCPv4场景下通告报文的格式示意图；

图7是本申请实施例提供的一种DHCPv4场景下通告报文的格式示意图；

图8是本申请实施例提供的一种控制客户端上线的方法的流程图；

图9是本申请实施例提供的一种控制客户端上线的方法的流程图；

图10是本申请实施例提供的一种控制客户端上线的方法的流程图；

图11是本申请实施例提供的一种网络设备的结构示意图；

图12是本申请实施例提供的一种客户端的结构示意图；

图13是本申请实施例提供的一种网络设备的结构示意图；

图14是本申请实施例提供的一种客户端的结构示意图；

图15是本申请实施例提供的一种网络系统的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

由于本申请实施例涉及动态主机配置协议(dynamic host configurationprotocol，DHCP)的应用，为了便于理解，下面对DHCP中的术语相关概念以及组网场景进行介绍。

DHCP是一种为主机分配参数的协议。DHCP采用客户端/服务器(client/server，C/S)的架构。客户端通过DHCP协议向服务器端请求网络参数，服务器做出响应，给客户端分配网络地址及其他参数。DHCP中的客户端也称动态主机配置协议客户端(dynamic hostconfiguration protocol client，DHCP client，即DHCP客户端)。DHCP中的服务器也称动态主机配置协议服务器(dynamic host configuration protocol server，DHCP server，即DHCP服务器)。例如，参见附图1，附图1是对DHCP客户端+DHCP服务器的组网架构的举例说明。在附图1所示的组网场景下，DHCP客户端直接通过向DHCP服务器请求服务。此外可选地，DHCP的架构还包括动态主机配置协议中继(dynamic host configuration protocolRelay，DHCP relay，即DHCP中继)。又如，参见附图2，附图2是对DHCP客户端+DHCP服务器+DHCP中继的组网架构的举例说明。在附图2所示的组网场景下，DHCP客户端通过DHCP中继向DHCP服务器请求服务。

DHCP包括两类场景，一类场景是互联网协议第四版(internet protocol version4，IPv4)动态主机配置协议(dynamic host configuration protocol for IPv4，DHCPv4)，另一类场景是互联网协议第六版(internet protocol version 6，IPv6)动态主机配置协议(dynamic host configuration protocol for IPv6，DHCPv6)。

DHCP客户端的上线过程通常通过四步交互实现。参见附图3，四步交互包括发现阶段、提供阶段、选择阶段以及确认阶段这四个阶段对应的四大步骤。

四步交互中第(1)步为发现阶段。在DHCPv4场景下，DHCP客户端在第(1)步会主动发送DHCP发现(DHCP discover)报文。其中，DHCP discover报文为DHCP客户端首次登录网络时进行DHCP交互过程发送的第一个报文，用来寻找DHCP服务器。在DHCPv6场景下DHCP客户端在第(1)步会主动发送DHCP征求(DHCP solicit，用来定位服务器)报文。DHCP solicit报文用于定位可以为DHCP客户端提供服务的DHCPv6服务器。以DHCPv4场景为例，在发现阶段中，首次接入网络的DHCP客户端以广播方式发送DHCP discover报文(目的IP地址为255.255.255.255)给同一网段内的所有设备(包括DHCP服务器或中继)，以便学习到DHCP服务器的IP地址。此外，在存在DHCP中继的场景下，DHCP中继接收到DHCP客户端广播发送的DHCP discover报文后，通过路由转发将DHCP discover报文单播发送到DHCP服务器或下一跳中继。

四步交互中第(2)步为提供阶段。在DHCPv4场景下，DHCP服务器在第(2)步会回应DHCP提供(DHCP offer)报文。在DHCPv6场景下DHCP服务器在第(2)步会回应DHCP宣告(DHCPadvertise)报文。以DHCPv4场景为例，在提供阶段中，与DHCP客户端位于同一网段的DHCP服务器都会接收到DHCP discover报文，DHCP服务器选择跟接收DHCP discover报文接口的IP地址处于同一网段的地址池，并且从中选择一个可用的IP地址，然后通过DHCP offer报文发送给DHCP客户端。此外，在存在DHCP中继的场景下，DHCP中继接收到DHCP discover报文后，DHCP offer报文单播发送给DHCP客户端。

四步交互中第(3)步为选择阶段。在DHCPv4场景或者DHCPv6场景下，DHCP客户端在第(3)步会发送DHCP请求(DHCP request)报文。

四步交互中第(4)步为确认阶段。在DHCPv4场景下，DHCP服务器在第(4)步会回应DHCP确认响应(DHCP acknowledgment，DHCP ACK)报文或DHCP拒绝响应(DHCP negativeacknowledgment，DHCP NAK)报文。在DHCPv6场景下DHCP服务器在第(4)步会回应DHCP回应(DHCP reply)报文。

下面介绍本申请实施例提供的系统架构。

参见附图4，本申请实施例提供了一种系统架构100。系统架构100是对DHCP组网架构的举例说明。系统架构100包括多个DHCP客户端101、DHCP中继102以及DHCP服务器103。

多个DHCP客户端101通过网络分别与DHCP中继102相连。DHCP中继102通过网络与DHCP服务器103相连。

DHCP中继102以及DHCP服务器103为系统架构100中的控制节点。DHCP客户端101用于发送DHCP请求报文(如上线请求报文)。DHCP中继102用于转发DHCP服务器103和DHCP客户端101之间的DHCP报文。DHCP服务器103用于从地址池中选择IP地址分配至DHCP客户端101，还可以为DHCP客户端101提供其他网络参数。

下面结合系统架构100，对本实施例的应用场景进行介绍。

在系统架构100所示的场景中，DHCP客户端通过DHCP中继接入DHCP服务器上线。或者，DHCP客户端不经过DHCP中继直接接入DHCP服务器上线。每个DHCP客户端上线通常会执行附图3所示的四步交互流程。从DHCP客户端主动发送DHCP discover报文或DHCP solicit报文开始，到DHCP客户端收到DHCP ACK报文、DHCP NAK报文或者DHCP reply报文结束。

DHCP上线过程中重传机制是一个重要技术。具体地，在DHCP上线过程中，需要在指定时间内完成四步交互中两对协议报文的交互，任何一个报文的延时处理或丢弃会导致本次上线失败。然而，受网络带宽、链路情况、DHCP服务器或DHCP中继处理能力影响，DHCP客户端难以通过一次拨号(如一次四步交互)就完成上线。根据协议规定，DHCP客户端发送请求报文后，如果DHCP客户端没有及时接收到应答报文，会触发重传机制。具体地，DHCP客户端会重新启动上线过程，从协议交互的首个报文开始重传报文。目前，DHCP客户端会按照固定间隔重传或者按照指数衰减间隔重传报文。

此外，大量用户并发上线是DHCP上线过程中典型的场景。具体地，系统中经常具有多个DHCP客户端，而多个DHCP客户端上线往往具有时间趋同性。例如，企业专线用户上线往往集中在上班时间，而家庭带宽用户上线往往集中在周末时间。当大量用户并发上线时，会在瞬间产生大量DHCP报文。

在以上介绍的场景中，如何避免雪崩效应是亟待解决的问题。具体地，大量DHCP报文经过网络到达DHCP中继或DHCP服务器时，如果超过DHCP中继或DHCP服务器的瞬时处理能力，报文会被DHCP中继或DHCP服务器延时处理或被丢弃。对于DHCP客户端而言，由于报文被延迟处理或丢弃，报文交互无法及时完成，DHCP客户端会尝试进行重传。重传的报文传输至系统后，会进一步加剧系统(例如DHCP服务器和DHCP中继)的负载。具体地，如果系统采取的策略是对所有报文都进行缓存，那么重传的上线请求报文会增加系统的存储开销以及用于存贮这部分报文的中央处理器(central processing unit，CPU)开销。而且，系统的处理能力是确定的，处理报文量的增多，必然延长了报文的平均处理时间。由于客户端对于报文的及时到达有要求，因此会出现即使报文处理也不能满足客户端要求，依然触发客户端重传报文的情况。如果系统采取的策略是丢弃超过处理能力的报文，如果丢弃的动作由CPU层面执行，依然会占用系统对应开销。如果丢弃的动作由底层执行，一般是基于端口层面丢弃，无法基于设备级进行处理，带来的最终结果仍然是协议报文的持续增加。由于重传的报文数量会持续增加，加剧了系统负担，并导致已上线用户的续租行为也无法被系统及时处理，使得更多用户加入到上线过程，整个网络中报文发送数量大量增长，造成系统发生雪崩效应。

经过分析发现，造成雪崩效应的原因是重传机制是依赖于客户端独立实现，而DHCP中继或DHCP服务器缺乏对于DHCP客户端的主动干预，DHCP中继或DHCP服务器只能被动响应报文并进行处理。这种方式容易由于设备(服务器或者中继)处理能力不足造成客户端持续重传，会进一步加剧系统负担。特别的，系统中往往具有大量的DHCP客户端，每个DHCP客户端作为个体独立上线，个体行为的大量重复，会造成整个系统超过负载能力，导致在报文汇聚节点(DHCP中继或DHCP服务器)形成瓶颈，触发雪崩效应，导致系统故障。特别地，如果某些客户端设置重传周期较短，或者不同客户端上线质量要求不同，那么客户端的无控制重传，对于客户上线的影响性会更为突出。

而本申请的一些实施例中，由系统的网络侧(DHCP中继或者DHCP服务器)根据自身处理能力，参考DHCP客户端的等级以及上线信息，计算合适重传间隔并通过通告报文发送给DHCP客户端，使得网络侧从被动处理变更为主动控制DHCP客户端上线请求报文的发送行为，由于客户端上线请求报文的发送行为受到网络侧的控制和调度，提升整个系统的效率，避免雪崩效应的发生，从而降低了系统故障的概率，增强了系统的鲁棒性和可靠性。

以上系统架构100侧重描述整体的网络架构，以下对系统架构100中DHCP服务器或DHCP中继的逻辑功能架构进行描述。

请参考附图5，本实施例提供了另一种系统架构200。系统架构200是对系统架构100中DHCP服务器或DHCP中继的逻辑功能架构的举例说明。

系统架构200包括的各个功能模块是对DHCP服务器或DHCP中继中功能模块的举例说明。具体地，系统架构200包括报文收发模块201、系统监控模块202、用户信息管理模块203、重传管理模块204、黑名单管理模块205。

报文收发模块201用于接收协议报文(如上线请求报文)，生成用户信息，并统计报文处理状态(如已缓存的报文数量)，将报文处理状态提供给重传管理模块204。同时，报文收发模块201201接收重传管理模块204计算出的重传间隔(如第一时长)和客户端信息，构造并发送报文(如通告报文)。

系统监控模块202用于监控系统CPU的状态(如CPU利用率)，并将CPU的状态提供给重传管理模块204。

用户信息管理模块203用于根据协议报文交互过程，生成上线信息，上线信息包括客户端的MAC地址、客户端是否首次上线等信息。

重传管理模块204用于根据系统监控模块202以及用户信息管理模块203分别提供的信息，计算重传间隔，将重传间隔通知给报文收发模块201和黑名单管理模块205。

黑名单管理模块205用于下发黑名单，以便报文收发模块201使用黑名单。同时，黑名单管理模块205用于根据存活时长对黑名单进行老化处理。

下面对本实施例提供的报文格式进行介绍。

本实施例提供了一种通告报文，通告报文用于通告重传间隔(即上线请求报文的发送时间间隔)。例如，如果网络侧确定客户端每隔第一时长发送上线请求报文是合适的，则网络侧将第一时长携带在通告报文中，将包含第一时长的通告报文传递给客户端。通告报文能指示客户端将上线请求报文的发送时间间隔调整为所述第一时长，从而控制客户端重传上线请求报文的实现方式。

在一些实施例中，通告报文为DHCP报文。在一些实施例中，通告报文称为DHCPRETRANS报文(DHCP重传时间报文)，DHCP RETRANS报文用于指示客户端重传实现。作为通告报文的DHCP报文包括重传选项(retransmission option，也称ReTranstime option)。重传选项包含了上线请求报文的发送时间间隔(例如下述实施例中的第一时长)。重传选项采用TLV编码方式，重传选项包括类型(type)字段、长度(length)字段以及值(value)字段。类型字段包括重传选项的选项号，该选项号用于标识重传选项携带了上线请求报文的发送时间间隔。长度字段包括重传选项中值字段的长度。值字段包括上线请求报文的发送时间间隔(例如下述实施例中的第一时长)。

在一些实施例中，作为通告报文的DHCP报文还包括DHCP消息类型字段，所述DHCP消息类型字段用于标识DHCP报文为携带上线请求报文的发送时间间隔的通告报文。在一些实施例中，作为通告报文的DHCP报文为DHCP应答报文。

通过新增一种DHCP协议报文作为通告报文，使用这种新增的DHCP协议报文指明上线请求报文的发送时间间隔，便于DHCP服务器或DHCP中继利用这种新增的DHCP协议报文控制DHCP客户端在重传时按照多长的时间间隔发送上线请求报文，这种扩展DHCP协议报文的方式能够复用DHCP的组网架构，并与DHCP已有的通信流程兼容，因此降低了实现复杂度。

本实施例包含DHCPv4场景和DHCPv6场景。在不同的场景下，通告报文的具体格式有所区别。下面通过场景一和场景二分别对通告报文的格式举例说明。

场景一、DHCPv4场景下通告报文的格式。

DHCPv4场景下通告报文为DHCPv4报文。例如，通告报文为一种新增的DHCPv4应答报文。例如，通告报文用于对DHCP discover报文进行应答。示例性地，参考附图6，附图6是对DHCPv4场景下通告报文的格式的举例说明。

附图6中每个字段括号内的数字表示字段的长度，字段的长度的单位是字节。例如，硬件类型(hardware type，htype)字段标注了“(1)”，表示htype字段的长度是1字节。具体，附图6中每个字段的含义如下所示。

报文类型(OP，op code)字段用于表示报文的类型。OP字段的长度是1字节。OP字段的取值为1或2。

当OP字段取值为1时，表示DHCP报文的类型是客户端请求报文。当OP字段取值为2时，表示DHCP报文的类型是服务器应答报文。本实施例中，通告报文中OP字段的取值例如为2。

htype字段表示硬件类型。htype字段的长度是1字节。不同的硬件类型下htype字段取值不同，本实施例中，通告报文中htype字段的取值例如为1，表示硬件类型是以太网(ethernet)。

硬件长度(hardware length，hlen)字段表示硬件地址的长度。hlen字段的长度是1字节。对于以太网，hlen字段的取值为6。本实施例中，通告报文中hlen字段的取值例如为6。

跳数(hops)字段表示当前的DHCP报文经过的DHCP中继的数目。本实施例中，通告报文中hops字段的长度是1字节。hops字段由客户端或服务器设置为0，每经过一个DHCP中继时，hops字段加1。hops字段的作用是限制DHCP报文所经过的DHCP中继数目。服务器和客户端之间的DHCP中继数目不能超过16个，也就是hops值不能大于16，否则DHCP报文将被丢弃。本实施例中，通告报文中hops字段的取值例如为0。

事务ID(transaction ID，xid)字段表示DHCP客户端选取的随机数，使DHCP服务器的回复与DHCP客户端的报文相关联。xid字段的长度为4字节。本实施例中，通告报文中xid字段的取值例如为0xb7722fdb，0xb7722fdb是一个随机数。

秒数(second，secs)字段表示客户端从开始获取地址或地址续租更新后所用的时间，该时间的单位是秒。secs字段的长度为2字节。本实施例中，通告报文中secs字段的取值为0。

至少一个标志(flags)字段。flags字段的长度为2字节。例如，flags字段的最高位有意义，flags字段的最高位可称为单播响应标志位或者广播响应标志位(broadcastflag)。

flags字段中最高位之外其余的15位例如均为保留的标志字段(reservedflags)，flags字段中最高位之外其余的15位均被置为0。例如，flags字段的最高位为0时，表示客户端请求服务器以单播形式发送响应报文。flags字段的最高位为1时，表示客户端请求服务器以广播形式发送响应报文。例如，通告报文中flags字段的取值为0x0000。0x0000包括两个部分，第一个部分是最高位，取值是0，表示单播(unicast)。第二个部分是最高位剩余的15位，取值是000 0000 0000 0000，可简化表示为0x0000。

客户端IP地址(client IP address，ciaddr)字段表示客户端的互联网协议(internet protocol，IP)地址。ciaddr字段的长度为4字节。ciaddr字段例如携带服务器分配给客户端的IP地址或者客户端已有的IP地址。例如，通告报文中ciaddr字段的取值为0.0.0.0。其中，0.0.0.0是临时的IP地址，由于客户端在初始化状态时没有IP地址，在采用DHCP方式的系统启动时允许主机利用IP地址0.0.0.0进行临时的通信，0.0.0.0不是有效的目的地址。

你的客户端的IP地址(Your(client)IP address，yiaddr)字段表示服务器分配给客户端的IP地址。当服务器进行DHCP响应时，将分配给客户端的IP地址填入此字段。例如，通告报文中yiaddr字段的取值为0.0.0.0。yiaddr字段的长度例如为4字节。

下一个服务器IP地址(next server IP address，siaddr)字段表示DHCP客户端获得启动配置信息的服务器的IP地址。例如，通告报文中siaddr字段的取值为0.0.0.0。siaddr字段的长度例如为4字节。

中继代理IP地址(relay agent IP address，giaddr)字段表示第一个DHCP中继的IP地址。当客户端发出DHCP请求时，如果服务器和客户端不在同一个网段，那么第一个DHCP中继在将DHCP请求报文转发给DHCP服务器时，会把自己的IP地址填入giaddr字段，DHCP服务器会根据giaddr字段来判断出客户端所在的网段地址，从而选择合适的地址池，为客户端分配该网段的IP地址。服务器还会根据此地址将响应报文发送给此DHCP中继，再由DHCP中继将此报文转发给客户端。例如，通告报文中giaddr字段的取值为10.147.160.20。giaddr字段的长度例如为4字节。

客户端硬件地址(client hardware address，chaddr)字段表示客户端的媒体访问控制(media access control，MAC)地址。chaddr字段的长度例如为16字节。chaddr字段与前面的htype字段和hlen字段保持一致。当客户端发出DHCP请求时，将自己的硬件地址填入chaddr字段。对于以太网，当硬件类型字段和硬件长度字段分别为“1”和“6”时，chaddr字段填入6字节的以太网MAC地址。例如，以太网MAC地址是RealtekS_86:2e:ca，则通告报文中chaddr字段的取值为00:e0:4c:86:2e:ca。00:e0:4c:86:2e:ca包括6字节的MAC地址以及10字节的填充字段(client hardware address padding)，填充字段的取值例如为00000000000000000000。

服务器名(server host name，sname)字段表示客户端获取配置信息的服务器名字。sname字段例如为64字节。

文件名(file(file name))表示客户端需要获取的启动配置文件名。file name字段例如为128字节。file name字段的取值例如为pxebdd.0。pxebdd.0是一个以0结尾的字符串。

至少一个选项(options)字段的长度是可变的。options字段包括option53字段、重传选项以及结束选项。option53字段用于设置DHCP消息类型(DHCP message type)。option53字段的选项号为53。option53字段的长度字段的取值例如为1。option53字段的值字段包括DHCP消息类型。

本实施例中，通告报文中的option53字段包括新增的消息类型值，该新增的消息类型值用于标识DHCP报文为通告报文，该新增的消息类型值与目前DHCPv4所定义的八种类型报文拥有的消息类型均不同。例如，通告报文中的option53字段包括9，9是对新增的DHCPv4消息类型值的举例说明。当客户端接收到DHCP报文时，查看option53字段中DHCP消息类型，如果发现DHCP消息类型的值为9，则客户端确定DHCP报文是携带发送时间间隔的通告报文。

重传选项例如称为DHCP重传时间(DHCP Retrans time)选项。DHCP Retrans time选项是DHCPv4报文中新增的选项。例如，重传选项为option 222。重传选项包括选项类型字段、选项长度字段以及DHCP重传时间值(DHCP Retrans time value)字段。其中，选项类型字段包括重传选项的选项类型(重传选项的选项号)。例如，重传选项为option 222时，选项类型字段包括222。选项长度字段包括重传选项的长度，例如，选项长度字段的取值为4。DHCP重传时间值字段是DHCPv4报文中新增的字段。DHCP重传时间值字段包括发送时间间隔的具体值(例如下述实施例中的第一时长)。

结束选项例如为选项255(option 255)，option 255的选项号为255。结束选项表示选项字段已经结束。

场景二、DHCPv6场景下通告报文的格式。

DHCPv6场景下通告报文为DHCPv6报文。例如，通告报文为一种新增的DHCPv6应答报文。例如，通告报文用于对DHCP solicit报文进行应答。示例性地，参考附图7，附图7是对DHCPv6场景下通告报文的格式的举例说明。

消息类型(message type，msg-type)字段表示报文的类型。本实施例中，通告报文中的msg-type字段包括新增的消息类型值，该新增的消息类型值用于标识DHCP报文为通告报文，该新增的消息类型值与目前DHCPv6所定义的十三种类型报文拥有的消息类型均不同。例如，通告报文中的msg-type字段的取值为14，14是对新增的DHCPv6消息类型值的举例说明。

事务ID(transaction ID)字段表示DHCPv6交互ID(也称事务ID)，用来标识一个来回的DHCPv6报文交互。例如solicit/advertise报文为一个交互。request/reply报文为另外一个交互，两者有不同的事务ID。事务ID字段的长度例如是3字节。本实施例中，通告报文中事务ID字段的取值例如为0xaa075c，0xaa075c是一个随机数。

此外，DHCPv6场景下作为通告报文的DHCPv6报文包括客户端ID(clientidentifier)选项。例如，客户端ID选项具体包括以下几个字段。

客户端ID选项包括选项类型(option type)字段。选项类型字段用于标识选项的类型为客户端ID选项。客户端ID选项中选项类型字段的取值例如为1。

客户端ID选项包括选项长度(option length)字段。客户端ID选项中选项长度字段的取值例如为10。

客户端ID选项包括值(value)字段。客户端ID选项中值字段的取值例如为00010203040506070809。

客户端ID选项包括DHCP唯一标识符(DHCP unique identifier，DUID)字段。DUID字段携带DUID。DUID是一台DHCPv6设备(包括客户端、服务器和中继)的唯一标识。在DHCPv6报文交互过程中，DHCPv6客户端、服务器和中继通过在报文中添加DUID来标识自己。例如，通告报文中DUID字段的取值为00010203040506070809。

客户端ID选项包括DUID类型(DUID type)字段。DUID类型字段表示DUID的类型。例如，通告报文中DUID类型字段的取值为1，1表示DUID的类型为基于链路层地址的DUID(DUIDbased on link-layer address，DUID-LL)。

客户端ID选项包括硬件类型(hardware type)字段。硬件类型字段表示硬件类型。例如，硬件类型字段包括6，6表示硬件类型是IEEE 802。

客户端ID选项包括时间(time)字段。例如，时间字段包括317290726。

客户端ID选项包括链路层地址(link layer address)字段。链路层地址字段用于指示设备的桥MAC地址。例如，链路层地址字段包括00:e0:4C:77:4e:5a。

此外，DHCPv6场景下作为通告报文的DHCPv6报文包括ID关联(identityassociation，IA)选项。每个DHCPv6客户端关联一个IA，而每个IA中可以包含多个地址以及相关的时间信息；并且根据地址类型的不同生成对应的IA。例如，通告报文包括IA_NA(identity association for non-temporary address，IA中包含的地址是非临时地址)选项。IA_NA选项的选项类型字段的取值例如为3。IA_NA选项的选项长度字段的取值例如为12。IA_NA选项的值字段的取值例如为1a00acf30000000000000000。IA_NA选项的值字段具体包括IAID字段、T1字段以及T2字段。IAID字段的取值例如为1a00acff。T1字段的取值例如为0。T2字段的取值例如为0。

重传选项例如称为Retrans time选项。Retrans time选项是DHCPv6报文中新增的选项。例如，重传选项为option 39。重传选项包括选项类型字段、选项长度字段以及DHCP重传时间值(DHCP Retrans time value)字段。其中，选项类型字段包括重传选项的选项类型(重传选项的选项号)。例如，重传选项为option 39时，选项类型字段包括39。选项长度字段包括重传选项的长度，例如，选项长度字段的取值为4。DHCP重传时间值字段包括发送时间间隔的具体值(例如下述实施例中的第一时长)。DHCP重传时间值字段是DHCPv6报文中新增的字段。

以上介绍了本实施例的组网架构、逻辑功能架构以及报文格式，以下通过方法300至方法500，示例性介绍基于上文介绍的内容控制客户端上线的方法流程。

参见附图8，附图8是本申请实施例提供的一种控制客户端上线的方法300的流程图。

在一些实施例中，所述方法300由如附图4所示系统架构中的DHCP客户端101、DHCP中继102以及DHCP服务器103交互执行。例如，所述方法300中的网络设备为DHCP服务器103或DHCP中继102，所述第一客户端或第二客户端为DHCP客户端101。

在一些实施例中，所述方法300中的网络设备具有附图5所示的架构200。所述方法300中的网络设备负责执行的各个步骤分别由架构200中的各个模块执行。

所述方法300中交互的通告报文可参考附图6、附图7以及对应的文字介绍。

示例性地，方法300包括S310至S380。

S310、第一客户端向网络设备发送第一上线请求报文。

第一上线请求用于请求为第一客户端分配IP地址或者其他网络参数。第一上线请求报文例如为DHCP报文。应用在DHCPv4的场景，第一上线请求报文例如为DHCPv4报文。例如，第一上线请求报文为DHCP discover报文。应用在DHCPv6的场景，第一上线请求报文例如为DHCPv6报文。例如，第一上线请求报文为DHCP solicit报文。

第一上线请求报文包含有第一客户端的源地址。第一客户端的源地址例如为第一客户端的源MAC地址。例如，第一上线请求报文包括MAC帧头，MAC帧头包括源MAC地址字段，源MAC地址字段包括MAC地址，第一客户端的源地址为源MAC地址字段中的MAC地址。

S320、网络设备接收第一客户端发送的第一上线请求报文。

S330、网络设备确定第一时长。

第一时长是对重传间隔的举例说明。第一时长为网络设备为第一客户端确定的上线请求报文的发送时间间隔。重传间隔是指客户端相邻两次发送上线请求报文的时间点之间的时间间隔。换句话说，重传间隔是下一次发送上线请求报文的时间点与上一次发送请求报文的时间点之间的时间差。例如，客户端在时刻M发送了上线请求报文，在时刻M之后的时刻N，客户端重新发送上线请求报文，则重传间隔为时刻N与时刻M之间的时间差。

第一时长如何确定包括多种实现方式，下面通过方式一至方式三举例说明。

方式一、网络侧根据客户端的级别确定第一时长。

例如，网络设备从第一上线请求报文获得第一客户端的源地址，网络设备根据第一客户端的源地址确定第一客户端的级别；网络设备根据第一客户端的级别确定第一时长。

在一些实施例中，客户端的级别通过客户端的服务质量(quality of service，QoS)信息表示。例如，网络设备根据第一客户端的源地址，在用户表中查询得到第一客户端的Qos信息。其中，Qos信息表示第一客户端的级别。例如，Qos信息包括第一客户端的上线时间或第一客户端的上线拥塞属性。

在一些实施例中，网络设备为级别更高的客户端确定更短的重传间隔。其中，客户端的级别例如根据客户端登录的用户账号的级别表示。客户端的级别包括而不限于贵宾(very important person，VIP)用户、普通用户、专线用户、特定用户等。VIP用户或者专线用户的优先级例如高于普通用户的优先级，网络设备为VIP用户或者专线用户确定的重传间隔短于为普通用户确定的重传间隔。例如，如果第一客户端的级别是VIP用户或者专线用户，则网络设备将第一预设取值作为第一时长；如果第一客户端的级别是普通用户，则网络设备将第二预设取值作为第一时长，其中，第一预设取值小于第二预设取值。又如，如果第一客户端的级别是普通用户，网络设备对上线请求报文的发送时间间隔增加第二时长，得到第一时长；如果第一客户端的级别是VIP用户或者专线用户，网络设备对上线请求报文的发送时间间隔减小第三时长，得到第一时长。

通过方式一达到的效果包括：由于网络设备在指定重传间隔时考虑了客户端的级别，为不同级别的客户端指定不同大小的第一时长，为高级别客户端(例如VIP用户或者专线用户的客户端)指定了更短的发送时间间隔，使得高级别用户能够优先重传上线请求，高级别用户的上线请求被网络侧优先接收和处理，高级别用户的上线请求被优先响应。因此，处理上线请求报文的系统资源被优先分配给高级别用户，那么由于系统资源向高级别的用户倾斜分配，从而提升高级别用户的用户体验。

方式二、网络侧根据客户端是否首次上线确定第一时长。

例如，网络设备从第一上线请求报文获得第一客户端的源地址，网络设备根据第一客户端的源地址获取第一客户端的上线信息；网络设备根据第一客户端的上线信息确定第一时长。

其中，上线信息表示第一客户端是否为首次上线的客户端。例如，上线信息包括一个标识，如果第一客户端为首次上线的客户端，该标识置为取值A，如果第一客户端为非首次上线的客户端，该标识置为取值B。例如，上线信息为正在上线的用户信息。正在上线的用户例如包括第一客户端。在一些实施例中，上线信息还包括第一客户端的身份标识(identity，ID)、用户的地址信息等。

在一些实施例中，网络设备为非首次上线的客户端增大重传时长。例如，网络设备获得第一客户端的上线信息之后，根据第一客户端的上线信息判断第一客户端是首次上线的客户端还是非首次上线的客户端。如果第一客户端是首次上线的客户端，则网络设备将第一预设取值作为第一时长；如果第一客户端是非首次上线的客户端，则网络设备将第二预设取值作为第一时长，其中，第一预设取值小于第二预设取值。又如，如果第一客户端是非首次上线的客户端，网络设备对上线请求报文的发送时间间隔增加第二时长，得到第一时长；如果第一客户端是首次上线的客户端，网络设备对上线请求报文的发送时间间隔减小第三时长，得到第一时长。

通过方式二达到的效果包括：由于网络设备在指定重传间隔时考虑了客户端是否首次上线，为非首次上线的客户端指定更长的发送时间间隔，从而抑制非首次上线的客户端重传上线请求的行为，避免非首次上线的客户端频繁重传上线请求加剧系统负担而触发雪崩效应。

方式三、网络侧根据自身处理能力来确定第一时长。

例如，网络设备获得能力数据，网络设备根据能力数据确定第一时长。

能力数据表示网络设备的报文处理能力，例如，能力数据包括网络设备的CPU利用率、网络设备已缓存的报文数量中的至少一项。其中，CPU利用率指示了网络设备CPU的状态。CPU利用率越高，表示网络设备的CPU状态越繁忙；CPU利用率越低，表示网络设备的CPU状态越空闲。网络设备已缓存的报文数量表示网络设备当前积压了多少还没有处理的报文。在一些实施例中，网络设备待处理的报文是通过缓存队列缓存的，网络设备已缓存的报文数量为网络设备缓存队列中积压报文数。在一些实施例中，能力数据还包括单位时间内处理报文的数量与报文处理能力的最大值之间的比值。单位时间内处理报文的数量越多，表示网络设备处理报文的能力越强。可选地，单位时间内处理报文的数量为单位时间内处理DHCP报文(如DHCP discover报文或DHCP solicit报文)的数量。

在一些实施例中，能力数据表示的报文处理能力越弱，第一时长越大。例如，如果网络设备的报文处理能力高于阈值，则网络设备将第一预设取值作为第一时长；如果网络设备的报文处理能力低于或等于阈值，则网络设备将第二预设取值作为第一时长，其中，第一预设取值小于第二预设取值。又如，如果网络设备的报文处理能力低于或等于阈值，网络设备对上线请求报文的发送时间间隔增加第二时长，得到第一时长；如果网络设备的报文处理能力高于阈值，网络设备对上线请求报文的发送时间间隔减小第三时长，得到第一时长。

通过方式三达到的效果包括：由于网络设备在指定重传间隔时考虑了自身处理能力，在自身处理能力弱的情况下指定更长的重传间隔，从而避免网络设备的处理能力不足导致重传的上线请求仍无法被处理，进而避免客户端需要再次重传上线请求导致触发雪崩效应、浪费客户端的处理开销、浪费传输上线请求的网络开销等问题；同时，在自身处理能力强的情况下指定更短的重传间隔，从而避免网络设备的处理资源闲置，并有助用户的上线请求得到更及时地处理，有助于用户更快上线。

在一些实施例中，方式三具体包括方式(3-A)至方式(3-B)中的至少一项。

方式(3-A)网络设备根据CPU利用率确定第一时长，CPU利用率越高，第一时长越大。

方式(3-B)网络设备根据已缓存的报文数量确定第一时长，已缓存的报文数量越多，第一时长越大。

在一些实施例中，上述方式一至方式三任意结合，即，网络设备执行上述方式一至方式三中两种或两种以上的方式。以方式一、方式二和方式三结合为例，例如，网络设备根据第一客户端的级别、第一客户端的上线信息以及网络设备的能力数据确定第一时长。例如，网络设备根据第一客户端的级别、第一客户端的上线信息以及网络设备的能力数据确定调节系数和抑制系数，根据调节系数和抑制系数确定第一时长。

调节系数为调节第一时长的取值的系数。调节系数越大，第一时长越大。调节系数根据网络设备的能力数据确定，例如根据网络设备的CPU状态和已缓存的报文数量确定。例如，CPU利用率越高，调节系数越大。缓存队列中已缓存的报文数量越大，调节系数越大。

抑制系数为抑制第一时长的取值的系数。抑制系数越小，第一时长越小。抑制系数根据客户端的上线信息以及客户端的级别确定。例如，非首次上线的客户端对应的抑制系数大于首次上线的客户端对应的抑制系数。高级别的客户端(如用户服务质量要求高的客户端)对应的抑制系数小于低级别的客户端对应的抑制系数。

例如，网络设备根据调节系数和抑制系数，基于下述公式(1)确定第一时长。

重传间隔＝(当前系统对DHCP报文最大处理能力/当前接收报文数量)*调节系数*抑制系数；公式(1)。

网络设备在基于公式(1)确定第一时长时，公式(1)中当前系统对DHCP报文最大处理能力例如为网络设备在确定第一时长时对DHCP报文的报文处理能力的最大值。公式(1)中当前接收报文数量例如为网络设备在确定第一时长时接收的DHCP报文的数量，或者为网络设备已接收的各种协议的报文数量总和。公式(1)中重传间隔例如为第一时长。

在一些实施例中，网络设备基于自身是否过载控制客户端的重传间隔。具体地，网络设备确定网络设备的负载，对网络设备的负载与阈值进行比较，若网络设备的负载大于或等于阈值，则确定自身处于过载状态；若网络设备的负载小于阈值，则确定自身处于未过载状态；其中，网络设备的负载例如通过网络设备的能力数据表示。阈值例如为能力数据阈值。例如，阈值具体包括三种，一种阈值是CPU利用率阈值，另一种阈值是报文数量阈值，另一种阈值是单位时间内处理报文的数量与报文处理能力的最大值之间的比值阈值。CPU利用率阈值、报文数量阈值以及比值阈值例如为预先设定的阈值。如果CPU利用率大于CPU利用率阈值，或者已缓存的报文数量大于报文数量阈值，或者比值大于比值阈值，则网络设备确定自身处于过载状态。

网络设备在过载的情况下具体如何控制重传间隔包括多种方式，以下通过方式A至方式C进行介绍。

方式A、若网络设备的负载大于或等于阈值，网络设备对上线请求报文的发送时间间隔增加第二时长，得到第一时长。

其中，第二时长为发送时间间隔的增量。例如，第二时长为调节发送时间间隔时使用的步长。第二时长例如为预先设定的时长，又如为通过算法计算出的时长。例如，网络设备原本将时长m指定为上线请求报文的发送时间间隔，在过载的情况下，网络设备在时长m的基础上增加时长n(第二时长)，则重传时长(第一时长)为时长m(上线请求报文的发送时间间隔)+时长n(第二时长)，使得重传时长变大。

通过方式A，由于网络设备在过载的情况下增大重传时长，使得网络设备负载大时重传时长变大，有助于重传时长随着网络侧的负载情况而自适应地调整，提高了灵活性。

方式B、若网络设备的负载小于阈值，网络设备对上线请求报文的发送时间间隔减小第三时长，得到第一时长。

其中，第三时长为发送时间间隔的减少量。例如，第三时长为调节发送时间间隔时使用的步长。第三时长例如为预先设定的时长，又如为通过算法计算出的时长。例如，网络设备原本将时长m指定为上线请求报文的发送时间间隔，在过载的情况下，网络设备在时长m的基础上减少时长n(第三时长)，则重传时长(第一时长)为时长m(上线请求报文的发送时间间隔)-时长n(第三时长)，使得重传时长变小。

通过方式B，由于网络设备在未过载的情况下减少重传时长，使得网络设备负载小时重传时长变小，有助于重传时长随着网络侧的负载情况而自适应地调整，提高了灵活性。

方式C、若网络设备的负载大于或等于阈值，网络设备执行确定第一时长、生成以及发送通告报文的步骤。若网络设备的负载小于阈值，网络设备对上线请求报文返回应答报文。换句话说，将网络设备自身是否过载作为通告重传间隔的触发条件，当网络设备自身过载时，执行通告重传间隔的步骤；当网络设备自身没有过载时，例如按照原有的上线流程处理。

通过以上列举的方式一至方式三、方式A至方式C等确定第一时长的方式可见，相对于时下客户端/服务器模式下由服务器被动处理上线请求报文的方式而言，本实施例提供了中心控制思路，由网络侧(如DHCP中继或DHCP服务器)收集自身处理能力、客户端上线信息、客户端的级别、自身负载这几类信息，参考这几类信息为客户端确定重传间隔，从而主动介入重传间隔的确定过程，有助于重传间隔与网络侧报文处理能力的强弱、客户端是首次上线还是非首次上线、客户端的级别高低、网络侧的负载高低等情况匹配，因此重传间隔会更加精确，因此网络侧通过控制客户端按照这种重传间隔来发送上线请求报文，有助于提升系统整体性能。

S340、网络设备生成通告报文，通告报文携带第一时长。

网络设备确定第一时长后，会将第一时长写入至通告报文中，使得通告报文携带第一时长。其中，通告报文用于指示第一客户端将上线请求报文的发送时间间隔调整为第一时长。例如，网络设备将第一时长写入至通告报文中的重传选项，使得重传选项包括第一时长。参见附图6和附图7，附图6和附图7均是对网络设备生成的通告报文的举例说明。

S350、网络设备向第一客户端发送通告报文，通告报文用于指示客户端将上线请求报文的发送时间间隔调整为第一时长。

网络设备由于执行上述确定第一时长、生成通告报文和发送通告报文的步骤，将客户端(如DHCP客户端)上线行为由个体独立转变为网络侧(如DHCP中继或DHCP服务器)的集中控制，达到在网络侧主动控制客户端(如DHCP客户端)重传的功能，使整个系统具备中心调优能力，保证系统上线效率，进而提高了系统性能。并且，为系统可能面对的攻击行为做出主动防御，防止因为大量报文处理导致雪崩效应的发生。

在一些实施例中，网络设备通过向第一客户端发送通告报文，从而应答第一上线请求报文。换句话说，将针对第一上线请求报文返回响应报文的步骤替代为向第一客户端发送通告报文。例如，在DHCPv4场景下，DHCP服务器或DHCP中继(网络设备)接收到DHCPdiscover报文(第一上线请求报文)时，DHCP服务器或DHCP中继向DHCP客户端发送通告报文来应答DHCP discover报文，而不再返回DHCP offer报文。例如，在DHCPv6场景下，DHCP服务器或DHCP中继(网络设备)接收到DHCP solicit报文(第一上线请求报文)时，DHCP服务器或DHCP中继向DHCP客户端发送通告报文来应答DHCP solicit报文，而不再返回DHCPadvertise报文。

S360、第一客户端接收通告报文。

S370、第一客户端获得通告报文携带的第一时长。

S380、第一客户端每隔第一时长，发送上线请求报文。

第一客户端会将上线请求报文的发送时间间隔调整为所述第一时长，从而按照通告报文的指示调整重传间隔。例如，第一客户端在第一上线请求报文的发送时间点的基础上增加第一时长，将得到的时间点作为下一次发送上线请求报文的时间点。当时间到达该时间点时，第一客户端再次发送上线请求报文。

在一些实施例中，第一客户端每隔第一时长重新生成上线请求报文，并发送重新生成的上线请求报文。在另一些实施例中，第一客户端生成的上线请求报文后，缓存上线请求报文，在超时未接收到服务器的应答报文时，第一客户端每隔第一时长，发送缓存的上线请求报文。

在一些实施例中，上线请求报文的接收端与通告报文的发送端是相同的。例如，所述客户端每隔所述第一时长，向网络设备发送上线请求报文，所述通告报文是由所述网络设备发送的。

在一些实施例中，在上线请求报文被丢弃的情况下，第一客户端根据自身能力选择是否响应通告报文。如果第一客户端支持响应通告报文，则第一客户端按照通告报文指示的第一时长重传上线请求报文。如果第一客户端不支持响应通告报文，则第一客户端按照自身重传能力重传上线请求报文。

示例性地，参见附图9，本实施例中DHCP客户端一侧的方法流程如附图9所示，DHCP客户端执行的方法400包括以下S401至S404。

S401、DHCP客户端判断是否需要重传。如果需要重传，则DHCP客户端执行以下S402。

S402、DHCP客户端判断是否接收到了通告报文。如果接收到了通告报文，则DHCP客户端执行以下S403。如果没有接收到了通告报文，则DHCP客户端自行确定重传间隔。

S403、DHCP客户端根据通告报文，调整重传间隔，例如将上线请求报文的发送时间间隔调整为所述第一时长。

S404、当重传时间到达时，DHCP客户端进行重传处理，即重新发送上线请求报文。

网络设备再次接收到上线请求报文时执行的动作包括多种情况。在一些实施例中，网络设备再次接收到上线请求报文时，确定负载小于阈值，网络设备已经来得及处理上线请求报文，则网络设备对上线请求报文进行处理，向第一客户端返回上线请求报文对应的应答报文。又如，网络设备再次接收到上线请求报文时，如果网络设备的报文处理能力发生变化或者由于其他因素，网络设备重新确定第一时长，将重新确定的第一时长携带在通告报文中，向第一客户端发送所述通告报文，从而更新第一客户端的重传间隔。

在一些实施例中，网络设备通过建立黑名单来抑制接收特定客户端的上线请求。以针对第二客户端应用黑名单为例，第二客户端与第一客户端例如是两个不同的客户端，又如第二客户端与第一客户端是同一个客户端。具体地，所述网络设备根据第二客户端的源地址，在黑名单中创建第二表项。第二客户端生成并向网络设备发送第二上线请求报文。所述网络设备接收第二上线请求报文；网络设备根据第二上线请求报文的源地址，查询黑名单。响应于所述第二上线请求报文命中黑名单中的第二表项，所述网络设备丢弃所述第二上线请求报文。此外，如果第二上线请求报文未命中黑名单中的任一表项，网络设备例如向第二客户端发送携带重传间隔的通告报文，又如所述网络设备处理所述第二上线请求报文。

黑名单(blacklist)为用于拒绝通过上线请求的用户表。黑名单包括至少一个表项，每个表项用于指示拒绝通过上线请求的一个用户。

在一些实施例中，黑名单用于记录已通告重传间隔的客户端。例如，DHCP服务器向DHCP客户端A发送了携带重传间隔的通告报文，则DHCP服务器将DHCP客户端A加入黑名单。在一些实施例中，黑名单保存了客户端的源地址(例如源MAC地址)。例如，黑名单中每个表项保存一个客户端的源地址(例如源MAC地址)。例如，所述第二表项包括第二客户端的源地址(例如第二客户端的MAC地址)。

在一些实施例中，上述黑名单的建立步骤由网络设备的控制面执行，控制面建立黑名单后，将黑名单下发给转发面。转发面存储控制面创建的黑名单。当转发面接收到上线请求报文后，转发面根据上线请求报文的源地址查询黑名单；转发面发现上线请求报文命中黑名单时，转发面丢弃上线请求报文；转发面发现上线请求报文没有命中黑名单时，转发面将上线请求报文上送给控制面。其中，转发面例如为网络设备的物理接口卡，控制面例如为网络设备的CPU。

在一些实施例中，黑名单还包括存活时长。存活时长也称存活周期或者活跃时间。存活时长为黑名单中表项的创建时间点至删除时间点之间的时长。例如，当在黑名单中创建一个表项时，会启动计时器，如果记录的时长超过该表项的存活时长而未收到客户端发来的报文，则将该表项作为老化的表项，从黑名单中删除该表项。如果记录的时长未超过存活时长，则该表项保持有效。在另一些实施例中，存活时长保存在与黑名单关联的其他表项中。

在一些实施例中，每个客户端分别对应于一个存活时长，不同客户端对应的存活时长相同或不同。例如，黑名单中的表项A记录了客户端A的源MAC地址，表项A的存活时长为指定客户端A重传上线请求报文的发送时间间隔。

在一些实施例中，黑名单的存活时长与重传间隔是相同的。例如，第二表项的存活时长与向第二客户端发送的通告报文中携带的时长相同。在一些实施例中，第二表项包括两个条目，一个条目包括第二客户端对应的发送时间间隔，另一个条目包括第二客户端的源MAC地址。

在一些实施例中，第二上线请求报文包含有所述第二客户端的源地址，网络设备从第二上线请求报文获得第二客户端的源地址，根据第二客户端的源地址查询黑名单。例如，第二客户端的源地址为第二客户端发送报文使用的源MAC地址，网络设备对第二上线请求报文的源MAC地址与黑名单中每个表项保存的MAC地址进行匹配，确定第二上线请求报文的源MAC地址与第二表项中的MAC地址相同，则确定第二上线请求报文命中第二表项。

在一些实施例中，针对通告重传间隔的客户端(如第一客户端)使用黑名单的流程包括下述步骤一至步骤三。

步骤一、所述网络设备在黑名单中创建第一表项，所述第一表项包括所述第一客户端的源地址，所述第一表项的存活时长与所述第一时长相同，所述存活时长为所述第一表项的创建时间点至删除时间点之间的时长。

步骤二、所述网络设备接收第三上线请求报文。

其中，所述第三上线请求报文包含有所述第一客户端的源地址。例如，所述第三上线请求报文的MAC帧头中的源MAC字段包含有所述第一客户端的源MAC地址。

步骤三、响应于所述第三上线请求报文命中所述第一表项，所述网络设备丢弃所述第三上线请求报文。

由于黑名单中表项的存活时长与通告报文携带的时长相同，即使客户端没有按照服务器指定的重传时间重传上线请求报文，比如在还没有到达服务器指定的重传时间时，客户端就重新发送了上线请求报文，那么由于客户端发送上线请求报文的发送时间间隔小于存活时长，服务器再次接收到上线请求报文时，客户端对应的表项还处于存活状态，因此服务器会由于客户端在黑名单中，丢弃客户端的上线请求报文，从而达到抑制上线请求报文的目的。而如果客户端按照服务器指定的重传时间重传上线请求报文，那么由于客户端发送上线请求报文的发送时间间隔大于或等于存活时长，服务器再次接收到上线请求报文时，客户端对应的表项由于老化被清除，使得客户端的上线请求报文得以处理。

在一些实施例中，网络设备生成通告报文后，将通告报文保存在转发硬件中。网络设备在丢弃上线请求报文(如第二上线请求报文或第三上线请求报文)的同时，向客户端(如第一客户端或第二客户端)发送预先保存的重传报文。

示例性地，参见附图10，本实施例中DHCP服务器或者DHCP中继一侧的方法流程如附图10所示，DHCP服务器或者DHCP中继执行的方法500包括以下S501至S510。

S501、DHCP服务器或者DHCP中继接收DHCP客户端发送的上线请求报文。

S502、DHCP服务器或者DHCP中继获取黑名单，判断DHCP客户端是否在黑名单中。如果DHCP客户端在黑名单中，则DHCP服务器或者DHCP中继执行S503。如果DHCP客户端不在黑名单中，则DHCP服务器或者DHCP中继执行S504且执行S505。

S503、DHCP服务器或者DHCP中继丢弃上线请求报文。

S504、DHCP服务器或者DHCP中继为DHCP客户端记录上线信息。

S505、DHCP服务器或者DHCP中继判断系统是否超载。如果系统没有超载，例如DHCP服务器或者DHCP中继的负载低于阈值，则DHCP服务器或者DHCP中继执行S506。如果系统超载，例如DHCP服务器或者DHCP中继的负载高于或等于阈值，则DHCP服务器或者DHCP中继执行S507。

S506、DHCP服务器或者DHCP中继按照原有上线流程处理。

S507、DHCP服务器或者DHCP中继根据监控到的处理能力(如能力数据)以及从DHCP客户端上线信息库中获取的上线信息、DHCP客户端的级别计算DHCP客户端的重传时间。

S508、DHCP服务器或者DHCP中继发送通告报文。

S509、DHCP服务器或者DHCP中继针对特定DHCP客户端(如发送上线请求报文的DHCP客户端)下发黑名单。

S510、DHCP服务器或者DHCP中继针对特定DHCP客户端(如发送上线请求报文的DHCP客户端)将黑名单以及存活时长保存至黑名单中。

通过上述方法，在实现DHCP中继/DHCP服务器控制DHCP客户端重传时间的基础上，由于DHCP中继/Serve向DHCP客户端发送通告报文后，还针对DHCP客户端下发黑名单，黑名单存活时长与重传间隔相同，使得即使DHCP客户端未遵照重传间隔发送上线请求报文时，依然能够保证系统处理能力。

本实施例提供了一种支持网络侧控制客户端重传上线请求报文的方法，通过由网络设备为客户端确定上线请求报文的发送时间间隔，将发送时间间隔通过通告报文传递给客户端，有助于客户端按照网络侧指定的时间间隔重传上线请求报文。相对于由客户端自行确定发送时间间隔以重传上线请求报文的机制而言，网络侧的角色从被动地响应客户端的上线请求发送行为演变至主动地控制客户端的上线请求发送行为，显著加强了网络侧对重传机制的干预，因此一定程度上解决目前客户端上线方法的局限性，有助于避免客户端按照自行确定的发送时间间隔进行无控制重传而触发的雪崩效应等问题，有助于提升整个系统的效率和鲁棒性。

以下介绍网络设备600。该网络设备600具有上述方法实施例中网络设备的任意功能。

附图11示出了网络设备600的一种可能的结构示意图。附图11所示的网络设备600例如实现方法300中网络设备的功能，或者，网络设备600实现方法500中DHCP服务器或DHCP中继的功能。

请参考附图11，网络设备600包括确定单元601、生成单元602和发送单元603。网络设备600中的各个单元全部或部分地通过软件、硬件、固件或者其任意组合来实现。网络设备600中的各个单元用于执行上述方法300中网络设备或DHCP服务器或DHCP中继的相应功能。例如，确定单元601用于支持网络设备600执行S330、S507或S505中的至少一项。生成单元602用于支持网络设备600执行S340。发送单元603用于支持网络设备600执行350或S508。

本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可选地有另外的划分方式。

在一些实施例中，网络设备600中各个单元集成在一个处理单元中。例如，网络设备600中各个单元集成在同一个芯片上。该芯片包括处理电路和与该处理电路内部连接通信的输入接口以及输出接口。确定单元601通过芯片中的处理电路实现。生成单元602通过芯片中的输入接口实现。发送单元603通过芯片中的输出接口实现。例如，该芯片通过一个或多个现场可编程门阵列(英文全称：field－programmable gate array，英文简称：FPGA)、可编程逻辑器件(英文全称：programmable logic device，英文简称：PLD)、控制器、状态机、门逻辑、分立硬件部件、任何其它适合的电路、或者能够执行本申请通篇所描述的各种功能的电路的任意组合实现。

在另一些实施例中，网络设备600各个单元单独物理存在。在另一些实施例中，网络设备600一部分单元单独物理存在，另一部分单元集成在一个单元中。例如，在一些实施例中，确定单元601和生成单元602是同一个单元。在另一些实施例中，确定单元601和生成单元602是不同的单元。在一些实施例中，不同单元的集成采用硬件的形式实现，即，不同单元对应于同一个硬件。又如，不同单元的集成采用软件单元的形式实现。

在网络设备600中通过硬件实现的情况下，网络设备600中确定单元601、生成单元602例如通过处理器实现。例如，确定单元601通过附图13所示网络设备800的主控板810实现，比如确定单元601通过中央处理器811实现。又如，生成单元602通过附图13所示网络设备800的接口板830实现，比如生成单元602通过网络处理器832实现。网络设备600中发送单元603例如通过附图13所示网络设备800的接口板830实现。例如，发送单元603通过物理接口卡833实现。

在网络设备600中通过软件实现的情况下，网络设备600中各个单元例如为处理器(如附图13所示网络设备800的中央处理器811)读取存储器(如附图13所示网络设备800的存储器812)中存储的程序代码后生成的软件。例如，网络设备600为虚拟化设备。虚拟化设备包括而不限于虚拟机、容器、Pod中的至少一种。在一些实施例中，网络设备600以虚拟机的形式，部署在硬件设备(如物理服务器)上。例如，基于通用的物理服务器结合网络功能虚拟化(Network Functions Virtualization，NFV)技术来实现网络设备600。采用虚拟机的方式实现时，网络设备600例如为虚拟主机、虚拟路由器或虚拟交换机。本领域技术人员通过阅读本申请即可结合NFV技术在通用物理服务器上虚拟出网络设备600。在另一些实施例中，网络设备600以容器(例如docker容器)的形式，部署在硬件设备上。例如，网络设备600执行上述方法实施例的流程被封装在镜像文件中，硬件设备通过运行镜像文件来创建网络设备600。在另一些实施例中，网络设备600以Pod的形式，部署在硬件设备上。Pod包括多个容器，每个容器用于实现网络设备600中的一个或多个单元。

以下介绍客户端700。该客户端700具有上述方法实施例中客户端的任意功能。

附图12示出了客户端700的一种可能的结构示意图。附图12所示的客户端700例如实现方法300或方法400中客户端(如DHCP客户端)的功能。

请参考附图12，客户端700包括接收单元701、获得单元702和发送单元703。客户端700中的各个单元全部或部分地通过软件、硬件、固件或者其任意组合来实现。客户端700中的各个单元用于执行上述方法300或方法400中客户端(如DHCP客户端)的相应功能。具体地，接收单元701用于支持客户端700执行S360或S402。获得单元702用于支持客户端700执行S370。发送单元703用于支持客户端700执行S380或S404。

在一些实施例中，客户端700中各个单元集成在一个处理单元中。例如，客户端700中各个单元集成在同一个芯片上。该芯片包括处理电路和与该处理电路内部连接通信的输入接口以及输出接口。获得单元702通过芯片中的处理电路实现。接收单元701通过芯片中的输入接口实现。发送单元703通过芯片中的输出接口实现。例如，该芯片通过一个或多个现场可编程门阵列(英文全称：field－programmable gate array，英文简称：FPGA)、可编程逻辑器件(英文全称：programmable logic device，英文简称：PLD)、控制器、状态机、门逻辑、分立硬件部件、任何其它适合的电路、或者能够执行本申请通篇所描述的各种功能的电路的任意组合实现。

在另一些实施例中，客户端700各个单元单独物理存在。在另一些实施例中，客户端700一部分单元单独物理存在，另一部分单元集成在一个单元中。例如，在一些实施例中，获得单元702和发送单元703是同一个单元。在另一些实施例中，获得单元702和发送单元703是不同的单元。在一些实施例中，不同单元的集成采用硬件的形式实现，即，不同单元对应于同一个硬件。又如，不同单元的集成采用软件单元的形式实现。

在客户端700中通过硬件实现的情况下，客户端700中获得单元702例如通过处理器实现。例如，获得单元702例如通过附图14所示客户端900的处理器901实现。客户端700中接收单元701、发送单元703例如通过通信接口实现。例如，接收单元701、发送单元703附图14所示客户端900的通信接口904实现。

在客户端700中通过软件实现的情况下，客户端700中各个单元例如为处理器(如附图14所示客户端900的处理器901)读取存储器(如附图14所示客户端900的存储器903)中存储的程序代码后生成的软件。例如，客户端700为虚拟化设备。虚拟化设备包括而不限于虚拟机、容器、Pod中的至少一种。在一些实施例中，客户端700以虚拟机的形式，部署在硬件设备(如物理服务器)上。例如，基于通用的物理服务器结合NFV技术来实现客户端700。采用虚拟机的方式实现时，客户端700例如为虚拟主机、虚拟路由器或虚拟交换机。本领域技术人员通过阅读本申请即可结合NFV技术在通用物理服务器上虚拟出客户端700。在另一些实施例中，客户端700以容器(例如docker容器)的形式，部署在硬件设备上。例如，客户端700执行上述方法实施例的流程被封装在镜像文件中，硬件设备通过运行镜像文件来创建客户端700。在另一些实施例中，客户端700以Pod的形式，部署在硬件设备上。Pod包括多个容器，每个容器用于实现客户端700中的一个或多个单元。

以上通过网络设备600，从逻辑功能的角度介绍了如何实现网络设备(如DHCP服务器或DHCP中继)。以下通过网络设备800，从硬件的角度介绍如何实现网络设备(如DHCP服务器或DHCP中继)。附图13所示的网络设备800是对网络设备(如DHCP服务器或DHCP中继)的硬件结构的举例说明。

网络设备800对应于上述方法300或方法500中的网络设备(如DHCP服务器或DHCP中继)，网络设备800中的各硬件、模块和上述其他操作和/或功能分别为了实现方法实施例中网络设备(如DHCP服务器或DHCP中继)所实施的各种步骤和方法，关于网络设备800如何对控制客户端上线的详细流程，具体细节可参见上述方法300或方法500，为了简洁，在此不再赘述。其中，方法300或方法500的各步骤通过网络设备800处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块例如位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤，为避免重复，这里不再详细描述。

参见附图13，附图13示出了本申请一个示例性实施例提供的网络设备的结构示意图，网络设备800例如配置为方法300或方法500中的网络设备(如DHCP服务器或DHCP中继)。网络设备800包括：主控板810和接口板830。

主控板也称为主处理单元(main processing unit，MPU)或路由处理卡(routeprocessor card)，主控板810用于对网络设备800中各个组件的控制和管理，包括路由计算、设备管理、设备维护、协议处理功能。主控板810包括：中央处理器811和存储器812。

接口板830也称为线路接口单元卡(line processing unit，LPU)、线卡(linecard)或业务板。接口板830用于提供各种业务接口并实现数据包的转发。业务接口包括而不限于以太网接口、POS(Packet over SONET/SDH)接口等，以太网接口例如是灵活以太网业务接口(Flexible ethernet clients，FlexE clients)。接口板830包括：中央处理器831、网络处理器832、转发表项存储器834和物理接口卡(physical interface card，PIC)833。

接口板830上的中央处理器831用于对接口板830进行控制管理并与主控板810上的中央处理器811进行通信。

网络处理器832用于实现报文的转发处理。网络处理器832的形态例如是转发芯片。具体而言，网络处理器832用于基于转发表项存储器834保存的转发表转发接收到的报文，如果报文的目的地址为网络设备800的地址，则将该报文上送至CPU(如中央处理器811)处理；如果报文的目的地址不是网络设备800的地址，则根据该目的地址从转发表中查找到该目的地址对应的下一跳和出接口，将该报文转发到该目的地址对应的出接口。其中，上行报文的处理包括：报文入接口的处理，转发表查找；下行报文的处理：转发表查找等等。

物理接口卡833用于实现物理层的对接功能，原始的流量由此进入接口板830，以及处理后的报文从该物理接口卡833发出。物理接口卡833也称为子卡，可安装在接口板830上，负责将光电信号转换为报文并对报文进行合法性检查后转发给网络处理器832处理。在一些实施例中，中央处理器也可执行网络处理器832的功能，比如基于通用CPU实现软件转发，从而物理接口卡833中不需要网络处理器832。

可选地，网络设备800包括多个接口板，例如网络设备800还包括接口板840，接口板840包括：中央处理器841、网络处理器842、转发表项存储器844和物理接口卡843。

可选地，网络设备800还包括交换网板820。交换网板820也例如称为交换网板单元(switch fabric unit，SFU)。在网络设备有多个接口板830的情况下，交换网板820用于完成各接口板之间的数据交换。例如，接口板830和接口板840之间例如通过交换网板820通信。

主控板810和接口板830耦合。例如。主控板810、接口板830和接口板840，以及交换网板820之间通过系统总线与系统背板相连实现互通。在一种可能的实现方式中，主控板810和接口板830之间建立进程间通信协议(inter-process communication，IPC)通道，主控板810和接口板830之间通过IPC通道进行通信。

在逻辑上，网络设备800包括控制面和转发面，控制面包括主控板810和中央处理器831，转发面包括执行转发的各个组件，比如转发表项存储器834、物理接口卡833和网络处理器832。控制面执行路由器、生成转发表、处理信令和协议报文、配置与维护设备的状态等功能，控制面将生成的转发表下发给转发面，在转发面，网络处理器832基于控制面下发的转发表对物理接口卡833收到的报文查表转发。控制面下发的转发表例如保存在转发表项存储器834中。在有些实施例中，控制面和转发面例如完全分离，不在同一设备上。

应理解，本申请实施例中接口板840上的操作与接口板830的操作一致，为了简洁，不再赘述。应理解，本实施例的网络设备800可对应于上述各个方法实施例中的网络设备(如DHCP服务器或DHCP中继)，该网络设备800中的主控板810、接口板830和/或840例如实现上述各个方法实施例中的网络设备(如DHCP服务器或DHCP中继)所具有的功能和/或所实施的各种步骤，为了简洁，在此不再赘述。

值得说明的是，主控板可能有一块或多块，有多块的时候例如包括主用主控板和备用主控板。接口板可能有一块或多块，网络设备的数据处理能力越强，提供的接口板越多。接口板上的物理接口卡也可以有一块或多块。交换网板可能没有，也可能有一块或多块，有多块的时候可以共同实现负荷分担冗余备份。在集中式转发架构下，网络设备可以不需要交换网板，接口板承担整个系统的业务数据的处理功能。在分布式转发架构下，网络设备可以有至少一块交换网板，通过交换网板实现多块接口板之间的数据交换，提供大容量的数据交换和处理能力。所以，分布式架构的网络设备的数据接入和处理能力要大于集中式架构的设备。可选地，网络设备的形态也可以是只有一块板卡，即没有交换网板，接口板和主控板的功能集成在该一块板卡上，此时接口板上的中央处理器和主控板上的中央处理器在该一块板卡上可以合并为一个中央处理器，执行两者叠加后的功能，这种形态设备的数据交换和处理能力较低(例如，低端交换机或路由器等网络设备)。具体采用哪种架构，取决于具体的组网部署场景，此处不做任何限定。

以上通过客户端700，从逻辑功能的角度介绍了如何实现客户端(如DHCP客户端)。以下通过客户端900从硬件的角度介绍如何实现客户端(如DHCP客户端)。附图14所示的客户端900是对客户端(如DHCP客户端)的硬件结构的举例说明。

客户端900对应于上述方法300或方法400中的客户端(如DHCP客户端)，客户端900中的各硬件、模块和上述其他操作和/或功能分别为了实现方法实施例中客户端(如DHCP客户端)所实施的各种步骤和方法，关于客户端900如何上线的详细流程，具体细节可参见上述方法300或方法400，为了简洁，在此不再赘述。其中，方法300或方法400的各步骤通过客户端900处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块例如位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤，为避免重复，这里不再详细描述。

参见附图14，附图14示出了本申请一个示例性实施例提供的客户端的结构示意图，该客户端900例如配置为方法300或方法400中的客户端(如DHCP客户端)。该客户端900可以是主机、服务器或个人计算机等。该客户端900可以由一般性的总线体系结构来实现。

客户端900包括至少一个处理器901、通信总线902、存储器903以及至少一个通信接口904。

处理器901例如是通用中央处理器(central processing unit，CPU)、网络处理器(network processer，NP)、图形处理器(Graphics Processing Unit，GPU)、神经网络处理器(neural-network processing units，NPU)、数据处理单元(Data Processing Unit，DPU)、微处理器或者一个或多个用于实现本申请方案的集成电路。例如，处理器901包括专用集成电路(application-specific integrated circuit，ASIC)，可编程逻辑器件(programmable logic device，PLD)或其组合。PLD例如是复杂可编程逻辑器件(complexprogrammable logic device，CPLD)、现场可编程逻辑门阵列(field-programmable gatearray，FPGA)、通用阵列逻辑(generic array logic，GAL)或其任意组合。

通信总线902用于在上述组件之间传送信息。通信总线902可以分为地址总线、数据总线、控制总线等。为便于表示，附图14中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器903例如是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其它类型的静态存储设备，又如是随机存取存储器(random access memory，RAM)或者可存储信息和指令的其它类型的动态存储设备，又如是电可擦可编程只读存储器(electrically erasable programmable read-only Memory，EEPROM)、只读光盘(compactdisc read-only memory，CD-ROM)或其它光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其它磁存储设备，或者是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其它介质，但不限于此。存储器903例如是独立存在，并通过通信总线902与处理器901相连接。存储器903也可以和处理器901集成在一起。

通信接口904使用任何收发器一类的装置，用于与其它设备或通信网络通信。通信接口904包括有线通信接口，还可以包括无线通信接口。其中，有线通信接口例如可以为以太网接口。以太网接口可以是光接口，电接口或其组合。无线通信接口可以为无线局域网(wireless local area networks，WLAN)接口，蜂窝网络通信接口或其组合等。

在具体实现中，作为一种实施例，处理器901可以包括一个或多个CPU，如附图14中所示的CPU0和CPU1。

在具体实现中，作为一种实施例，客户端900可以包括多个处理器，如附图14中所示的处理器901和处理器905。这些处理器中的每一个可以是一个单核处理器(single-CPU)，也可以是一个多核处理器(multi-CPU)。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(如计算机程序指令)的处理核。

在具体实现中，作为一种实施例，客户端900还可以包括输出设备和输入设备。输出设备和处理器901通信，可以以多种方式来显示信息。例如，输出设备可以是液晶显示器(liquid crystal display，LCD)、发光二级管(light emitting diode，LED)显示设备、阴极射线管(cathode ray tube，CRT)显示设备或投影仪(projector)等。输入设备和处理器901通信，可以以多种方式接收用户的输入。例如，输入设备可以是鼠标、键盘、触摸屏设备或传感设备等。

在一些实施例中，存储器903用于存储执行本申请方案的程序代码910，处理器901可以执行存储器903中存储的程序代码910。也即是，客户端900可以通过处理器901以及存储器903中的程序代码910，来实现方法实施例提供的客户端上线的方法。

本申请实施例的客户端900可对应于上述各个方法实施例中的客户端(如DHCP客户端)，并且，该客户端900中的处理器901、通信接口904等可以实现上述各个方法实施例中的客户端(如DHCP客户端)所具有的功能和/或所实施的各种步骤和方法。为了简洁，在此不再赘述。

参见附图15，本申请实施例提供了一种网络系统1000，所述系统1000包括：网络设备1001和客户端1002。可选的，网络设备1001为如附图11所示的网络设备600或附图13所示的网络设备800，客户端1002为如附图12所述的客户端700或附图14所示的客户端900。

在一些实施例中，还提供了一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。网络设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该网络设备执行上述方法实施例中网络设备一侧的方法。

在一些实施例中，还提供了一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。客户端的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该客户端执行上述方法实施例中客户端一侧的方法。

本领域普通技术人员可以意识到，结合本文中所公开的实施例中描述的各方法步骤和单元，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各实施例的步骤及组成。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域普通技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参见前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，该单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。

该作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本申请实施例方案的目的。

另外，在本申请各个实施例中的各单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件单元的形式实现。

该集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例中方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请中术语“第一”“第二”等字样用于对作用和功能基本相同的相同项或相似项进行区分，应理解，“第一”、“第二”之间不具有逻辑或时序上的依赖关系，也不对数量和执行顺序进行限定。还应理解，尽管以下描述使用术语第一、第二等来描述各种元素，但这些元素不应受术语的限制。这些术语只是用于将一元素与另一元素区别分开。例如，在不脱离各种所述示例的范围的情况下，第一客户端可以被称为第二客户端，并且类似地，第二客户端可以被称为第一客户端。第一客户端和第二客户端都可以是客户端，并且在某些情况下，可以是单独且不同的客户端。

本申请中术语“至少一个”的含义是指一个或多个，本申请中术语“多个”的含义是指两个或两个以上。本文中术语“系统”和“网络”经常可互换使用。

还应理解，术语“如果”可被解释为意指“当...时”(“when”或“upon”)或“响应于确定”或“响应于检测到”。类似地，根据上下文，短语“如果确定...”或“如果检测到[所陈述的条件或事件]”可被解释为意指“在确定...时”或“响应于确定...”或“在检测到[所陈述的条件或事件]时”或“响应于检测到[所陈述的条件或事件]”。

以上描述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机程序指令。在计算机上加载和执行该计算机程序指令时，全部或部分地产生按照本申请实施例中的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。

该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机程序指令可以从一个网站站点、计算机、服务器或数据中心通过有线或无线方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如软盘、硬盘、磁带)、光介质(例如，数字视频光盘(digital video disc，DVD)、或者半导体介质(例如固态硬盘)等。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims

1.一种控制客户端上线的方法，其特征在于，包括：

网络设备确定第一时长；

所述网络设备向第一客户端发送所述通告报文，所述通告报文用于指示所述第一客户端将上线请求报文的发送时间间隔调整为所述第一时长。

2.根据权利要求1所述的方法，其特征在于，所述网络设备为动态主机配置协议服务器DHCP server或动态主机配置协议中继DHCP relay，所述第一客户端为动态主机配置协议客户端DHCP client。

3.根据权利要求1或2所述的方法，其特征在于，所述通告报文为动态主机配置协议DHCP报文，所述DHCP报文包括重传选项，所述重传选项包括所述第一时长。

4.根据权利要求3所述的方法，其特征在于，所述DHCP报文还包括DHCP消息类型字段，所述DHCP消息类型字段用于标识DHCP报文为通告报文。

5.根据权利要求1至4任一权利要求所述的方法，其特征在于，所述网络设备确定第一时长之前，所述方法还包括：

所述网络设备接收所述第一客户端发送的第一上线请求报文，所述第一上线请求报文包含有所述第一客户端的源地址。

6.根据权利要求5所述的方法，其特征在于，所述网络设备确定第一时长包括：

所述网络设备根据所述第一客户端的源地址确定所述第一客户端的级别；

所述网络设备根据所述第一客户端的级别确定第一时长，所述第一客户端的级别越高所述第一时长越小。

7.根据权利要求5所述的方法，其特征在于，所述网络设备确定第一时长包括：

所述网络设备根据所述第一客户端的上线信息确定第一时长，所述上线信息表示所述第一客户端是否为首次上线的客户端。

8.根据权利要求1至4任一权利要求所述的方法，其特征在于，所述网络设备确定第一时长包括：

9.根据权利要求8所述的方法，其特征在于，所述能力数据包括所述网络设备的中央处理器CPU利用率，所述网络设备根据能力数据确定第一时长，包括：

10.根据权利要求8所述的方法，其特征在于，所述能力数据包括所述网络设备已缓存的报文数量，所述网络设备根据能力数据确定第一时长，包括：

11.根据权利要求1至10中任一项所述的方法，其特征在于，所述网络设备确定第一时长，包括：

12.根据权利要求1至10中任一项所述的方法，其特征在于，所述网络设备确定第一时长，包括：

13.根据权利要求1至12中任一项所述的方法，其特征在于，所述网络设备向第一客户端发送所述通告报文之后，所述方法还包括：

所述网络设备在黑名单中创建第一表项，所述第一表项包括所述第一客户端的源地址，所述第一表项的存活时长与所述第一时长相同，所述存活时长为所述第一表项的创建时间点至删除时间点之间的时长；

所述网络设备接收第三上线请求报文，所述第三上线请求报文包含有所述第一客户端的源地址；

响应于所述第三上线请求报文命中所述第一表项，所述网络设备丢弃所述第三上线请求报文。

14.根据权利要求1-12中任一项所述的方法，其特征在于，所述方法还包括：

所述网络设备在黑名单中创建第二表项，所述第二表项包括第二客户端的源地址；

所述网络设备接收第二上线请求报文，所述第二上线请求报文包含有所述第二客户端的源地址；

响应于所述第二上线请求报文命中所述第二表项，所述网络设备丢弃所述第二上线请求报文。

15.一种客户端上线的方法，其特征在于，所述方法包括：

客户端接收通告报文，所述通告报文用于指示所述客户端将上线请求报文的发送时间间隔调整为所述第一时长；

所述客户端获得所述通告报文携带的所述第一时长；

所述客户端每隔所述第一时长，发送上线请求报文。

16.根据权利要求15所述的方法，其特征在于，所述通告报文为动态主机配置协议DHCP报文，所述DHCP报文包括重传选项，所述重传选项包括所述第一时长。

17.根据权利要求16所述的方法，其特征在于，所述DHCP报文还包括DHCP消息类型字段，所述DHCP消息类型字段用于标识DHCP报文为通告报文。

18.根据权利要求15至17中任一项所述的方法，其特征在于，所述客户端每隔所述第一时长，发送上线请求报文包括：

所述客户端每隔所述第一时长，向网络设备发送上线请求报文，所述通告报文是由所述网络设备发送的。

19.一种网络设备，其特征在于，包括：

确定单元，用于确定第一时长；

生成单元，用于生成通告报文，所述通告报文携带所述第一时长；

发送单元，用于向第一客户端发送所述通告报文，所述通告报文用于指示所述第一客户端将上线请求报文的发送时间间隔调整为所述第一时长。

20.根据权利要求19所述的网络设备，其特征在于，所述网络设备为动态主机配置协议服务器DHCP server或动态主机配置协议中继DHCP relay，所述第一客户端为动态主机配置协议客户端DHCP client。

21.根据权利要求19或20所述的网络设备，其特征在于，所述通告报文为动态主机配置协议DHCP报文，所述DHCP报文包括重传选项，所述重传选项包括所述第一时长。

22.根据权利要求21所述的网络设备，其特征在于，所述DHCP报文还包括DHCP消息类型字段，所述DHCP消息类型字段用于标识DHCP报文为通告报文。

23.根据权利要求19至22任一权利要求所述的网络设备，其特征在于，所述网络设备还包括：

接收单元，用于接收所述第一客户端发送的第一上线请求报文，所述第一上线请求报文包含有所述第一客户端的源地址。

24.根据权利要求23所述的网络设备，其特征在于，所述确定单元，用于根据所述第一客户端的源地址确定所述第一客户端的级别；根据所述第一客户端的级别确定第一时长，所述第一客户端的级别越高所述第一时长越小。

25.根据权利要求23所述的网络设备，其特征在于，所述确定单元，用于根据所述第一客户端的上线信息确定第一时长，所述上线信息表示所述第一客户端是否为首次上线的客户端。

26.根据权利要求19至22任一权利要求所述的网络设备，其特征在于，所述确定单元，用于根据能力数据确定第一时长，所述能力数据表示所述网络设备的报文处理能力，所述报文处理能力越弱，所述第一时长越大。

27.根据权利要求26所述的网络设备，其特征在于，所述能力数据包括所述网络设备的中央处理器CPU利用率，所述确定单元，用于根据所述CPU利用率确定第一时长，所述CPU利用率越高，所述第一时长越大。

28.根据权利要求26所述的网络设备，其特征在于，所述能力数据包括所述网络设备已缓存的报文数量，所述确定单元，用于根据所述已缓存的报文数量确定所述第一时长，所述已缓存的报文数量越多，所述第一时长越大。

29.根据权利要求19至28中任一项所述的网络设备，其特征在于，所述确定单元，用于若所述网络设备的负载大于或等于阈值，对上线请求报文的发送时间间隔增加第二时长，得到所述第一时长。

30.根据权利要求19至28中任一项所述的网络设备，其特征在于，所述确定单元，用于若所述网络设备的负载小于阈值，对上线请求报文的发送时间间隔减小第三时长，得到所述第一时长。

31.根据权利要求19至30中任一项所述的网络设备，其特征在于，所述网络设备还包括：

创建单元，用于在黑名单中创建第一表项，所述第一表项包括所述第一客户端的源地址，所述第一表项的存活时长与所述第一时长相同，所述存活时长为所述第一表项的创建时间点至删除时间点之间的时长；

接收单元，用于接收第三上线请求报文，所述第三上线请求报文包含有所述第一客户端的源地址；

丢弃单元，用于响应于所述第三上线请求报文命中所述第一表项，丢弃所述第三上线请求报文。

32.根据权利要求19-30中任一项所述的网络设备，其特征在于，所述网络设备还包括：

创建单元，用于在黑名单中创建第二表项，所述第二表项包括第二客户端的源地址；

接收单元，用于接收第二上线请求报文，所述第二上线请求报文包含有所述第二客户端的源地址；

丢弃单元，用于响应于所述第二上线请求报文命中所述第二表项，丢弃所述第二上线请求报文。

33.一种客户端，其特征在于，所述客户端包括：

接收单元，用于接收通告报文，所述通告报文用于指示所述客户端将上线请求报文的发送时间间隔调整为所述第一时长；

获得单元，用于获得所述通告报文携带的所述第一时长；

发送单元，用于每隔所述第一时长，发送上线请求报文。

34.根据权利要求33所述的客户端，其特征在于，所述通告报文为动态主机配置协议DHCP报文，所述DHCP报文包括重传选项，所述重传选项包括所述第一时长。

35.根据权利要求34所述的客户端，其特征在于，所述DHCP报文还包括DHCP消息类型字段，所述DHCP消息类型字段用于标识DHCP报文为通告报文。

36.根据权利要求33至35中任一项所述的客户端，其特征在于，所述发送单元，用于每隔所述第一时长，向网络设备发送上线请求报文，所述通告报文是由所述网络设备发送的。

37.一种网络系统，其特征在于，所述网络系统包括如权利要求19至32中任一项所述的网络设备以及如权利要求33至36中任一项所述的客户端。

38.一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令，当所述至少一条指令在设备上执行时，使得所述设备执行如权利要求1至权利要求18中任一项所述的方法。