1.5運輸層

運輸層為相互通信的應用程序提供邏輯通信
端口和套接字的意義
無連接UDP的特點
面向連接TCP的特點
在不可靠的網絡上實現可靠傳輸的工作原理,停止等待協議和ARQ協議
TCP滑動窗口、流量控制、連接管理

5.1運輸層協議概述

5.1.1運輸層之間的通信

運輸層向它上面的應用層提供通信服務,只有主機協議棧才有運輸層,網絡核心部分中的路由器轉發分組時只有下三層功能。

真正進行通信的實體時在主機中的進程,從運輸層角度看,通信的真正端點并不是主機而是主機中的進程。運輸層有一個很重要的功能-“復用”和“分用”,不用進程使用同一個運輸層協議傳送數據。網絡層為主機之間提供邏輯通信,而運輸層為應用進程之間提供端到端的邏輯通信。

當運輸層采用面向連接的TCP協議時,盡管下面的網絡是不可靠的(best-effort),但這種邏輯信道相當于一條全雙工的可靠信道;采用無連接的UDP協議時,認識不可靠信道。

運輸層對報文進行差錯控制,IP數據報之檢驗首部而不檢驗數據部分差錯。

5.1.2運輸層兩個主要協議

用戶數據報協議UDP User Datagram Protocol

不需要建議連接,收到UDP報文后,不需給出確認。

傳輸控制協議TCP Transmission Control Protocol

TCP提供面向連接服務,要建立連接、釋放連接,TCP不提供廣播多播服務,由于TCP提供可靠的運輸服務,增加了許多開銷,如確認、流量控制、計時器、連接管理,占用處理及資源、數據單元首部增大。

5.1.3運輸層的端口

通信的一方無法識別對方機器進程,往往需要利用目的主機提供的功能來識別終點,不需要知道具體實現這個功能的進程是哪一個。

運輸層使用協議端口號(protocol port number)簡稱端口,軟件端口是應用層的各種協議進程與運輸實體進行層間交互的一種地址。端口號只具有本地意義,是為了標志本計算機應用層中哥各個進程在和運輸層交互的層間接口。

服務端使用的端口號 系統端口號 熟知端口號
客戶端是通的端口號 短暫端口號


5.2用戶數據報協議UDP

相比IP增加了復用分用、差錯檢測功能
1、無連接
2、盡最大努力交付
3、面向報文 保留應用層報文邊界
4、沒有擁塞控制
5、支持一對一、一對多、多對一通信
6、首部開銷小



如果UDP發現報文中目睹端口號不正確,就丟棄并由網際控制協議ICMP發送端口不可達報文給源主機(traceroute)。
UDP把首部和數據部分一起檢驗,簡單,處理快。

5.3傳輸控制協議TCP概述

5.3.1TCP主要特點

1、TCP是面向連接協議,應用程序使用TCP協議之前必須先建立連接,傳送數據后需釋放連接。應用程序通信過程好像在打電話。
2、每一條TCP連接只能有兩個端點,每一條TCP連接是點對點的。
3、TCP提供可靠交付的服務,通過TCP連接傳送的數據,無差錯、不丟失、不重復、按序到達。
4、全雙工通信
5、面向字節流 TCP中流Stream指流入到進程或從進程流出的字節序列,雖然應用程序和TCP的交互是一次一個數據塊,但TCP把應用程序交下來的數據僅僅看成是一連串的無結構字節流。

TCP并不關心應用進程一次把多長的報文發送打TCP緩存中,而是根據對方給出的窗口值和當前網絡擁塞的程度來決定一個報文段應包含多少字節。

TCP的連接

TCP把連接作為最基本的抽象,TCP連接的端點叫做套接字(socket)或端口。端口號拼接到IP地址即構成套接字。
套接字socket=IP地址:端口號
每一條TCP連接被通信兩端的端口確定

5.4可靠傳輸原理

TCP必須采取適當的措施才能使得兩個運輸層之間的通信變得可靠:傳送信道不產生差錯、不管發送發以多塊的速度發送數據,接收方總時來得及處理收到的數據。

5.4.1停止等待協議

無差錯情況

A發送分組M1,發完暫停發送,等待B的確認,B收到M1向A發送確認,A收到對M1確認發送下一個分組M2.

出現差錯

A沒有收到確認需要超時重傳,設置超時計時器。

1、發送完分組后必須暫時保留已發送的分組
2、分組確認分組需要編號
3、重傳時間應比分組往返時間長

確認丟失和確認遲到

B又收到了重傳分組M1,則丟棄分組M1,再次向A發送確認。

上述可靠傳輸協議稱為自動重傳請求ARQ Automatic Repeat erQuest

信道利用率

停止等待協議信道利用率太低,使用流水線傳輸,連續發送多個分組,不必每發完一個分組就停頓下來噸袋對方確認。

流水線傳輸時,用連續ARQ協議和滑動窗口協議

5.4.2連續ARQ協議

滑動窗口協議是TCP協議精髓所在,唯一窗口內的分組可連續發送出去,不許等待對方確認。連續ARQ協議規定發送發每收到一個確認,九八發送窗口向前滑動一個分組。

接收方一般采取累計確認的方式:對按序到達的最后一個分組發送確認,到這個分組為止的所有分組已經正確收到了。

優點:容易實現
缺點:不能反映接收方已經全部正確接收到所有的信息。發送5個分組,丟失中間第3個分組,接收方只能對前兩個分組確認,發送方只能重傳后面3個分組。

5.5TCP報文的首部格式

TCP是面向字節流的,但TCP傳送的數據單元確實報文段。


源端口和目的端口
序號

在一個TCP連接中傳送的字節流的每一個字節都順序編號,整個要傳送的字節流的起始序號必須在連接建立時設置。

!首部中的序號字段值指本報文段所發送的數據的第一個字節的序號。

確認號

!期望收到對方下一個報文段的第一個數據字節的額序號。
若確認號=N,則表示到序號N-1為止的所有數據都已正確收到。

數據偏移

指出TCP 報文的數據起始距離TCP報文的起始處有多遠。

保留

占6位 目前置0

控制位

1、緊急URG URGent 當URG=1時緊急指針字段有效,告訴系統有緊急數據,優先級高。

2、確認ACK ACKnowledgement 連接建立后所有傳送的報文段ACK必須置1。

3、推送PSH push 當兩個應用進程進行交互式通信時,優勢一端的應用進程希望在鍵入一個命令后就能夠收到對方的響應,TCP可以使用推送操作,對方并不用等到緩存填滿了再交付。

4、復位RST reset 當RST=1時,表明TCP連接中出現嚴重差錯,必須釋放連接。

5、同步SNY SNYchronization 在連接建立的時候用來同步序號,當SYN=1,ACK=0時表明這是個連接請求或連接接受報文。

6、種植FIN finish 用來釋放一個連接,當FIN=1表明此報文段的發送方數據已經發送完畢,要求釋放連接。

窗口

窗口值告訴對方:從本報文段首部中的確號開始算起,接收方目前允許對方發送的數據量。窗口值作為接收方讓發送方設置其發送窗口的依據。

檢驗和

檢驗首部數據兩部分

緊急指針

當UEG=1時,指出緊急數據的字節數

選項

最大報文MSS Maximum Segment Size 盡可能大,在IP層傳輸不分片。
窗口增大 時間戳、選擇確認

5.6TCP可靠傳輸實現

5.6.1 以字節為單位的滑動窗口

TCP滑動窗口是以字節為單位的
A收到了B發來的報文段,窗口時20字節,確認號31



A發送序號為31~41的數據,發送窗口有位置未改變



從上述看出描述一個窗口需要三個指針P1\P2\P3
小于P1的是已發送并收到確認的部分,大于P3不允許發送;
P3-P1=A的發送窗口;

P2-P1=已發送尚未收到確認的字節收;
P3-P2=允許發送但當前未發送的字節收 可用窗口



沒有收到B的車確認時,A經過一段時間(由超時控制器控制)就重傳數據。

緩存空間和序號空間有限,緩存或窗口字節數很大。
發送緩存:發送應用程序傳送給發送方TCP準備發送的數據,TCP已發送出但尚未收到確認的數據。
就收緩存:按序到達的、但尚未被接收應用程序讀取的數據,未按序到達的數據。

1、發送窗口并不總時和接收窗口一樣大。
2、TCP通常對不按序到達的數據是先臨時存放在接收窗口中,等到字節流所缺少的字節收到后,在按序交付上次應用程序。
3、TCP要求接收方必須要求累計確認功能,接收方可以在自己有數據要發送時把確認信息捎帶上,確認推遲時間一般不超過0.5s。

5.6.2超時重傳時間的選擇

TCP采用自適應算法,記錄報文段發出的時間,以及收到相應的確認的時間。報文段往返時間RTT,TCP保留了RTT的加權平均往返時間RTTS。
報文段每重傳一次,就把超時重傳時間加大一些。

選擇確認SACK

只傳送缺少的數據而不重傳已經正確接收的數據。

5.7TCP流量控制

流量控制flow control讓發送方發送速率不要太快,讓接收方來得及接收。

利用滑動窗口實現流量控制


發送方的發送窗口不能超過接收方給出的接收窗口的數值,TCP窗口單位是字節。
死鎖:B向A發送零窗口報文后接受緩存有空間,向A發送rwnd=400報文段,然而報文段在傳送過程丟失了,A一直在等待B非零窗口通知,B也一直等待A發送數據。
設置持續計時器,TCP連接收到對方零窗口通知,啟動持續計時器,時間到期發送零窗口探測報文段(即使設置為零窗口也必須接收零窗口報文段,確認報文段,接待緊急數據報文段)。

5.7.2TCP傳輸效率

如何控制TCP報文發送時機,Nagle算法如下:若發送應用進程把要發送的數據逐個字節地送到TCP發送緩存,則發送發就把第一個數據字節先發送出去,把后面到達的所有數據字節都緩存起來,當發送方收到對第一個字節的確認后,再把發送緩存中的所有數據組裝成一個報文發送,同時對隨后到達的數據進行緩存。

糊涂窗口綜合征 silly widown syndrom
讓接收方等待一段時間,使得就收緩存已有足夠空間容納一個最長報文,或等到接受緩存由一般空閑。

5.8TCP擁塞控制

一般原理

擁塞:在某段時間,若對網絡中某一資源的需求超過了該資源做能提供的可用部分,網絡的性能就要變壞。
擁塞控制:防止過多的數據注入到網絡當中,這樣可以使網絡中路由器或鏈路不致過載。是一個全局性過程。


擁塞控制是一個動態的問題,分為開環、閉環控制。
開環控制:在設計網絡時事先將有關發生擁塞的因素考慮周到,力求網絡在工作時不發生擁塞。
閉環控制基于反饋環路概念,檢測網絡系統以便檢測到擁塞在何時、何處發生;把擁塞發生的信息傳送到可采取行動的地方;調整網絡系統的運行已解決問題。

5.8.2TCP擁塞控制的方法

滿開始slow-start,擁塞避免congestion avoidance,快重傳fast retransmit和快恢復fast recovery

慢開始和擁塞避免

基于窗口的擁塞控制,發送方外吃一個叫擁塞窗口cwnd congest window的狀態變量。發送方讓自己的發送窗口等于擁塞窗口。

原則:只要網絡沒有出現擁塞,擁塞窗口就可以在增大一一些,以便把更多的分組發送出去;網絡出現擁塞或可能出現擁塞,就必須把擁塞窗口減小一些。判斷網絡擁塞的依據時出現超時。

慢開始:由小到大逐漸增大發送窗口。把出事擁塞窗口設置1~2個最大報文段SMSS Sender Maximum Segment Size的數值。
為了防止擁塞窗口cwnd增長過大 慢開始門限ssthresh

擁塞避免:每經過一個往返時間RTT把擁塞窗口cwnd加1,在擁塞避免階段,擁塞窗口cwnd線性緩慢增長。


有時候個別報文會在網絡中丟失,但實際上并未發生擁塞,采用快重傳可以讓發送方盡早知道發生了個別報文的丟失。算法要求接收方立即發送確認,即使收到失序報文段。發送方只要一連收到3個重復確認,立即重傳。不啟動慢開始,而是執行快恢復算法,調整門限值ssthresh=cwnd/2,并開始執行擁塞避免算法。

擁塞避免階段擁塞窗口是按照線性規律增大的,假發增大Additive Increase,快恢復乘減小MD Multiplicative Decrease 。AIMD算法。


5.8.3主動管理隊列AQM

假定路由器對某些分組處理時間長,引起發送方對這些報文重傳,誤認為發生擁塞。路由器分組策略FIFO First In First Out的規則處理到來的分組。尾部丟棄策略。發生路由器尾部丟棄,可能會影響很多條TCP連接,使它門同一時間進入到慢開始狀態,這稱為全局同步 global syncronization。

主動管理隊列AQM Active Queue Management 不要等到路由器隊列長出已經到達某個值才不得不丟棄后面到達分組,應當在網絡有了擁塞征兆時丟棄。實際上是對路由器中的分組排隊進行智能管理,而不是簡單地把隊列尾部丟棄。

5.9TCP運輸的連接管理

TCP時面向連接的協議:建立連接、數據傳輸、連接釋放。
解決問題:
1、要使每一方能夠確知對方存在
2、要允許每一方協商一些參數如窗口最大值、窗口擴大選項、時間戳選項、服務質量。
3、能夠對運輸實體資源(如緩存大小、連接表中項目)進行分配。
主動發起連接建立的進程叫客戶client,被動等待的應用進程叫服務器server

5.9.1TCP連接的建立

三報文握手



A最后一次確認:防止已失效的連接請求報文突然又傳送到了B,浪費資源。

5.9.2TCP連接的釋放

四報文握手



時間等待計時器TIME-WAIT timer設置時間2MSL
最長報文壽命MSL Maximum Segment Lifetime
A在TIME-WAIT等待2MSL時間原因:
1、保證A發送的最后一個ACK報文能夠到達B,這個ACK報文有可能丟失,B會超時重傳FIN+ACK報文段,而A就能在2MSL時間收到重傳的FIN+ACK報文段。
2、防止已失效的蓮姐姐請求報文段。

保活計時器keepalive timper主機出現故障,使服務器不要白白等待。

5.9.3TCP有限狀態機

粗實線:客戶進程正常變遷
粗虛線:服務器進程正常變遷
細線:異常變遷


?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,002評論 6 542
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,400評論 3 429
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 178,136評論 0 383
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,714評論 1 317
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,452評論 6 412
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,818評論 1 328
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,812評論 3 446
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,997評論 0 290
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,552評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,292評論 3 358
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,510評論 1 374
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,035評論 5 363
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,721評論 3 348
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,121評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,429評論 1 294
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,235評論 3 398
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,480評論 2 379

推薦閱讀更多精彩內容

  • 運輸層協議概述 從通信和信息處理的角度看,運輸層向它上面的應用層提供通信服務,它屬于面向通信部分的最高層,同時也是...
    srtianxia閱讀 2,438評論 0 2
  • 六、TCP可靠傳輸的實現 首先介紹以字節為單位的滑動窗口。為了講述可靠傳輸原理的方便,假定數據傳輸只在一個方向進行...
    dmmy大印閱讀 1,742評論 0 1
  • 本書結構是自頂向下的,所以請按下列順序閱讀: 1.計算機網絡自頂向下--應用層2.計算機網絡自頂向下--運輸層3....
    牛富貴兒閱讀 2,835評論 0 3
  • 注:本文的圖片均來源于謝希仁《計算機網絡》第六版的課件PPT 1.重點內容 (1)運輸層為相互通信的應用進程提供邏...
    zuyuxia閱讀 1,122評論 0 1
  • 5.1 運輸層協議概述 從通信和處理信息的角度看,運輸層是向它上面的應用層提供通信服務的,它屬于面向通信部分的最高...
    yzbkaka閱讀 916評論 0 0