DHCP（Dynamic Host Configuration Protocol,動態主機配置協議）是由IETF(Internet工作任務小組)設計開發的，專門用於為TCP/IP網絡中的計算機自動分配TCP/IP參數的協議

1.1.1 使用DHCP的好處

減少管理員的工作量

避免輸入錯誤的可能

避免IP沖突

提高了IP地址的利用率

方便客戶端的配置

1.1.2 DHCP的分配方式

自動分配 ：分配到一個IP地址後永久使用

手動分配 ：由DHCP服務器管理員專門指定IP地址

動態分配 ：使用完後釋放該IP，供其它客戶機使用

1.1.3 DHCP工作原理

1. 客戶機請求IP

當一個DHCP客戶機啟動時，客戶機還沒有IP地址，所以客戶機要通過DHCP獲取一個合法的地址。此時DHCP客戶機以廣播方式（因為DHCP服務器的IP地址對客戶機來說是未知的）發送DHCP Discover發現信息來尋找DHCP服務器。廣播信息中包含DHCP客戶機的MAC地址和計算機名，以便DHCP服務器確定是哪個客戶機發送的請求。

2. 服務器響應

當DHCP服務器接收到來自客戶機請求IP地址的信息時，它就在自己的IP地址池中查找是否有合法的IP地址提供給客戶機，如果有，DHCP服務器就將此IP地址做上標記，加入到DHCP Offer的消息中，然後DHCP服務器就廣播一則包含下列信息的DHCP Offer消息。

3. 客戶機選擇IP

DHCP客戶機從接收到的第一個DHCP Offer消息中提取IP地址，發出IP地址的DHCP服務器將該地址保留，這樣該地址就不能提供給另一個DHCP客戶機。當客戶機從第一個DHCP服務器接收DHCP Offer消息並提取了IP地址後，客戶機將DHCP Request消息廣播到所有的DHCP服務器，表明它接受提供的內容，DHCP Request消息包括為客戶機提供IP配置的服務器的服務標示符（服務器IP地址），DHCP服務器查看服務器標識符字段，以確定提供的IP地址是否被接受，如果DHCP Offer被拒絕，則DHCP服務器將會取消並保留其IP地址以提供給下一個IP租約的請求。

4. 服務器確定租約

DHCP服務器接收到DHCP Request消息後，以DHCP ACK消息的形式向客戶機廣播成功的確認。該消息包含有IP地址的有效租約和其他可配置的信息，雖然服務器確認了客戶機的租約請求，但是客戶機還沒有接收到服務器的DHCP ACK消息。當客戶機收到DHCP ACK消息時，它就配置了IP地址，完成TCP/IP的初始化。

5. 重新登錄

DHCP客戶機每次重新登錄網絡時，不需要再發送DHCP Discover信息，而是直接發送包含前一次所分配的IP地址的DHCP Request請求信息。當DHCP服務器接收到這一信息後，它會嘗試讓DHCP客戶機繼續使用原來的IP地址，並回答一個DHCP ACK確認信息。如果此IP地址已無法再分配給原來的DHCP客戶機使用時（比如IP已經分配給其他的DHCP客戶機使用），DHCP服務器給DHCP客戶機回答一個DHCP Nack否認信息。當原來的DHCP客戶機收到此DHCP Nack否認信息後，它就必須重新發送DHCP Discover發現信息來請求新的IP地址。

（1）發送帶有IP地址的DHCP Request請求包

（2）IP地址沒有分配使用，發送DHCP ACK確認信息

客戶端繼續使用重啟前的IP地址

（3）IP地址分配到其他客戶機使用

發送DHCP Nack否認信息

客戶機重新發送DHCP Discover

6. 更新租約

IP地址的租期達到50%後，須重新更新租期

客戶端直接向服務器發送DHCP Request包

第2章 傳輸層的兩種協議（TCP和UDP）

傳輸層=====>主機到主機層

2.1 TCP：傳輸控制協議 ---屬於面向連接的網絡協議---同步（安全 效率低）

TCP協議特點：屬於面向連接的網絡協議

同步 （提供全雙工服務，即數據可在同一時間雙向傳輸）

安全，可靠傳輸 ，傳輸速度慢，效率低

使用TCP的應用：web瀏覽器；電子郵件；文件傳輸程序

2.2 UDP: 用戶報文協議---屬於無連接的網絡協議-----異步（不安全 效率高）

UDP協議特點： 屬於無連接的網絡協議

異步

不安全，速度傳輸快

盡力而為，不管你是否收到

使用UDP的應用：DNS，視頻流，IP語音（VoIP）

2.2.1 端口號計算

可用端口：2的16次方=65536 0號端口不會用到，所以是1-65535

1-65535（涉及到一些著名的端口號1-1024 ）

註：著名端口號範圍1-1024，自定義端口的時候不要使用（避免沖突）

隨機端口號默認範圍區間：

源端口隨機端口號分配，取決於這個配置文件

第3章 TCP三次握手/四次揮手

3.1 TCP報頭

1. 源端口號：發送端的端口號（隨機）

2. 目的端口號：接收端的端口號（固定）

3. 確認號的概念：服務端接受到拆分後的數據包。進行確認，告知下一次發送的數據包序列號信息

4. TCP報文重要控制位：

1）syn：請求建立連接

2）fin：請求斷開連接

3）ack：確認控制字段，表示接收的數據進行確認（從而實現了TCP協議的可靠性）

3.2 三次握手

3.2.1 第一次

由主機A發送建立TCP連接的請求報文，其中報文中包含seq序列號，是由發送端隨機生成的，並且還將報文中SYN字段置為1，表示需要建立TCP連接請求

3.2.2 第二次

主機B會回復A發送的TCP連接請求報文，其中包含seq序列號，也是由回復端隨機生成的，並且將回復報文的SYN字段置1，而且會產生ACK驗證字段，ACK驗證字段數值是在A發過來的seq序列號基礎上加1進行回復；並且還會回復ack確認控制字段，以便A收到信息時，知曉自己的TCP建立請求已得到了確認。

3.2.3 第三次

A端收到B端發送的TCP建立請求後，會使自己的原有序列號加1進行再次發送序列號，並且再次回復ACK驗證請求，在B端發送過來的seq基礎上加1，進行回復；同時也會回復ack確認控制字段，

以便B收到信息時，知曉自己的TCP建立請求已經得到了確認

數據傳輸過程中：每發送一次數據，都會產的ACK（表示收到了對方seq對應的信息），ack（表示確認收到），seq（請求序列號）

3.3 四次揮手

3.3.1 第一次揮手

主機A發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。

3.3.2 第二次揮手

主機B收到FIN後，發送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN占用一個序號），Server進入CLOSE_WAIT狀態。

3.3.3 第三次揮手

主機B發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。

3.3.4 第四次揮手

A端收到FIN後，Client進入TIME_WAIT狀態，接著發送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成四次揮手

3.4 總結

運維網絡基礎（二）