3.1傳輸層服務(wù)

3.1.1傳輸層服務(wù)概述

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

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

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

§ 接收方：將接收到的segment組裝成消息刘绣，并向上交給應(yīng)用層柄延。

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

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

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

§ 依賴于網(wǎng)絡(luò)層服務(wù)§ 對網(wǎng)絡(luò)層服務(wù)進(jìn)行（可能的）增強(qiáng)

Internet傳輸層協(xié)議

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

3.2多路復(fù)用和多路分用

Why彼城？v 如果某層的一個協(xié)議對應(yīng)直接上層的多個協(xié)議/實(shí)體，則需要復(fù)用/分用

分用如何工作候生？

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

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

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

v■主機(jī)收到Segment之后硅确，傳輸層協(xié)議提取IP地址和端口號信息肿孵，將Segment導(dǎo)向相應(yīng)的Socket

`TCP做更多處理

無連接分用

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

SocketDatagramSocket mySocket1 = new DatagramSocket(99111);

DatagramSocket mySocket2 = new DatagramSocket(99222);

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

■主機(jī)收到UDP段后§ 檢查段中的目的端口號§ 將UDP段導(dǎo)向綁定在該端口號的Socket

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

面向連接的分用

■TCP的Socket用四元組標(biāo)識

§ 源IP地址

§ 源端口號

§ 目的IP地址

§ 目的端口號

■接收端利用所有的四個值將Segment導(dǎo)向合適的Socketv

■服務(wù)器可能同時支持多個TCP Socket

§ 每個Socket用自己的四元組標(biāo)識

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

面向連接的分用：多線程Web服務(wù)器

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

UDP: User Datagram Protocol [RFC 768]

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

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

■“Best effort”服務(wù)大莫，UDP段可能

§ 丟失

§ 非按序到達(dá)

■無連接

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

§ 每個UDP段的處理獨(dú)立于其他段

UDP為什么存在?

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

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

?頭部開銷少

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

v■常用于流媒體應(yīng)用

§ 容忍丟失

§ 速率敏感

v■UDP還用于

§DNS

§SNMP

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

§ 在應(yīng)用層增加可靠性機(jī)制§ 應(yīng)用特定的錯誤恢復(fù)機(jī)制

UDP校驗(yàn)和(checksum)

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

v■發(fā)送方

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

§ 校驗(yàn)和計(jì)算：計(jì)算所有整數(shù)的和只厘，進(jìn)位加在和的后面烙丛，將得到的值按位求反，得到校驗(yàn)和

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

v■接收方§ 計(jì)算所收到段的校驗(yàn)和

§ 將其與校驗(yàn)和字段進(jìn)行對比

? 不相等：檢測出錯誤

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

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

■什么是可靠羔味？

§ 不錯河咽、不丟、不亂

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

§ 可靠數(shù)據(jù)傳輸對應(yīng)用層赋元、傳輸層忘蟹、鏈路層都很重要

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

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

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

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

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

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

§ 但控制信息雙向流動

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

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

v■底層信道完全可靠

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

?不會丟棄分組

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

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

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

v■如何從錯誤中恢復(fù)？

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

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

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

v ■Rdt 2.0中引入的新機(jī)制

§ 差錯檢測

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

§ 重傳

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

Rdt 2.0有什么缺陷？

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

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

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

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

v ■如何解決重復(fù)分組問題？

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

Rdt 2.1 vs. Rdt 2.0

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

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

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

v ■如何實(shí)現(xiàn)藤乙？

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

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

Rdt 3.0

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

§ “校驗(yàn)和+序列號+ ACK +重傳”夠用嗎敞曹？加定時器

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

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

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

?接收方需在ACK中顯式告知所確認(rèn)的分組

§ ·需要定時器

Rdt 3.0性能分析

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

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

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

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

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

流水線協(xié)議

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

滑動窗口協(xié)議

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

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

v■滑動窗口

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

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

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

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

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

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

■為空中的分組設(shè)置計(jì)時器(timer)

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

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

§ 只需要記住唯一的expectedseqnum

v■亂序到達(dá)的分組：

§ 直接丟棄

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

§ 重新確認(rèn)序列號最大的锐极、按序到達(dá)的分組

Selective Repeat協(xié)議

v■GBN有什么缺陷笙僚？

v■接收方對每個分組單獨(dú)進(jìn)行確認(rèn)

§ 設(shè)置緩存機(jī)制，緩存亂序到達(dá)的分組

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

§ 為每個分組設(shè)置定時器

v■發(fā)送方窗口

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

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

SR協(xié)議

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

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

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

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

■接收方的時間和動作

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

序號在[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■點(diǎn)對點(diǎn)§ 一個發(fā)送方，一個接收方

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

§TCP擁塞控制和流量控制機(jī)制設(shè)置窗口尺寸

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

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

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

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

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

v■流量控制機(jī)制

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

TCP:序列號和ACK

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

§ 建立TCP連接時种玛，雙方隨機(jī)選擇序列號ACKs:

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

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

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

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

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

v■流水線機(jī)制

v■累積確認(rèn)

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

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

§ 超時

§ 收到重復(fù)ACK

v■漸進(jìn)式

§ 暫不考慮重復(fù)ACK

§ 暫不考慮流量控制

§ 暫不考慮擁塞控制

TCP RTT和超時

v■問題：如何設(shè)置定時器的超時時間蒂誉？

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

v■過短：

§ 不必要的重傳

v■過長：

§ 對段丟失時間反應(yīng)慢

v■問題：如何估計(jì)RTT？

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

§ 忽略重傳

v■SampleRTT變化

§ 測量多個SampleRTT距帅，求平均值右锨，形成RTT的估計(jì)值EstimatedRTT

TCP發(fā)送方事件

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

§ 開啟計(jì)時器§ 設(shè)置超時時間：TimeOutInterval

v■超時

§ 重傳引起超時的Segment

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

v■收到ACK

§ 如果確認(rèn)此前未確認(rèn)的Segment

? 更新SendBase

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

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

快速重傳機(jī)制

v■TCP的實(shí)現(xiàn)中碌秸，如果發(fā)生超時绍移，超時時間間隔將重新設(shè)置，即將超時時間間隔加倍讥电，導(dǎo)致其很大

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

v■通過重復(fù)ACK檢測分組丟失

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

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

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

§ 快速重傳：在定時器超時之前即進(jìn)行重傳

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將標(biāo)志位SYN置為1恩敌，隨機(jī)產(chǎn)生一個值seq=client_isn瞬测，并將該數(shù)據(jù)包發(fā)送給Server，Client進(jìn)入SYN_SENT狀態(tài)纠炮，等待Server確認(rèn)月趟。

（2）第二次握手：Server收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道Client請求建立連接，Server將標(biāo)志位SYN和ACK都置為1恢口，ack=client_isn+1孝宗，隨機(jī)產(chǎn)生一個值seq=server_isn，并將該數(shù)據(jù)包發(fā)送給Client以確認(rèn)連接請求耕肩，Server進(jìn)入SYN_RCVD狀態(tài)因妇。（3）第三次握手：Client收到確認(rèn)后问潭，檢查ack是否為client_isn+1，ACK是否為1婚被，如果正確則將標(biāo)志位ACK置為1狡忙，ack=server_isn+1，并將該數(shù)據(jù)包發(fā)送給Server址芯，Server檢查ack是否為server_isn+1去枷，ACK是否為1，如果正確則連接建立成功是复，Client和Server進(jìn)入ESTABLISHED狀態(tài)，完成三次握手竖螃，隨后Client與Server之間可以開始傳輸數(shù)據(jù)了淑廊。

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

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

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

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

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

Step 3: client收到FIN,回復(fù)ACK.

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

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

3.7擁塞控制原理

擁塞(Congestion)

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

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

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

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

擁塞控制的方法

v■端到端擁塞控制：

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

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

§TCP采取這種方法

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

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

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

案例：ATM ABR擁塞控制

v■ABR：available bit rate

§ ·“彈性服務(wù)”

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

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

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

§ 發(fā)送方發(fā)送§ 交換機(jī)設(shè)置RM cell位(網(wǎng)絡(luò)輔助)

?NI bit: rate不許增長

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

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

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

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

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

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

3.8TCP擁塞控制

TCP擁塞控制的基本原理

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

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

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

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

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

加性增—乘性減:?

AIMDv慢啟動: SS

加性增—乘性減: AIMD

v■原理：逐漸增加發(fā)送速率酬核，謹(jǐn)慎探測可用帶寬蜜另，直到發(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

■可用帶寬可能遠(yuǎn)遠(yuǎn)高于初始速率：

§ 希望快速增長

v■原理：

§ 當(dāng)連接開始時嫡意，指數(shù)性增長

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

§ 收到每個ACK進(jìn)行操作v

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

Threshold變量

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

A:當(dāng)CongWin達(dá)到Loss事件前值的1/2時.

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

Loss事件的處理

v ■3個重復(fù)ACKs:

§CongWin切到一半

§ 然后線性增長v

?■Timeout事件:

§CongWin直接設(shè)為1個MSS

§ 然后指數(shù)增長

§ 達(dá)到threshold后,再線性增長

注：3個重復(fù)ACKs表示網(wǎng)絡(luò)還能夠傳輸一些segments蔬螟，timeout事件表明擁塞為嚴(yán)重

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

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

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

■當(dāng)出現(xiàn)擁塞事件的時候菠齿，Threadhold更新為congwin/2佑吝，congwin為Threadhold大小

■當(dāng)出現(xiàn)超時事件時，Threadhold更新為congwin/2绳匀，congwin設(shè)置為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

§ 多媒體應(yīng)用通常不使用TCP开仰，以免被擁塞控制機(jī)制限制速率

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

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

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

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

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

§ 新來的應(yīng)用請求1個TCP众弓，獲得R/10的速率

§ 新來的應(yīng)用請求11個TCP，獲得R/2的速率