DHCP，TCP的三次握手和四次揮手

1.1 DHCP協議

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）

TCP傳輸控制協議	UDP用戶數據報協議
面向鏈接	無鏈接
可靠傳輸（安全）	不可靠傳輸（不安全）
可實現流量控制	盡力而爲，盡力傳遞
同步 ，提供全雙工服務	異步
效率低	效率高

2.2.1 端口號計算

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

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

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

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

[root@wuhuang ~]#  cat /proc/sys/net/ipv4/ip_local_port_range 4000 65000

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

第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 總結