DHCP、UDP

計算機如何使用IP地址：

源IPv4地址：發送數據的主機上配置的IP地址；

源IPv4的配置方式：

手動配置：直接向網卡的配置文件中添加我們認為合法的IPv4地址；

特點：

地址分配精確；

管理員的重復工作量很大；

容易發生手誤導致主機無法接入網絡；

自動配置：沒有IP地址的計算機，通過特定協議向其他能夠提供IP地址的計算機進行通信，并獲得IPv4地址；

協議：

BOOTP：

啟動協議

利用RARP協議向全網廣播獲取IP地址的需求；BOOTP服務器會從其地址池中選擇一個IPv4地址，永久歸這臺主機使用；

DHCP：

Dynamic Host Configuration Protocol，動態主機配置協議；

地址租借規劃；

每一個地址都有其對應的租約期限；

續租的規則：

當租約期限過去50%時，客戶端聯系服務器進行地址續租；如果續租不成功，客戶端會連續嘗試三次；

當租約期限過去87.5%時，客戶端會放棄IP地址；重新廣播是否有其他服務器能夠讓其繼續使用之前的IP地址；

一直等等租約到期，客戶端IP地址徹底被釋放；客戶端將試圖從其他的服務器獲得其他的IP地址以連接網絡；

DHCP客戶端地址的租借過程——四線會話：

1.客戶端廣播發送DHCP Discover消息，以確定網絡中是否有DHCP服務器能為本機提供IP地址；

2.服務器收到DHCP Discover消息后，會檢查自己的地址池，如果仍然有可用IP地址，就從中選擇一個IP地址，向客戶端廣播發送DHCP Offer消息；

3.客戶端將接收到的第一個DHCP Offer消息中的IP地址作為可選擇IP地址，向網絡中廣播DHCP Request消息，通知服務器，選定這個IP地址作為本次通信的IP地址；

4.提供IP地址的服務器收到DHCP Request消息后，將IP地址和對應主機的物理地址臨時綁定；并且開始租約計時；給客戶端發送DHCP ACK消息；

不是提供該IP地址的服務器收到DHCP Request，將剛剛提供的IP地址重新放入地址池中，并給客戶端發送DHCP NAK消息

目的IP地址如何給出：

手動指定：

直接在地址欄中手動書寫目的主機的IP地址；

自動解析：

DNS協議：Domain Name System

在DNS服務器上，保存著特定的域名和IP地址的映射關系；可以完成地址解析的任務；

地址解析：

正向地址解析：

通過域名獲得其對應的IP地址的過程；

反向地址解析：

通過IP地址反解其域名的過程；

www.baidu.com：完全限定域名(FQDN)

花生殼——DNS緩存服務器

202.99.166.4

202.99.160.68

222.222.222.222

222.222.202.202

TCP/IP協議棧分層結構：

應用層

傳輸層

互聯網層

網絡訪問層(物理層、數據鏈路層)

傳輸層：

OSI第四層：端到端的連接

TCP/IP第三層：

TCP：Transfer Control Protocol，傳輸控制協議；

UDP：User Datagram Protocol，用戶數據報協議；

UDP協議的首部格式：

端口：也稱為邏輯端口，或叫協議端口；它是應用層和傳輸層之間的通信接口；

端口是由16bits二進制構成的數字標識；其范圍為0-65535；

其中：

0：表示全部端口號，不能單獨使用；

1-1023：保留端口號，

1024-64511：動態分配端口，

64512-65535：注冊端口，

ssh：TCP/22

http：TCP/80

https：TCP/443

SMTP：TCP/25

POP3：TCP/110

IMAP：TCP/143

telnet：TCP/22

ftp：TCP/21

DHCP：UDP/67(Server) UDP/68(Client)

DNS：UDP/53 TCP/53

Windows系統中：C:\Windows\System32\drivers\etc\services

Linux類系統中：/etc/services

這類文件中，保存了應用層協議和傳輸層協議之間默認的通信接口映射關系；

源端口：16bits，發送方在封裝數據的時候選擇的端口號；一般來講，客戶端發送的數據的源端口號是隨機選擇的空閑端口；

目的端口：16bits，此次數據通信的接收方在傳輸層向應用層進行數據傳遞時所必須使用的端口號；一般來講，數據的目的端口號是固定的；

注意：

1.一般來講，一次往返通信過程中，兩組數據的端口號會互換；

2.在使用端口時，更加在意目標端口的準確性；如果因為目標端口不明確而導致接收方無法使用正確的應用程序來處理數據，則該數據會直接被傳輸層協議丟棄；

數據長度：16bits，整個UDP數據報的報文長度，包括首部；

數據校驗和：16bits，整個UDP數據報的校驗和，一定程度上保證數據完整性；

回顧：

使用IP地址：

源地址：

目的地址：

UDP協議：

特點：

首部：

傳輸層協議

TCP協議：

TCP特點：

TCP/IP 協議棧的傳輸層

為應用程序訪問的網絡層

面向連接的協議

全雙工模式運行

錯誤檢查

數據包序列化

接收確認

數據恢復功能

TCP協議首部：

源端口號：16bits

目的端口號：16bits

序列號：32bits，序列號的范圍：1 ~ 2^32-2

第一個數據段的序列號為隨機選擇；

第二個數據段的序列號：前一個數據段的序列號+前一個數據段數據部分的大小+1

...

確認號：32bits，確認號的范圍：2 ~ 2^32-1

接收方用來對已經接收到的數據進行確認，并要求發送方繼續傳輸后續數據段的標識；

一般來講，確認號是發送方要發送的下一個數據段的序列號；

首部長度：4bits，24字節 ~ 60字節

保留標志位：3bits，暫時沒有被使用

認證加密標志位：3bits

TCP特性標志位：

URG：緊急指針標志位；如果該標志位置1，該數據的轉發優先級將會被提高，以使得這樣的數據被優先轉發；如果多個數據的URG標志位同時置1，則后面16位的緊急指針越大的，優先級越高；

ACK：與連接管理有關的確認標志位；用來響應主動發起連接的建立請求或拆除請求的那一方；

PSH：推進位，如果該標志位置1，則在接收方可以將該數據不加入緩存隊列，直接交給應用程序進程進行處理；

RST：重置連接標志位；在TCP連接耗盡或者出現故障的時候，重新構建TCP連接的標志位；

SYN：同步標志位，用戶在建立TCP連接的過程中，主動發生連接建立請求的那一方發起連接的信號；

FIN：結束連接標志位，如果該標志位置1，則另一方將知道此次TCP連接將被拆除，予以確認即可；

窗口尺寸：16bits，主要實現流量協商及控制，可以防止網絡擁塞；

滑動窗口：

擁塞窗口：

緊急窗口：

窗口的大小，意味著我們一次可以傳輸的數據段的數量；

數據段校驗和：16bits，保證數據的完整性的校驗信息；

緊急指針：16bits，在URG標志位都置1時，用于區分其優先級；

選項：數據段分段的時間戳

TCP協議的面向連接的特性：

1.連接建立：三次握手

1) 發送方生成一個TCP首部數據，在首部中，源、目的端口由應用層協議給出；序列號為隨機選擇，確認號為0，標志位SYN置1；

2) 接收方收到由發送方發來的SYN請求數據之后，判斷自身能否完成對方所要求的數據通信；如果可以，則返回一個由其生成的TCP首部數據；源、目的端口與之前的數據正好相反；序列號隨機，確認號為對方下一個數據的序列號，SYN和ACK兩個標志位同時置1；

3) 發送方在接收的對方的響應數據之后，檢查其ACK標志位是否置1；如果為1再看SYN標志位是否置1，如果也是1就予以確認；隨即生成第二個TCP首部數據；序列號為前一個數據的序列號+1，確認號為接收方下一個數據的序列號；ACK標志位置1；

2.拆除連接：四次揮手

1) 當所有的數據傳輸結束之后，由一方主動向另一方發送一個FIN標志位置1的TCP首部數據；

2) 另一方收到這樣的FIN標志位置1的數據之后，回應一個ACK標志位置1的確認數據；

3) 另一方主動發出一個FIN標志位置1的TCP首部數據，請求拆除連接；

4) 主動結束方予以確認，發送ACK標志位置1的TCP首部數據；

TCP協議的流量控制特性：

被動流量控制：擁塞窗口

由于收發雙方的網絡資源不均衡或不對等造成的網絡擁塞，導致接收方數據緩沖區溢出，使得大量的數據丟失；由接收方發送一個窗口大小為0的確認數據段給發送方，以暫停發送方的數據發送；

主動流量控制：滑動窗口

每一次雙方互相通信時，都會協商窗口大小，以最小窗口為標準，發送方安裝這樣的窗口大小進行數據發送；

TCP協議的確認特性：

1.在發送方尚未接收到來自于接收方的確認信息之前，不會繼續發生后續數據；

2.如果在一定的超時時間之內，發送方沒有收到接收方發送來的確認信息，發送方會重新傳輸之前發生過的數據；

通過確認特性，能夠保證數據的可靠性傳輸；

數據通信過程描述——雙機互連

1.如果用戶在應用程序中沒有指定目標IP地址，則應用程序會自動向DNS服務器發出查詢請求，以獲得對應的目標主機的IP地址；

2.當前應用程序所需要使用的傳輸層的哪個協議？選擇了TCP進行進一步封裝。

3.傳輸層并不馬上為應用層發送數據，而是由TCP協議自行生成數據段首部，通過三次握手建立TCP連接；

4.IP協議會按照正確的地址和對應格式完成數據封裝，但是網絡訪問層需要通過MAC地址完成數據傳輸，因此需要查詢ARP緩存中是否有對應該IP地址的MAC地址記錄；

5.如果未找到該記錄，TCP三次握手請求，將暫存內存；有ARP協議生成ARP請求數據包，以廣播的方式發送出去；目標主機收到后，會先將源主機的MAC地址緩存下來，然后將自己的IP地址和MAC當作數據封裝并以單播返回源主機；

6.源主機緩存目的主機的MAC地址，而后將TCP三次握手的請求封裝并予以發送；

7.當TCP連接正確建立之后，就可以為應用程序發送數據到目的主機；

8.對于每一批次的TCP報文，目的主機都必須予以確認；

9.當所有數據報文發送完成后，通過四次揮手拆除TCP連接；