計算機網絡筆記之傳輸層知識總結
傳輸層概述:
爲什麼要劃分傳輸層?
既然網絡層已經能把源主機上發出的數據傳送給目的主機,那麼爲什麼還需要加上一個傳輸層呢?這就需要我們理解主機用戶應用層通信的主體,位於兩臺網絡主機中真正的數據通信主體並不是這兩臺主機,而是兩臺主機中的各種網絡應用進程.同一時間一臺主機上可能有多個進程同時運行,這時候就需要爲應用程序提供一個標識,那就是端口.而傳輸層就是爲了提供這種端到端的服務而存在的.下面以一張圖來解釋.
同時從圖中也可以看出來,IP協議提供了主機之間的邏輯通信.而傳輸層協議提供的是進程之間的邏輯通信.
什麼是端到端? 和點對點有啥區別?
"點對點"連接是通信雙方直接通過電纜進行的連接,中間沒有經過其他任何設備.
"端到端"連接是兩個終端主機之間的連接,這兩個終端系統的連接中要經過很多個設備(路由器).
傳輸層兩個重要的術語:TSAP和TPDU
TSAP(傳輸層服務訪問點)是上層(應用層)調用下層(傳輸層)的一個邏輯接口,其實就是我們所說的端口,端口用來標識應用層的進程.
端口:
端口用16位二進制來表示,所以共有65535個端口號.
一般將0~1023號端口分配給一些市面上公用的一些網絡協議或應用,這一類端口號的分配被廣大使用者所接受,事實上成爲了一種標準,稱爲保留端口.
剩下的是一般端口,可以自己使用.
TPDU(傳輸層協議數據單元)指的是傳輸層與對等層之間傳輸的報文,也就是"數據段",其實每一層都有每一層的SAP和PDU.
傳輸層提供的服務:
-
- 邏輯連接的建立
- 傳輸層尋址
- 數據傳輸
- 傳輸連接釋放
- 流量控制
- 擁塞控制
- 多路複用和解複用
- 崩潰恢復
TCP(傳輸控制)協議
TCP協議的特點:
面向連接的傳輸協議:數據傳輸之前必須先建立連接,數據傳輸完成之後,必須釋放連接.
僅支持單播傳輸:每條傳輸連接只能有兩個端點,只能進行點對點的連接,不支持多播和廣播的傳輸方式,UDP是支持的.
提供可靠的交付服務:傳送的數據無差錯,不丟失,不重複,且順序與與源數據一致
傳輸單位是數據段:每次發送的數據段不固定,受應用層傳送報文大小和網絡中的MTU(最大傳輸單元)值大小的影響.最小數據段可能僅有21個字節(其中20個字節屬於TCP頭部,數據部分僅1字節).
支持全雙工傳輸:通信雙方可以同時發數據和接收數據.
TCP連接是基於字節流的:UDP是基於報文流的.
TCP數據報格式:
各字段的具體說明,可以詳見這篇博文,內容很多,不想寫了.http://www.360doc.com/content/12/1218/10/3405077_254718387.shtml
TCP套接字(Socket):
Socket是TCP/IP協議中的叫法,它類似於之前說的TSAP地址,即傳輸層協議接口,爲了區別不同的應用程序進程和連接,一般計算機操作系統都爲應用程序與TCP/IP交互提供了套接字(socket)接口.
注意:Socket與TSAP最大的不同之處就是,TSAP是位於傳輸層的,而Socket是位於應用層的,但它調用了傳輸層的端口.
在應用層上,針對每一個應用進程都有一個Socket,用來調用傳輸層的一個特定端口,Socket與端口和IP地址是多對一的關係.
TCP傳輸連接的建立(3次握手):
TCP傳輸連接的釋放(4次握手):
TCP是如何保證數據可靠性的:
TCP是一個可以保證可靠數據傳輸的傳輸層協議,主要採用採用以下四個機制實現數據可靠性傳輸:
-
- 字節編號機制:TCP數據段以字節爲單位對數據段的"數據"部分進行一一編號,確保每一個字節的數據都可以有序傳送和接收.
- 數據段確認機制:每接收一個數據段都必須有接收端向發送端返回確認數據段,其中的確認號表示已經正確接收的數據段序號.
- 超時重傳機制:TCP中有一個重傳定時器(RTT),發送一個數據段的同時也開啓這個定時器,如果定時器過期之時還沒有返回確認,則定時器停止,重傳該數據.
- 選擇性確認機制:(Selective ACK,SACK)/只重傳缺少部分的數據,不會重傳那些已經正確接收的數據.
TCP的流量控制:
需要進行流量控制的原因就是,數據發送的太快,接收端來不及接收而出現的丟包狀況.流量控制的目的也就是不要讓發送端的發送的數據大於接收端的數據處理能力.
TCP的流量控制通過滑動窗口機制來進行,窗口的大小的單位是字節.
在TCP首部有一個窗口字段(見上圖TCP首部),這個字段的數值就是給對方設置的發送窗口的上限,發送窗口在連接時由雙方商定,但在通信過程中,接收端可以依據自己的資源狀況,動態的調整對方發送窗口的值的大小,達到控制的目的.
假設每個字段大小爲100字節,當前發送窗口大小是400字節,發送端已經發送了400字節的數據,但是僅收到前200個字節的確認信息,還有200個字節沒有發來確認,那麼發送窗口當前時刻還能發送300字節,於是發送窗口前移,整個過程如圖所示.是一個簡單的滑動窗口的情況.
TCP的擁塞控制:
什麼是網絡擁塞呢?我只發圖,不說話.
兩個方案:慢啓動與擁塞避免
"擁塞窗口":是爲了避免發生擁塞而設置的窗口,最終發送的字節數是接收端爲發送端設置的"發送窗口"和"擁塞窗口"的最小值.
"慢啓動閾值"(SSTHRESH):初始值是64k,即65535個字節,當發生一次數據丟失時,其值變爲"擁塞窗口"大小的一半.
慢啓動:
主機剛開始發送報文段時先將擁塞窗口的大小設置爲一個MSS(該連接上當前使用的最大數據段大小).
每收到一個報文段的確認後,將擁塞窗口增加最多一個MSS的大小.
以此類推,用這樣的方法逐步增大發送端擁塞窗口的大小,使分組注入到網絡的速率更加合理.
直到擁塞窗口的值達到慢啓動閾值,這時候"擁塞避免"就發揮作用了.
擁塞避免:
該方案不再像慢啓動一樣以指數速度增長擁塞窗口的大小,而是到達慢啓動閾值後,按線性規律增長,是網絡比較不容易出現擁塞.
以上兩個方案配合使用,可有效減少網絡擁塞的影響,但不能完全避免擁塞情況,後來又提出了"快速重傳"和"快速恢復"機制,基本思想是:
當接收端收到一個不是按3順序到達的數據段時,迅速發送一個重複ACK數據段,再重複收到3個重複的ACK數據段後,即認爲對應"確認號"上的字段已丟失,TCP不等重傳定時器失效,就重傳已丟失的數據,此爲快速重傳,同時快速恢復發揮作用,把當前擁塞窗口大小設置爲當前慢啓動閾值大小的一半,以減輕網絡負荷,然後再執行"擁塞避免"....
UDP協議:
在一些視頻通過,網絡電話中,丟失一部分數據,影響並不大,這時候使用UDP協議傳輸就是一個更好的選擇.
UDP協議的特點:
-
- 無連接性
- 不可靠性
- 以報文爲邊界
- 無流量控制和擁塞控制方案
- 支持但播,組播,廣播等多種通信方式
其他的...就真沒啥好說的了.......