☰

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 回覆了一個請求，它同意了該請求，因為該位址在其範圍內並且可用。

Server2 和 Server3 從未收到請求，因此它們不會指派它們提供的 IP，從而使它們仍然可用。如果您沒有額外的請求步驟，則一個客戶端將耗盡 3 個 IP 位址，而不是 1 個。

答案2

客戶還沒有租約並正在要求租約，因此稱為「請求」。它要求簽發、驗證或延長租約。

答案3

第三步是「我（客戶端）想使用你（伺服器）的IP」。由於下一步是伺服器確認或不確認，因此伺服器必須確認接受聽起來很愚蠢。

答案4

我很喜歡韋斯·賽義德的回答。多個 DHCP 伺服器可能是該請求有用的原因之一。

還有另一個原因：嘗試重新使用與以前相同的地址。

該請求是請求使用該位址的許可。發現、提供、請求、確認有時稱為 DORA。

#1：DISCOVER：客戶端向網路（透過廣播訊息）請求 DHCP 伺服器

#2：OFFER：DHCP伺服器回應，並提供潛在的位址

#3：請求：最終用戶機器/設備向伺服器發送請求，請求 DHCP 伺服器為該設備分配/保留/使用所請求的位址

#4：ACKnowledge：如果回應是ACKnowledge，而不是NACK（否定確認），則認為請求已被授予。

這是棘手的部分：請求不需要與報價相符。

例如：如果一台筆記型電腦脫離網路一段時間，然後嘗試連接（連接到相同網路或不同的網路），則筆記型電腦可能想要使用相同的位址（如果可能）。這是一個虛構的對話範例：

#1：DISCOVER：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：請求：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 伺服器說：「好吧。在接下來的8 小時內，192.168.0.235 已為您保留。如果您想繼續保留該位址，請務必在該時間之前請求續訂。否則，我可能會放棄這個地址給別人。

這證明了我們透過 REQUEST 步驟獲得的另一個好處。

現在，由於 REQUEST 是設計的一部分，因此該步驟實際上是電子對話的必需部分。

發現和報價以及基本上關於計劃的對話。請求是獲得承諾的實際嘗試。在做出 ACK 之前，實際上不會提交任何內容。 DHCP 伺服器可以合法地向多台電腦提供相同的位址，只要它只確認將位址分配給一台電腦即可。 （我並不是說 DHCP 伺服器有充分的理由這樣做。我只是說協定/標準允許這樣做，而不會導致 IP 位址衝突。）不允許客戶端使用位址，直到獲得確認，該確認僅在請求之後出現。 DHCP 伺服器不會在 REQUEST 之前發送確認，因為典型的 DHCP 用戶端在發送 REQUEST 之前不會準備好確認，因此典型的 DHCP 用戶端會忽略並錯過意外的確認。

相關內容