傳輸層

傳輸層的基本服務

一秸谢、傳輸層的功能

傳輸層的核心任務是為應用進程之間提供 $\color{blue}{端到端的邏輯通信服務}$ 撑碴。

1. 主要功能包括：

$\bullet$ ?傳輸層尋址

$\bullet$ ?應用層報文的分段和重組

$\bullet$ ?報文的差錯檢測

$\bullet$ ?進程間的端到端可靠數(shù)據(jù)傳輸控制

$\bullet$ ?面向應用層實現(xiàn)復用與分解

$\bullet$ ?端到端的流量控制

$\bullet$ ?擁塞控制

2. 傳輸層提供的服務

傳輸層協(xié)議提供 $\color{blue}{邏輯通信}$ 服務苏遥；

傳輸層協(xié)議只需在 $\color{blue}{端系統(tǒng)}$ 中實現(xiàn)暂雹；

通信的真正端點并不是主機不同，而是主機中運行的 $\color{blue}{應用進程}$ 泡一。

二颤殴、傳輸層尋址與端口

1. 用統(tǒng)一的尋址方法對應用進程進行標識—— $\color{blue}{端口號}$ 。

2. 在全網(wǎng)范圍內(nèi)利用 " $\color{blue}{IP地址+端口號}$ " 唯一標識一個通信端點鼻忠。(即應用進程)

3. 傳輸層端口號為16位整數(shù)涵但，包含三類端口：

? ??(1) $\color{blue}{熟知端口號}$ ，數(shù)值為 0~1023.

? ? (2) $\color{blue}{登記端口號}$ 帖蔓，數(shù)值為 1024~49151矮瘟，為沒有熟知端口號的應用程序使用。使用這個范圍的端口號必須在IANA登記讨阻，以防止重復芥永。

? ? (3) $\color{blue}{客戶端口號或短暫端口號}$ ，數(shù)值為 49152~65535钝吮，留給客戶進程選擇暫時使用埋涧。

提供服務的人端口號一定要固定，但對于用戶來說無所謂奇瘦。

三棘催、無連接服務與面向連接服務

1. 無連接服務——數(shù)據(jù)傳輸之間無需與對端進行任何信息交換（即 “握手”），直接構造傳輸層報文段并向接收端發(fā)送耳标。? ? ? ? ? ?——UDP

2. 面向連接服務——在數(shù)據(jù)傳輸之前醇坝，需要雙方交換一些控制信息， $\color{blue}{建立邏輯連接}$ 次坡，然后再 $\color{blue}{傳輸數(shù)據(jù)}$ 呼猪，數(shù)據(jù)傳輸結束后還需要再 $\color{blue}{拆除連接}$ 。? ? ? ? ? ?——TCP

傳輸層的復用與分解

多路復用與多路分解：是傳輸層的一項基本功能砸琅，支持眾多應用進程共用同一個傳輸層協(xié)議宋距，并能夠將接收到的數(shù)據(jù)準確交付給不同的應用進程。

一症脂、無連接的多路復用與多路分解

UDP套接字：<目的IP地址谚赎，目的端口號>

UDP套接字的端口號是UDP實現(xiàn)復用與分解的重要依據(jù)淫僻。

通過目的IP地址可以判斷到哪個主機，通過目的端口可以判斷到哪個應用進程壶唤。

二雳灵、面向連接的多路復用與多路分解

TCP套接字(標識一條TCP連接)：

<源IP地址，源端口號闸盔，目的IP地址悯辙，目的端口號>

當一個TCP報文段從網(wǎng)絡層到達一臺主機時，該主機根據(jù)這 4 個值來將報文段分解到相應的套接字蕾殴。

停-等協(xié)議與滑動窗口協(xié)議

一笑撞、可靠數(shù)據(jù)傳輸基本原理

實現(xiàn)可靠數(shù)據(jù)傳輸?shù)拇胧?/p>

1. 差錯檢測：利用差錯編碼實現(xiàn)數(shù)據(jù)包傳輸過程中的比特差錯檢測。

2. 確認：接收方向發(fā)送方反饋接收狀態(tài)钓觉。

3. 重傳：發(fā)送方重新發(fā)送接收方?jīng)]有正確接收的數(shù)據(jù)茴肥。

4. 序號：確保數(shù)據(jù)按序提交。

5. 計時器：解決數(shù)據(jù)丟失問題荡灾。

二瓤狐、停-等協(xié)議

停-等協(xié)議的主要特點就是每發(fā)送一個報文段后就停下來等待接收方的確認。

停-等協(xié)議的基本工作過程：

1. 發(fā)送方發(fā)送經(jīng)過差錯編碼和編號的報文段批幌，等待接收方的確認础锐；( $\color{blue}{發(fā)送并等待確認}$ )

2. 接收方如果正確接收報文段，即差錯檢測無誤且序號正確荧缘，則接收報文段皆警，并向發(fā)送方發(fā)送ACK，否則丟棄報文段截粗，并向發(fā)送方發(fā)送NAK信姓；（ $\color{blue}{接收并確認/否認}$ ）

3. 發(fā)送方如果收到ACK，則繼續(xù)發(fā)送后續(xù)報文段绸罗，否則重發(fā)剛剛發(fā)送的報文段意推。( $\color{blue}{繼續(xù)發(fā)送/重發(fā)}$ )

三、滑動窗口協(xié)議

1. 停-等協(xié)議的主要性能問題：

停止-等待機制降低了信道利用率珊蟀。

2.解決方法：

$\color{blue}{流水線協(xié)議}$ 或管道協(xié)議——允許發(fā)送方在沒有收到確認前連續(xù)發(fā)送多個分組菊值。

3. 流水線協(xié)議的改進：

增加分組序號范圍；

發(fā)送方和(或)接收方必須育灸。

4. 典型的流水線協(xié)議：

滑動窗口協(xié)議

停-等協(xié)議發(fā)送端每發(fā)送一個報文就需要停下來等待對方確認腻窒，相當于發(fā)送窗口大小為1；接收端僅接收符合當前預期的一個報文磅崭，接收窗口大小為1.

三定页、滑動窗口協(xié)議

兩種最具有代表性的滑動窗口協(xié)議：

1. 回退N步（Go-Back-N，GBN）協(xié)議：

發(fā)送端窗口大小較大绽诚，可以在未得到確認前連續(xù)發(fā)送多個分組；但接收窗口大小僅為一，只能接收1個按序到達的分組恩够，未按序到達的分組或者某個分組差錯卒落，就會引起發(fā)送方重發(fā)該分組及其之后的所有分組。

2. 選擇重傳（Selective Repeat蜂桶，SR）協(xié)議：

增加接收方緩存能力（接收窗口>1）,緩存正確到達但失序的分組儡毕，僅要求發(fā)送方重傳未被接收方確認的分組，等缺失分組到達后一并向上層按序提交扑媚。

用戶數(shù)據(jù)報協(xié)議（UDP）

用戶數(shù)據(jù)報協(xié)議UDP是Internet傳輸層協(xié)議腰湾，提供 $\color{blue}{無連接}$ 、 $\color{blue}{不可靠}$ 疆股、數(shù)據(jù)報盡力傳輸服務费坊。

一、UDP數(shù)據(jù)報結構

1. 源和目的端口號：用于UDP實現(xiàn)復用與分解旬痹。

2. 長度字段：在UDP報文段中的字節(jié)數(shù)（首部和數(shù)據(jù)的總和）附井。

3.校驗和：接收方用來檢測該報文段是否出現(xiàn)了差錯。

二两残、UDP校驗和

計算校驗和：

1. 對所有參與運算的內(nèi)容（包括UDP報文段）按16位（16位對齊）求和永毅；

2. 求和過程中遇到的任何溢出（即進位）都被回卷（即進位與和的最低位再加）；

3. 最后得到的和取反碼人弓。

傳輸控制協(xié)議（TCP）

一沼死、TCP報文段結構

源端口（2字節(jié)）：發(fā)送端應用程序的端口號.

目的端口（2字節(jié)）：接收端應用程序的端口號.

序號（4個字節(jié)）：TCP是面向字節(jié)流傳輸?shù)模麨槊恳粋€字節(jié)編了一個序號崔赌，該報文段中序號為傳輸數(shù)據(jù)第一個字節(jié)的序號意蛀。例如：一個報文端的數(shù)據(jù)部分大小為100個字節(jié)，他的序號為400峰鄙，那么下一次報文段的序號就為500.

確認號（4個字節(jié)）：指明了下一個期待接收的字節(jié)序號浸间，表明該序號之前的所有字節(jié)都正確接收到了，只有當ACK為 1 的時候確認號才有效.

數(shù)據(jù)偏移/首部長度（4個字節(jié)）：用來表示報文段數(shù)據(jù)的起始處距離報文起始處的長度吟榴，也就是TCP報文首部的長度魁蒜，由于首部含有可選項，所以TCP報頭長度是不確定的.

保留：為了將來定義新的用途保留吩翻，現(xiàn)在一般都置為0.

URG緊急控制位：與緊急指針配合使用兜看，當URG為1的時候，就是通知系統(tǒng)這個報文段有緊急數(shù)據(jù)狭瞎，需要優(yōu)先傳輸细移。

ACK確認控制位：當它為?1?的時候，確認號字段才有效熊锭，TCP規(guī)定弧轧，在連接建立后雪侥，所有ACK都應該置為1

PSH推送控制位：當報文段的psh為 1 的時候，接收方接到該報文段精绎，就立刻將他交付給接收應用進程速缨，而不是等緩存已滿的時候再交付。

RST復位控制位：當報文段的RST為1的時候代乃，說明該TCP連接出現(xiàn)錯誤旬牲，必須釋放連接，并重新建立連接搁吓。

SYN同步控制位：在連接建立時用來同步序列號原茅，當 SYN=1,ACK=0 時說明這是一個連接請求報文段，如果對方同意建立連接則應該在響應的報文段中將 SYN=1,ACK=1堕仔，表示接受請求

FIN終止控制位：用來釋放連接擂橘，當FIN=1時表示此報文段發(fā)送方的數(shù)據(jù)已經(jīng)發(fā)送完畢，并要求釋放連接贮预。

窗口（2字節(jié)）：用來告知發(fā)送端贝室，接收端的緩存大小，以此控制發(fā)送方發(fā)送數(shù)據(jù)的速率仿吞，從而達到流量控制滑频，窗口最大為65536。

校驗和：用CRC來校驗整個TCP報文段唤冈，包括tcp頭峡迷，tcp數(shù)據(jù)，由發(fā)送端進行計算和存儲你虹，接收端進行校驗绘搞，如果接收方發(fā)現(xiàn)校驗和有差錯，則TCP段會被直接丟棄傅物。

緊急指針（2字節(jié)）：標識緊急數(shù)據(jù)在報文段結束的位置夯辖。

選項：長度可變，最大長度40個字節(jié)

二董饰、TCP連接管理

連接建立——三次握手：

1. SYN連接請求（客戶端-->服務端）

2. SYNACK確認（同步確認）

3. ACK確認（客戶端再次確認）

TCP三次握手建立連接過程：

TCP斷開連接的過程——四次揮手：

三蒿褂、TCP可靠數(shù)據(jù)傳輸

1. TCP的可靠數(shù)據(jù)傳輸實現(xiàn)機制包括差錯編碼、確認卒暂、序號啄栓、重傳、計時器等也祠。

2. TCP的可靠數(shù)據(jù)傳輸是基于滑動窗口協(xié)議昙楚，但是發(fā)送窗口大小動態(tài)變化。

? ? (1)封裝TCP報文段

? ? (2)發(fā)出一個報文段后啟動一個計時器

????(3)通過校驗和發(fā)現(xiàn)數(shù)據(jù)差錯

? ? (4)通過序號重新排序诈嘿，丟棄重復的報文段

????(5)流量控制

四堪旧、TCP流量控制

1. TCP協(xié)議利用 $\color{blue}{窗口機制}$ 實現(xiàn)流量控制削葱，但不是簡單的滑動窗口協(xié)議。

2. TCP連接建立時淳梦，雙方都為之分配了固定大小的緩沖空間佩耳；TCP的接收端只允許另一端發(fā)送其緩沖區(qū)所能接納的數(shù)據(jù)。

? ? (1)接收端在給發(fā)送端發(fā)送確認段時谭跨，通告接收窗口大小。

? ? (2)發(fā)送端在接下來發(fā)送數(shù)據(jù)段時李滴，確保未確認段的應用層數(shù)據(jù)總量不超過接收端通告的接收窗口大小螃宙，從而確保接收端不會發(fā)生緩存溢出。

五所坯、TCP擁塞控制

1. 窗口機制：

通過調節(jié)窗口的大小實現(xiàn)對發(fā)送數(shù)據(jù)速率的調整谆扎。

2. 窗口調整的基本策略：

AIMD（Additive Increase，Multiplicative Decrease）加性增加芹助，乘性減小堂湖；

網(wǎng)絡未發(fā)送擁塞時，逐漸 “加性” 增大窗口大小状土，當網(wǎng)絡擁塞時 “乘性” 快速減小窗口大小无蜂。

3. TCP的擁塞控制算法：

包括了慢啟動、擁塞避免蒙谓、快速重傳和快速恢復4部分斥季。

最后編輯于：2020.04.02 17:30:08

?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者

禁止轉載，如需轉載請通過簡信或評論聯(lián)系作者累驮。

人面猴
序言：七十年代末酣倾，一起剝皮案震驚了整個濱河市，隨后出現(xiàn)的幾起案子谤专，更是在濱河造成了極大的恐慌躁锡，老刑警劉巖，帶你破解...
沈念sama閱讀 210,978評論 6贊 490
死咒
序言：濱河連續(xù)發(fā)生了三起死亡事件置侍，死亡現(xiàn)場離奇詭異映之，居然都是意外死亡，警方通過查閱死者的電腦和手機墅垮，發(fā)現(xiàn)死者居然都...
沈念sama閱讀 89,954評論 2贊 384
救了他兩次的神仙讓他今天三更去死
文/潘曉璐我一進店門惕医，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人算色，你說我怎么就攤上這事抬伺。” “怎么了灾梦？”我有些...
開封第一講書人閱讀 156,623評論 0贊 345
道士緝兇錄：失蹤的賣姜人
文/不壞的土叔我叫張陵峡钓，是天一觀的道長妓笙。經(jīng)常有香客問我，道長能岩，這世上最難降的妖魔是什么寞宫？我笑而不...
開封第一講書人閱讀 56,324評論 1贊 282
?港島之戀（遺憾婚禮）
正文為了忘掉前任，我火速辦了婚禮拉鹃，結果婚禮上辈赋，老公的妹妹穿的比我還像新娘。我一直安慰自己膏燕，他們只是感情好钥屈，可當我...
茶點故事閱讀 65,390評論 5贊 384
惡毒庶女頂嫁案：這布局不是一般人想出來的
文/花漫我一把揭開白布。她就那樣靜靜地躺著坝辫，像睡著了一般篷就。火紅的嫁衣襯著肌膚如雪。梳的紋絲不亂的頭發(fā)上近忙，一...
開封第一講書人閱讀 49,741評論 1贊 289
城市分裂傳說
那天竭业，我揣著相機與錄音，去河邊找鬼及舍。笑死未辆，一個胖子當著我的面吹牛，可吹牛的內(nèi)容都是我干的击纬。我是一名探鬼主播鼎姐，決...
沈念sama閱讀 38,892評論 3贊 405
雙鴛鴦連環(huán)套：你想象不到人心有多黑
文/蒼蘭香墨我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼更振！你這毒婦竟也來了炕桨？” 一聲冷哼從身側響起，我...
開封第一講書人閱讀 37,655評論 0贊 266
萬榮殺人案實錄
序言：老撾萬榮一對情侶失蹤肯腕，失蹤者是張志新（化名）和其女友劉穎献宫，沒想到半個月后，有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體实撒，經(jīng)...
沈念sama閱讀 44,104評論 1贊 303
?護林員之死
正文獨居荒郊野嶺守林人離奇死亡姊途，尸身上長有42處帶血的膿包…… 初始之章·張勛以下內(nèi)容為張勛視角年9月15日...
茶點故事閱讀 36,451評論 2贊 325
?白月光啟示錄
正文我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了知态。大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片捷兰。...
茶點故事閱讀 38,569評論 1贊 340
活死人
序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖负敏，靈堂內(nèi)的尸體忽然破棺而出贡茅，到底是詐尸還是另有隱情，我是刑警寧澤，帶...
沈念sama閱讀 34,254評論 4贊 328
?日本核電站爆炸內(nèi)幕
正文年R本政府宣布顶考，位于F島的核電站赁还，受9級特大地震影響，放射性物質發(fā)生泄漏驹沿。R本人自食惡果不足惜艘策，卻給世界環(huán)境...
茶點故事閱讀 39,834評論 3贊 312
男人毒藥：我在死后第九天來索命
文/蒙蒙一、第九天我趴在偏房一處隱蔽的房頂上張望渊季。院中可真熱鬧朋蔫，春花似錦、人聲如沸却汉。這莊子的主人今日做“春日...
開封第一講書人閱讀 30,725評論 0贊 21
一樁弒父案，背后竟有這般陰謀
文/蒼蘭香墨我抬頭看了看天上的太陽病涨。三九已至，卻和暖如春璧坟，著一層夾襖步出監(jiān)牢的瞬間既穆，已是汗流浹背。一陣腳步聲響...
開封第一講書人閱讀 31,950評論 1贊 264
情欲美人皮
我被黑心中介騙來泰國打工雀鹃，沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留幻工，地道東北人。一個月前我還...
沈念sama閱讀 46,260評論 2贊 360
代替公主和親
正文我出身青樓黎茎，卻偏偏與公主長得像囊颅，于是被迫代替她去往敵國和親。傳聞我的和親對象是個殘疾皇子傅瞻，可洞房花燭夜當晚...
茶點故事閱讀 43,446評論 2贊 348

傳輸層