網絡模型
七層網絡模型
層數 | 名稱 | 功能 | 傳輸單位 | 舉例 |
---|---|---|---|---|
7 | 應用層 | 提供應用程序間通信 | 程序級數據 | FTP、HTTP、SMTP |
6 | 表示層 | 處理數據格式、數據加密等 | 程序級數據 | 編碼、URL傳輸 |
5 | 會話層 | 建立、維護和管理會話 | 程序級數據 | session認證、斷點續傳 |
4 | 傳輸層 | 建立端到端的連接 | 數據段 segment | 進程、端口 |
3 | 網絡層 | 尋址和路由選擇 | 數據包 packet | 路由器、防火牆 |
2 | 數據鏈路層 | 提供介質訪問、鏈路管理 | 幀 frame | 網卡、交換機 |
1 | 物理層 | 比特流傳輸 | 比特 bit | 網線 |
五層網絡模型
層數 | 名稱 | 功能 | 傳輸單位 | 舉例 |
5 | 應用層 | 提供應用程序間的通信、確定進程之間通信的性質。 | 程序級數據 | HTTP、SMTP |
4 | 運輸層 | 負責主機間不同進程的通信 | 數據段 | TCP、UDP |
3 | 網絡層 | 負責分組交換網絡中不同主機間的通信 | 數據報 | IP |
2 | 數據鏈路層 | 負責將網絡層IP數據報組裝成幀 | 幀 | 網卡、交換機 |
1 | 物理層 | 透明地傳輸比特流 | 比特 | 網線 |
四層網絡模型
層數 | 名稱 | 功能 | 應用到的協議 |
4 | 應用層 | 提供應用程序間的通信。 | FTP、DNS、HTTP、SMTP |
3 | 傳輸層 | 提供兩種端到端的通信服務 | TCP、UDP |
2 | 網間層 | 負責數據的包裝、尋址和路由,同時還提供網絡診斷信息 | TCMP、IP |
1 | 網絡接口層 | 提供TCP/IP協議的數據結構和實際物理硬件之間的接口。 | ARP、RARP |
TCP頭部:
名稱 | 功能 |
port number 端口號 |
16位,source port 源端口號表示該報文段來自哪裏,destination port目的端口號表示該報文段傳給哪個上層協議或應用程序。進行TCP通信時,客戶端一般使用系統自動選擇的臨時端口號,而服務端使用知名端口號。 |
32位序號(sequence number) |
一次TCP通信過程中某一個傳輸方向上的字節流的每個字節的編號。序號值被系統初始化爲某個隨機值,後續的TCP報文段中序號值將被系統設置成隨機值加上該報文段所攜帶的數據的第一個字節在整個字節流中的偏移。 |
32位確認號(acknowledgment number) |
用作對另一方發送來的TCP報文段響應。其值是收到的TCP報文段的序號值加1。 |
4位頭部長度(header length) |
標識該TCP頭部有多少個32bit,所以TCP頭部最長是60Byte。 |
6位標誌項 |
URG標誌:表示緊急指針是否有效。ACK標誌:表示確認號是否有效,一般稱攜帶ACK標誌的TCP報文段爲“確認報文段”。PSH標誌:提示接收端應用程序應該立即從TCP接收緩衝區中讀走數據,爲接收後續數據騰出空間。RST標誌:表示要求對方重新建立連接,攜帶RST標誌的TCP報文段稱爲“復位報文段”。SYN標誌:表示請求建立一個連接,攜帶SYN標誌的TCP報文段爲“同步報文段”。FIN標誌:表示通知對方本端要關閉連接了,一般稱攜帶FIN標誌的TCP報文段爲“結束報文段”。 |
16位窗口大小 |
TCP流量控制的一個手段。告訴對方本端TCP接收緩衝區還能容納多少字節的數據,對方便可控制發送數據的速度。 |
16位校驗和 |
由發送端填充,接收端對TCP報文段執行的CRC算法。以檢驗TCP報文段在傳輸過程中是否損壞。這個校驗不僅包括TCP頭部,也包括數據部分。 |
16位緊急指針 |
一個正的偏移量,和序號字段的值相加表示最後一個緊急數據的下一個字節的序號。是發送端向接收端發送緊急數據的方法。 |
總結:
1、TCP的包不包含IP地址,有源端口號和目的端口號。
2、一個TCP連接需要5個元組(源ip、源port、目的ip、目的port、協議)來表示同一個連接。
3、Sequence Number 包的序號,用來解決網絡包亂序問題。
4、Acknowledgement Number ,即ACK 用於確認收到,解決不丟包的問題。
5、Window,即Advertised-Window,滑動窗口,用於流控問題。
6、Tcp Flag,包的類型、用於操控TCP的狀態機。
3次握手4次揮手
網絡上的傳輸是沒有連接的,TCP也一樣,所謂的“連接”,其實只是在通信的雙方維護一個“連接狀態”。
3次握手:
1、第一次握手:建立連接,客戶端發送SYN包到服務器,等待服務器確認。
2、第二次握手:服務器收到SYN包,發送確認包ACK,同時發送自己的SYN包到客戶端。
3、第三次握手:客戶端收到服務器的SYN包,向服務端發送確認包ACK。
三次握手完成,客戶端和服務器進入ESTABLISHED狀態。3次握手建立連接,主要是初始化Sequence Number的初始值,通信雙方要互相通知對方自己的初始化Sequence Number值,這個序號作爲以後的數據通信的序號,以保證應用層接收到的數據不會因爲網絡上的傳輸問題而亂序(TCP會用這個序號來拼接數據)。
4次揮手:
TCP的連接時全雙工(同時發送和接收),因此在關閉連接的時候,必須關閉兩個方向上的連接。
1、第一次揮手:客戶端發送FIN包,關閉連接。
2、第二次揮手:服務端收到客戶端的FIN包,發送ACK包。
3、第三次揮手:服務端發送FIN包,關閉連接。
4、第四次揮手:客戶端收到服務端的FIN包,發送ACK包。
四次揮手完成,TCP連接斷開。TCP是全雙工的,發送方和接收方都需要FIN包和ACK包。只不過,有一方是被動的,所以看上去就成了4次揮手。如果兩邊同時斷連接,則就會進入到CLOSING狀態,然後到達TIME_WAIT狀態。
TCP狀態流轉圖
1、CLOSED:初始化狀態。
2、LISTEN:服務端的某個socket處於監聽狀態,可以接受連接。
3、SYN_SENT:在服務端監聽後,客戶端scoket執行CONNECT連接時,客戶端發送SYN報文,此時客戶端就進入SYN_SENT狀態,等待服務端的確認。
4、SYN_RCVD:表示服務端接受到SYN報文,在正常情況下,這個狀態是服務端在建立TCP連接時的3次握手會話過程中的一箇中間狀態。
5、ESTABLISHED:表示連接已經建立了。
6、FIN_WAIT_1:其中一方請求終止連接,等待對方的FIN報文,就進入此狀態。
7、FIN_WAIT_2:在此狀態下的socket表示半連接,即有一方要求關閉連接,但另外一方數據爲傳輸完畢,待稍後關閉連接。
8、TIME_WAIT:表示收到了對方的FIN報文,併發送了ACK包,等2MSL後回到CLOSED狀態。
9、CLOSING:表示發送了FIN報文後,並沒有收到對方的ACK報文,而是收到了對方的FIN報文。
10、CLOSE_WAIT:表示在等待關閉。此狀態下考慮的是檢查是否已將全部數據發送給對方。
11、LAST_ACK:被動關閉一方發送FIN報文後,等待對方的ACK報文。
2MSL等待: 在上圖裏有一個TIME_WAIT等待狀態,這個狀態又叫2MSL狀態。說的是在TIME_WAIT2發送了最後一個ACK數據報以後,要進入TIME_WAIT狀態。防止最後一次握手的數據沒有傳送到對方那裏而準備的(這不是4次握手,是第4次握手的保險狀態)。這個狀態很大程度上保證了雙發都可以正常結束。由於socket的2MSL狀態,使得應用程序在2MSL時間內無法再次使用同一個socket。故爲了避免這個錯誤,服務器給出了一個平靜時間概念,即服務器要平靜的等待2MSL的時間才能進行下一次連接。
FIN_WAIT_2狀態:著名的半關閉狀態,在關閉連接時,客戶端和服務端兩次握手之後的狀態。在這個狀態下,應用程序還有接收數據的能力,但是已經無法發送數據。
TCP超時重傳
網絡異常情況:
當出現這些異常情況時,TCP就會超時重傳:
TCP每發送一個報文段,就對這個報文段設置一次計時器,只要計時器設置的重傳時間到了,但還沒有收到確認,就要重傳這一報文段。
影響超時重傳機制協議效率的一個關鍵參數是RTO(重傳超時時間)。TCP的底層網絡環境是一個完全異構的互聯結構。在實現端到端的通信時,不同端點之間的傳輸通路的性能可能存在着巨大的差異,而且同一個TCP連接在不同的時間段上,也會由於不同的網絡狀態具有不同的傳輸時延。因爲TCP協議必須適應兩個方面的時延差異,一個是達到不同目的端的時延差異,另一個是統一連接上的傳輸時延對業務量負載的變化而出現的差異。
TCP協議使用自適應算法(Adaptive Retransmission Algorithm)以適應互聯網分組傳輸時延的變化。該算法要點是監視每個連接的性能(即傳輸時延),由每一個TCP的連接情況推算出合適的RTO值。當連接時延性能變化時,TCP也能夠相應地自動修改RTO設定,以適應這種網絡的變化。
RTT(Round Trip Time):連接往返時間,發送端從發送TCP包到接收它的立即響應所耗費的時間。在任何時刻連接的RTT都是隨機的,TCP通過測量來獲得連接當前RTT的一個估計值,並以該RTT估計值爲基準來設置當前的RTO。
自適應算法的關鍵就在於對當前的RTT的準確估計,以便適時調整RTO。
TCP滑動窗口
滑動窗口主要有兩個作用:1、提供TCP的可靠性;2、提供TCP的流控特性
TCP的窗口是一個16bit位字段,代表是窗口的字節容量。標準窗口最大爲2的16次方=65535個字節。另外在TCP的選項字段中還包含了一個TCP窗口擴大因子。用來擴大窗口,可把原來的16bit的窗口,擴大爲32bit。
TCP是雙工的協議,會話的雙方都可以同時接收、發送數據。TCP會話的雙方都各自維護一個“發送窗口”和一個“接收窗口”。各自的“接收窗口”大小取決於應用、系統、硬件的限制。各自的“發送窗口”則要求取決於對端通告的“接收窗口”,要求相同。
滑動窗口實現面向流的可靠性來源於“確認重傳”機制。TCP的滑動窗口的可靠性也是建立在“確認重傳”基礎上的。發送窗口只有收到對端對於本端發送窗口內字節的ACK確認,纔會移動發送窗口的左邊界。接收窗口只有在前面所有的段都確認的情況下才會移動左邊界。前面還有字節未接收但收到後面字節的情況下,窗口不會移動,並不對後續字節確認,一次確保對端會對這些數據重傳。
應用程序在需要(如內存不足時),通過API通知TCP協議棧縮小TCP的接收窗口,然後TCP協議棧在下個時間段發送時包含新的窗口大小通知給對端,對端按通知的窗口來改變發送窗口,以此達到減緩發送速率的目的。
TCP擁塞控制
在某段時間內,若對網絡中某一資源的需求超過了該資源所能提供的可用部分,網絡的性能就會變壞。這種情況就是擁塞。
TCP的擁塞控制由4個核心算法組成:慢開始(Slow Start)、擁塞避免(Congestion Voidance)、快速重傳(Fast Retransmit)、快速恢復(Fast Recovery)。
發送方維持一個擁塞窗口的狀態變量。擁塞窗口的大小取決於網絡的擁塞程度,並在動態變化。
發送方讓自己的發送窗口等於擁塞窗口,但考慮到接收方的接收能力,即發送窗口小於等於擁塞窗口。
慢開始
思路:不要一開始發送大量數據,先探測一下網絡的擁塞程度,即由小到大逐漸增加擁塞窗口的大小。實時擁塞窗口大小是以字節爲單位傳輸數據。
原理:在剛剛開始發送報文段可先將擁塞窗口設置一個最大報文段MSS值,在每收到一個對新報文段確認後,將擁塞窗口增加至多一個MSS數值,當擁塞窗口足夠大時,防止擁塞窗口的增長引起網絡擁塞,引入了慢開始門限ssthresh。
擁塞避免
擁塞避免算法讓擁塞窗口緩慢增長,即每經過一個往返時間RTT就把發送方的擁塞窗口線性增長。
擁塞控制具體過程:
1、TCP連接初始化,設置擁塞窗口初始值。
2、執行慢開始算法,擁塞窗口按指數規律增長,直到達到慢開始門限ssthresh,開始執行擁塞避免算法,擁塞窗口線性增長。
3、當網絡發生擁塞,將慢開始門限ssthresh值更新爲擁塞前的一半,擁塞窗口重新設置爲初始化值,按步驟2執行。
快重傳
快重傳要求接收方在收到一個失序的報文段後就立即發出重複確認(爲的是使發送方及早知道有報文段沒有到達對方),而不要等到自己發送數據時捎帶確認。
快重傳算法規定:發送方只要收到3個重複確認就應當立即重傳對方尚未收到的報文段,無需等待設置的重傳計時器時間到期。
快恢復
快恢復算法有以下兩個要點:
1、當發送方連續收到三個重複確認時,就執行“乘法減小”算法,把ssthresh門限減半。接下來並不執行慢開始算法。
2、考慮到如果網絡出現擁塞的話就不會收到好幾個重複確認,所以發送方現在認爲網絡可能沒有出現擁塞。所以此時不執行慢開始算法,而是將擁塞窗口設置爲慢開始門限ssthresh的大小,執行擁塞避免算法。
總結:TCP擁塞窗口變化的原則是加法增大、乘法減小。