DHCP——动态主机配置协议

一。DHCP的由来及概念

（1）IETF制定了BOOTP（Bootstrap Protocal）协议，专门用来解决IP地址等网络参数的配置问题。后来针对BOOTP协议的各种缺陷和不足，IETF又制定了一个新的协议，称为DHCP——动态主机配置协议。

（2）该协议提供了一种动态分配网络配置参数的机制，并且可以后向兼容BOOTP协议。

（3）通常情况下，路由器时不适合通过DHCP来自动获取它的IP值的。对于路由器，一般应该根据它所处的网络环境及其他的一些原则来手工配置它的IP地址等参数。

（4）DHCP是一种Client/Server模式的网络协议。在这里的Server虽然常被称为“服务器”，但是它并不是指我们平时可以看到和摸到的服务器（高性能计算机），而只是一个应用程序而已。这个应用程序可以运行在个人电脑上，也可以运行在服务器（高性能计算机）上，还可以运行在路由器等其他设备上。同样的，Client也只是一个应用程序。

问题1：一个处在公司中的电脑是如何得到IP地址进行上网的呢？

答：其实，电脑上电之后，会自动运行DHCP Client。DHCP Client会与运行在公司其他设备上的DHCP Server进行交互，请求从DHCP  Server 那里获取自己的IP地址。DHCP Server在收到DHCP  Client的请求后，会根据某种规则在自己的地址池中选择一个IP地址，然后将其分配给DHCP Client。

二。DHCP的基本工作流程

DHCP的基本工作流程分为4个阶段：发现阶段、提供阶段、请求阶段、确认阶段。

1. 发现阶段：发现阶段就是PC 1上的DHCP Client寻找DHCP Server的阶段。

如上图：PC 1上的DHCP Client开始运行后，会发送一个广播帧，这个广播帧的源MAC地址为PC 1的MAC地址，类型字段的值为0x0800，载荷数据为一个广播IP报文。该IP报文的目的IP地址为有限广播地址255.255.255.255，源IP地址为0.0.0.0，协议字段的值为0x11，载荷数据是一个UDP报文。该UDP报文的目的端口号是67，源端口号是68，载荷数据是一个DHCPDISCOVER消息。

则与PC 1处于同一个二层网络中的所有设备（包含路由器R1）都会收到这个广播帧。交换机收到这个广播帧后，只会将其泛洪出去。其他设备（如：服务器、路由器、其他的PC等）收到这个广播帧后，会将相关的载荷数据逐层上送。传输层的UDP模块接收到网络层上送的UDP报文后，会检查UDP报文的目的端口号。只有运行了DHCP Server的设备才会识别出目的端口号67，并将其载荷数据（DHCPDISCOVER消息）上送至应用层的DHCP Server。如果设备上没有运行的DHCP Server，则目的端口号为67的UDP报文会在传输层被直接丢弃。

2. 提供阶段：提供阶段也就是DHCP Server向DHCP Client提供IP地址的阶段。

注意：DHCP Client是否愿意接受DHCP Server所提供的IP地址，这个阶段还反映不出来。

如上图：每个接收到DHCP DISCOVER消息的DHCP Server（包含路由器R1上运行的DHCP Server）都会从自己维护的地址池中选择一个合适的IP地址，并通过DHCPOFFER消息将这个IP地址发送给DHCP Client。

DHCPOFFER消息是封装在目的端口号为68的、源端口号为67 的UDP报文中的，该UDP报文又是封装在一个广播IP报文中的。IP报文的目的IP地址为有限广播地址255.255.255.255，源IP地址为DHCP Server所对应的单播IP地址，协议字段的值为0x11。而且该IP报文又是封装在一个广播帧里的，这个帧的源MAC地址为DHCP Server所对应的单播MAC地址，类型字段的值为0x0800。

则与PC 1处于同一个二层网络中的所有设备（包含路由器R1）都会收到这个广播帧。交换机收到这个广播帧后，只会将其泛洪出去。其他设备（如：服务器、路由器、其他的PC等）收到这个广播帧后，会将相关的载荷数据逐层上送。传输层的UDP模块接收到网络层上送的UDP报文后，会检查UDP报文的目的端口号。只有运行了DHCP Server的设备才会识别出目的端口号68，并将其载荷数据（DHCPOFFER消息）上送至应用层的DHCP Client。如果设备上没有运行的DHCP Client，则目的端口号为68的UDP报文会在传输层被直接丢弃。

问题2：二层网络中除了PC 1外，可能还存在比如的PC，并且别的PC上可能也运行了DHCP Client。那么，这些DHCP Client在发送DHCPOFFER消息确定这个Offer是不是给自己的呢？

答：每个DHCP Client在发送DHCPDISCOVER消息的时候，都会在DHCPDISCOVER消息中设定一个交易号（Transaction ID），DHCP Server在回应DHCPDISCOVER消息的时候，会将这个交易号拷贝到DHCPOFFER消息中。在这之后，一个DHCP Client在收到衣蛾DHCPOFFER消息后，只要检查其中的交易号是不是自己当初设定的交易号，就能判断出这个Offer是不是给自己的。（交易号是一个4字节的二进制数，则交易号“撞车”的可能性非常小）。

3. 请求阶段：

在请求阶段中，PC 1的DHCP Client会在若干个收到的Offer（即若干个收到的DHCPOFFER消息）中根据某种原则来确定出自己将要接受哪一个Offer。通常情况下，DHCP Client会接受它所收到的第一个Offer（即最先收到的那个DHCPOFFER消息）。

如上图：假设PC 1最先收到的DHCPOFFER消息是来自路由器R1上的DHCP Server提出请求，希望获取到该DHCP Server发送给自己的DHCPOFFER消息中所提供的那个IP地址。

PC 1的DHCP Client发送的广播帧的源MAC地址为PC 1的MAC地址，类型字段的值为0x0800,载荷数据为一个广播IP报文。该IP报文的目的IP地址为有限广播地址255.255.255.255，源IP地址为0.0.0.0，协议字段的值为0x11，载荷数据是一个UDP报文。该UDP报文的目的端口号是67，源端口号是68，载荷数据是一个DHCPREQUEST消息。（这个DHCPREQUEST消息中携带有R1上的DHCP Server的标识（称为Server Identifier）,表示PC 1的DHCP Client只愿意接受R1上的DHCP Server所给出的Offer。）

该二层网络上所有的DHCP Server都会接收到PC 1上的DHCP Client发送的DHCPREQUEST消息。R1上的DHCP Server收到并分析该DHCPRQUEST消息后，会明白PC 1已经愿意接受自己的Offer。其他的DHCP Server收到并分析该DHCPREQUEST消息后，会明白PC 1拒绝了自己的Offer。于是，这些DHCP Server就会收回自己当初给与PC 1的Offer。即当初准备提供给PC 1使用的IP地址现在可以用来分配给其他的设备使用了。

4. 确认阶段

在确认阶段，R1上的DHCP Server会向PC 1上的DHCP Client发送一个DHCPACK消息。DHCPACK消息是封装在目的端口号为68，源端号为67的UDP报文中的，该UDP报文又是封装在一个广播IP报文中的。IP报文的目的IP地址为有限广播地址255.255.255.255，源IP地址为DHCP Server所对应的单播IP地址，协议字段的值为0x11。而且该IP报文又是封装在一个广播帧里的，这个帧的源MAC地址为DHCP Server所对应的单播MAC地址，类型字段的值为0x0800。

但是由于各种各样的原因，R1上的DHCP Server也可能会向PC 1上的DHCP Client发送一个DHCPACK消息。如果PC 1接收到了DHCPACK消息，就说明这次获取IP地址的尝试失败了。在这样的情况下，PC 1只能重新回到发现阶段来开始新一轮的IP地址申请过程。

PC 1上的DHCP Client接收到R1上的DHCP Server发送的DHCPACK消息后，就意味着PC 1首次获得了DHCP Server分配给自己的IP地址。实际上，PC 1还会立即通过Gratuitous ARP机制来检验所获得的IP地址的唯一性。

补充：Gratuitous ARP也称为免费ARP，无故ARP。Gratuitous ARP不同于一般的ARP请求，它并非期待得到ip对应的mac地址，而是当主机启动的时候，将发送一个Gratuitous arp请求，即请求自己的ip地址的mac地址。

问题3：PC 1下次开机启动时，是否还需要完全重复前面所简述的4个阶段才能获得IP地址呢？

答：否。因为在实际情况上，PC 1上是有磁盘等存储设备的，所以PC 1是能够记住自己上次所获得的IP地址的，并且能够记住当初分配这个IP地址的那个DHCP Server的Server Identifier（就是R1上的DHCP Server的Server Identifier），还能记住这个DHCP Server所对应的单播IP地址和单播MAC地址等信息。即便PC 1再次重新启动时，只需要直接进入第三阶段——请求阶段，以广播帧及广播IP报文的形式发送DHCPREQUEST消息，在这个消息中，携带有R1上的DHCP Server的Server Identifier，表示希望继续使用上次分配给自己的IP地址。而PC 1在收到来自R1上的DHCP Server的DHCPACK消息后，就可以开始继续使用这个IP地址了。

但是由于各种原因，R1上的DHCP Server不能让PC 1继续使用这个IP地址，那么R1上的DHCP Server就会回应一个DHCPNACK消息。PC 1如果收到了DHCPNACK消息后，就必须放弃原先使用的IP地址，而必须重新从发现阶段开始重新申请一个IP地址。

问题4：既然PC 1能够记住R1上的DHCP Server所对应的单播IP地址和单播MAC地址（就是R1的GE1/0/0接口的IP地址和MAC地址），那么，PC 1重新启动时，为什么是以广播帧和广播IP报文的方式发送DHCPREQUEST消息的呢？

答：实际上，DHCP协议是允许先以单播帧和单播IP报文的方式来发送DHCPREQUEST消息的，如果在发送之后接收不到回应（例如：R1上的GE1/0/0接口的IP地址或者MAC地址发生了变化），就会再用广播帧及广播IP报文的方式发送DHCPREQUEST消息。

从DHCP协议的角度看，IP地址的所有权是属于DHCP Sever的，而不是DHCP Client的；DHCP Client所拥有的只是IP地址的使用权。在事实上，DHCP Server每次给DHCP Client分配一个IP地址时，只是跟DHCP Client订立了一个关于这个IP地址的租约。每个租约都有一个租约期（Duration of Lease），DHCP协议规定租约期的缺省值不得小于一个小时，然而在实际部署DHCP时，租约期的缺省值通常都是24小时。在租约期内，DHCP Client才能使用相应的IP地址。但是，当租约期到期之后，DHCP Client是不被允许继续使用这个IP地址的。解决方法是，在租约期还未到期的时候，DHCP Client是可以继续申请续租这个IP地址的。

申请流程如下图：

按照DHCP协议的规定，在缺省情况下，上图中的T1时刻是租约到期了一半的时间，而T2时刻是租约期到期了87.5%的时间。在T1时刻，PC 1上的DHCP Client会以单播方式向R1上的DHCP Server发送一个DHCPREQUEST消息，请求续租IP地址（即请求重新开始租约期的计时）。如果在T2时刻之前，PC 1上的DHCP Client收到了回应的DHCPACK消息，则说明续租已经成功。但是如果直到T2时刻，PC 上的DHCP Client都没有收到回应的DHCPACK消息，则在T2时刻，PC 1上的DHCP Client会以广播帧的方式再发送一个DHCPREQUEST消息，继续请求续租IP地址。如果在租约期到期之前，PC 1上的DHCP Client收到了所回应的DHCPACK消息，则表示续租成功；但是如果直到续租期到期时，PC 1上的DHCP Client还未收到回应的DHCPACK消息，那么PC 1就必须停止使用原来的IP地址，PC 1只能重新从发现阶段开始重新申请一个IP地址。

三。DHCP中继代理

DHCP Client总是以广播（广播帧即广播IP报文）方式来发送DHCPDISCOVER消息和DHCPREQUEST消息的。但是，如果DHCP Server和DHCP Client不在同一个二层网络（二层广播域）中，那么DHCP Server根本就不可能接收到这些DHCPDISCOVER消息和DHCPREQUEST消息。所以，在上述的DHCP工作流程的描述中，只适合于DHCP Server和DHCP Client位于同一个二层网络的场景中。

问题5：如果一个公司的网络包含了多个二层网络，那么是不是必须在每个二层网络中都至少部署一个DHCP Server呢？

答：理论上，是可以的。但是在实际情况中，这样会很不经济。其实，DHCP协议除了定义了DHCP Client和DHCP Server这两个角色之外，还定义了DHCP Relay Agent（DHCP中继代理）这种角色。

DHCP Relay Agent的基本作用是专门在DHCP Client和DHCP Server之间进行DHCP消息的中转。

如上图所示：DHCP Client利用DHCP Rrelay Agent来从DHCP Server那里获取IP地址等配置参数时，DHCP Relay Agent必须和DHCP Client位于同一个二层网络，但是DHCP Server可以与DHCP Rrelay Agent位于同一个网络，也可以与DHCP Rrelay Agent位于不同的二层网络。

DHCP Client和DHCP Rrelay Agent之间是以单播方式交换DHCP消息的（就是DHCP Rrelay Agent必须事先知道DHCP Server的IP地址）。DHCP Rrelay Agent通常是部署在路由器上或者三层交换机上。