1. 程式人生 > >計算機網絡——運輸層

計算機網絡——運輸層

端到端 適合 tcp、udp 判斷 包括 網絡管理 dbase mss log

運輸層位於應用層與網絡層之間,是分層網絡體系結構的重要組成部分。 運輸層協議為運行在不同主機上的應用進程之間提供了邏輯通信,使得在應用進程的角度看,運
行不同進程的主機好像直接相連。應用進程使用運輸層提供的邏輯通信功能彼此發送報文,而無
需考慮這些報文的物理基礎設施的細節。下文主要介紹兩個運輸層協議: UDP 與 TCP,通過比較
它們的異同,來說明它們各自的特點。 以兩臺主機之間通信為例,當我們只討論運輸層時,我們可以看到運輸層在發送端將從應用進程
接收到的報文轉換成運輸層分組(即報文段),再將這些報文段傳遞給網絡層;在接受段,網絡層
從數據報中提取運輸層報文段,並將該報文段交給運輸層,運輸層則處理收到的報文段,使報文
段中的數據為接收端的應用進程使用。 技術分享圖片


在整個過程中,我們應該思考以下這些問題,並且下文將會通過這些問題來介紹運輸層。

1.報文為什麽要轉換為報文段?
2.UDP、TCP的優缺點?
3.采用不同運輸層協議時,報文段的格式有何區別?
4.通過何種機制來實現TCP、UDP各自的功能?
5.UDP、TCP各自適合哪種網絡應用場景?
運輸層的多路復用與多路分解————數據在應用層與運輸層間的傳遞

在敘述數據在應用層與運輸層間的傳遞之前,我們需要先了解什麽是 套接字

套接字SOCKET:它相當於從網絡向進程傳遞數據和從進程向網絡傳遞數據的門戶,在主
機的運輸層中,實際上並沒有直接將數據交付給進程,而是將數據交給了中間的一個套
接字,再通過該套接字將數據交給該套接字對應的進程。任意時刻,每個主機可能有多
個套接字,但每個套接字都有唯一的描述符。

技術分享圖片


多路復用:在源主機從不同套接字中收集數據塊,並為每個數據封裝上首部信息從而生成報
文段,然後將報文段傳遞到網絡層

首部信息:
源端口號字段、目的端口號字段、其他首部字段(具體見下文UDP、TCP報文段結構)

端口號:一個16比特的數,其大小在0-65535之間
具體介紹:https://blog.csdn.net/zuyi532/article/details/7731617

多路分解:將運輸層報文段中的數據交付到正確的套接字
無連接運輸:UDP
UDP只提供了運輸層協議能夠提供的最低限度的功能,除了復用、分解功能及少量的差錯檢
測外它幾乎沒有對IP增加別的東西

UDP作用過程:UDP從應用進程得到數據,附加上用於多路復用、分解所需的源和目
的地端口號字段,以及兩個其他的小字段,然後將形成的報文段交給網絡層。

UDP報文結構:
技術分享圖片

UDP校驗和:用於確定UDP報文段從源到目的地的移動時,其中比特是否發生了改變
具體介紹:www.cnblogs.com/noble/p/4144139.html

UDP為何提供校驗和?

端到端原則:與在較高級別提供某些功能相比,在較低級別上設置的功能可能是
冗余的或幾乎沒有價值。

優點:
1.關於何時、發送哪些數據的應用層控制更為精細
2.無需建立連接,因此UDP沒有建立連接的時延
3.無連接狀態,減少使主機開銷
4.分組首部開銷小

缺點:
1.UDP沒有擁塞控制,可能導致發送方和接收方之間的高丟包率
2.不保證數據傳輸的可靠性(UDP應用可以通過在應用程序自身中建立可靠性機制來完成
可靠的數據傳輸)


面向連接的運輸:TCP TCP特點:
1.面向連接
2.全雙工
3.提供可靠數據傳送
4.擁塞控制

TCP被稱為是面向連接的,這是因為在一個進程可以向另一個進程發送數據之前,這
兩個進程必須向相互“握手”,即相互發送某些預備報文段,以確定數據傳輸的參數。

全雙工:如果一臺主機上的進程A與另一臺主機上的進程B之間存在一條TCP連接,那
麽應用層數據就可以在進程B流向進程A的同時,也從進程A流向進程B

TCP傳輸數據的過程:

一旦建立起一條TCP連接,兩個應用進程之間就可以相互發送數據,進程通過套接字
遞數據流,TCP將這些數據引導進該連接的發送緩存,TCP從發送緩存中取出數據塊發送

TCP可以從緩存中取出並放入報文段中的數據數量受限於最大報文段長度MSS,MSS通常
根據最初確定的由本地發送主機發送的最大鏈路層幀長度(即最大傳輸單元MTU)確定

需要註意的是MSS是指報文段中應用層數據的最大長度而不是指包括TCP首部的TCP報文
段的最大長度
技術分享圖片

TCP連接的建立與終止,在TCP連接終止後,主機中的資源(緩存、變量)都將被釋放

技術分享圖片

技術分享圖片

TCP報文結構:
技術分享圖片

在上圖中,我們可以看到TCP報文首部中兩個最重要的字段是序號字段和確認號字
段,若果主機A向主機B發送一個TCP報文段,主機A填充進報文段的確認號是主機A
期望從主機B收到的下一字節的序號。

TCP的可靠數據傳輸服務確保一個從其接受緩存中讀取的數據流是無損壞、無間隔、
非冗余和按序的數據流,即該字節流與連接的另一端系統發出的字節流時完全相同
那麽TCP如何提供可靠地數據傳送服務?

TCP采用超時/重傳機制來處理報文段的丟失問題,那麽應該如何設置超時時間?
而TCP又是如何知道丟失了哪些報文段?

我們可能會想到,如果我們可以為每一個已發送但未被確認的TCP報文段設置一個
定時器,這樣在判斷超時時就會十分方便,但定時器的管理需要相當大的開銷,因
此TCP在超時管理時僅使用單一的重傳定時器,即使有多個已發送但未被確認的報
文段。TCP發送方維持一個狀態變量SendBase,這是最早已發送未被確認的字節的
序號。

TCP接收方只確認已收到的數據流中至第一個丟失字節為止的字節,所以TCP被稱為
提供累積確認

TCP將ACK的值y與SendBase比較,來確認是否超時。

TCP超時重傳機制具體可參考:https://blog.csdn.net/wdscq1234/article/details/52476231

TCP擁塞控制:

TCP使用端到端擁塞控制,讓每一個發送方根據感知到的網絡擁塞程度來限制其能向
連接發送流量的速率。

1.當TCP發送方出現丟包事件(出現超時或收到接收方的三個冗余ACK)時,發送方就認
為在發送方到接收方的路徑上出現了擁塞指示,此時應當降低減小發送方的速率
2.當對先前未確認報文段的確認到達時,能夠增加發送方的速率

TCP擁塞控制算法:

慢啟動:TCP發送速率起始慢,但在慢啟動階段以指數級增長
擁塞避免:一旦進入擁塞避免狀態,即很快可能擁塞
快速恢復

TCP擁塞控制算法詳述:http://www.cnblogs.com/fll/archive/2008/06/10/1217013.html


UDP、TCP各自的應用場景:

UDP:DNS、遠程文件服務器、網絡管理、多媒體應用

TCP:電子郵件、遠程終端訪問、Web、文件傳輸、多媒體應用
全面了解運輸層及各種運輸層協議,可以閱讀這本書:《Unix網絡編程》,想要了解這本書,
你可以點擊下面的鏈接:https://book.douban.com/subject/1500149/

計算機網絡——運輸層