CN105939405B - 一种dhcp业务处理方法及装置 - Google Patents

Abstract

本申请提供DHCP业务处理方法及装置，所述方法包括：在收到客户端DHCP请求后，获取所述DHCP请求中客户端的MAC地址；查询所述MAC地址是否已存在；如果不存在，在多线程进程中创建一个新的线程用于处理该DHCP请求。应用本申请实施例，利用多线程技术，DHCP服务器针对客户端发送的DHCP请求只需在多线程中创建一个线程进行处理。如此，DHCP服务器只需开启一个多线程进程就可以处理多个不同网段内客户端的DHCP请求，进而可以提升DHCP服务器性能，减少DHCP服务器响应时间。

Description

一种DHCP业务处理方法及装置

技术领域

本申请涉及通信技术领域，尤其涉及一种DHCP业务处理方法及装置。

背景技术

动态主机配置协议(Dynamic Host Configuration Protocol，简称DHCP)是为内部网络(如局域网)中的客户端分配IP地址以及与IP地址相关的参数信息等地址资源的服务协议，而提供该服务的服务器被称为DHCP服务器。

客户端如果想要访问某个内部网络，那么必须要向该内部网络中的DHCP服务器发送DHCP请求，从而获取分配给本客户端的IP地址；然后，根据该IP地址才能正常访问内部网络。

现有技术中，在DHCP业务处理时，DHCP服务器对于不同网段会相应创建一个进程，同一网段内的DHCP请求由该网段内的进程处理。图1所示的一个DHCP业务处理的应用场景示意图，DHCP服务器具有4个网段分别是，vlan1网段、vlan2网段、vlan3网段及vlan4网段。客户端A在vlan1网段中，DHCP服务器会开启一个进程处理客户端A发送的DHCP请求；客户端B在vlan2网段中，DHCP服务器会开启一个进程处理客户端B发送的DHCP请求；客户端C在vlan3网段中，DHCP服务器会开启一个进程处理客户端C发送的DHCP请求；客户端D在vlan4网段中，DHCP服务器会开启一个进程处理客户端D发送的DHCP请求。然而，当大量处于不同网段的客户端访问内部网络时，DHCP服务器需要开启大量用于处理DHCP业务的进程，这样就会占用大量系统资源，从而造成DHCP服务器响应缓慢。

发明内容

本申请提供DHCP业务处理方法及装置，以解决现有技术中DHCP服务器响应缓慢的问题。

根据本申请实施例提供的一种DHCP业务处理方法，所述方法包括：

在收到客户端DHCP请求后，获取所述DHCP请求中客户端的MAC地址；

查询所述MAC地址是否已存在；

如果不存在，在多线程进程中创建一个新的线程用于处理该DHCP请求。

根据本申请实施例提供的一种DHCP业务处理装置，所述装置包括：

获取单元，用于在收到客户端DHCP请求后，获取所述DHCP请求中客户端的MAC地址；

查询单元，用于查询所述MAC地址是否已存在；

处理单元，用于在查询所述MAC地址不存在时，在多线程进程中创建一个新的线程用于处理该DHCP请求。

本申请实施例中，利用多线程技术，DHCP服务器针对客户端发送的DHCP请求只需在多线程中创建一个线程进行处理。如此，DHCP服务器只需开启一个多线程进程就可以处理来自多个不同网段内客户端发送的DHCP请求，进而可以提升DHCP服务器性能，减少DHCP服务器响应时间。避免了现有技术中不同网段都会相应创建一个用于处理DHCP请求的进程所造成的响应延迟。

附图说明

图1是现有技术中一个DHCP业务处理的业务场景示意图；

图2是本申请一实施例提供的DHCP业务处理方法的流程图；

图3是本申请一实施例提供的DHCP业务处理方法的流程图；

图4是本申请一实施例提供的DHCP业务处理方法的流程图；

图5是本申请一实施例提供的DHCP业务处理方法的流程图；

图6是本申请一实施例提供的DHCP业务处理方法的流程图；

图7是本申请一实施例提供的DHCP业务处理方法的流程图；

图8是本申请提供的DHCP业务处理装置所在设备的一种硬件结构图；

图9是本申请一实施例提供的DHCP业务处理装置的模块示意图。

具体实施方式

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

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

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

本申请实施例中，DHCP服务器作为DHCP请求的处理方，客户端作为DHCP请求发送方。其中，所述客户端可以具体包括服务器、台式计算机、膝上型计算机、平板计算机、智能手机、手持式计算机、个人数字助理(“PDA”)，或者其它任何的有线或无线处理器驱动装置。如上所述，所述客户端如果需要接入内部网络，就必须向该内部网络中的DHCP服务器发送DHCP请求，从而获取DHCP服务器返回的IP地址，再根据该IP地址来正常的访问所述内部网络。本申请实施例中，DHCP服务器无需针对不同网段都开启一个进程，而是利用多线程技术，仅需开启一个多线程进程，对于来自同网段内的每一个客户端发送的DHCP请求在该多线程进程中创建一个新的线程来实现DHCP业务处理。因此，DHCP服务器不会因为接入太多不同网段的客户端而造成响应时间缓慢，以此提高了DHCP服务器的整体运行效率。

参见图2，为本申请一实施例提供的DHCP业务处理方法的流程图，该实施例从DHCP服务器侧进行描述，包括以下步骤：

步骤201：在收到客户端DHCP请求后，获取所述DHCP请求中所述客户端的MAC地址。

本实施例中，客户端发送的DHCP请求中包含有该客户端的MAC地址。所述MAC(Media Access Control或者Medium Access Control)地址是客户端的物理地址(或称为硬件地址)，由于MAC地址具有唯一性，所以MAC地址可以作为客户端的身份标识。例如，客户端A的MAC地址为F4-8E-35-88-78-3B，那么只要获取到MAC地址为F4-8E-35-88-78-3B，就可以确定对应是客户端A。

步骤202：查询所述MAC地址是否已存在。

本实施例中，DHCP服务器中记录有正在访问内部网络的所有客户端的MAC地址。如果所述MAC地址对应的客户端已经连接了内部网络，那么在DHCP服务器中就可以查询到所述MAC地址；反之，如果所述MAC地址对应的客户端没有连接内部网络，那么在DHCP服务器中就查询不到所述MAC地址。

具体地，所述步骤202，具体可以包括：

查选线程链表中是否存在所述MAC对应的线程号。

本实施例中，在所述DHCP服务器中可以设置有线程链表。所述线程链表中记录有正在访问内部网络的客户端的MAC地址、线程号和线程状态之间的对应关系。如下表1所示：

表1

表1中，每一个接入内部网络的客户端都会被记录在上述线程链表中，线程号表示对应客户端的MAC地址的线程的编号；线程状态可以包括正常状态、异常状态。正常状态：当创建一个线程后，线程运行正常的话，线程状态就是正常状态。异常状态：当创建一个线程后，线程运行出现异常的话，线程状态就是异常状态。

步骤203：如果不存在，在多线程进程中创建一个新的线程用于处理该DHCP请求。

本实施例中，如果查询DHCP服务器中不存在所述客户端的MAC地址，可以说明所述客户端还没有连接内部网络，如此，DHCP服务器就需要对所述客户端发送的DHCP请求做出响应，具体地，即在多线程进程中创建一个新的线程用于处理该DHCP请求。

所述多线程进程，是利用了多线程技术(Multi thread technology)实现的进程。所述多线程技术主要是通过设备硬件支持同一时间，同时执行多个线程的技术。利用所述多线程技术可以有效提高DHCP服务器整体的处理能力。

本申请实施例中，利用多线程技术，DHCP服务器针对客户端发送的DHCP请求只需在多线程中创建一个线程进行处理。如此，DHCP服务器只需开启一个多线程进程就可以处理来自多个不同网段内客户端发送的DHCP请求。避免了现有技术中不同网段都会相应创建一个用于处理DHCP请求的进程所造成的响应延迟。

参见图3，为本申请一实施例提供的DHCP业务处理方法的流程图，该实施例从DHCP服务器侧进行描述，包括以下步骤：

步骤301：在收到客户端DHCP请求后，获取所述DHCP请求中客户端的MAC地址。

本实施例中，所述步骤301与上述实施例中所述步骤201相同，此处不再赘述。

步骤302：查询所述MAC地址是否已存在。

本实施例中，所述步骤302与上述实施例中所述步骤202相同，此处不再赘述。

步骤303：如果不存在，查询多线程进程的线程池中是否存在空闲线程。

本实施例中，DHCP服务器在创建一个新的线程之前，还需要查询多线程进程的线程池中是否存在空闲线程。如果存在，则执行步骤304；如果不存在，则放入任务队列中等待出现空闲线程后再执行步骤304。

所述线程池是一种多线程技术中的一个组成部分，线程池中存放这多线程进程的全部线程，包括空闲线程及使用中的线程。

所述线程池大小即线程池中线程的数量可以是人为预先设定的一个经验值。例如，线程池大小为100个线程。

或者，所述线程池大小可以由平均数算法计算得出。具体地，所述平均数算法如下公式1所示：

TP＝(R+T+U+L)/2 公式1

其中，TP表示线程池大小；R表示正在处理的DHCP请求数；T表示预测线程数；U表示预设线程总数上限值；L表示预设线程总数下限值。

值得一提的是，由于公式1中，T、U、L的值一般都是预先人为设定的，而R的值是变化的，所以通过上述公式1，可以实现线程池大小随着DHCP业务的处理量动态变化。如此，避免固定大小的线程池不能高效的处理DHCP业务。

步骤304：如果存在空闲线程，则在多线程进程中创建一个新的线程用于处理该DHCP请求。

本实施例中，如果线程池中存在空闲线程，DHCP服务器就可以在多线程进程中创建一个新的线程用于处理该DHCP请求。值得一提的是，所述新的线程可以是从空闲线程中随机选择的，或者，按照预设规则从空闲线程中选择的，所述预设规则例如包括按照线程号顺序选择。

所述在多线程进程中创建一个新的线程用于处理该DHCP请求与上述实施例中步骤203类似，此处不再赘述。

通过本实施例，利用多线程技术及线程池机制，DHCP服务器针对客户端发送的DHCP请求，只需在多线程的线程池中存在空闲线程时创建一个空闲线程进行处理。如此，DHCP服务器只需开启一个多线程进程就可以处理来自多个不同网段内客户端发送的DHCP请求，进而可以提升DHCP服务器性能，减少DHCP服务器响应时间。避免了现有技术中不同网段都会相应创建一个用于处理DHCP请求的进程所造成的响应延迟。

参见图4，为本申请一实施例提供的DHCP业务处理方法的流程图，该实施例从DHCP服务器侧进行描述，包括以下步骤：

步骤401：在收到客户端DHCP请求后，获取所述DHCP请求中客户端的MAC地址。

本实施例中，所述步骤401与上述实施例中所述步骤201相同，此处不再赘述。

步骤402：查询所述MAC地址是否已存在。

本实施例中，所述步骤402与上述实施例中所述步骤202相同，此处不再赘述。

步骤403：如果不存在，在多线程进程中创建一个新的线程。

本实施例中，如果DHCP服务器查询客户端的所述MAC地址不存在，就在多线程进程中创建一个新的线程。

步骤404：分配一个IP地址，并绑定所述MAC地址。

本实施例中，所述线程运行后可以给所述客户端分配一个IP地址，并将所述IP地址与所述MAC地址绑定。

通常，DHCP服务器上会预先设置一段IP地址段，给客户端分配的IP地址都是在这个IP地址段中选取的空闲IP地址。这个分配可以是随机的，也可以是按照一定规则选取的，例如从前往后顺序选取。分配后的IP地址在本客户端使用期间不能再分配给其它客户端。

DHCP服务器还可以将该MAC地址、IP地址记录到线程链表中。如上述实施例中表1的线程链表，除了记录MAC地址、线程号、线程状态之外，还可以包括IP地址，如下表2所示：

表2

MAC地址	线程号	线程状态	IP地址
				F4-8E-35-88-78-3B	011	正常状态	192.168.0.110
45-00-B5-3C-F8-53	012	异常状态	192.168.0.111

步骤305：向所述客户端返回包含所述IP地址的响应信息。

本实施例中，DHCP服务器可以将分配的IP地址封装到响应信息(所述响应信息中还可以包括子网掩码、DHCP服务器的IP地址、租约时间、以及其他的有关DHCP范围的详细配置)中，将所述响应信息返回至所述客户端。所述客户端接收到所述响应信息后可以根据IP地址来访问DHCP服务器所在的内部网络。

通过本实施例，利用多线程技术，DHCP服务器针对客户端发送的DHCP请求只需在多线程中创建一个线程进行处理。如此，DHCP服务器只需开启一个多线程进程就可以处理多个DHCP请求，避免了现有采用单线程技术那样对于每个DHCP请求都会创建一个进程，进而可以提升DHCP服务器性能，减少DHCP服务器响应时间。

参见图5，为本申请一实施例提供的DHCP业务处理方法的流程图，该实施例从DHCP服务器侧进行描述，包括以下步骤：

步骤501：在收到客户端DHCP请求后，获取所述DHCP请求中客户端的MAC地址。

本实施例中，所述步骤501与上述实施例中所述步骤201相同，此处不再赘述。

步骤502：查询所述MAC地址是否已存在。

本实施例中，所述步骤502与上述实施例中所述步骤201相同，此处不再赘述。

步骤503：如果不存在，在多线程进程中创建一个新的线程

本实施例中，所述步骤503与上述实施例中所述步骤403相同，此处不再赘述。

步骤504：分配一个IP地址，并绑定所述MAC地址。

本实施例中，所述步骤504与上述实施例中所述步骤404相同，此处不再赘述。

步骤505：向所述客户端返回包含所述IP地址的响应信息。

本实施例中，所述步骤505与上述实施例中所述步骤405相同，此处不再赘述。

步骤506：在所述客户端的租约时间到期时，清除所述IP地址绑定的MAC地址，并释放该线程。

本实施例中，DHCP服务器分配的每个IP地址都有相应的租约时间。因为DHCP服务器并不给客户端分配永久的IP地址，而只允许客户端在某个指定的时间段内使用某个IP地址。当然无论是DHCP服务器还是客户端都可以在任何时刻主动中止租用，即使IP地址与MAC地址解绑。

所述租约时间是随着时间的减少而同步减少的，当客户端的IP地址租约时间为0秒时，就表示所述客户端的租约时间到期。在所述客户端的租约时间到期时，DHCP服务器就会清除所述IP地址绑定的MAC地址，并释放该线程。具体地，清除线程链表中记录的MAC地址、IP地址、线程号等信息。释放该线程后，该线程在线程池中就成为一个空闲线程。

通常，当客户端的IP地址的租约时间剩余不足50％时，所述客户端会向DHCP服务器发送一个延期请求，用以更新租约时间，所述延期请求可以是一个UDP信息包，具体为一个DHCP Request信息包。如果DHCP服务器是可用的，则会将所述客户端的租约时间更新为100％，并通知所述客户端，具体是发送一个DHCP Acknowledge信息给客户端。

当客户端的IP地址的使用时间到达租约时间的87.5％时，如果在前一次延期请求(租约时间剩余不足50％时)中没能更新租约时间，所述客户端会再次向DHCP服务器发送一个延期请求，这个过程与前一次相同，此处不再赘述。如果这次延期请求失败的话，所述客户端还可以向内部网络中的任何一个DHCP服务器重新获得一个有效的IP地址。

本实施例与上述实施例不同之处在于，DHCP服务器在分配客户端IP地址之后，还可以持续监控所述客户端的租约时间，并在所述租约时间到期后，除所述IP地址及绑定的MAC地址，并释放该线程。如此，可以及时回收线程及IP地址，便于其它客户端使用。

参见图6，为本申请一实施例提供的DHCP业务处理方法的流程图，该实施例从DHCP服务器侧进行描述，包括以下步骤：

步骤601：在收到客户端DHCP请求后，获取所述DHCP请求中客户端的MAC地址。

本实施例中，所述步骤601与上述实施例中所述步骤201相同，此处不再赘述。

步骤602：查询所述MAC地址是否已存在。

本实施例中，所述步骤602与上述实施例中所述步骤202相同，此处不再赘述。

步骤603：如果不存在，在多线程进程中创建一个新的线程。

本实施例中，所述步骤603与上述实施例中所述步骤403相同，此处不再赘述。

步骤604：分配一个IP地址，并绑定所述MAC地址。

本实施例中，所述步骤604与上述实施例中所述步骤404相同，此处不再赘述。

步骤605：向所述客户端返回包含所述IP地址的响应信息。

本实施例中，所述步骤605与上述实施例中所述步骤405相同，此处不再赘述。

步骤606：在所述客户端异常退出时，清除所述IP地址绑定的MAC地址，释放该线程。

在本实施例中，如果客户端异常退出，DHCP服务器可以清除所述IP地址绑定的MAC地址，释放该线程。具体地，清除线程链表中记录的MAC地址、IP地址、线程号等信息。释放该线程后，该线程在线程池中就成为一个空闲线程。所述客户端异常退出可以有很多原因，例如客户端网络异常，客户端关机、重启等，在DHCP服务器就表现为与客户端之间的网络通讯异常或者中断。

本实施例与上述实施例不同之处在于，DHCP服务器在分配客户端IP地址之后，还可以持续监控与所述客户端之间的网络通讯状态，并在所述客户端异常退出时，除所述IP地址及绑定的MAC地址，并释放该线程。如此，可以及时回收线程及IP地址，便于其它客户端使用。

参见图7，为本申请一实施例提供的DHCP业务处理方法的流程图，该实施例从DHCP服务器侧进行描述，包括以下步骤：

步骤701：在收到客户端DHCP请求后，获取所述DHCP请求中客户端的MAC地址。

本实施例中，所述步骤701与上述实施例中所述步骤201相同，此处不再赘述。

步骤702：查询所述MAC地址是否已存在。

本实施例中，所述步骤702与上述实施例中所述步骤202相同，此处不再赘述。

步骤703：如果不存在，在多线程进程中创建一个新的线程。

本实施例中，所述步骤703与上述实施例中所述步骤403相同，此处不再赘述。

步骤704：分配一个IP地址，并绑定所述MAC地址。

本实施例中，所述步骤704与上述实施例中所述步骤404相同，此处不再赘述。

步骤705：向所述客户端返回包含所述IP地址的响应信息。

本实施例中，所述步骤705与上述实施例中所述步骤405相同，此处不再赘述。

步骤706：在所述客户端异常退出时，判断所述客户端的租约时间是否少于预设阈值。

本实施例中，所述预设阈值可以是人为预先设置的一个经验值或者一个比例值。例如，判断所述客户端的租约时间是否少于10％，或者判断所述客户的租约时间是否小于100秒。

如果所述客户端的租约时间小于预设阈值时，执行步骤306；如果所述客户端的租约时间不小于预设阈值，则继续监控客户端的租约时间。

步骤707：如果是，查询所述客户端MAC地址绑定的IP地址是否在使用。

本实施例中，如果所述客户端的租约时间小于预设阈值，则DHCP服务器可以查询所述客户端MAC地址绑定的IP地址是否在使用。具体地，DHCP服务器可以发送ARP(AddressResolution Protocol，地址解析)报文，如果发出的ARP报文有回应，说明所述IP地址在使用，继续监控所述客户端。如果发出的ARP报文没有回应，说明所述IP地址没在使用，则执行步骤708。

步骤708：如果否，则清除所述IP地址绑定的MAC地址，释放该线程。

本实施例中，如果所述客户端MAC地址绑定的IP地址没在使用，则清除所述IP地址绑定的MAC地址，释放该线程。具体地，清除线程链表中记录的MAC地址、IP地址、线程号等信息。释放该线程后，该线程在线程池中就成为一个空闲线程。

本实施例与上一实施例不同之处在于，本实施例在客户端异常退出时，只有在该客户端的租约时间小于预设阈值，并且确定该客户端没在使用分配的IP地址时，才会清除所述IP地址绑定的MAC地址，释放该线程，这样就可以避免客户端闪退闪连的情况，提高了用户体验。

与前述DHCP业务处理方法实施例相对应，本申请还提供了DHCP业务处理装置的实施例。

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

参见图9，为本申请一实施例提供的DHCP业务处理装置的模块图，该实施例从DHCP服务器侧进行描述，所述装置包括：获取单元910、查询单元920和处理单元930。

其中，所述获取单元910，用于在收到客户端DHCP请求后，获取所述DHCP请求中客户端的MAC地址；

查询单元920，用于查询所述MAC地址是否已存在；

处理单元930，用于在查询所述MAC地址不存在时，在多线程进程中创建一个新的线程用于处理该DHCP请求。

在一个可选的实现方式中：

所述处理单元930，具体包括：

创建子单元，用于在多线程进程中创建一个新的线程；

分配子单元，用于分配一个IP地址，并绑定所述MAC地址；

返回子单元，用于向所述客户端返回包含所述IP地址的响应信息。

在一个可选的实现方式中：

在所述返回子单元之后，所述装置还包括：

清除子单元，用于在所述客户端的租约时间到期时，清除所述IP地址绑定的MAC地址，释放该线程。

在一个可选的实现方式中：

在所述返回子单元之后，所述装置还包括：

异常检测子单元，在所述客户端异常退出时，判断所述客户端的租约时间是否少于预设阈值；

查询子单元，用于在所述客户端的租约时间小于预设阈值时，查询所述客户端MAC地址绑定的IP地址是否在使用；

清除子单元，用于在所述客户端MAC地址绑定的IP地址没在使用时，清除所述IP地址绑定的MAC地址，释放该线程。

在一个可选的实现方式中：

所述创建子单元，具体包括：

第一创建子单元，用于查询多线程进程的线程池中是否存在空闲线程；

第二创建子单元，用于如果存在空闲线程，则在所述多线程进程中创建一个空闲线程。

在一个可选的实现方式中：

所述线程池大小由平均数算法计算得出；所述平均数算法如下所示：

TP＝(R+T+U+L)/2,

其中，TP表示线程总数；R表示正在处理的DHCP请求数；T表示预测线程数；U表示预设线程总数上限值；L表示预设线程总数下限值。

综上所述，本申请实施例利用多线程技术，DHCP服务器针对客户端发送的DHCP请求只需在多线程中创建一个线程进行处理。如此，DHCP服务器只需开启一个多线程进程就可以处理来自多个不同网段内客户端发送的DHCP请求，进而可以提升DHCP服务器性能，减少DHCP服务器响应时间。避免了现有技术中不同网段都会相应创建一个用于处理DHCP请求的进程所造成的响应延迟。

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

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

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (6)

1.一种DHCP业务处理方法，其特征在于，所述方法包括：

在收到客户端DHCP请求后，获取所述DHCP请求中客户端的MAC地址；

查询所述MAC地址是否已存在；

如果不存在，在多线程进程中创建一个新的线程用于处理该DHCP请求；

所述在多线程进程中创建一个新的线程用于处理该DHCP请求，具体包括：

在多线程进程中创建一个新的线程；

分配一个IP地址，并绑定所述MAC地址；

向所述客户端返回包含所述IP地址的响应信息；

所述在多线程进程中创建一个新的线程，具体包括：

查询多线程进程的线程池中是否存在空闲线程；

如果存在空闲线程，则在所述多线程进程中创建一个空闲线程；

所述线程池大小由平均数算法计算得出；所述平均数算法如下所示：

TP＝(R+T+U+L)/2,

其中，TP表示线程总数；R表示正在处理的DHCP请求数；T表示预测线程数；U表示预设线程总数上限值；L表示预设线程总数下限值。

2.根据权利要求1所述的方法，其特征在于，在向所述客户端返回包含所述IP地址的响应信息之后，所述方法还包括：

在所述客户端的租约时间到期时，清除所述IP地址绑定的MAC地址，释放该线程。

3.根据权利要求1所述的方法，其特征在于，在向所述客户端返回包含所述IP地址的响应信息之后，所述方法还包括：

在所述客户端异常退出时，判断所述客户端的租约时间是否少于预设阈值；

如果是，查询所述客户端MAC地址绑定的ip地址是否在使用；

如果否，则清除所述IP地址绑定的MAC地址，释放该线程。

4.一种DHCP业务处理装置，其特征在于，所述装置包括：

获取单元，用于在收到客户端DHCP请求后，获取所述DHCP请求中客户端的MAC地址；

查询单元，用于查询所述MAC地址是否已存在；

处理单元，用于在查询所述MAC地址不存在时，在多线程进程中创建一个新的线程用于处理该DHCP请求；

所述处理单元，具体包括：

创建子单元，用于在多线程进程中创建一个新的线程；

分配子单元，用于分配一个IP地址，并绑定所述MAC地址；

返回子单元，用于向所述客户端返回包含所述IP地址的响应信息；

所述创建子单元，具体包括：

第一创建子单元，用于查询多线程进程的线程池中是否存在空闲线程；

第二创建子单元，用于如果存在空闲线程，则在所述多线程进程中创建一个空闲线程；

所述线程池大小由平均数算法计算得出；所述平均数算法如下所示：

TP＝(R+T+U+L)/2,

其中，TP表示线程总数；R表示正在处理的DHCP请求数；T表示预测线程数；U表示预设线程总数上限值；L表示预设线程总数下限值。

5.根据权利要求4所述的装置，其特征在于，在所述返回子单元之后，所述装置还包括：

清除子单元，用于在所述客户端的租约时间到期时，清除所述IP地址绑定的MAC地址，释放该线程。

6.根据权利要求4所述的装置，其特征在于，在所述返回子单元之后，所述装置还包括：

异常检测子单元，在所述客户端异常退出时，判断所述客户端的租约时间是否少于预设阈值；

查询子单元，用于在所述客户端的租约时间小于预设阈值时，查询所述客户端MAC地址绑定的IP地址是否在使用；

清除子单元，用于在所述客户端MAC地址绑定的IP地址没在使用时，清除所述IP地址绑定的MAC地址，释放该线程。

Images