傳輸層
1 傳輸層功能與簡(jiǎn)介
為什么需要兩個(gè)不同的獨(dú)立控制層
- 網(wǎng)絡(luò)層運(yùn)行在由運(yùn)營(yíng)商ISP操作的路由器上，用戶無(wú)法控制到這一層
設(shè)置一個(gè)層位于網(wǎng)絡(luò)層之上可以讓用戶控制服務(wù)質(zhì)量 - 傳輸層原語(yǔ)，是對(duì)網(wǎng)絡(luò)層（網(wǎng)絡(luò)層由于網(wǎng)絡(luò)的不同，會(huì)有不同的原語(yǔ)）的抽象宪卿，提供統(tǒng)一接口（便利，降低開(kāi)發(fā)難度）
傳輸層的主要功能
傳輸層是整個(gè)協(xié)議棧(TCP/IP)的核心谦屑，傳輸層的任務(wù)是提供可靠的甫贯、高效的數(shù)據(jù)傳輸
- 傳輸服務(wù)：（面向連接、面向無(wú)連接）
- 在該層還需對(duì)字節(jié)流進(jìn)行數(shù)據(jù)分段（塊）和重組
- 保證數(shù)據(jù)可靠傳輸和進(jìn)行流量控制
- 建立端到端的操作；【端點(diǎn)實(shí)質(zhì)是機(jī)器上的套接字】
- 從一端主機(jī)向另一端主機(jī)發(fā)送數(shù)據(jù)段
傳輸層使整個(gè)報(bào)文到達(dá)了該計(jì)算機(jī)上正確的進(jìn)程
傳輸層的最終目標(biāo)是向它的用戶（應(yīng)用層）提供高效蔼两、可靠和性價(jià)比高的服務(wù)【例如從一臺(tái)主機(jī)到另一臺(tái)主機(jī)的報(bào)文到底送給這臺(tái)機(jī)器的email去解析甩鳄，還是送給播放器播放，還是瀏覽器解析】
- 雖然與鏈路層相似（流控制额划、差錯(cuò)控制妙啃、報(bào)文排序），但傳輸環(huán)境不同（傳輸層-通信子網(wǎng)俊戳，鏈路層-物理信道）
1.1 簡(jiǎn)單的傳輸層服務(wù)原語(yǔ)：
1.2 傳輸層的數(shù)據(jù)傳輸單元（PDU）是TPDU
2 傳輸層協(xié)議
2.1 UDP
- UDP 是一個(gè)無(wú)連接的（connectionless）的傳輸層協(xié)議
- 提供端點(diǎn)標(biāo)識(shí)揖赴，端到端的數(shù)據(jù)傳輸
- 不提供差錯(cuò)檢測(cè)和可靠傳輸。但簡(jiǎn)潔高效
端口（port）定義
16 位品抽，共有 216個(gè)端口
端口范圍：0~65535
<1023 : 用于公共應(yīng)用（保留储笑，全局分配，用于標(biāo)準(zhǔn)服務(wù)器）圆恤，IANA分配突倍；
1024~49151 :用戶端口，注冊(cè)端口盆昙；
> 49152 : 動(dòng)態(tài)端口羽历，私人端口。
2.1.1 UDP校驗(yàn)和
2.2 TCP（傳輸控制協(xié)議）
TCP (Transmission Control Protocol) 是專(zhuān)門(mén)為了在不可靠的互聯(lián)網(wǎng)絡(luò)上提供可靠的端到端字節(jié)流而設(shè)計(jì)的
TCP必須動(dòng)態(tài)地適應(yīng)不同的拓?fù)涞病掞趿住⒀舆t、分組大小和其它的參數(shù)炼团，并且當(dāng)有錯(cuò)誤的時(shí)候澎嚣，能夠足夠健壯
TCP服務(wù)模型：
- 要想獲得TCP服務(wù)，發(fā)送方和接收方必須創(chuàng)建一種稱(chēng)為套接字（ sockets ）的端點(diǎn)（ end points）
- 每個(gè)套接字是包含一個(gè)IP地址和一個(gè)16位的端口（ port ）
- 通信進(jìn)程的全球唯一標(biāo)識(shí)
·三元組：協(xié)議瘟芝、本地地址易桃、本地端口號(hào)
·五元組：協(xié)議、本地地址锌俱、本地端口號(hào)晤郑、遠(yuǎn)端地址、遠(yuǎn)端端口號(hào) - 所有的 TCP 連接是全雙工的(同時(shí)雙向傳輸)和端到端的(每條連接只有兩個(gè)端點(diǎn))
- TCP 不支持組播和廣播
- TCP連接是字節(jié)流而不是消息流
2.2.1 tcp數(shù)據(jù)段頭
- 源端口和 目的端口字段標(biāo)明了一個(gè)連接的兩個(gè)端點(diǎn)
-
序列號(hào)– 字節(jié)號(hào) (32 位)
·初始序列號(hào)(ISNs) 隨機(jī)產(chǎn)生
·SYN :攜帶了ISNs和SYN控制位的數(shù)據(jù)段 - 確認(rèn)號(hào) – 期望接收的字節(jié)號(hào)（32位）
- TCP 段頭長(zhǎng)度 – TCP段頭長(zhǎng)度贸宏，單位32位
2.2.1.1數(shù)據(jù)段頭解釋
保留域/字段
PSH表示這是帶有PUSH標(biāo)志的數(shù)據(jù)（接收方收到這樣的數(shù)據(jù)造寝，應(yīng)該立刻送到上層，而不需要緩存它）
RST 被用來(lái)重置一個(gè)已經(jīng)混亂的連接
SYN用在連接建立的過(guò)程
·當(dāng)SYN=1吭练，ACK=0诫龙， 連接請(qǐng)求
·當(dāng)SYN=1，ACK=1鲫咽， 連接接受FIN 被用來(lái)釋放連接赐稽，它表示發(fā)送方已經(jīng)沒(méi)有數(shù)據(jù)要傳輸了叫榕，但是可以繼續(xù)接收數(shù)據(jù).
Windowsize – 告訴對(duì)方可以發(fā)送的數(shù)據(jù)字節(jié)數(shù)（從確認(rèn)字節(jié)號(hào)開(kāi)始（決定于接收方））【流控】
Checksum –提供額外的可靠性校驗(yàn)的范圍包括頭部、數(shù)據(jù)和概念性的偽頭部
TCP頭部范圍（5x4B15x4B（最大數(shù)值））--（20B60B）
2.2.2 TCP建立連接-三次握手
- 一方（server）被動(dòng)地等待一個(gè)進(jìn)來(lái)的連接請(qǐng)求
- 另一方（the client）通過(guò)發(fā)送連接請(qǐng)求姊舵，設(shè)置一些參數(shù)
- 服務(wù)器方回發(fā)確認(rèn)應(yīng)答
-
應(yīng)答到達(dá)請(qǐng)求方晰绎，請(qǐng)求方最后確認(rèn)，連接建立
image.png
- 正常情況下括丁，發(fā)送TCP端順序如a所示
- 兩主機(jī)同時(shí)企圖在一對(duì)套接字之間建立連接荞下，結(jié)果恰好只建立了一個(gè)連接，表項(xiàng)為（x史飞，y）
SYN泛洪
`惡意發(fā)送SYN段請(qǐng)求服務(wù)器的連接尖昏，但又故意不完成連接建立的后續(xù)服務(wù)，以此消耗一臺(tái)主機(jī)的資源构资。
2.2.3 TCP 連接釋放（四次揮手）
釋放連接
- 任何一方在沒(méi)有數(shù)據(jù)要傳送的時(shí)候抽诉，都可以發(fā)送一個(gè)FIN置位了的 TCP 數(shù)據(jù)段
- 當(dāng)FIN被確認(rèn)的時(shí)候，該方向的連接被關(guān)閉
- 當(dāng)雙向連接都關(guān)閉了的時(shí)候吐绵，連接釋放
兩軍隊(duì)問(wèn)題
- B2向B1發(fā)送今晚十二點(diǎn)一起發(fā)起總進(jìn)攻【合作才能打敗白軍隊(duì)】
- B1收到后迹淌，不知B2是否會(huì)沖下去【因?yàn)锽2不知道B1是否收到信】，所以發(fā)送確認(rèn)郵件給B2（讓其今晚十二點(diǎn)也沖下去）【如果只有B1沖下去肯定失敗】
- B2收到郵件己单，但不知道B1是否知道自己收到郵件【B1如果因?yàn)椴恢雷约菏欠袷盏桨η裕桓覜_下去，那自己沖下去也是輸】纹笼。保險(xiǎn)起見(jiàn)纹份，發(fā)送給B1【我收到了你的信，咱們今晚一起沖下去】
難題在于最后發(fā)送的一方永遠(yuǎn)無(wú)法知道自己的信對(duì)方有無(wú)收到廷痘。
為了避免兩軍隊(duì)（two-army）問(wèn)題蔓涧，使用定時(shí)器
- 如果一方發(fā)送了FIN數(shù)據(jù)段出去卻在一個(gè)設(shè)定的時(shí)間沒(méi)有收到應(yīng)答，釋放連接
- 另一方最終會(huì)注意到連接的對(duì)方已經(jīng)不在了笋额，超時(shí)后連接釋放
半開(kāi)放連接（half- open）
-
發(fā)送者將放棄發(fā)送且釋放連接蠢笋，
但是，另外一端卻不知道這些情況【初始DR鳞陨、重傳都丟失】，仍然處于活躍的狀態(tài) - 殺死半開(kāi)放連接的方式：如果在一定的時(shí)間內(nèi)瞻惋，沒(méi)有TPDUs 到達(dá)的話厦滤，連接自動(dòng)釋放
·這個(gè)TPDU是啞TPDU（dummy TPDU）
TCP是全雙工的，連接必須是雙向的歼狼。半開(kāi)半閉的連接必須殺掉
2.2.4 TCP滑窗技術(shù)與傳輸策略
TCP 傳輸策略
發(fā)送方（Nagle’s algorithm）
- 盡量不發(fā)送數(shù)據(jù)含量小的數(shù)據(jù)段
- 緩存應(yīng)用層的數(shù)據(jù)掏导，達(dá)到一定量再發(fā)送
接收方（Clark’s solution）
- 不請(qǐng)求對(duì)方發(fā)送短數(shù)據(jù)段(window size)
- 延遲窗口變更信息，使接收緩沖區(qū)足夠大
2.2.5 TCP擁塞控制
分組守恒：當(dāng)有一個(gè)老的分組離開(kāi)之后才允許新的分組注入網(wǎng)絡(luò)
TCP希望通過(guò)動(dòng)態(tài)維護(hù)窗口大小來(lái)實(shí)現(xiàn)這個(gè)目標(biāo)
擁塞檢測(cè)Congestiondetection擁塞標(biāo)記
所有的互聯(lián)網(wǎng)TCP算法都假定超時(shí)是由擁塞引起的羽峰，并且通過(guò)監(jiān)視超時(shí)的情況來(lái)判斷是否出現(xiàn)問(wèn)題
擁塞控制Congestionprevention
- 當(dāng)一個(gè)連接建立的時(shí)候趟咆，雙方選擇一個(gè)合適的窗口大小添瓷，接收方根據(jù)自己的緩沖區(qū)大小來(lái)指定窗口的大小。
-
如果發(fā)送者遵守此窗口大小的限制值纱，則接收端不會(huì)出現(xiàn)緩沖區(qū)溢出的問(wèn)題鳞贷，但可能由于網(wǎng)絡(luò)內(nèi)部的擁塞而發(fā)生問(wèn)題
image.png
2.2.5.1 決定擁塞窗口大小的算法：
慢啟動(dòng)算法（Slow Start） (嘗試的過(guò)程)：
- 當(dāng)連接建立的時(shí)候，發(fā)送者用當(dāng)前使用的最大數(shù)據(jù)段長(zhǎng)度初始化擁塞窗口虐唠，然后發(fā)送一個(gè)最大的數(shù)據(jù)段
- 如果在定時(shí)器超期之前收到確認(rèn)搀愧，則將擁塞窗口翻倍，然后發(fā)送兩個(gè)數(shù)據(jù)段疆偿。咱筛。。杆故。迅箩。直至超時(shí)（或達(dá)到接收方窗口的大小）
- 確定出擁塞窗口的大小
如：如果試圖發(fā)送 4096 字節(jié)沒(méi)有問(wèn)題处铛，但是發(fā)送8192字節(jié)的時(shí)候饲趋，超時(shí)沒(méi)有收到應(yīng)答，則擁塞窗口設(shè)為4096個(gè)字節(jié)
2.2.6 定時(shí)器的作用
最重要的定時(shí)器是重傳定時(shí)器
持續(xù)定時(shí)器（persistence timer）罢缸，用來(lái)避免如下的死鎖（ deadlock ）發(fā)生
- 接收方發(fā)送了一個(gè)窗口數(shù)為零的確認(rèn)（窗口更新）篙贸，告訴發(fā)送方等待
- 稍后，接收方空出了緩沖枫疆，發(fā)送更新窗口的數(shù)據(jù)段爵川，但是，很不幸息楔，該分組丟失啦寝贡！
-
現(xiàn)在，收發(fā)雙方都在等待對(duì)方發(fā)送數(shù)據(jù)段過(guò)來(lái)值依，但永遠(yuǎn)等不到圃泡！死鎖產(chǎn)生
image.png
保活定時(shí)器（keep-alive timer）
- 用來(lái)檢查連接是否存活愿险，當(dāng)一個(gè)連接空閑的時(shí)間超過(guò)逼睦活定時(shí)器的時(shí)間，該連接將被殺掉
- 最后一個(gè)定時(shí)器是在關(guān)閉時(shí)刻處于TIMED WAIT 狀態(tài)中使用的定時(shí)器辆亏，它運(yùn)行兩倍的最大分組生存時(shí)間风秤，以確保連接關(guān)閉之后，該連接上的所有分組都完全消失
3 TCP UDP比較
TCP
- 可靠傳輸方式
- 可讓?xiě)?yīng)用程序簡(jiǎn)單化扮叨，程序員可以不必進(jìn)行錯(cuò)誤檢查缤弦、修正等工作
UDP - 為了降低對(duì)計(jì)算機(jī)資源的需求，如DNS
- 應(yīng)用程序本身已提供數(shù)據(jù)完整性的檢查機(jī)制彻磁，勿須依賴傳輸層的協(xié)議來(lái)保證
- 應(yīng)用程序傳輸?shù)牟⒎顷P(guān)鍵性的數(shù)據(jù)碍沐，如路由器周期性的路由信息交換
- 一對(duì)多方式狸捅，必須使用UDP（TCP限于一對(duì)一的傳送），如視頻傳播
