1.1 DHCP協(xié)議
DHCP（Dynamic Host Configuration Protocol,動態(tài)主機(jī)配置協(xié)議）是由IETF(Internet工作任務(wù)小組)設(shè)計開發(fā)的，專門用于為TCP/IP網(wǎng)絡(luò)中的計算機(jī)自動分配TCP/IP參數(shù)的協(xié)議
1.1.1 使用DHCP的好處
減少管理員的工作量
避免輸入錯誤的可能
避免IP沖突
提高了IP地址的利用率
方便客戶端的配置
1.1.2 DHCP的分配方式
自動分配 ：分配到一個IP地址后永久使用
手動分配 ：由DHCP服務(wù)器管理員專門指定IP地址
動態(tài)分配 ：使用完后釋放該IP，供其它客戶機(jī)使用
1.1.3 DHCP工作原理
1. 客戶機(jī)請求IP
當(dāng)一個DHCP客戶機(jī)啟動時，客戶機(jī)還沒有IP地址，所以客戶機(jī)要通過DHCP獲取一個合法的地址。此時DHCP客戶機(jī)以廣播方式（因為DHCP服務(wù)器的IP地址對客戶機(jī)來說是未知的）發(fā)送DHCP Discover發(fā)現(xiàn)信息來尋找DHCP服務(wù)器。廣播信息中包含DHCP客戶機(jī)的MAC地址和計算機(jī)名，以便DHCP服務(wù)器確定是哪個客戶機(jī)發(fā)送的請求。
2. 服務(wù)器響應(yīng)
當(dāng)DHCP服務(wù)器接收到來自客戶機(jī)請求IP地址的信息時，它就在自己的IP地址池中查找是否有合法的IP地址提供給客戶機(jī)，如果有，DHCP服務(wù)器就將此IP地址做上標(biāo)記，加入到DHCP Offer的消息中，然后DHCP服務(wù)器就廣播一則包含下列信息的DHCP Offer消息。
3. 客戶機(jī)選擇IP
DHCP客戶機(jī)從接收到的第一個DHCP Offer消息中提取IP地址，發(fā)出IP地址的DHCP服務(wù)器將該地址保留，這樣該地址就不能提供給另一個DHCP客戶機(jī)。當(dāng)客戶機(jī)從第一個DHCP服務(wù)器接收DHCP Offer消息并提取了IP地址后，客戶機(jī)將DHCP Request消息廣播到所有的DHCP服務(wù)器，表明它接受提供的內(nèi)容，DHCP Request消息包括為客戶機(jī)提供IP配置的服務(wù)器的服務(wù)標(biāo)示符（服務(wù)器IP地址），DHCP服務(wù)器查看服務(wù)器標(biāo)識符字段，以確定提供的IP地址是否被接受，如果DHCP Offer被拒絕，則DHCP服務(wù)器將會取消并保留其IP地址以提供給下一個IP租約的請求。
4. 服務(wù)器確定租約
DHCP服務(wù)器接收到DHCP Request消息后，以DHCP ACK消息的形式向客戶機(jī)廣播成功的確認(rèn)。該消息包含有IP地址的有效租約和其他可配置的信息，雖然服務(wù)器確認(rèn)了客戶機(jī)的租約請求，但是客戶機(jī)還沒有接收到服務(wù)器的DHCP ACK消息。當(dāng)客戶機(jī)收到DHCP ACK消息時，它就配置了IP地址，完成TCP/IP的初始化。
5. 重新登錄
DHCP客戶機(jī)每次重新登錄網(wǎng)絡(luò)時，不需要再發(fā)送DHCP Discover信息，而是直接發(fā)送包含前一次所分配的IP地址的DHCP Request請求信息。當(dāng)DHCP服務(wù)器接收到這一信息后，它會嘗試讓DHCP客戶機(jī)繼續(xù)使用原來的IP地址，并回答一個DHCP ACK確認(rèn)信息。如果此IP地址已無法再分配給原來的DHCP客戶機(jī)使用時（比如IP已經(jīng)分配給其他的DHCP客戶機(jī)使用），DHCP服務(wù)器給DHCP客戶機(jī)回答一個DHCP Nack否認(rèn)信息。當(dāng)原來的DHCP客戶機(jī)收到此DHCP Nack否認(rèn)信息后，它就必須重新發(fā)送DHCP Discover發(fā)現(xiàn)信息來請求新的IP地址。
（1）發(fā)送帶有IP地址的DHCP Request請求包
（2）IP地址沒有分配使用，發(fā)送DHCP ACK確認(rèn)信息
客戶端繼續(xù)使用重啟前的IP地址
（3）IP地址分配到其他客戶機(jī)使用
發(fā)送DHCP Nack否認(rèn)信息
客戶機(jī)重新發(fā)送DHCP Discover
6. 更新租約
IP地址的租期達(dá)到50%后，須重新更新租期
客戶端直接向服務(wù)器發(fā)送DHCP Request包
第2章 傳輸層的兩種協(xié)議（TCP和UDP）
傳輸層=====>主機(jī)到主機(jī)層
2.1 TCP：傳輸控制協(xié)議 ---屬于面向連接的網(wǎng)絡(luò)協(xié)議---同步（安全 效率低）
TCP協(xié)議特點：屬于面向連接的網(wǎng)絡(luò)協(xié)議
同步 （提供全雙工服務(wù)，即數(shù)據(jù)可在同一時間雙向傳輸）
安全，可靠傳輸 ，傳輸速度慢，效率低
使用TCP的應(yīng)用：web瀏覽器；電子郵件；文件傳輸程序
2.2 UDP: 用戶報文協(xié)議---屬于無連接的網(wǎng)絡(luò)協(xié)議-----異步（不安全 效率高）
UDP協(xié)議特點： 屬于無連接的網(wǎng)絡(luò)協(xié)議
異步
不安全，速度傳輸快
盡力而為，不管你是否收到
使用UDP的應(yīng)用：DNS，視頻流，IP語音（VoIP）
TCP傳輸控制協(xié)議
UDP用戶數(shù)據(jù)報協(xié)議
面向連接
無連接
可靠傳輸（安全）
不可靠傳輸（不安全）
可實現(xiàn)流量控制
盡力而為，盡力傳遞
同步 ，提供全雙工服務(wù)
異步
效率低
效率高
2.2.1 端口號計算
可用端口：2的16次方=65536 0號端口不會用到，所以是1-65535
1-65535（涉及到一些著名的端口號1-1024 ）
注：著名端口號范圍1-1024，自定義端口的時候不要使用（避免沖突）
隨機(jī)端口號默認(rèn)范圍區(qū)間：
[root@wuhuang ~]# cat /proc/sys/net/ipv4/ip_local_port_range
4000 65000
源端口隨機(jī)端口號分配，取決于這個配置文件
第3章 TCP三次握手/四次揮手
3.1 TCP報頭
1. 源端口號：發(fā)送端的端口號（隨機(jī)）
2. 目的端口號：接收端的端口號（固定）
3. 確認(rèn)號的概念：服務(wù)端接受到拆分后的數(shù)據(jù)包。進(jìn)行確認(rèn)，告知下一次發(fā)送的數(shù)據(jù)包序列號信息
4. TCP報文重要控制位：
1）syn：請求建立連接
2）fin：請求斷開連接
3）ack：確認(rèn)控制字段，表示接收的數(shù)據(jù)進(jìn)行確認(rèn)（從而實現(xiàn)了TCP協(xié)議的可靠性）
3.2 三次握手
3.2.1 第一次
由主機(jī)A發(fā)送建立TCP連接的請求報文，其中報文中包含seq序列號，是由發(fā)送端隨機(jī)生成的，并且還將報文中SYN字段置為1，表示需要建立TCP連接請求
3.2.2 第二次
主機(jī)B會回復(fù)A發(fā)送的TCP連接請求報文，其中包含seq序列號，也是由回復(fù)端隨機(jī)生成的，并且將回復(fù)報文的SYN字段置1，而且會產(chǎn)生ACK驗證字段，ACK驗證字段數(shù)值是在A發(fā)過來的seq序列號基礎(chǔ)上加1進(jìn)行回復(fù)；并且還會回復(fù)ack確認(rèn)控制字段，以便A收到信息時，知曉自己的TCP建立請求已得到了確認(rèn)。
3.2.3 第三次
A端收到B端發(fā)送的TCP建立請求后，會使自己的原有序列號加1進(jìn)行再次發(fā)送序列號，并且再次回復(fù)ACK驗證請求，在B端發(fā)送過來的seq基礎(chǔ)上加1，進(jìn)行回復(fù)；同時也會回復(fù)ack確認(rèn)控制字段，
以便B收到信息時，知曉自己的TCP建立請求已經(jīng)得到了確認(rèn)
數(shù)據(jù)傳輸過程中：每發(fā)送一次數(shù)據(jù)，都會產(chǎn)的ACK（表示收到了對方seq對應(yīng)的信息），ack（表示確認(rèn)收到），seq（請求序列號）
3.3 四次揮手
3.3.1 第一次揮手
主機(jī)A發(fā)送一個FIN，用來關(guān)閉Client到Server的數(shù)據(jù)傳送，Client進(jìn)入FIN_WAIT_1狀態(tài)。
3.3.2 第二次揮手
主機(jī)B收到FIN后，發(fā)送一個ACK給Client，確認(rèn)序號為收到序號+1（與SYN相同，一個FIN占用一個序號），Server進(jìn)入CLOSE_WAIT狀態(tài)。
3.3.3 第三次揮手
主機(jī)B發(fā)送一個FIN，用來關(guān)閉Server到Client的數(shù)據(jù)傳送，Server進(jìn)入LAST_ACK狀態(tài)。
3.3.4 第四次揮手
A端收到FIN后，Client進(jìn)入TIME_WAIT狀態(tài)，接著發(fā)送一個ACK給Server，確認(rèn)序號為收到序號+1，Server進(jìn)入CLOSED狀態(tài)，完成四次揮手
3.4 總結(jié)
