☰

为什么 DHCP 请求被称为请求

tag-icon • tag-icon networking dhcp
为什么 DHCP 请求被称为请求

DHCP 有 4 个步骤：发现、提供、请求和确认。

为什么第三步叫做“请求”？没有人在这一步请求任何东西，对吧？

客户端只是说它将接受 DHCP 服务器提供的 IP。

这一步的“请求”部分在哪里？

答案1

是的，有请求。

你可以这样阅读对话：

Computer:  "I need an IP address!"          <-- This is the discover
Server:    "I have 10.11.12.13 available."  <-- This is the offer
Computer:  "May I have have 10.11.12.13?"   <-- This is the request
Server:    "Yes, you may."                  <-- This is the ack

还有很多事情要做，但本质上这就是过程。当你考虑到对话时，这是有道理的可以像这样：

Computer:  "I need an IP address!"
Server1:   "I have 10.11.12.13 available."
Server2:   "I have 10.11.12.19 available."
Server3:   "I have 10.12.1.2 available."
Computer:  "May I have 10.11.12.13?"
Server1:   "Yes, you may."

在这种情况下，有三台 DHCP 服务器都听到了发现数据包，并且都以提供响应。客户端“选择”了它收到的第一个提供，并向 Server1 发出请求，Server1 批准了该请求，因为该地址在其范围内并且可用。

Server2 和 Server3 从未收到请求，因此它们不会分配它们提供的 IP，从而使它们仍然可用。如果没有额外的请求步骤，一个客户端将耗尽 3 个 IP 地址，而不仅仅是一个。

答案2

客户端尚未拥有租约，但正在请求租约，因此这被称为“请求”。它请求签发、验证或延长租约。

答案3

第三步是“我（客户端）想使用您（服务器）的 IP”。由于下一步是服务器确认或不确认，因此服务器必须确认接受听起来很愚蠢。

答案4

我很喜欢Wes Sayeed 的回答。多个 DHCP 服务器可能是该请求有用的一个原因。

还有另一个原因：尝试重新使用与以前相同的地址。

请求是请求允许使用地址。发现、提供、请求、确认有时称为 DORA。

#1：发现：客户端向网络（通过广播消息）询问 DHCP 服务器

#2：OFFER ：DHCP 服务器响应，并提供一个潜在地址

#3：请求：最终用户机器/设备向服务器发送请求，请求 DHCP 服务器为该设备分配/保留/使用所请求的地址

#4：ACKnowledge：如果响应是ACKnowledge，而不是NACK（否定确认），则认为请求已被批准。

这里有一个棘手的部分：请求不需要与报价相匹配。

例如：如果笔记本电脑暂时脱离网络，然后尝试连接（同一网络或不同网络），则笔记本电脑可能希望尽可能使用相同的地址。以下是一段虚构的对话示例：

#1：发现：0.0.0.0 询问 255.255.255.255：“可以提供一个地址给我，让我知道你是谁吗？” 第 2 层地址从设备的 MAC-48 地址发送到 FF-FF-FF-FF-FF-FF（广播）。

#2：OFFER: 192.168.0.10 说：“我是 DHCP 服务器。使用 192.168.0.235 怎么样？”这将发送回 IP 地址 0.0.0.0，并发送到 DHCP 客户端的 MAC-48 地址。

#3：REQUEST: 0.0.0.0 对 192.168.0.10 说：“我可以有 192.168.0.117 吗？”（例如，笔记本电脑之前使用的是 192.168.0.117。）

#4：NACK：192.168.0.10 响应：“不。”（也许另一个系统现在正在使用它。）

#5：笔记本电脑放弃继续使用它想要的地址。

#6：（可能在另一个 DISCOVER 和 OFFER 之后？）DHCP 客户端发出另一个 REQUEST。因此，使用此示例中已经显示的数字，0.0.0.0 对 192.168.0.10 说：“让我拥有 192.168.0.235 怎么样？”

#6：ACK：DHCP 服务器说：“好的。192.168.0.235 在接下来的 8 小时内为您保留。如果您想继续保留该地址，请务必在此时间之前请求续订。否则，我可能会将该地址提供给其他人。”

所以这证明了我们通过 REQUEST 步骤获得的另一个好处。

现在，由于 REQUEST 是设计的一部分，该步骤实际上是电子对话的必需部分。

DISCOVER 和 OFFER 以及关于计划的基本对话。REQUEST 是获得承诺的实际尝试。在做出 ACK 之前，实际上什么都不会承诺。DHCP 服务器可以合法地向多台机器提供相同的地址，只要它只确认将地址分配给一台机器即可。（我并不是说 DHCP 服务器这样做有充分的理由。我只是说协议/标准允许这样做而不会导致 IP 地址冲突。）客户端在获得确认之前不允许使用该地址，而确认仅在 REQUEST 之后出现。DHCP 服务器不会在 REQUEST 之前发送确认，因为典型的 DHCP 客户端在发送 REQUEST 之后才会准备好确认，因此典型的 DHCP 客户端会忽略并错过意外的确认。

相关内容