DHCP 協定工作流程

DHCP一共有8種封包，分别為DHCP Discover、DHCP Offer、DHCP Request、DHCP ACK、DHCP NAK、DHCP Release、DHCP Decline、DHCP Inform。各種類型封包的基本功能如下：

DHCP封包類型

說明

DHCP Discover

(廣播)

DHCP用戶端在請求IP位址時并不知道DHCP伺服器的位置，是以DHCP用戶端會在本地網絡内以廣播方式發送Discover請求封包，以發現網絡中的DHCP伺服器。所有收到Discover封包的DHCP伺服器都會發送應答封包，DHCP用戶端據此可以知道網絡中存在的DHCP伺服器的位置。

DHCP Offer

(廣播，單點傳播)

DHCP伺服器收到Discover封包後，就會在所配置的位址池中查找一個合适的IP位址，加上相應的租約期限和其他配置資訊（如網關、DNS伺服器等），構造一個Offer封包，發送給DHCP用戶端，告知使用者本伺服器可以為其提供IP位址。但這個封包隻是告訴DHCP用戶端可以提供IP位址，最終還需要用戶端通過ARP來檢測該IP位址是否重複。

DHCP Request

(廣播，單點傳播)

DHCP用戶端可能會收到很多Offer請求封包，是以必須在這些應答中選擇一個。通常是選擇第一個Offer應答封包的伺服器作為自己的目标伺服器，并向該伺服器發送一個廣播的Request請求封包，通告選擇的伺服器，希望獲得所配置設定的IP位址。另外，DHCP用戶端在成功擷取IP位址後，在位址使用租期達到50%時，會向DHCP伺服器發送單點傳播Request請求封包請求續延租約，如果沒有收到ACK封包，在租期達到87.5%時，會再次發送單點傳播的Request請求封包以請求續延租約。

DHCP ACK

(廣播，單點傳播)

DHCP伺服器收到Request請求封包後，根據Request封包中攜帶的使用者MAC來查找有沒有相應的租約記錄，如果有則發送ACK應答封包，通知使用者可以使用配置設定的IP位址。

DHCP NAK

(廣播，單點傳播)

如果DHCP伺服器收到Request請求封包後，沒有發現有相應的租約記錄或者由于某些原因無法正常配置設定IP位址，則向DHCP用戶端發送NAK應答封包，通知使用者無法配置設定合适的IP位址。

DHCP Release

(單點傳播)

當DHCP用戶端不再需要使用配置設定IP位址時，就會主動向DHCP伺服器發送RELEASE請求封包，告知伺服器使用者不再需要配置設定IP位址，請求DHCP伺服器釋放對應的IP位址。

DHCP Decline

(單點傳播)

DHCP用戶端收到DHCP伺服器ACK應答封包後，通過位址沖突檢測發現伺服器配置設定的位址沖突或者由于其他原因導緻不能使用，則會向DHCP伺服器發送Decline請求封包，通知伺服器所配置設定的IP位址不可用，以期獲得新的IP位址。

DHCP Inform

(單點傳播)

DHCP用戶端如果需要從DHCP伺服器端擷取更為詳細的配置資訊，則向DHCP伺服器發送Inform請求封包；DHCP伺服器在收到該封包後，将根據租約進行查找到相應的配置資訊後，向DHCP用戶端發送ACK應答封包。目前基本上不用了。

1. 發現階段，即DHCP客戶機尋找DHCP伺服器的階段。DHCP客戶機以廣播方式（因為DHCP伺服器的IP位址對于客戶機來說是未知的）發送DHCP discover發現資訊來尋找DHCP伺服器，即向位址255.255.255.255發送特定的廣播資訊。網絡上每一台安裝了TCP/IP協定的主機都會接收到這種廣播資訊，但隻有DHCP伺服器才會做出相應。
2. 提供階段，即DHCP伺服器提供IP位址的階段。在網絡中接收到DHCP discover發現資訊的DHCP伺服器都會做出響應，它從尚未出租的IP位址中挑選一個配置設定DHCP客戶機，向DHCP客戶機發送一個包含出租的IP位址和其他設定的DHCP offer提供資訊。
3. 選擇階段，即DHCP客戶機選擇某台DHCP伺服器提供的IP位址的階段。如果有多台DHCP伺服器向DHCP客戶機發來的DHCP offer提供資訊，則DHCP客戶機隻接受第一個收到的DHCP offer提供資訊，然後它就以廣播方式回答一個DHCP request請求資訊，該資訊中包含向它所標明的DHCP伺服器請求IP位址的内容。之是以要以廣播方式回答，是為了通知所有的DHCP伺服器，他将選擇某台DHCP伺服器所提供的IP位址。
4. 确定階段，即DHCP伺服器确認所提供的IP位址的階段。當DHCP伺服器收到DHCP用戶端回答的DHCP request請求資訊之後，它便向DHCP客戶機發送一個包含它所提供的IP位址和其他設定的DHCP ack确認資訊，告訴DHCP客戶機可以使用它所提供的IP位址。然後DHCP客戶機便将其TCP/IP協定與網卡綁定，另外，除DHCP客戶機選中的伺服器外，其他的DHCP伺服器都将收回曾提供的IP位址。
5. 重新登入。以後DHCP客戶機每次重新登入網絡時，就不需要再發送DHCP discover發現資訊了，而是直接發送包含前一次所配置設定的IP位址的DHCP request請求資訊。當DHCP伺服器收到這一資訊後，它會嘗試讓DHCP客戶機繼續使用原來的IP位址，并回答一個DHCP ack确認資訊。如果此IP位址已無法再配置設定給原來的DHCP客戶機使用時（比如此IP位址已配置設定給其它DHCP客戶機使用），則DHCP伺服器給DHCP客戶機回答一個DHCP nack否認資訊。當原來的DHCP客戶機收到此DHCP nack否認資訊後，它就必須重新發送DHCP discover發現資訊來請求新的IP位址。
6. 更新租約。DHCP伺服器向DHCP客戶機出租IP位址一般都有一個租借期限，期滿後DHCP伺服器變會收回出租的IP位址。如果DHCP客戶機要延長其IP租約，則必須更新其IP租約。DHCP客戶機啟動時和IP租約期限過半時，DHCP客戶機都會自動向DHCP伺服器發送更新其IP租約資訊。

為了便于了解，我們把DHCP客戶機比作餐館裡的客人，DHCP伺服器比作服務員（一個餐館裡也可以有多個服務員），IP位址比作客戶需要的食物。那麼可以這樣描述整個過程：客人走進餐館，問：“有沒有服務員啊？”（DHCP discover），多個服務員同時回答：“有，我這有漢堡”“有，我這有雞翅”（DHCP offer）。客人說：“好吧，我要一份漢堡”（DHCP request， 這個客人比較死闆，總是選擇第一次聽到的食物），端着漢堡的服務員回應了一聲：“來啦”（DHCP ack），并把食物端到客人面前，供其想用（将網卡和IP位址綁定）。客人下次來的時候，就直接找上次那個服務員點自己喜歡的漢堡了（DHCP request），如果還有漢堡，服務員會再次确認并上菜（DHCP ack），而如果已經賣完了，服務員則會告訴客人：“不好意思，已經賣完了”（DHCP nack）。當然，服務員隔一段時間會來收拾一次桌子，除非客人特别說明這菜還要繼續吃的，服務員會将剩菜端走。