如果只为了应付选择题，记住下面这一条链条基本就够了。

`DHCPDISCOVER → DHCPOFFER → DHCPREQUEST → DHCPACK`

客户机还没有获得 DHCP 服务器最终确认时，没有一个已经正式属于自己的 IPv4 地址，所以发送 DHCP 报文时仍然使用 `0.0.0.0` 作为源 IP 地址。等收到 DHCPACK，租约正式建立，客户机才进入可以正常使用所分配地址的状态。

不过，这道题里面其实藏着一个很有价值的工程细节。按照常见教材和考试题的简化模型，多台 DHCP 服务器同时回答时，客户机通常接受最先到达的 DHCPOFFER，所以第 68 题选 B。但按照 DHCP 的正式标准 RFC 2131，协议并没有强制规定客户机只能选择最先到达的 Offer。RFC 明确允许客户机收集多个 DHCPOFFER，再按照实现自己的策略选择其中一个，最先收到的 Offer 只是可能的选择策略之一。

所以这道题需要分成两个层面理解。

在考试语境中，答案是 `B、B`。

在真实协议实现中，第 69 题几乎没有争议，确实是 `0.0.0.0`。第 68 题则属于教材常用简化，实际 DHCP 客户端拥有更大的选择自由。

把这件事从头走一遍，会发现两个答案其实都和 DHCP 客户端刚接入网络时面临的同一个问题有关，客户机此时几乎什么都不知道。

一台刚刚启动、准备通过 DHCP 获取网络配置的计算机，可能知道自己的网卡 MAC 地址，却通常还不知道自己的 IPv4 地址是什么，也不知道默认网关是什么，不知道 DNS Server 在哪里，甚至不知道局域网里究竟有没有 DHCP Server。

这时如果要求它向一台特定 DHCP Server 发普通单播包，会立刻碰到困难。

发送普通 IPv4 单播报文，至少需要知道两个核心信息。

一个是自己的源 IPv4 地址。

另一个是对方的目标 IPv4 地址。

但 DHCP 客户机启动时恰恰缺少这些信息。

DHCP 为了解决这种鸡生蛋、蛋生鸡的问题，允许客户端在尚未取得地址的时候使用一个特殊源地址

`0.0.0.0`

同时向本地网络广播

`255.255.255.255`

从协议角度看，可以把客户端此时的状态理解为

`我目前还没有一个可以合法使用的 IPv4 地址，请网络里的 DHCP Server 给我提供一个配置方案。`

RFC 2131 对这一点写得非常明确，客户端在获得自己的 IP 地址之前发送广播 DHCP 报文时，IP Header 的 Source Address 应当设置为零，也就是 `0.0.0.0`。

于是 DHCP 的第一步出现了。

客户端发送 DHCPDISCOVER。

可以把关键网络层地址理解成

```text
源 IP 地址
0.0.0.0

目的 IP 地址
255.255.255.255
```

UDP 层通常是

```text
客户端端口
68

服务器端口
67
```

这里的 `0.0.0.0` 很重要。

它并不是 DHCP Server 分配给客户机的临时地址，也不是客户机随机挑出来的地址，更不是某个特殊局域网地址。

它表达的是一种状态

`当前主机尚未拥有可以在这个接口上正常使用的 IPv4 地址。`

这也正好解释第 69 题。

题目问

在没有得到 DHCP 服务器最后确认之前，客户机使用什么作为源 IP 地址。

答案自然是

`0.0.0.0`

而不是服务器准备分配给它的那个地址。

这里经常出现一个很容易掉进去的思维陷阱。

假设 DHCP Server 给客户端发来一个 DHCPOFFER，里面建议分配

```text
192.168.1.100
```

不少人在做题时会产生一个很自然的想法

`服务器都已经告诉客户端 192.168.1.100 了，那么下一步客户端发送 DHCPREQUEST 时，源地址是不是就应该变成 192.168.1.100`

恰恰不能这样做。

DHCPOFFER 只是 Offer。

它的含义更接近

`我可以把这个地址租给客户端。`

并不是

`这个地址现在已经正式归客户端使用。`

客户端还必须发送 DHCPREQUEST，明确表示自己接受哪一个服务器的方案。

服务器收到之后，再返回 DHCPACK。

到了 DHCPACK 这一阶段，租约才真正得到确认。

Microsoft 对 DHCPREQUEST 的说明也直接给出了抓包层面的表现，客户机此时的 Source Address 仍然是 `0.0.0.0`，Destination Address 仍然是 `255.255.255.255`。原因正是客户端尚未获得服务器最终确认，还不能认定自己已经可以使用 Offered Address。

这就形成了非常清楚的一条状态线。

```text
没有地址
    ↓
DHCPDISCOVER
    ↓
收到一个或多个 DHCPOFFER
    ↓
选择一个 Offer
    ↓
DHCPREQUEST
    ↓
DHCPACK
    ↓
地址正式生效
```

第 68 题讨论的是中间的 Offer 选择。

第 69 题讨论的是 DHCPACK 之前客户端的身份。

把两者串起来，比单独背两个 B 稳定得多。

再回到第 68 题。

客户机发出的 DHCPDISCOVER 是广播，因此同一个广播域中如果存在多台 DHCP Server，多台服务器都可能收到这个请求。

例如网络中同时存在

```text
DHCP Server A
192.168.1.2

DHCP Server B
192.168.1.3

DHCP Server C
192.168.1.4
```

客户端发送一个 DHCPDISCOVER。

三台服务器都有可用地址，于是可能分别给出

```text
Server A
提供 192.168.1.100

Server B
提供 192.168.1.150

Server C
提供 192.168.1.200
```

客户端不可能同时接受三个 IPv4 地址租约作为这一轮配置结果，因此必须选中其中一个 DHCPOFFER。

在很多网络基础教材和认证考试的简化模型中，处理方式描述为

客户端接受最先收到的 DHCPOFFER。

所以本题给出的四个选项中，考试答案就是

B，向响应最先到达的 DHCP 服务器发送 IP 地址租用请求。

A 所说的随机选择不符合这类基础考试题的预设模型。

C 所说的网络号最小没有 DHCP 标准依据。

D 所说的网络号最大同样没有这种规则。

不过在工程实践中不能把 `最先到达` 当成 DHCP 协议不可改变的铁律。

RFC 2131 的描述更严谨。

客户端可能收到一台或者多台服务器发出的 DHCPOFFER，它可以等待多个响应，再选择一个服务器。选择依据可以和服务器提供的配置参数有关。RFC 后面还进一步说明，客户端收集多个 DHCPOFFER 后，具体选择机制属于 Implementation Dependent，也就是由客户端实现决定。RFC 举出的可能策略甚至包括第一个收到的 Offer，或者以前曾经使用过的服务器。

这里能够看出教材与协议标准之间经常存在的一种关系。

教材为了让刚学习网络的人建立清晰模型，会把实现中的自由度压缩成一个常见情况。

于是形成

```text
多台 DHCP Server 响应
        ↓
最先到达的 Offer 被选择
```

正式 RFC 则更接近

```text
多台 DHCP Server 响应
        ↓
客户端可能收集多个 Offer
        ↓
客户端按照自己的实现策略选择一个
```

两种说法并不是完全互相否定。

第一种属于考试模型。

第二种属于协议规范。

考试时看到这四个选项，仍然选择 B。

工程分析、抓包排障或者实现 DHCP Client 时，则应当记住 RFC 并没有规定必须永远选第一个。

有意思的地方还在后面。

客户端已经选择 Server A 之后，为什么 DHCPREQUEST 经常仍然采用广播，而不是直接单播给 Server A。

因为其他 DHCP Server 也需要知道客户端作出了选择。

假设三台服务器都发送了 DHCPOFFER。

Server A 提供 `192.168.1.100`。

Server B 提供 `192.168.1.150`。

Server C 提供 `192.168.1.200`。

客户端决定接受 Server A。

它发送 DHCPREQUEST，并且在 DHCP 报文里的 Server Identifier 中指出被选中的 DHCP Server。

由于这条 DHCPREQUEST 可以广播出去，Server B 和 Server C 也能够看到

`客户端选择的不是我们的 Offer。`

于是它们可以放弃对应的临时 Offer，把地址重新放回可分配地址池。

RFC 2131 对这一流程也有明确描述。未被选择的服务器收到 DHCPREQUEST 后，可以据此得知客户端拒绝了自己的 Offer，被选中的服务器则提交租约绑定，并返回 DHCPACK。

所以 DHCPREQUEST 这一包很有意思。

从 IP Header 看，典型初始化阶段可以看到

```text
Source IP
0.0.0.0

Destination IP
255.255.255.255
```

从 DHCP Options 看，却可能已经包含

```text
Requested IP Address
192.168.1.100

Server Identifier
192.168.1.2
```

这三个地址的意义完全不同。

`0.0.0.0` 表示

客户端当前仍没有正式可用的地址。

`255.255.255.255` 表示

这是一条本地广播。

`192.168.1.100` 表示

客户端正在请求服务器确认这个被 Offer 的地址。

`192.168.1.2` 表示

客户端选择了哪一台 DHCP Server。

所以看到 DHCPREQUEST 抓包时，不能看到 Requested IP Address 是 `192.168.1.100`，就误以为 IP Header 的 Source IP 也一定已经是 `192.168.1.100`。

两个字段属于不同层次。

一个表达

`想要哪个地址`

另一个表达

`现在已经拥有什么地址`

在 SELECTING 和 REQUESTING 阶段，两者完全可能不同。

这也是第 69 题真正想考察的地方。

再把 DHCP 四步对应到状态变化里，就更容易形成长期记忆。

DORA 里的 D 是 Discover。

客户端还不知道服务器在哪里，也没有自己的正式地址，因此发 DHCPDISCOVER。

可以记成

```text
我没有 IP
我也不知道 DHCP Server 在哪里
所以广播寻找
```

O 是 Offer。

DHCP Server 收到请求以后，根据自己的地址池和策略给出可用地址。

可以记成

```text
Server 提议
这个地址可以租给客户端
```

注意这里仍然只是提议。

R 是 Request。

客户端从收到的 Offer 中选择一个，再发送 DHCPREQUEST。

可以记成

```text
客户端决定接受某个方案
请对应 Server 正式确认
```

A 是 Acknowledge。

服务器返回 DHCPACK。

可以记成

```text
租约成立
网络参数正式确认
```

于是考试时遇到

`没有得到 DHCP 服务器最后确认之前`

看到 `最后确认` 四个字，就应该马上联想到 DHCPACK。

ACK 还没来，客户端仍不能把 Offered IP 当成已经正式属于自己的地址。

因此源 IP 仍然是

`0.0.0.0`

这个判断方法比死记选项更可靠。

再看第 69 题另外三个干扰项。

A 是 `255.255.255.255`。

这个地址在这里用于 Limited Broadcast，也就是受限广播地址。

它适合作为目的地址。

客户端不知道 DHCP Server 的具体位置时，可以把 DHCPDISCOVER 发往这个目的地址。

但它不能拿来表达客户端自己的身份，所以不能作为这里的正常源 IPv4 地址。

一个很实用的记忆关系是

```text
0.0.0.0
我是谁还不知道

255.255.255.255
不知道服务器是谁，所以问大家
```

于是 DHCPDISCOVER 的经典组合就非常容易记住

```text
0.0.0.0
        ↓
255.255.255.255
```

也就是

`从还没有地址的我，发给当前广播域里的大家。`

C 是 `127.0.0.0`。

`127.0.0.0/8` 属于 IPv4 Loopback 地址空间。

最常见的地址是

`127.0.0.1`

它代表本地主机回环通信。

如果把 DHCPDISCOVER 的源地址理解成 `127.0.0.0`，整个语义就完全错了。

DHCP 的目标是通过真实网络接口去寻找服务器。

Loopback 的主要意义是本机协议栈内部通信。

两者用途完全不同。

D 是随机生成地址。

DHCP 客户端当然不能在标准 DHCP 地址获取流程里随便产生一个普通 IPv4 地址并直接拿来作为 Source IP。

如果客户端随机生成

`192.168.1.88`

而局域网里已经有另一台设备使用 `192.168.1.88`，马上就可能造成 IP 地址冲突。

DHCP 存在的一个重要目的，就是让地址分配受到统一管理，而不是每台客户机随意挑地址。

因此 D 也明显错误。

到了 DHCPACK 收到以后，情况发生变化。

假设 Server A 最终确认

```text
IP Address
192.168.1.100

Subnet Mask
255.255.255.0

Default Gateway
192.168.1.1

DNS Server
192.168.1.53

Lease Time
86400 秒
```

客户端此时拥有了一组正式 DHCP Configuration Parameters。

在正常完成必要检查以后，就可以把 `192.168.1.100` 配置到接口上。

这时候再进行普通 IPv4 通信，源地址当然就不再是 `0.0.0.0`。

例如访问同一局域网里的服务器时可能变成

```text
Source IP
192.168.1.100

Destination IP
192.168.1.20
```

访问互联网时，在客户机本机的网络层报文里仍可能是

```text
Source IP
192.168.1.100

Destination IP
8.8.8.8
```

随后经过默认网关以及可能存在的 NAT 设备。

这与启动阶段

```text
0.0.0.0 → 255.255.255.255
```

已经是完全不同的通信状态。

从状态机角度理解会更严谨一些。

客户端最初处于 INIT。

发出 DHCPDISCOVER 后进入 SELECTING。

收到一个或多个 DHCPOFFER 后选中一个。

发送 DHCPREQUEST 后进入 REQUESTING。

收到 DHCPACK 并成功配置后进入 BOUND。

于是第 69 题所谓

`没有得到 DHCP 服务器最后确认之前`

实际上主要覆盖的就是客户端尚未进入正常 BOUND 状态的阶段。

在这种初始化场景里，不能提前把 Server Offer 出来的地址当成已经绑定完成。

这也解释了为什么 DHCP 不是简单的两步协议。

乍看起来似乎可以设计成

```text
客户端
给我 IP

服务器
192.168.1.100 给客户端
```

但真实网络里可能有多个 DHCP Server，还需要处理地址租约、冲突、续租、重新绑定、拒绝、服务器选择等问题。

DORA 四步把 Offer 与最终 Commit 分开，就能够在多服务器环境里协调这一过程。

这里甚至还能和 TCP 建立连接作一个有限度的类比。

TCP 建立连接不能只凭某一端单方面认为连接已经成立。

DHCP 地址租约同样不是收到 DHCPOFFER 就立即等价于最终绑定。

当然，两种协议解决的问题完全不同，一个属于传输层连接管理，一个属于网络配置协议，不能把机制完全对应起来。但从状态确认这个角度理解，会比较顺手。

现在回头看题目原句

`如果客户机收到网络上多台 DHCP 服务器的响应，它将（68）DHCP 服务器发送 IP 地址租用请求。在没有得到 DHCP 服务器最后确认之前，客户机使用（69）为源 IP 地址。`

按照考试题意，可以直接还原成

`客户端收到多个 DHCPOFFER 后，按照教材模型选择最先响应的 DHCP Server，并发送 DHCPREQUEST。在收到 DHCPACK 之前，客户端尚没有正式获得可用地址，因此源 IPv4 地址使用 0.0.0.0。`

所以答案是

```text
（68）B

（69）B
```

这道题最适合留下的记忆并不是单独的 `B、B`，而是下面这幅脑中的 DHCP 流程图。

```text
刚启动
没有 IP
    │
    │  DHCPDISCOVER
    │  0.0.0.0 → 255.255.255.255
    ▼
一个或多个 DHCP Server 响应
    │
    │  DHCPOFFER
    ▼
客户端选择一个 Offer
    │
    │  DHCPREQUEST
    │  此时仍未最终获得地址
    │  Source IP 仍为 0.0.0.0
    ▼
被选中的 DHCP Server
    │
    │  DHCPACK
    ▼
租约确认
客户端正式使用获得的 IP 地址
```

以后再遇到类似题目，只需要问两个问题。

当前处在 DORA 哪一步。

客户端有没有收到 DHCPACK。

只要 DHCPACK 还没有完成最终确认，在这道题所描述的初始地址获取过程中，就不要急着把 DHCPOFFER 里的地址写进 Source IP。

再补一层经常被考试省略、但做实际网络排障很有用的知识。

DHCPREQUEST 并不永远等价于 `源地址 0.0.0.0`。

RFC 2131 规定，客户端在不同状态下发送 DHCPREQUEST，字段使用会有所不同。例如客户端已经处于 BOUND、RENEWING 或 REBINDING 等状态时，它已经拥有一个有效地址，相关 DHCPREQUEST 可以出现客户端自己的网络地址。RFC 对 `ciaddr` 的使用也区分了客户端当前状态。

因此不能机械地背成

`所有 DHCPREQUEST 的源 IP 都是 0.0.0.0`

正确范围应该限定成

`客户端初次申请地址，在尚未获得 DHCPACK、尚未拥有可用 IPv4 地址的阶段，可以使用 0.0.0.0 作为源地址。`

这个限定特别重要。

网络题经常通过删掉上下文来制造错误判断。

同一个 DHCPREQUEST，在初始化租约、续租和重新绑定阶段，网络层表现可能并不完全相同。

题目已经明确说

`在没有得到 DHCP 服务器最后确认之前`

所以这里显然讨论的是初始地址获取阶段，答案 B 没有问题。

还有一个容易和第 69 题混淆的点，就是 `0.0.0.0` 与默认路由里的 `0.0.0.0/0`。

虽然字符看起来很像，但语义需要根据出现位置判断。

作为 IPv4 Source Address 的 `0.0.0.0`，在 DHCP 初始化这种场景里表示客户端尚未拥有有效 IPv4 地址。

作为路由表中的

```text
0.0.0.0/0
```

它表示默认路由，前缀长度为零，可以匹配没有被更具体路由命中的任意 IPv4 目的地址。

一个属于 IP 地址字段语义。

一个属于 CIDR 路由前缀。

看到 `0.0.0.0` 时，不能脱离上下文直接赋予固定含义。

同理，`255.255.255.255` 也不是 DHCP 专属地址，它是 IPv4 Limited Broadcast Address，只是 DHCP 在客户端不知道网络配置的时候恰好非常需要这种广播能力。

把这些细节连起来，会发现 DHCP 这道选择题虽然只有两个空，却把 IPv4 特殊地址、广播、客户机状态机、多 DHCP Server 竞争、租约确认和 DHCP DORA 流程揉在了一起。

因此做题时可以用一句相当紧凑的口诀收住整条逻辑

`Discover 广播找，Offer 服务器报，Request 客户端挑，ACK 到手才算拿到。`

其中 Request 阶段还没有拿到最终确认，所以 Source IP 仍然可以是

`0.0.0.0`

而考试模型下，多服务器 Offer 中优先采用先到达的响应，所以第 68 题选择 B。

最终答案保持不变

```text
（68）B，向响应最先到达的 DHCP 服务器发送 IP 地址租用请求

（69）B，0.0.0.0
```

需要额外牢牢记住的工程边界则是，第 68 题里的 `最先到达` 属于常见教材和考试简化。RFC 2131 并没有要求所有 DHCP Client 都必须采用 First Offer Wins。正式协议允许客户端收集多个 Offer，再根据自己的实现策略进行选择。相比之下，第 69 题的核心原理非常稳定，在初始地址获取阶段，客户端尚未获得可用地址时，广播 DHCP 报文使用 `0.0.0.0` 作为源地址正是标准规定的行为。

## 参考资料

RFC Editor，RFC 2131，Dynamic Host Configuration Protocol。该标准给出了 DHCP Client 与 DHCP Server 的完整交互状态、DHCPOFFER 选择规则、DHCPREQUEST 行为以及客户端尚未获得地址时使用零地址作为源地址的规定。

Microsoft Learn，DHCP Dynamic Host Configuration Protocol Basics。Microsoft 的说明结合 DHCPREQUEST 抓包明确展示了客户端在尚未得到服务器确认时仍使用 `0.0.0.0` 作为 Source Address，并把 `255.255.255.255` 作为 Destination Address。

DHCPDISCOVER → DHCPOFFER → DHCPREQUEST → DHCPACK

从 DHCP 的 DORA 四步握手看懂多服务器竞争与 0.0.0.0

紫薇堂堂主

网络与通信

架构设计

DHCP四步流程为DISCOVER→OFFER→REQUEST→ACK，客户端在收到ACK前使用0.0.0.0作为源IP地址广播请求。多服务器响应时考试模型选择最先到达的Offer（第68题选B），但RFC2131允许客户端按策略自选。第69题答案为0.0.0.0，代表客户端尚未获得正式地址。

代码解释

服务器

路由

CIDR

DHCP

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

从 DHCP 的 DORA 四步握手看懂多服务器竞争与 0.0.0.0-腾讯云开发者社区-腾讯云

从 DHCP 的 DORA 四步握手看懂多服务器竞争与 0.0.0.0

从 DHCP 的 DORA 四步握手看懂多服务器竞争与 0.0.0.0

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐