重點部分：
掌握Internet的傳輸層協(xié)議：
- UDP：無連接傳輸服務(wù)
- TCP： 面向連接的傳輸服務(wù)
- TCP擁塞控制
如圖，傳輸層協(xié)議為運行在不同HOST上的進程提供了一種邏輯通信機制
端系統(tǒng)運行傳輸層協(xié)議：
- 發(fā)送方：將應(yīng)用遞交的消息分成一個或多個的segment(數(shù)據(jù)報文段)， 并向下傳給網(wǎng)絡(luò)層
- 接收方：將接收到的segment組裝成消息，并向上交給應(yīng)用層
傳輸層可以為應(yīng)用提供多種協(xié)議
- Internet上的TCP
- Internet上的UDP
傳輸層 vs 網(wǎng)絡(luò)層
網(wǎng)絡(luò)層：提供主機之間的邏輯通信機制
傳輸層：提供應(yīng)用進程之間的邏輯通信機制
- 位于網(wǎng)絡(luò)層之上
- 依賴于網(wǎng)絡(luò)層服務(wù)
- 對網(wǎng)絡(luò)層服務(wù)進行（可能的）增強
Internet傳輸層協(xié)議
可靠、按序的交付服務(wù)(TCP)
- 擁塞控制
- 流量控制
- 連接建立
不可靠的交付服務(wù)(UDP)
- 基于“盡力而為(best-effort)”的網(wǎng)絡(luò)層，沒有做可靠性方面的擴展
兩種服務(wù)均不保證
- 延遲
- 帶寬
多路復(fù)用和多路分用
如果某層的一個協(xié)議對應(yīng)直接上層的多個協(xié)議/實體，則需要復(fù)用/分用
接收端進行多路分用：傳輸層依據(jù)頭部信息將收到的segment交給正確的socket，即不同的進程（從下往上）
發(fā)送端進行多路復(fù)用：從多個socket接收數(shù)據(jù)，為每塊數(shù)據(jù)封裝上頭部信息，生成segment，交給網(wǎng)絡(luò)層（從上往下）
多路分用
盡管TCP和UDP不同，但它們都滿足以上格式
主機接收到IP數(shù)據(jù)報(datagram)
- 每個數(shù)據(jù)報攜帶源IP地址、目的IP地址
- 每個數(shù)據(jù)報攜帶一個傳輸層的段(segment)
- 每個段攜帶源端口號和目的端口號
主機收到segment之后，傳輸層協(xié)議提取IP地址和端口號信息，將segment導(dǎo)向相應(yīng)的socket
- TCP會做更多處理
無連接分用（面向UDP）
UDP的socket用二元組標(biāo)識
- (目的IP地址，目的端口號)
主機收到UDP段后
- 檢查段中的目的端口號
- 將UDP段導(dǎo)向綁定在該端口號的socket
來自不同源IP地址和/或源端口號的IP數(shù)據(jù)包被導(dǎo)向同一個socket
面向連接的分用
TCP的socket用四元組標(biāo)識
- 源IP地址
- 源端口號
- 目的IP地址
- 目的端口號
接收端利用所有的四個值將segment導(dǎo)向合適的socket
服務(wù)器可能同時支持多個TCP socket
- 每個socket用自己的四元組標(biāo)識
web服務(wù)器為每個客戶端開不同的socket
(TCP是一對一的，一個客戶機進程對應(yīng)一個服務(wù)器進程)
UDP
UDP：user datagram protocol（RFC 768）
UDP只是在IP協(xié)議上增加了兩點
基于Internet IP協(xié)議
- 復(fù)用/分用
- 簡單的錯誤校驗（只有校驗，沒有錯誤恢復(fù)）
（傳輸層提供的是一個端到端的協(xié)議，所以需要在傳輸層增加一個錯誤檢測機制）
“Best effort”服務(wù)，UDP段可能
- 丟失
- 非按序到達(dá)
無連接
- UDP發(fā)送方和接收方之間不需要握手
- 每個UDP段的處理獨立于其他段
UDP為什么存在？
- 無需建立連接（減少延遲）
- 實現(xiàn)簡單：無需維護連接狀態(tài)
- 頭部開銷少（UDP：8個字節(jié) TCP：20個字節(jié)）
- 沒有擁塞控制：應(yīng)用可更好地控制發(fā)送時間和速率
常用于流媒體應(yīng)用
- 容忍丟失
- 速率敏感
UDP還用于
- DNS
- SNMP
在UDP上實現(xiàn)可靠數(shù)據(jù)傳輸？
- 在應(yīng)用層增加可靠性機制
- 應(yīng)用特定的錯誤恢復(fù)機制
UDP校驗和(checksum)
目的：檢測UDP段在傳輸中是否發(fā)生錯誤（如位翻轉(zhuǎn)）
發(fā)送方：
- 將段的內(nèi)容視為16-Bit整數(shù)
- 檢驗和計算：計算所有整數(shù)的和，進位加在和的后面，將得到的值按位求反，得到校驗和
- 發(fā)送方將校驗和放入checksum字段
接收方：
- 計算所收到段的校驗和
- 將其與校驗和字段進行對比：1.不相等：檢測出錯誤 2.相等：沒有檢測出錯誤（但可能有錯誤，例如有兩個位發(fā)生了翻轉(zhuǎn)...）
校驗和計算示例：
- 注意：最高位進位必須被加進去，加到最末一位
可靠數(shù)據(jù)傳輸原理
可靠：不錯、不丟、不亂
可靠數(shù)據(jù)傳輸：rdt
信道的不可靠特性決定了可靠數(shù)據(jù)傳輸協(xié)議(rdt)的復(fù)雜性
-
可靠數(shù)據(jù)傳輸協(xié)議基本結(jié)構(gòu)：接口
可靠數(shù)據(jù)傳輸協(xié)議
利用狀態(tài)機（Finite State Machine, FSM）刻畫傳輸協(xié)議
rdt 1.0: 可靠信道上的可靠數(shù)據(jù)傳輸
假設(shè)：底層信道完全可靠：
- 不會發(fā)生錯誤（bit error）
- 不會丟棄分組
發(fā)送方和接收方的FSM獨立
rdt 2.0：產(chǎn)生位錯誤的信道
底層信道可能翻轉(zhuǎn)分組中的位(bit)
- 利用校驗和檢測位錯誤
從錯誤中恢復(fù)：
- 增加一個確認(rèn)機制(Acknowledgements, ACK): 接收方顯式地告知發(fā)送方分組已正確接收
- NAK：接收方顯式地告知發(fā)送方分組有錯誤
- 發(fā)送方收到NAK后，重傳分組
基于這種重傳機制的rdt協(xié)議稱為ARQ（Automatic Repeat reQuest）協(xié)議
Rdt 2.0中引入的新機制：
- 差錯檢測
- 接收方反饋控制消息：ACK/NAK
- 重傳
rdt 2.0的缺陷
如果ACK/NAK消息發(fā)生錯誤/被破壞， 有以下幾種解決方法：
- 為ACK/NAK增加校驗和，檢測并糾錯
- 發(fā)送方收到被破壞ACK/NCK時不知道接收方發(fā)生了什么，添加額外的控制消息
- 如果ACK/NAK壞掉，發(fā)送方重傳
- 不能簡單的重傳：產(chǎn)生重復(fù)分組
- 解決重復(fù)分組問題：序列號，發(fā)送方給每個分組增加序列號，接收方丟棄重復(fù)分組
rdt 2.2：無NAK消息協(xié)議
與rdt2.1功能相同，但是只使用ACK
- 接收方通過ACK告知最后一個被正確接收的分組
- 在ACK消息中顯式地加入被確認(rèn)分組的序列號
- 發(fā)送方收到重復(fù)ACK之后，采取與收到NAK消息相同的動作，重傳當(dāng)前分組
rdt2.2.png
rdt 3.0
如果信道既可能發(fā)生錯誤，也可能丟失分組，則rdt 2.x 的“校驗和+序列號+ACK+重傳”不夠用.
方法：發(fā)送方等待“合理”時間
- 如果沒收到ACK，重傳
- 如果分組或ACK只是延遲而不是丟了：重傳會產(chǎn)生充分，序列號機制能夠處理；接收方需在ACK中顯式告知所確認(rèn)的分組
-
需要定時器.
rdt3.0.png
rdt 3.0性能分析
rdt 3.0能夠正確工作，但性能很差
![]()
rdt 3.0停等操作.png
流水線機制：提高資源利用率
流水線協(xié)議：允許發(fā)送方在收到ACK之前連續(xù)發(fā)送多個分組
- 更大的序列號范圍（原本只有0和1，不夠）
- 發(fā)送方和/或接收方需要更大的存儲空間以緩存分組
滑動窗口協(xié)議（Sliding-window protocol）
窗口：
- 允許使用的序列號范圍
- 窗口尺寸為N：最多有N個等待確認(rèn)的消息
滑動窗口：
- 隨著協(xié)議的運行，窗口在序列號空間內(nèi)向前滑動
滑動窗口協(xié)議：GBN， SR
滑動窗口協(xié)議一：GBN
GBN：Go-Back-N協(xié)議
- 分組頭部包含K-bit序列號
-
窗口尺寸為N，最多允許N個分組未確認(rèn)
GBN.png - ACK(n):確認(rèn)序列號n（包含n）的分組均已被正確接收（是一個累積確認(rèn)機制），可能收到重復(fù)ACK
- 為空中的分組設(shè)置計時器timer
-
超市Timeout(n)事件：重傳序列號大于等于n，還未收到ACK的所有分組
GBN：發(fā)送方擴展FSM.png
ACK機制：發(fā)送擁有最高序列號的、已被正確接收的分組的ACK
- 可能產(chǎn)生重復(fù)的ACK
- 只需要記住唯一的expectedseqnum（所以是沒有緩存的，只記住一個expectedseqnum就好）
亂序到達(dá)的分組：
- 直接丟棄->接收方?jīng)]有緩存
-
重新確認(rèn)序列號最大的、按序到達(dá)的分組
GBN示例.png
如上圖所示，是一個GBN的示例。首先發(fā)0～3個pk，其中0和1正確到達(dá)，接收方發(fā)給發(fā)送方ACK。而pk2丟失了，此時接收方的expectedseqnum是2，然而2并未正確的到達(dá)。當(dāng)pk3到達(dá)時，此時接收方的expectedseqnum還是2，所以并不會接收pk3。由于ACK0和ACK1，窗口向后滑動，則開始發(fā)送pk4&5，它們和pk3一樣，由于expectedseqnum是2,而不會被接收，會被丟棄。此時發(fā)生了超時，而ACK2還未到達(dá)，故重新從pk2開始發(fā)送。
滑動窗口協(xié)議二：SR
SR：Selective Repeat協(xié)議
GBN有很明顯的缺陷：1.它是一個累積接收機制，如果有一個分組被丟棄，則后面的都會丟棄 2.從第一個被丟棄的分組開始重傳，會導(dǎo)致很多重復(fù)的重傳
SR的motivation:
- 接收方對每個分組單獨進行確認(rèn)：設(shè)置緩存機制，緩存亂序到達(dá)的分組
- 發(fā)送方只重傳那些沒收到ACK的分組：為每個分組設(shè)置定時器
- 發(fā)送方窗口：N個連續(xù)的序列號，限制已發(fā)送且未確認(rèn)的分組
