3.1傳輸層服務

3.1.1傳輸層服務概述

傳輸層服務和協(xié)議

■傳輸層協(xié)議為運行在不同Host上的進程提供了一種邏輯通信機制

■端系統(tǒng)運行傳輸層協(xié)議§ 發(fā)送方：將應用遞交的消息分成一個或多個的Segment，并向下傳給網(wǎng)絡層。

§ 接收方：將接收到的segment組裝成消息，并向上交給應用層。

■傳輸層可以為應用提供多種協(xié)議§Internet上的TCP§Internet上的UD

傳輸層vs.網(wǎng)絡層

v■網(wǎng)絡層：提供主機之間的邏輯通信機制v■傳輸層：提供應用進程之間的邏輯通信機制§ 位于網(wǎng)絡層之上

§ 依賴于網(wǎng)絡層服務§ 對網(wǎng)絡層服務進行（可能的）增強

Internet傳輸層協(xié)議

v■可靠、按序的交付服務(TCP)§ 擁塞控制§ 流量控制§ 連接建立v■不可靠的交付服務(UDP)§ 基于“盡力而為(Best-effort)”的網(wǎng)絡層，沒有做（可靠性方面的）擴展■v兩種服務均不保證§ 延遲§ 帶寬

3.2多路復用和多路分用

Why？v 如果某層的一個協(xié)議對應直接上層的多個協(xié)議/實體，則需要復用/分用

分用如何工作？

v■主機接收到IP數(shù)據(jù)報(datagram)

§ 每個數(shù)據(jù)報攜帶源IP地址、目的IP地址?！?每個數(shù)據(jù)報攜帶一個傳輸層的段(Segment）。

§ 每個段攜帶源端口號和目的端口號

v■主機收到Segment之后，傳輸層協(xié)議提取IP地址和端口號信息，將Segment導向相應的Socket

`TCP做更多處理

無連接分用

■利用端口號創(chuàng)建

SocketDatagramSocket mySocket1 = new DatagramSocket(99111);

DatagramSocket mySocket2 = new DatagramSocket(99222);

■UDP的Socket用二元組標識§(目的IP地址，目的端口號)

■主機收到UDP段后§ 檢查段中的目的端口號§ 將UDP段導向綁定在該端口號的Socket

■來自不同源IP地址和/或源端口號的IP數(shù)據(jù)包被導向同一個Socket (源端口號提供返回地址）

面向連接的分用

■TCP的Socket用四元組標識

§ 源IP地址

§ 源端口號

§ 目的IP地址

§ 目的端口號

■接收端利用所有的四個值將Segment導向合適的Socketv

■服務器可能同時支持多個TCP Socket

§ 每個Socket用自己的四元組標識

■Web服務器為每個客戶端開不同的Socket

面向連接的分用：多線程Web服務器

3.3無連接傳輸協(xié)議-UDP

UDP: User Datagram Protocol [RFC 768]

v ■基于Internet IP協(xié)議§ 復用/分用§ 簡單的錯誤校驗

（端到端的原則：不能保證下面各層都有錯誤檢測機制，也不能保證在各層傳輸過程中不會出錯，所以需要在靠近應用層做一個錯誤校驗。）

■“Best effort”服務，UDP段可能

§ 丟失

§ 非按序到達

■無連接

§UDP發(fā)送方和接收方之間不需要握手

§ 每個UDP段的處理獨立于其他段

UDP為什么存在?

無需建立連接(減少延遲)

實現(xiàn)簡單：無需維護連接狀態(tài)

?頭部開銷少

沒有擁塞控制:應用可更好地控制發(fā)送時間和速率

v■常用于流媒體應用

§ 容忍丟失

§ 速率敏感

v■UDP還用于

§DNS

§SNMP

v■在UDP上實現(xiàn)可靠數(shù)據(jù)傳輸？

§ 在應用層增加可靠性機制§ 應用特定的錯誤恢復機制

UDP校驗和(checksum)

目的：檢測UDP段在傳輸中是否發(fā)生錯誤（如位翻轉(zhuǎn)）

v■發(fā)送方

§ 將段的內(nèi)容視為16-bit整數(shù)

§ 校驗和計算：計算所有整數(shù)的和，進位加在和的后面，將得到的值按位求反，得到校驗和

§ 發(fā)送方將校驗和放入校驗和字段

v■接收方§ 計算所收到段的校驗和

§ 將其與校驗和字段進行對比

? 不相等：檢測出錯誤

? 相等：沒有檢測出錯誤（但可能有錯誤）

3.4可靠數(shù)據(jù)傳輸?shù)脑?/b>

■什么是可靠？

§ 不錯、不丟、不亂

■可靠數(shù)據(jù)傳輸協(xié)議

§ 可靠數(shù)據(jù)傳輸對應用層、傳輸層、鏈路層都很重要

§ 網(wǎng)絡Top-10問題

§ 信道的不可靠特性決定了可靠數(shù)據(jù)傳輸協(xié)議(rdt)的復雜性

可靠數(shù)據(jù)傳輸協(xié)議基本結(jié)構(gòu):接口

可靠數(shù)據(jù)傳輸協(xié)議

v■漸進地設計可靠數(shù)據(jù)傳輸協(xié)議的發(fā)送方和接收方

v■只考慮單向數(shù)據(jù)傳輸

§ 但控制信息雙向流動

v■利用狀態(tài)機(Finite State Machine, FSM)刻畫傳輸協(xié)議

Rdt 1.0:可靠信道上的可靠數(shù)據(jù)傳輸

v■底層信道完全可靠

?不會發(fā)生錯誤(bit error)

?不會丟棄分組

v■發(fā)送方和接收方的FSM獨立

Rdt 2.0:產(chǎn)生位錯誤的信道（會有位錯誤）

v ■底層信道可能翻轉(zhuǎn)分組中的位(bit)§ 利用校驗和檢測位錯誤

v■如何從錯誤中恢復？

§ 確認機制(Acknowledgements, ACK):接收方顯式地告知發(fā)送方分組已正確接收

§NAK:接收方顯式地告知發(fā)送方分組有錯誤§ 發(fā)送方收到NAK后，重傳分組

v ■基于這種重傳機制的rdt協(xié)議稱為ARQ(Automatic Repeat reQuest)協(xié)議

v ■Rdt 2.0中引入的新機制

§ 差錯檢測

§ 接收方反饋控制消息: ACK/NAK

§ 重傳

停等協(xié)議：發(fā)送方?jīng)]有收到接收方的確認ACK不會發(fā)送下一個分組。

Rdt 2.0有什么缺陷？

v ■如果ACK/NAK消息發(fā)生錯誤/被破壞(corrupted)會怎么樣？? 為ACK/NAK增加校驗和，檢錯并糾錯（花銷較大）

? 發(fā)送方收到被破壞ACK/NAK時不知道接收方發(fā)生了什么，添加額外的控制消息(額外消息任然可能會壞掉）

? 如果ACK/NAK壞掉，發(fā)送方重傳

? 不能簡單的重傳：產(chǎn)生重復分組

v ■如何解決重復分組問題？

§序列號(Sequence number):發(fā)送方給每個分組增加序列號§ 接收方丟棄重復分組

Rdt 2.1 vs. Rdt 2.0

v■發(fā)送方：·p為每個分組增加了序列號·p兩個序列號(0, 1)就夠用，為什么？（因為使用了停等協(xié)議）·p需校驗ACK/NAK消息是否發(fā)生錯誤·p狀態(tài)數(shù)量翻倍p狀態(tài)必須“記住”“當前”的分組序列號v■接收方p·需判斷分組是否是重復p當前所處狀態(tài)提供了期望收到分組的序列號p·注意：接收方無法知道ACK/NAK是否被發(fā)送方正確收到

Rdt 2.2:無NAK消息協(xié)議

v ■與rdt 2.1功能相同，但是只使用ACK

v ■如何實現(xiàn)？

? 接收方通過ACK告知最后一個被正確接收的分組? 在ACK消息中顯式地加入被確認分組的序列號（發(fā)送確定收到最后一個分組的序列號）

v ■發(fā)送方收到重復ACK之后，采取與收到NAK消息相同的動作? 重傳當前分組

Rdt 3.0

■如果信道既可能發(fā)生錯誤，也可能丟失分組，怎么辦？

§ “校驗和+序列號+ ACK +重傳”夠用嗎？加定時器

v■方法：發(fā)送方等待“合理”時間§ ·如果沒收到ACK，重傳

§ ·如果分組或ACK只是延遲而不是丟了

?重傳會產(chǎn)生重復，序列號機制能夠處理

?接收方需在ACK中顯式告知所確認的分組

§ ·需要定時器

Rdt 3.0性能分析

v■Rdt 3.0能夠正確工作，但性能很差

v■示例：1Gbps鏈路，15ms端到端傳播延遲，1KB分組

§ 發(fā)送方利用率：發(fā)送方發(fā)送時間百分比

§ 在1Gbps鏈路上每30毫秒才發(fā)送一個分組è33KB/sec§ 網(wǎng)絡協(xié)議限制了物理資源的利用

3.5流水線機制與滑動窗口協(xié)議

流水線協(xié)議

■允許發(fā)送方在收到ACK之前連續(xù)發(fā)送多個分組§ 更大的序列號范圍§ 發(fā)送方和/或接收方需要更大的存儲空間以緩存分組

滑動窗口協(xié)議

v■滑動窗口協(xié)議: Sliding-window protocol

v■窗口§ 允許使用的序列號范圍§ 窗口尺寸為N：最多有N個等待確認的消息

v■滑動窗口

§ 隨著協(xié)議的運行，窗口在序列號空間內(nèi)向前滑動

v■滑動窗口協(xié)議：GBN, SR

Go-Back-N(GBN)協(xié)議:發(fā)送方

■分組頭部包含k-bit序列號

v■窗口尺寸為N，最多允許N個分組未確認（累積N確認，N之前的全部都確認收到了）

v■ACK(n):確認到序列號n(包含n)的分組均已被正確接收§ 可能收到重復ACK

■為空中的分組設置計時器(timer)

v■超時Timeout(n)事件:重傳序列號大于等于n，還未收到ACK的所有分組

■ACK機制:發(fā)送擁有最高序列號的、已被正確接收的分組的ACK§ 可能產(chǎn)生重復ACK

§ 只需要記住唯一的expectedseqnum

v■亂序到達的分組：

§ 直接丟棄

è接收方?jīng)]有緩存

§ 重新確認序列號最大的、按序到達的分組

Selective Repeat協(xié)議

v■GBN有什么缺陷？

v■接收方對每個分組單獨進行確認

§ 設置緩存機制，緩存亂序到達的分組

v■發(fā)送方只重傳那些沒收到ACK的分組

§ 為每個分組設置定時器

v■發(fā)送方窗口

§N個連續(xù)的序列號

§ 限制已發(fā)送且未確認的分組

SR協(xié)議

■發(fā)送方的時間和動作

從上層收到數(shù)據(jù)：檢查下一個可用分組的序號，如果序號是在窗口內(nèi)則打包發(fā)送，

超時：重發(fā)分組，重新定時

收到ACK（n），在窗口內(nèi)，就會將已確認的分組標記為已接收。如果這個分組是該窗內(nèi)最小分組即send_base就挪動窗口，發(fā)送窗口內(nèi)為發(fā)送的分組。

■接收方的時間和動作

分組序號在[rcvbase, rcvbase+N-1]：發(fā)送ACK（n），超過則緩沖，在序號內(nèi)，滑動窗口，并且將已經(jīng)確認有序的分組交付給上層。

序號在[rcvbase-N,rcvbase-1]：發(fā)送ACK（n）。

■其他情況：忽略

問題：序列號空間大小與窗口尺寸需滿足什么關(guān)系？§N_send+N_recv<=2k

3.6面向連接傳輸協(xié)議-TCP

TCP概述: RFCs-793, 1122, 1323, 2018, 2581

v■點對點§ 一個發(fā)送方，一個接收方

v■可靠的、按序的字節(jié)流v■流水線機制

§TCP擁塞控制和流量控制機制設置窗口尺寸

v■發(fā)送方/接收方緩存

v■全雙工(full-duplex)§ 同一連接中能夠傳輸雙向數(shù)據(jù)流

v■面向連接§ 通信雙方在發(fā)送數(shù)據(jù)之前必須建立連接。

§ 連接狀態(tài)只在連接的兩端中維護，在沿途節(jié)點中并不維護狀態(tài)。

§TCP連接包括：兩臺主機上的緩存、連接狀態(tài)變量、socket等

v■流量控制機制

TCP段結(jié)構(gòu)

TCP:序列號和ACK

序列號:§ 序列號指的是segment中第一個字節(jié)的編號，而不是segment的編號

§ 建立TCP連接時，雙方隨機選擇序列號ACKs:

§ 希望接收到的下一個字節(jié)的序列號

§ 累計確認：該序列號之前的所有字節(jié)均已被正確接收到Q:接收方如何處理亂序到達的Segment？

§A: TCP規(guī)范中沒有規(guī)定，由TCP的實現(xiàn)者做出決策

TCP可靠數(shù)據(jù)傳輸概述

v■TCP在IP層提供的不可靠服務基礎上實現(xiàn)可靠數(shù)據(jù)傳輸服務

v■流水線機制

v■累積確認

v■TCP使用單一重傳定時器

v■觸發(fā)重傳的事件

§ 超時

§ 收到重復ACK

v■漸進式

§ 暫不考慮重復ACK

§ 暫不考慮流量控制

§ 暫不考慮擁塞控制

TCP RTT和超時

v■問題：如何設置定時器的超時時間？

v■大于RTT§ 但是RTT是變化的

v■過短：

§ 不必要的重傳

v■過長：

§ 對段丟失時間反應慢

v■問題：如何估計RTT？

v■SampleRTT:測量從段發(fā)出去到收到ACK的時間

§ 忽略重傳

v■SampleRTT變化

§ 測量多個SampleRTT，求平均值，形成RTT的估計值EstimatedRTT

TCP發(fā)送方事件

v■從應用層收到數(shù)據(jù)§ 創(chuàng)建Segment§ 序列號是Segment第一個字節(jié)的編號

§ 開啟計時器§ 設置超時時間：TimeOutInterval

v■超時

§ 重傳引起超時的Segment

§ 重啟定時器（只重傳一個超時的那個）

v■收到ACK

§ 如果確認此前未確認的Segment

? 更新SendBase

? 如果窗口中還有未被確認的分組，重新啟動定時器

TCP發(fā)送端程序 （偽碼）

快速重傳機制

v■TCP的實現(xiàn)中，如果發(fā)生超時，超時時間間隔將重新設置，即將超時時間間隔加倍，導致其很大

§ 重發(fā)丟失的分組之前要等待很長時間

v■通過重復ACK檢測分組丟失

§Sender會背靠背地發(fā)送多個分組

§ 如果某個分組丟失，可能會引發(fā)多個重復的ACK

v■如果sender收到對同一數(shù)據(jù)的3個ACK，則假定該數(shù)據(jù)之后的段已經(jīng)丟失

§ 快速重傳：在定時器超時之前即進行重傳

TCP流量控制

TCP連接管理

v■TCP sender和receiver在傳輸數(shù)據(jù)前需要建立連接

v■初始化TCP變量

§Seq. #

§Buffer和流量控制信息

v■Client：連接發(fā)起者Socket clientSocket = new Socket("hostname","port number");

v■Server:等待客戶連接請求Socket connectionSocket = welcomeSocket.accept();

三次握手協(xié)議：

（1）[endif]第一次握手：Client將標志位SYN置為1，隨機產(chǎn)生一個值seq=client_isn，并將該數(shù)據(jù)包發(fā)送給Server，Client進入SYN_SENT狀態(tài)，等待Server確認。

（2）第二次握手：Server收到數(shù)據(jù)包后由標志位SYN=1知道Client請求建立連接，Server將標志位SYN和ACK都置為1，ack=client_isn+1，隨機產(chǎn)生一個值seq=server_isn，并將該數(shù)據(jù)包發(fā)送給Client以確認連接請求，Server進入SYN_RCVD狀態(tài)。（3）第三次握手：Client收到確認后，檢查ack是否為client_isn+1，ACK是否為1，如果正確則將標志位ACK置為1，ack=server_isn+1，并將該數(shù)據(jù)包發(fā)送給Server，Server檢查ack是否為server_isn+1，ACK是否為1，如果正確則連接建立成功，Client和Server進入ESTABLISHED狀態(tài)，完成三次握手，隨后Client與Server之間可以開始傳輸數(shù)據(jù)了。

TCP為什么是三次握手，為什么不是兩次或四次？

如果兩次握手的話,客戶端有可能因為網(wǎng)絡阻塞等原因會發(fā)送多個請求報文,這時服務器就會建立連接,浪費掉許多服務器的資源.如果四次握手:三次已經(jīng)互相確認了可以進行連接了，在來一次確認浪費資源

TCP連接管理：關(guān)閉

Step 1: client向server發(fā)送TCP FIN控制segment

Step 2: server收到FIN,回復ACK.關(guān)閉連接,發(fā)送FIN.

Step 3: client收到FIN,回復ACK.

§ 進入“等待” –如果收到FIN，會重新發(fā)送ACK

Step 4: server收到ACK.連接關(guān)閉

3.7擁塞控制原理

擁塞(Congestion)

v■非正式定義：“太多發(fā)送主機發(fā)送了太多數(shù)據(jù)或者發(fā)送速度太快，以至于網(wǎng)絡無法處理”

v■表現(xiàn)：§ 分組丟失（路由器緩存溢出）

§ 分組延遲過大（在路由器緩存中排隊）

v■擁塞控制vs.流量控制

擁塞控制的方法

v■端到端擁塞控制：

§ 網(wǎng)絡層不需要顯式的提供支持

§ 端系統(tǒng)通過觀察loss，delay等網(wǎng)絡行為判斷是否發(fā)生擁塞

§TCP采取這種方法

v■網(wǎng)絡輔助的擁塞控制：

§ 路由器向發(fā)送方顯式地反饋網(wǎng)絡擁塞信息§ 簡單的擁塞指示(1bit)：SNA,DECbit, TCP/IP ECN, ATM)

§ 指示發(fā)送方應該采取何種速率

案例：ATM ABR擁塞控制

v■ABR：available bit rate

§ ·“彈性服務”

§· 如果發(fā)送方路徑“underloaded”?使用可用帶寬

§ ·如果發(fā)送方路徑擁塞?將發(fā)送速率降到最低保障速率

v■資源管理單元RM(resource management cells）

§ 發(fā)送方發(fā)送§ 交換機設置RM cell位(網(wǎng)絡輔助)

?NI bit: rate不許增長

?CI bit:擁塞指示§RM cell由接收方返回給發(fā)送方

v ■在RM cell中有顯式的速率(ER)字段：兩個字節(jié)

§ 擁塞的交換機可以將ER置為更低的值

§ 發(fā)送方獲知路徑所能支持的最小速率

v ■數(shù)據(jù)cell中的EFCI位:擁塞的交換機將其設為1

§ 如果RM cell前面的data cell的EFCI位被設為1，那么發(fā)送方在返回的RM cell中置CI位

3.8TCP擁塞控制

TCP擁塞控制的基本原理

v■Sender限制發(fā)送速率LastByteSent-LastByteAcked<= CongWin.

v■CongWin:§ 動態(tài)調(diào)整以改變發(fā)送速率§ 反映所感知到的網(wǎng)絡擁塞

■問題：如何感知網(wǎng)絡擁塞？

Loss事件=timeout或3個重復ACKv發(fā)生loss事件后，發(fā)送方降低速率

■如何合理地調(diào)整發(fā)送速率？

加性增—乘性減:?

AIMDv慢啟動: SS

加性增—乘性減: AIMD

v■原理：逐漸增加發(fā)送速率，謹慎探測可用帶寬，直到發(fā)生lossv

■方法: AIMD§Additive Increase:每個RTT將CongWin增大一個MSS——擁塞避免

§Multiplicative Decrease:發(fā)生loss后將CongWin減半

TCP慢啟動: SS

v■TCP連接建立時，CongWin=1

§ 例：MSS=500 byte,RTT=200msec

§ 初始速率=20k bps

■可用帶寬可能遠遠高于初始速率：

§ 希望快速增長

v■原理：

§ 當連接開始時，指數(shù)性增長

v■指數(shù)性增長§ 每個RTT將CongWin翻倍

§ 收到每個ACK進行操作v

■初始速率很慢，但是快速攀升

Threshold變量

■Q:何時應該指數(shù)性增長切換為線性增長(擁塞避免)?

A:當CongWin達到Loss事件前值的1/2時.

■實現(xiàn)方法:v 變量ThresholdvLoss事件發(fā)生時, Threshold被設為Loss事件前CongWin值的1/2。

Loss事件的處理

v ■3個重復ACKs:

§CongWin切到一半

§ 然后線性增長v

?■Timeout事件:

§CongWin直接設為1個MSS

§ 然后指數(shù)增長

§ 達到threshold后,再線性增長

注：3個重復ACKs表示網(wǎng)絡還能夠傳輸一些segments，timeout事件表明擁塞為嚴重

TCP擁塞控制:總結(jié)

■當congwin小于Threadhold，發(fā)送方處于滿啟動狀態(tài)，congwin以指數(shù)增長。

■當congwin在Threadhold以上，發(fā)送方處于擁塞避免階段，congwin以線性增長

■當出現(xiàn)擁塞事件的時候，Threadhold更新為congwin/2，congwin為Threadhold大小

■當出現(xiàn)超時事件時，Threadhold更新為congwin/2，congwin設置為1

TCP性能分析

TCP throughput:吞吐率

v■給定擁塞窗口大小和RTT，TCP的平均吞吐率是多少？

§ 忽略掉Slow start

■假定發(fā)生超時時CongWin的大小為W，吞吐率是W/RTT

v■超時后，CongWin=W/2，吞吐率是W/2RTT

v■平均吞吐率為：0.75W/RTT

TCP的公平性

TCP是公平的

連接1,2的速率增加到擁塞時同時減半，然后有增加，最終會收斂于45°斜線

v■公平性與UDP

§ 多媒體應用通常不使用TCP，以免被擁塞控制機制限制速率

§ 使用UDP：以恒定速率發(fā)送，能夠容忍丟失

§ 產(chǎn)生了不公平

v■公平性與并發(fā)TCP連接

§ 某些應用會打開多個并發(fā)連接§Web瀏覽器§ 產(chǎn)生公平性問題v

■例子：鏈路速率為R，已有9個連接

§ 新來的應用請求1個TCP，獲得R/10的速率

§ 新來的應用請求11個TCP，獲得R/2的速率