udp協議：

dhcp,dns,QICQ,TFTP

1:DHCP協議
動態主機配置協議，用於實現終端裝置的動態ip資訊分佈，包括IP地址，閘道器地址，dns伺服器等

DHCP協議處在應用層，進行動態ip資訊分佈。
基本原理：
pc和server之間將合計傳送四個dhcp包，主要過程如下
1：pc：discover包

  2：server：offer包

  3：pc：request包

  4：server：ack包

通過抓包軟體可以清楚的看到分發ip地址以及dns伺服器，閘道器的過程，而這一切，都是通過dhcp協議完成的
如下圖所示（值的注意的是，由於快取等原因，我們通常抓取不到前兩個包，但是我們可以解除之前的快取）：
通過如下指令：ipconfig /release

下面我們簡單看一下這些包的結構
1：pc機發送的discover包，包結構如下

可以看到這個discover的包的ip地址是0.0.0.0,這並不奇怪，因為它確實沒有ip地址，所以用這種方式發一個廣播
通過圖二可以看出目標mac地址是255.255.255.255，他傳送了一個廣播包，因為我們的pc機也不知誰是dhcp伺服器
所以乾脆全都發送一遍，這個包稱之為發現包，即discover包

2：當這個區域內的其中一個dhcp接受到這個特殊的廣播包之後，對其進行了反饋，這時候dhcp傳送一個offer包
包結構如下：


可以看到這個offer包不但提供了ip地址，在這個包中還提供了dhcp伺服器ip，路由伺服器ip，以及域名伺服器ip

我們還看上面這個包，第二個包我們觀察到，這是目標地址就被分配到我們的pc機器上，按道理說。這裡我們就可以結束了
這個協議的任務已經完成了，ip地址，dns伺服器，以及閘道器地址都已經分配完成，這個協議的使命不是已經應該完成了？
為什麼還會有接下來的兩個request包以及ack包呢？

有一個很重要的原因，我們觀察到第一步可以知道discover包是通過廣播的形式發出去的，當流入到某個網路區域（含有dhcp伺服器的環境）
的時候，有多個dhcp伺服器接受到了我們pc機器傳送的discover包，那麼他們在地位上是平等的，所以他們應該是都能返回offer響應包，
這些offer包我們的pc機器應該都能接收到，但是我們的pc機器不能把接受的offer包都使用，而且我們的server機器也不能接受你們腳踏幾條船，
所以我們這裡需要一個確認機制，一方面是為了確認使用這個dhcp offer，另一方面也讓dhcp不認為我們是“渣男”！

3：pc機器傳送request包 資料包如下圖所示

這裡我們發現一個搞笑的現象，通過圖二的第三個資料包可以看到，這是pc機器仍然是使用0.0.0.0來發送資料包
而且是通過廣播255.255.255.255的廣播的形式傳送，但是這時我們看圖一中的option50 可以看到，這個request
資料包是攜帶具體的ip地址的。也就是說，這個request包仍然通過廣播的方式來尋找已知的這個dhcp伺服器，來告訴他
我確定要使用你的offer了！
不過可以理解，畢竟pc和伺服器並沒有確定關係，所以直接通過指定的方式來尋找是不是顯得不太紳士，或者是為了更加安全？
emmmm。。。。。。。

4：當我們的dhcp收到攜帶著指定ip的request包的以後，出於禮貌就會發送一個和offer大差不差的ack包，如下圖

至此：dhcp才完成了他的使命，光榮結束了。
可以看出來：
pc端一直通過廣播和使用預設的ip 傳送discover 和request資料包到dhcp伺服器上，這兩個資料包的區別可能
是後者攜帶option 50 的分配的ip用來與dhcp伺服器進行確認

    而dhcp伺服器通過返回offer和ack的兩個相同迴應包的方式作為回覆，兩者都攜帶了dhcp協議要解決的問題答案！