DICP協議采用客戶端-服務器方式進行交互，其報文格式共有8種，由報文中“ DHCP message
0pe”字段的值來確定，后面括號中的值即為相應類型的值，具體含義如下
1、 DHCP Discover報文，是客戶端開始DHCP過程的第一個報文。
2. DHCP Ofer報文，是服務器對DHCP_ Discover報文的響應
3. DHCP Request報文，是客戶端開始DHCP過程中對服務器的 DHCP Ofer報文的回應，
或者是客戶端續延P地址租期時發出的報文
4. DHCP Decline報文，是當客戶端發現服務器分配給他的IP地址無法使用，如P地址沖
突時，將發出此報文，通知服務器禁止使用P地址
5. DHCP Ack報文，是服務器對客戶端的 DHCP Request報文的確認響應報文，客戶端收
到此報文后，才真正獲得了IP地址和相關的配置信息
6. DHCP Nack報文，是服務器對客戶端的 DHCP Request報文的拒絕響應報文，客戶端收
到此報文后，一般會重新開始新的DHCP過程
7. DHCP Release報文，是客戶端主動釋放服務器分配給他的1P地址的報文，當服務器收
到此報文后，就可以回收這個IP地址，能夠分配給其他的客戶端。
8. DHCP Inform報文，是客戶端已經獲得了IP地址，發送此報文，只是為了從DHCP服
務器處獲取其他的一些網絡配置信息，如DNS等，這種報文的應用報文非常少見
由於DHCP協議是初始化協議，簡單的說，就是讓終端獲取P地址的協議。既然終端連IP
地址都沒有，何以能夠發出IP報文呢?服務器給客戶端回送的報文該怎么封裝呢?為了解決
這個問題，DHCP報文的封裝采取了如下措施
1.首先鏈路層的封裝必須是廣播形式，既讓在同一物理子網中的所有主機都能夠收到這個
報文。在以太網中，就是目的MAC為全1
2.由於終端沒有IP地址，IP頭中的源P規定填為0.0.0.0
3.當終端發出DHCP請求報文，它並不知道DHCP服務器的IP地址，因此IP頭中的目的
IP填為子網廣播1P--255.255255255，以保證DHCP服務器不丟棄這個報文。
4.上面的措施保證了DHCP服務器能夠收到終端的請求報文，但僅憑鏈路層和P層信息，
DHCP服務器無法區分出DHCP報文，因此終端發出的DHCP請求報文的UDP層中源
端口為68，目的端口為67。即DHCP服務器通過知名端口號67來判斷一個報文是否是
DHCP報文。
5.DHCP服務器發給終端的響應報文將會根據DHCP報文中的內容決定是廠廣播還是單播，
般都是廣播形式。廣播封裝時，鏈路層的封裝必須是廣播形式，在以太網中，就是目
的MAC為全1，IP頭中的目的IP為廣播1P--25525255:255
單播封裝時，鏈路層
的封裝時單播形式，在以太網中，就是目的MAC為終端的網卡MAC地址。P頭中的
目的P填為有限的子網廣播P-2552525255或者是即將分配給用戶的P地址(當
終端能夠接收這樣的IP報文時)。兩種封裝方式中UDP層都是相同的，源端口為67，
目的端口為68。終端通過知名端口號68來判斷一個報文是否是DHCP服務器的響應報
文