我們從開始到現(xiàn)在胀葱，用了十一篇小文章討論和解決了網(wǎng)絡(luò)中的基本通信問題。以后的主要任務(wù)笙蒙，是對網(wǎng)絡(luò)進行優(yōu)化：比如讓網(wǎng)絡(luò)在速度抵屿、性能、健壯捅位、安全等多方面進行提升轧葛，比如可以更容易上網(wǎng)，比如讓網(wǎng)管人員工作更輕松艇搀，等等尿扯。當(dāng)然，還可以根據(jù)需要焰雕，給網(wǎng)絡(luò)增加新的功能衷笋。

第一個要優(yōu)化的，就是IP地址矩屁！

IP地址辟宗？這還能怎么優(yōu)化爵赵？

IP地址標(biāo)識了你在網(wǎng)絡(luò)中是誰，別人找你或者你找別人都會用到它泊脐】栈茫可是，在電腦上配置IP地址可不是件容易的事容客，需要你了解IP地址氛悬、掩碼、網(wǎng)關(guān)等知識耘柱。可是咱不能因為不懂這些就不能上網(wǎng)呀棍现，所以得有個解決辦法调煎。

DHCP（Dynamic Host Configuration Protocol，動態(tài)主機配置協(xié)議）就是一個能讓電腦獲得IP地址的協(xié)議己肮。

DHCP是一個應(yīng)用層協(xié)議士袄，分為服務(wù)端和客戶端，基于UDP傳輸谎僻，端口號服務(wù)端使用67娄柳，客戶端使用68。需要IP地址的電腦都可以叫客戶端艘绍。當(dāng)電腦開機后赤拒，可以自動從服務(wù)端獲取所需的IP地址、掩碼诱鞠、網(wǎng)關(guān)等信息挎挖，完全不需要我們參與。

我們來討論下DHCP都干了啥航夺。

客戶端電腦開機后蕉朵，會自動產(chǎn)生一個叫DHCP Discover的報文，寫入自己的MAC地址阳掐，然后交給傳輸層UDP封裝始衅，源端口號填寫68，目的端口號填寫67缭保，向下交給網(wǎng)絡(luò)層IP汛闸。IP封裝時，源IP地址填寫0.0.0.0（客戶電腦還沒有IP地址）艺骂，目的IP地址填寫255.255.255.255（客戶端沒有IP地址蛉拙，并不知道自己在哪個網(wǎng)段，所以無法使用網(wǎng)段廣播地址彻亲。當(dāng)然更不知道DHCP服務(wù)器在哪孕锄，所以只能封裝一個全網(wǎng)廣播地址）吮廉，協(xié)議號填寫17（表示是UDP給下來的。TCP的還記得不畸肆？）宦芦，向下交給鏈路層以太網(wǎng)，以太網(wǎng)封裝時填寫源MAC地址為客戶端電腦的MAC轴脐，目的MAC填寫FFFF-FFFF-FFFF廣播地址调卑，Type填寫0x0800。封裝完成后發(fā)送出去大咱。

服務(wù)端收到后恬涧，記錄Discover報文中的MAC地址，產(chǎn)生一個DHCP Offer報文碴巾，把準(zhǔn)備分配給客戶端的IP地址溯捆、掩碼、網(wǎng)關(guān)厦瓢、租期提揍、客戶端MAC等信息寫在報文中，交給UDP煮仇。UDP封裝源端口號67劳跃，目的端口號68，交給IP浙垫。IP封裝源地址為DHCP服務(wù)器地址刨仑，目的地址為255.255.255.255，協(xié)議號17夹姥，交給以太網(wǎng)贸人。以太網(wǎng)封裝源MAC為服務(wù)器MAC地址，目的地址為FFFF-FFFF-FFFF廣播地址佃声，Type為0x0800艺智。封裝完成后發(fā)送出去。

客戶端收到Offer報文后圾亏，檢查里面的MAC如果是自己的十拣，會封裝一個Request報文發(fā)出去。為什么要發(fā)這個Request呢志鹃？Offer報文里IP信息都有了夭问，客戶端干嘛不直接用，還要Request請求一下呢曹铃？

這是因為缰趋，網(wǎng)絡(luò)中可能存在多臺DHCP服務(wù)器，每臺服務(wù)器收到Discover后，都會預(yù)留一個預(yù)分配地址并寫進Offer發(fā)出去秘血，客戶端可能會收到多份Offer味抖。所以，客戶端發(fā)出Request的目的就是做一個選擇灰粮，只能要一個DHCP服務(wù)器分配的地址仔涩，并把選擇的DHCP服務(wù)器的IP地址寫在Request中，其他服務(wù)器收到Request后粘舟，發(fā)現(xiàn)沒有選擇自己熔脂，就會把剛才準(zhǔn)備分配的IP地址釋放掉。

客戶端一般選擇收到的第一個Offer柑肴。

Request的IP封裝中霞揉，源地址為什么不使用服務(wù)器在Offer中分配的地址，還是使用0.0.0.0呢晰骑？

主要原因是現(xiàn)在還不知道有沒有其他人在使用這個地址适秩。如果網(wǎng)絡(luò)中的地址全是由同一臺DHCP服務(wù)器分配的，不會出現(xiàn)地址沖突些侍。但更多情況下，有很多設(shè)備的IP地址是手工填寫的政模，而這些手工填寫的IP地址岗宣，DHCP服務(wù)器并不知情。

服務(wù)器收到Request報文后淋样，看看里面的MAC地址之前有沒有記錄過耗式，如果有，則把客戶端MAC寫進DHCP ACK報文趁猴，封裝后發(fā)出去刊咳。ACK報文內(nèi)容和封裝與Offer報文基本相同。如果沒有儡司，則把這個Request報文中攜帶的客戶端MAC封裝進一個NAK消息中發(fā)出娱挨，通知這個客戶端無法給它分配地址（意思是服務(wù)器沒有收到這個客戶端的Discover，直接收到了它的Request捕犬。如果收到Discover肯定有記錄）跷坝。客戶端收到NAK后會重新發(fā)出Discover申請地址碉碉。

客戶端收到ACK報文后柴钻，封裝一個免費ARP報文，Sender IP和Target IP都填寫為服務(wù)器分配的IP地址（在服務(wù)器發(fā)的Offer和ACK報文中都有）發(fā)出去垢粮，檢查此地址是否可用贴届。如果收到ARP Reply回復(fù)，則表示此地址已被使用，客戶端則封裝一個DHCP Decline報文發(fā)給服務(wù)器毫蚓，告訴服務(wù)器禁用這個地址占键，然后發(fā)出Discover重新開始地址申請。若客戶端沒有收到ARP Reply绍些，表示此地址可用捞慌，開始使用這個地址并開始計算租期。

我們可以發(fā)現(xiàn)柬批，客戶端在申請地址過程中啸澡，需要與服務(wù)器進行多次通信，雙方每次通信基本靠“吼”（廣播）氮帐，如果客戶端數(shù)量較多嗅虏，就要考慮大量報文在傳輸中別出岔子。把客戶端MAC地址寫進每個報文中是最好的辦法上沐。不然服務(wù)器說這個Discover誰發(fā)的呀皮服，客戶端說這個Offer是給誰分配的地址呀，如果大家都用第一個Offer参咙，地址不就沖突了嘛龄广。

客戶端在使用地址期間，隨時可以通過DHCP Release報文釋放此地址蕴侧。服務(wù)器收到Release報文后择同，收回該地址重新參與分配。

客戶端使用地址的時間到達(dá)租期的50%時净宵，會封裝DHCP Request報文發(fā)出（對敲才，還是Request，只是這個Request封裝的源IP是客戶端正在使用的IP地址择葡，目的IP是DHCP服務(wù)器的IP地址紧武，兩人單播聯(lián)系，小聲耳語敏储，別人聽不到）阻星，服務(wù)器收到后，回復(fù)DHCP ACK報文已添。如果客戶端收到這個ACK報文迫横，則重新計算租期，否則繼續(xù)使用這個地址酝碳。

當(dāng)客戶端使用地址的時間到達(dá)租期的87.5%時矾踱，再次封裝DHCP Request報文發(fā)出（這個Request跟50%那次有點不同，目的地址不是DHCP服務(wù)器的IP地址而是255.255.255.255廣播地址疏哗。因為上次單播時服務(wù)器沒有理我呛讲，沒辦法只好再次使出“獅吼功”），服務(wù)器收到后，回復(fù)DHCP ACK報文贝搁。如果客戶端收到ACK吗氏，重新計算租期，否則依然繼續(xù)使用這個地址雷逆。

當(dāng)客戶端使用地址的時間到達(dá)租期弦讽，則封裝DHCP Release釋放此地址，重新開始新的地址申請過程（“吼”了也沒人理我膀哲，算了這個地址我不要了往产，重新申請去）。

我們舉個栗子：假如地址租期為24小時（一般默認(rèn)是這個時間）某宪》麓澹客戶端使用地址12小時，小聲單播發(fā)出DHCP Request報文兴喂，如果收到服務(wù)器的ACK報文蔼囊，則重新計時。否則繼續(xù)使用但不重新計時衣迷。使用到21小時畏鼓，大聲吼出Request報文，如果收到ACK壶谒，租期重新計算云矫，否則繼續(xù)使用但不重新計時。使用到24小時佃迄，客戶端發(fā)出Release釋放這個地址不要了泼差，重新發(fā)Discover申請地址贵少。

我們發(fā)現(xiàn)呵俏，雖然UDP協(xié)議不可靠，但DHCP已有應(yīng)對辦法滔灶。關(guān)鍵是普碎，因為客戶端沒有IP地址，根本無法使用TCP去建立連接录平。所以麻车，UDP協(xié)議在很多場合下非常有用，并沒有因為它不可靠而顯得不堪斗这。通常动猬，應(yīng)用程序使用UDP作傳輸協(xié)議時，都已經(jīng)解決了它不可靠的問題表箭。

小Q：地址申請過程中的Discover赁咙、Offer、Request和ACK都被IP和以太網(wǎng)封裝成了廣播，那么彼水，如果服務(wù)器和客戶端不在同一個網(wǎng)段怎么辦崔拥？

歡迎留言討論。