DHCP在設計之初，充分考慮到TCP/IP協議實現的多樣性，具體和DHCP有關的多樣性體現在：TCP/IP協議棧沒有完成IP地址的配置前，是否可以接受單播(Unicast)報文？
有些IP協議棧在完成IP地址的配置前，是可以接收Destination IP = Any 的IP報文，只要該IP報文能夠被硬體網絡卡接收並過濾給IP協議棧。
而有些IP協議棧在完成IP地址的配置前，是不會接收任何單播IP報文的，只會接收廣播IP報文，即Destination IP = 255.255.255.255。
無論是哪種IP協議棧，都是可以接收廣播報文的，對嗎？
DHCP為了增強協議的健壯性(Robustness)，是這樣規定的：
如果協議棧在初始化過程中，不接收單播IP報文，請在DHCP Discovery / Request報文的Flags裡明確告知伺服器，透過設定“BROADCAST flag = 1”，伺服器就使用廣播來和客戶端通訊。
如果協議棧在初始化過程中，可以接收單播IP報文，請在DHCP Discovery / Request報文的Flags裡明確告知伺服器，透過設定“BROADCAST flag = 0”，伺服器就使用單播來和客戶端通訊。
既然廣播方式通訊適合所有的協議棧，統統使用廣播不就ok了，為何要有這個Flags，豈不是多此一舉？
單播最大的優點：通訊是點對點方式，不會影響到廣播域的其它主機。
廣播的特點：通訊是點對所有點的方式，會影響到廣播域裡其它所有主機。
同學們可能沒有充分理解這裡的“影響”二字。
當主機收到廣播報文時，網絡卡會產生一次硬體中斷CPU，CPU會暫停手頭的工作來處理這個中斷，處理完中斷，CPU繼續工作。IP協議棧取走資料，檢查之後和自己無關，丟了。廢了那麼多功夫，最後的報文和自己無關，這不是資源浪費嗎？
如果廣播域裡的廣播報文滿天飛，主機們會疲於處理無關的廣播報文，不僅浪費網路資源，同時也浪費主機的CPU資源。所以在協議的設計中，要儘可能地避免使用廣播。
解釋完為單播和廣播，現在來回答這個問題。
問題一：DHCP Offer為何是單播？
題主的DHCP Discovery 裡設定了“BROADCAST flag = 0”，所以DHCP 伺服器使用單播來發送自己的迴應報文，即DHCP Offer報文，避免打擾其它主機。
問題二：伺服器是透過ARP請求得到客戶端的MAC地址的嗎？
不是，此時客戶端還沒有獲得任何IP地址，客戶端如何迴應ARP呢？這點從圖中可以清晰看出，ARP請求沒有獲得迴應。
是透過下圖中DHCP協議欄位“chaddr”獲得的，chaddr是 “Client Hardware Address”縮寫，客戶端硬體地址，由客戶端填入，通常為網絡卡的MAC地址，這裡chaddr = 7c:04:d0:d6:c6:54。
伺服器端給客戶端分配的IP地址則填充在“yiaddr”(Your IP Address)，這裡yiaddr = 10.0.0.51。
DHCP伺服器有了客戶端的IP、MAC地址，就可以完成整個IP報文的封裝，將DHCP Offer發給客戶端了。客戶端接收一點問題沒有，在四次訊息互動之後，最終完成IP協議棧的配置工作。
DHCP在設計之初，充分考慮到TCP/IP協議實現的多樣性，具體和DHCP有關的多樣性體現在：TCP/IP協議棧沒有完成IP地址的配置前，是否可以接受單播(Unicast)報文？
有些IP協議棧在完成IP地址的配置前，是可以接收Destination IP = Any 的IP報文，只要該IP報文能夠被硬體網絡卡接收並過濾給IP協議棧。
而有些IP協議棧在完成IP地址的配置前，是不會接收任何單播IP報文的，只會接收廣播IP報文，即Destination IP = 255.255.255.255。
無論是哪種IP協議棧，都是可以接收廣播報文的，對嗎？
DHCP為了增強協議的健壯性(Robustness)，是這樣規定的：
如果協議棧在初始化過程中，不接收單播IP報文，請在DHCP Discovery / Request報文的Flags裡明確告知伺服器，透過設定“BROADCAST flag = 1”，伺服器就使用廣播來和客戶端通訊。
如果協議棧在初始化過程中，可以接收單播IP報文，請在DHCP Discovery / Request報文的Flags裡明確告知伺服器，透過設定“BROADCAST flag = 0”，伺服器就使用單播來和客戶端通訊。
既然廣播方式通訊適合所有的協議棧，統統使用廣播不就ok了，為何要有這個Flags，豈不是多此一舉？
單播最大的優點：通訊是點對點方式，不會影響到廣播域的其它主機。
廣播的特點：通訊是點對所有點的方式，會影響到廣播域裡其它所有主機。
同學們可能沒有充分理解這裡的“影響”二字。
當主機收到廣播報文時，網絡卡會產生一次硬體中斷CPU，CPU會暫停手頭的工作來處理這個中斷，處理完中斷，CPU繼續工作。IP協議棧取走資料，檢查之後和自己無關，丟了。廢了那麼多功夫，最後的報文和自己無關，這不是資源浪費嗎？
如果廣播域裡的廣播報文滿天飛，主機們會疲於處理無關的廣播報文，不僅浪費網路資源，同時也浪費主機的CPU資源。所以在協議的設計中，要儘可能地避免使用廣播。
解釋完為單播和廣播，現在來回答這個問題。
問題一：DHCP Offer為何是單播？
題主的DHCP Discovery 裡設定了“BROADCAST flag = 0”，所以DHCP 伺服器使用單播來發送自己的迴應報文，即DHCP Offer報文，避免打擾其它主機。
問題二：伺服器是透過ARP請求得到客戶端的MAC地址的嗎？
不是，此時客戶端還沒有獲得任何IP地址，客戶端如何迴應ARP呢？這點從圖中可以清晰看出，ARP請求沒有獲得迴應。
是透過下圖中DHCP協議欄位“chaddr”獲得的，chaddr是 “Client Hardware Address”縮寫，客戶端硬體地址，由客戶端填入，通常為網絡卡的MAC地址，這裡chaddr = 7c:04:d0:d6:c6:54。
伺服器端給客戶端分配的IP地址則填充在“yiaddr”(Your IP Address)，這裡yiaddr = 10.0.0.51。
DHCP伺服器有了客戶端的IP、MAC地址，就可以完成整個IP報文的封裝，將DHCP Offer發給客戶端了。客戶端接收一點問題沒有，在四次訊息互動之後，最終完成IP協議棧的配置工作。