動態主機設定協議（英語：dynamic host configuration protocol1. 客戶端尋找 server dhcp discover
當 dhcp 客戶端第一次登入網路的時候，也就是客戶發現本機上沒有任何 ip 資料設定，它會向網路發出乙個 dhcp discover 封包。因為客戶端還不知道自己屬於哪乙個網路，所以封包的**位址會為 0.0
.0.0 ，而目的位址則為 255.255
.255
.255 ，然後再附上 dhcp discover 的資訊，向網路進行廣播。 在 windows 的預設情形下，dhcp discover 的等待時間預設為 1 秒，也就是當客戶端將第乙個 dhcp discover 封包送出去之後，在 1 秒之內沒有得到響應的話，就會進行第二次 dhcp discover 廣播。若一直得不到響應的情況下，客戶端一共會有四次 dhcp discover 廣播(包括第一次在內)，除了第一次會等待 1 秒之外，其餘三次的等待時間分別是 9、13、16 秒。如果都沒有得到 dhcp 伺服器的響應，客戶端則會顯示錯誤資訊，宣告 dhcp discover 的失敗。之後，基於使用者的選擇，系統會繼續在 5 分鐘之後再重複一次 dhcp discover 的過程。
2. 伺服器提供 ip 租用位址 dhcp offer
當 dhcp 伺服器監聽到客戶端發出的 dhcp discover 廣播後，它會從那些還沒有租出的位址範圍內，選擇最前面的空置 ip ，連同其它 tcp/ip 設定，響應給客戶端乙個 dhcp offer 封包。 由於客戶端在開始的時候還沒有 ip 位址，所以在其 dhcp discover 封包內會帶有其 mac 位址資訊，並且有乙個 xid 編號來辨別該封包，dhcp 伺服器響應的 dhcp offer 封包則會根據這些資料傳遞給要求租約的客戶。根據伺服器端的設定，dhcp offer 封包會包含乙個租約期限的資訊。
3. 客戶端 接受 ip 租約 arp 及 dhcp request
(接受) 或者 arp 及 dhcp declient
(拒絕)
如果客戶端收到網路上多台 dhcp 伺服器的響應，只會挑選其中乙個 dhcp offer 而已(通常是最先抵達的那個)，並且會向網路傳送乙個dhcp request廣播封包，告訴所有 dhcp 伺服器它將指定接受哪一台伺服器提供的 ip 位址。 同時，客戶端還會向網路傳送乙個 arp 封包，查詢網路上面有沒有其它機器使用該 ip 位址；如果發現該 ip 已經被占用，客戶端則會送出乙個 dhcpdeclient 封包給 dhcp 伺服器，拒絕接受其 dhcp offer ，並重新傳送 dhcp discover 資訊。 事實上，並不是所有 dhcp 客戶端都會無條件接受 dhcp 伺服器的 offer ，尤其這些主機安裝有其它 tcp/ip 相關的客戶軟體。客戶端也可以用 dhcp request 向伺服器提出 dhcp 選擇，而這些選擇會以不同的號碼填寫在 dhcp option field 裡面。
換一句話說，在 dhcp 伺服器上面的設定，未必是客戶端全都接受。客戶端可以保留自己的一些 tcp/ip 設定，並且主動權永遠在客戶端這邊。
4. 伺服器 確認 租約確認 dhcp ack
當 dhcp 伺服器接收到客戶端的 dhcp request 之後，會向客戶端發出乙個 dhcpack 響應，以確認 ip 租約的正式生效，也就結束了乙個完整的 dhcp 工作過程。
dhcp 發放流程第一次登入之後：
要是您想退租，可以隨時送出 dhcprelease 命令解約，就算您的租約在前一秒鐘才獲得的。
一旦 dhcp 客戶端成功地從伺服器**取得 dhcp 租約之後，除非其租約已經失效並且 ip 位址也重新設定回 0.0
.0.0 ，否則就無需再傳送 dhcp discover 資訊.
而會直接使用已經租用到的 ip 位址向之前之 dhcp 伺服器發出 dhcp request 資訊，dhcp 伺服器會盡量讓客戶端使用原來的 ip 位址，如果沒問題的話，直接響應 dhcpack 來確認則可。
如果該位址已經失效或已經被其它機器使用了，伺服器則會響應乙個 dhcpnack 封包給客戶端，要求其重新執行 dhcp discover。 至於 ip 的租約期限卻是非常考究的，並非如我們租房子那樣簡單， 以 nt 為例子：
dhcp 客戶端除了在開機的時候發出 dhcp request 請求之外，在租約期限一半的時候也會發出 dhcp request ，如果此時得不到 dhcp 伺服器的確認的話，客戶端還可以繼續使用該 ip ；當租約期過了87.5
%時，如果客戶端仍然無法與當初的dhcp伺服器聯絡上，它將與其它dhcp伺服器通訊。如果網路上再沒有任何dhcp伺服器在執行時，該客戶端必須停止使用該ip位址，並從傳送乙個dhcpdiscover資料報開始，再一次重複整個過程。
src/core/ipv4/dhcp.c
dhcp_start
(struct netif *netif)
dhcp_inc_pcb_refcount
udp_recv
(dhcp_pcb, dhcp_recv,
null);
dhcp_discover // 廣播
dhcp_recv
dhcp_ack :
dhcp_handle_ack
(netif, msg_in)
;dhcp_check
(netif)
;// 為什麼在dhcp 流程完成了之後採取 check? // 且 這次check 是在 (ip,mac) 表中 check.
etharp_query
(netif,
&dhcp->offered_ip_addr,
null);
dhcp_nak :
dhcp_handle_nak
(netif)
; dhcp_offer :
dhcp_handle_offer
(netif, msg_in)
;// 這裡面要處理接受
dhcp_select
(netif)
;//
udp_sendto_if_src
(dhcp_pcb, p_out, ip_addr_broadcast, lwip_iana_port_dhcp_server, netif, ip4_addr_any)
;// /* send broadcast to any dhcp server */
dhcp_arp_reply // 在第二層處理不接受,這個不接受是啥?
dhcp_decline
udp_sendto_if_src
(dhcp_pcb, p_out, ip_addr_broadcast, lwip_iana_port_dhcp_server, netif, ip4_addr_any)
;
LWIP 接收資料從網絡卡到應用層完整流程（未完成）
這裡解釋下從網絡卡phy到ip層的資料接收流程 這裡是以函式呼叫方式來體現 netif add ethernetif init low level init ethernetif input low level input和tcpip input ethernet input ip4 input e...
表示層 應用層
表示層 功能 為異種機通訊提供一種公共語言，以便能進行互操作。這種型別的服務之所以需要，是因為不同的計算機體系結構使用的資料表示法不同。例如，ibm主機使用ebcdic編碼，而大部分pc機使用的是ascii碼。在這種情況下，便需要表示層來完成這種轉換。應用層 包含了通常要使用的協議 http協議 超...
應用層協議
應用層協議定義了執行在不同端系統上的應用程式程序如何相互傳遞訊息。特別是定義了 交換的訊息型別，如請求訊息和響應訊息。各種訊息型別的語法，如訊息中的各個字段及其詳細描述。欄位的語義，即包含在字段中的資訊的含義。程序何時 如何傳送訊息及對訊息進行響應的規則。有些應用層協議是由rfc文件定義的，因此它們...