3.1傳輸層服務(wù)

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

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

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

■端系統(tǒng)運(yùn)行傳輸層協(xié)議§ 發(fā)送方：將應(yīng)用遞交的消息分成一個(gè)或多個(gè)的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 如果某層的一個(gè)協(xié)議對應(yīng)直接上層的多個(gè)協(xié)議/實(shí)體，則需要復(fù)用/分用

分用如何工作？

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

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

§ 每個(gè)段攜帶源端口號和目的端口號

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)向同一個(gè)Socket (源端口號提供返回地址）

面向連接的分用

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

§ 源IP地址

§ 源端口號

§ 目的IP地址

§ 目的端口號

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

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

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

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

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

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

UDP: User Datagram Protocol [RFC 768]

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

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

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

§ 丟失

§ 非按序到達(dá)

■無連接

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

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

UDP為什么存在?

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

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

?頭部開銷少

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

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

§ 容忍丟失

§ 速率敏感

v■UDP還用于

§DNS

§SNMP

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

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

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

目的：檢測UDP段在傳輸中是否發(fā)生錯(cuò)誤（如位翻轉(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)行對比

? 不相等：檢測出錯(cuò)誤

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

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

■什么是可靠？

§ 不錯(cuò)、不丟、不亂

■可靠數(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ù)傳輸

§ 但控制信息雙向流動(dòng)

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

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

v■底層信道完全可靠

?不會(huì)發(fā)生錯(cuò)誤(bit error)

?不會(huì)丟棄分組

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

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

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

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

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

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

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

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

§ 差錯(cuò)檢測

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

§ 重傳

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

Rdt 2.0有什么缺陷？

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

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

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

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

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

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

Rdt 2.1 vs. Rdt 2.0

v■發(fā)送方：·p為每個(gè)分組增加了序列號·p兩個(gè)序列號(0, 1)就夠用，為什么？（因?yàn)槭褂昧送５葏f(xié)議）·p需校驗(yàn)ACK/NAK消息是否發(fā)生錯(cuò)誤·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告知最后一個(gè)被正確接收的分組? 在ACK消息中顯式地加入被確認(rèn)分組的序列號（發(fā)送確定收到最后一個(gè)分組的序列號）

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

Rdt 3.0

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

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

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

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

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

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

§ ·需要定時(shí)器

Rdt 3.0性能分析

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

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

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

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

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

流水線協(xié)議

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

滑動(dòng)窗口協(xié)議

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

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

v■滑動(dòng)窗口

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

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

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

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

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

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

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

v■超時(shí)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■接收方對每個(gè)分組單獨(dú)進(jìn)行確認(rèn)

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

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

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

v■發(fā)送方窗口

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

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

SR協(xié)議

■發(fā)送方的時(shí)間和動(dòng)作

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

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

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

■接收方的時(shí)間和動(dòng)作

分組序號在[rcvbase, rcvbase+N-1]：發(fā)送ACK（n），超過則緩沖，在序號內(nèi)，滑動(dòng)窗口，并且將已經(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)§ 一個(gè)發(fā)送方，一個(gè)接收方

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連接包括：兩臺(tái)主機(jī)上的緩存、連接狀態(tài)變量、socket等

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

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

TCP:序列號和ACK

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

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

§ 希望接收到的下一個(gè)字節(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使用單一重傳定時(shí)器

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

§ 超時(shí)

§ 收到重復(fù)ACK

v■漸進(jìn)式

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

§ 暫不考慮流量控制

§ 暫不考慮擁塞控制

TCP RTT和超時(shí)

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

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

v■過短：

§ 不必要的重傳

v■過長：

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

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

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

§ 忽略重傳

v■SampleRTT變化

§ 測量多個(gè)SampleRTT，求平均值，形成RTT的估計(jì)值EstimatedRTT

TCP發(fā)送方事件

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

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

v■超時(shí)

§ 重傳引起超時(shí)的Segment

§ 重啟定時(shí)器（只重傳一個(gè)超時(shí)的那個(gè)）

v■收到ACK

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

? 更新SendBase

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

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

快速重傳機(jī)制

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

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

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

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

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

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

§ 快速重傳：在定時(shí)器超時(shí)之前即進(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)生一個(gè)值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)生一個(gè)值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ò)阻塞等原因會(huì)發(fā)送多個(gè)請求報(bào)文,這時(shí)服務(wù)器就會(huì)建立連接,浪費(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，會(huì)重新發(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)字段：兩個(gè)字節(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:§ 動(dòng)態(tài)調(diào)整以改變發(fā)送速率§ 反映所感知到的網(wǎng)絡(luò)擁塞

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

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

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

加性增—乘性減:?

AIMDv慢啟動(dòng): SS

加性增—乘性減: AIMD

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

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

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

TCP慢啟動(dòng): SS

v■TCP連接建立時(shí)，CongWin=1

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

§ 初始速率=20k bps

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

§ 希望快速增長

v■原理：

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

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

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

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

Threshold變量

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

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

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

Loss事件的處理

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

§CongWin切到一半

§ 然后線性增長v

?■Timeout事件:

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

§ 然后指數(shù)增長

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

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

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

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

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

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

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

TCP性能分析

TCP throughput:吞吐率

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

§ 忽略掉Slow start

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

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

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

TCP的公平性

TCP是公平的

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

v■公平性與UDP

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

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

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

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

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

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

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

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