第03章 傳輸層服務(wù)與協(xié)議

《計算機網(wǎng)絡(luò)與信息安全》第三章傳輸層服務(wù)與協(xié)議主要內(nèi)容本章學(xué)習(xí)目標(biāo)理解傳輸層服務(wù)掌握傳輸層復(fù)用/分解方法掌握UDP協(xié)議掌握TCP協(xié)議TCP協(xié)議特點TCP段結(jié)構(gòu)TCP可靠數(shù)據(jù)傳輸TCP流量控制TCP連接控制TCP擁塞控制主要內(nèi)容第一節(jié)

傳輸層服務(wù)第二節(jié)傳輸層多路復(fù)用與分解第三節(jié)停等協(xié)議與滑動窗口協(xié)議第四節(jié)UDP協(xié)議第五節(jié)TCP協(xié)議一、TCP段結(jié)構(gòu)二、TCP連接管理三、TCP可靠數(shù)據(jù)傳輸四、TCP流量控制五、TCP擁塞控制2本章重點與難點本章重點可靠數(shù)據(jù)傳輸?shù)幕驹硗?等協(xié)議典型滑動窗口協(xié)議（GBN、SR協(xié)議）TCP的段結(jié)構(gòu)TCP的連接建立與斷開過程TCP序列號以及確認(rèn)序列號TCP可靠數(shù)據(jù)傳輸?shù)臋C制TCP流量控制TCP擁塞控制方法本章難點停-等協(xié)議與滑動窗口協(xié)議的理解停-等協(xié)議與滑動窗口協(xié)議信道利用率的計算TCP協(xié)議的連接管理TCP段序列號TCP協(xié)議的擁塞控制慢啟動擁塞避免TCP發(fā)送窗口的變化3第一節(jié)

傳輸層服務(wù)李全龍傳輸層？3第一節(jié)

傳輸層服務(wù)物理層數(shù)據(jù)鏈路層網(wǎng)絡(luò)層物理層數(shù)據(jù)鏈路層網(wǎng)絡(luò)層傳輸層應(yīng)用層物理層數(shù)據(jù)鏈路層網(wǎng)絡(luò)層傳輸層應(yīng)用層主機A主機B路由器傳輸介質(zhì)傳輸介質(zhì)協(xié)議協(xié)議協(xié)議協(xié)議協(xié)議協(xié)議協(xié)議物理層數(shù)據(jù)鏈路層交換機協(xié)議協(xié)議協(xié)議傳輸介質(zhì)互聯(lián)網(wǎng)互聯(lián)網(wǎng)傳輸層？3第一節(jié)

傳輸層服務(wù)傳輸層服務(wù)和協(xié)議傳輸層協(xié)議為運行在不同Host上的進程提供了一種邏輯通信機制端系統(tǒng)運行傳輸層協(xié)議發(fā)送方：將應(yīng)用遞交的消息分成一個或多個的Segment，并向下傳給網(wǎng)絡(luò)層。接收方：將接收到的segment組裝成消息，并向上交給應(yīng)用層。傳輸層可以為應(yīng)用提供多種協(xié)議Internet的TCPInternet的UDP3applicationtransportnetworkdatalinkphysicalapplicationtransportnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicallogicalend-endtransport第一節(jié)

傳輸層服務(wù)傳輸層vs.網(wǎng)絡(luò)層網(wǎng)絡(luò)層：提供主機之間的邏輯通信機制傳輸層：提供應(yīng)用進程之間的邏輯通信機制位于網(wǎng)絡(luò)層之上依賴于網(wǎng)絡(luò)層服務(wù)對網(wǎng)絡(luò)層服務(wù)進行（可能的）增強4家庭類比:12個孩子給12個孩子發(fā)信應(yīng)用進程=孩子應(yīng)用消息=信封里的信主機=房子傳輸層協(xié)議=李雷和韓梅梅網(wǎng)絡(luò)層協(xié)議=郵政服務(wù)第一節(jié)

傳輸層服務(wù)Internet傳輸層協(xié)議可靠、按序的交付服務(wù)(TCP)擁塞控制流量控制連接建立不可靠的交付服務(wù)(UDP)基于“盡力而為(Best-effort)”的網(wǎng)絡(luò)層，沒有做（可靠性方面的）擴展兩種服務(wù)均不保證延遲帶寬4applicationtransportnetworkdatalinkphysicalapplicationtransportnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicallogicalend-endtransport第一節(jié)

傳輸層服務(wù)第二節(jié)

傳輸層多路復(fù)用與分解李全龍為什么需要多路復(fù)用/分用？3第二節(jié)

傳輸層多路復(fù)用/分解NPP1P2P3N+1層N層PDU上層協(xié)議IDQ：為什么需要實現(xiàn)復(fù)用與分解？如何實現(xiàn)復(fù)用與分解？A：如果某層的一個協(xié)議/實體直接為上層的多個協(xié)議/實體提供服務(wù)，

則需要復(fù)用/分用復(fù)用與分解只在傳輸層進行嗎？傳輸層多路復(fù)用/分用？3傳輸層如何實現(xiàn)復(fù)用與分解功能？可能通過其他方式實現(xiàn)復(fù)用與分解嗎？第二節(jié)

傳輸層多路復(fù)用/分解傳輸層分用如何工作？主機接收到IP數(shù)據(jù)報(datagram)每個數(shù)據(jù)報攜帶源IP地址、目的IP地址。每個數(shù)據(jù)報攜帶一個傳輸層的段(Segment）。每個段攜帶源端口號和目的端口號主機收到Segment之后，傳輸層協(xié)議提取IP地址和端口號信息，將Segment導(dǎo)向相應(yīng)的SocketTCP做更多處理13源端口號#目的端口號#32bits應(yīng)用數(shù)據(jù)(message)其他頭部信息TCP/UDP段格式第二節(jié)

傳輸層多路復(fù)用/分解傳輸層無連接分用創(chuàng)建Socket并綁定端口號UDP的Socket用二元組標(biāo)識(目的IP地址，目的端口號)主機收到UDP段后檢查段中的目的端口號將UDP段導(dǎo)向綁定在該端口號的Socket來自不同源IP地址和/或源端口號的IP數(shù)據(jù)包被導(dǎo)向同一個Socket14第二節(jié)

傳輸層多路復(fù)用/分解傳輸層無連接分用15第二節(jié)

傳輸層多路復(fù)用/分解傳輸層面向連接的分用TCP的Socket用四元組標(biāo)識源IP地址源端口號目的IP地址目的端口號接收端利用所有的四個值將Segment導(dǎo)向正確的Socket16服務(wù)器可能同時支持多個TCPSocket每個Socket用自己的四元組標(biāo)識Web服務(wù)器為每個客戶端創(chuàng)建不同的Socket第二節(jié)

傳輸層多路復(fù)用/分解傳輸層面向連接的分用17第二節(jié)

傳輸層多路復(fù)用/分解第三節(jié)

停等協(xié)議與滑動窗口協(xié)議18李全龍可靠數(shù)據(jù)傳輸原理什么是可靠？不錯、不丟、不亂、不多可靠數(shù)據(jù)傳輸協(xié)議可靠數(shù)據(jù)傳輸對應(yīng)用層、傳輸層、鏈路層都很重要網(wǎng)絡(luò)Top-10問題信道的不可靠特性決定了可靠數(shù)據(jù)傳輸?shù)膹?fù)雜性實現(xiàn)可靠數(shù)據(jù)傳輸?shù)闹饕胧翰铄e檢測確認(rèn)（ACK/NAK）重傳序號計時器19第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議停-等協(xié)議發(fā)送方發(fā)送經(jīng)過差錯編碼和編號的報文段，等待接收方的確認(rèn)；接收方如果正確接收報文段，即差錯檢測無誤、且序號正確，則接收報文段，并向發(fā)送方發(fā)送ACK，否則丟棄報文段，并向發(fā)送方發(fā)送NAK；發(fā)送方如果收到ACK，則繼續(xù)發(fā)送后續(xù)報文段，否則重發(fā)剛剛發(fā)送的報文段。幾個要點：關(guān)于差錯檢測，報文段和ACK或NAK數(shù)據(jù)包均需進行差錯編碼關(guān)于序列號，序列號字段只需要1位即可關(guān)于ACK和NAK，可以只使用ACK進行確認(rèn)，只需在ACK數(shù)據(jù)包中帶上所確認(rèn)的報文段序列號關(guān)于ACK或NAK差錯，“有錯推斷”原則20第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議停-等協(xié)議典型交互場景21第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議停等協(xié)議的信道利用率22

第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議停-等協(xié)議性能分析停-等協(xié)議能夠正確工作，但性能很差停-等協(xié)議信道利用率：

其中，是報文段的傳輸時延，是ACK報文段的傳輸時延，RTT是往返時間。例如：1Gbps鏈路，15ms端到端傳播延遲，1KB分組，忽略ACK報文段大小，則發(fā)送方利用率：發(fā)送方發(fā)送時間百分比為0.027%在1Gbps鏈路上每30毫秒才發(fā)送一個分組33KB/sec網(wǎng)絡(luò)協(xié)議限制了物理資源的利用23第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議停等操作24發(fā)送數(shù)據(jù)包的第一個比特,t=0senderreceiverRTT

發(fā)送數(shù)據(jù)包的最后一個比特,t=L/R第一個比特到達最后一個比特到達，發(fā)送ACKACK到達，發(fā)送下一個包

t=RTT+L/R第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議流水線機制：提高信道利用率25senderreceiverRTT利用率提高到3倍第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議發(fā)送數(shù)據(jù)包的第一個比特,t=0發(fā)送數(shù)據(jù)包的最后一個比特,t=L/R第一個比特到達最后一個比特到達，發(fā)送ACKACK到達，發(fā)送下一個包

t=RTT+L/R流水線協(xié)議允許發(fā)送方在收到ACK之前連續(xù)發(fā)送多個分組更大的序列號范圍發(fā)送方和/或接收方需要更大的存儲空間以緩存分組典型的流水線可靠傳輸協(xié)議是滑動窗口協(xié)議窗口允許使用的序列號范圍窗口尺寸為N：最多有N個等待確認(rèn)的消息滑動窗口隨著協(xié)議的運行，窗口在序列號空間內(nèi)向前滑動滑動窗口協(xié)議：GBN,SR26第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議滑動窗口協(xié)議27第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議滑動窗口協(xié)議的信道利用率28

第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議Go-Back-N(GBN)協(xié)議:發(fā)送方分組頭部包含k-bit序列號窗口尺寸為Ws，最多允許Ws個分組未確認(rèn)ACK(n):確認(rèn)到序列號n(包含n)的分組均已被正確接收累積確認(rèn)可能收到重復(fù)ACK為“空中”的分組設(shè)置計時器(timer)超時Timeout(n)事件:重傳序列號大于等于n，還未收到ACK的所有分組29第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議GBN:接收方30接收窗口WR=1ACK機制:發(fā)送擁有最高序列號的、已被正確接收的分組的ACK可能產(chǎn)生重復(fù)ACK只需要記住唯一的期望接收序號亂序到達的分組：直接丟棄

接收方?jīng)]有緩存重新確認(rèn)序列號最大的、按序到達的分組第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議GBN示例31sendpkt0sendpkt1sendpkt2sendpkt3(wait)senderreceiverreceivepkt0,sendack0receivepkt1,sendack1

receivepkt3,discard,(re)sendack1sendpkt2sendpkt3sendpkt4sendpkt5Xlosspkt2timeoutreceivepkt4,discard,(re)sendack1receivepkt5,discard,(re)sendack1rcvpkt2,deliver,sendack2rcvpkt3,deliver,sendack3rcvpkt4,deliver,sendack4rcvpkt5,deliver,sendack5ignoreduplicateACKsenderwindow(Ws=4)012345678012345678012345678012345678rcvack0,sendpkt4012345678012345678012345678012345678012345678012345678rcvack1,sendpkt5第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議例題32【例1】數(shù)據(jù)鏈路層采用后退N幀（GBN）協(xié)議，發(fā)送方已經(jīng)發(fā)送了編號為0～7的幀。當(dāng)計時器超時時，若發(fā)送方只收到0、2、3號幀的確認(rèn)，則發(fā)送方需要重發(fā)的幀數(shù)是多少？分別是那幾個幀？【解】根據(jù)GBN協(xié)議工作原理，GBN協(xié)議的確認(rèn)是累積確認(rèn)，所以此時發(fā)送端需要重發(fā)的幀數(shù)是4個，依次分別是4、5、6、7號幀。第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議SelectiveRepeat（SR）協(xié)議GBN有什么缺陷？SR協(xié)議：接收方對每個分組單獨進行確認(rèn)設(shè)置緩存機制，緩存亂序到達的分組發(fā)送方只重傳那些沒收到ACK的分組為每個分組設(shè)置定時器發(fā)送方窗口N個連續(xù)的序列號限制已發(fā)送且未確認(rèn)的分組數(shù)接收窗口可以接收的無差錯到達的分組序號33第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議SR協(xié)議：發(fā)送方/接收方窗口34第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議SR協(xié)議-發(fā)送方35上層調(diào)用，請求發(fā)送數(shù)據(jù):如果“下一可用序號”位于發(fā)送方窗口內(nèi)，則將數(shù)據(jù)封裝成SR分組，并用“下一可用序號”進行編號，發(fā)送分組；否則或者將數(shù)據(jù)緩存或者返回給上層以便以后傳輸。定時器超時，timeout(n):重發(fā)n號分組，并重啟計時器收到ACK(n)，n在當(dāng)前窗口范圍內(nèi)：標(biāo)記n號分組已接收如果n是當(dāng)前未被確認(rèn)分組序號的最小序號，則滑動窗口到下一個最小未被確認(rèn)分組序號發(fā)送方第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議SR協(xié)議-接收方36接收到n號分組，n在當(dāng)前接收窗口范圍內(nèi)：發(fā)送ACK(n)序號不連續(xù)：緩存序號連續(xù)：向上層提交數(shù)據(jù)（包括緩存中連續(xù)的分組），滑動窗口接收到n號分組，n在[當(dāng)前窗口基序號-Ws，基序號-1]范圍丟棄分組，發(fā)送ACK(n)其他事件：

忽略接收方思考：SR協(xié)議還可以有其他設(shè)計嗎？第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議SR協(xié)議示例37sendpkt0sendpkt1sendpkt2sendpkt3(wait)senderreceiversendpkt2(butnot3,4,5)Xlosspkt2timeoutsenderwindow(N=4)012345678012345678012345678012345678rcvack0,sendpkt4012345678012345678012345678012345678012345678012345678rcvack1,sendpkt5receivepkt0,sendack0receivepkt1,sendack1

receivepkt3,buffer,

sendack3recordack3arrivedreceivepkt4,buffer,sendack4receivepkt5,buffer,sendack5rcvpkt2;deliverpkt2,pkt3,pkt4,pkt5;sendack2Q:當(dāng)ack2到達發(fā)送方會怎么樣？第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議SR協(xié)議：困境序列號:0,1,2,3窗口尺寸：3接收方能區(qū)分開右側(cè)兩種不同的場景嗎？(a)中，發(fā)送方重發(fā)0號分組,接收方收到后會如何處理？38第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議窗口大小與序號空間的約束條件？問題：序列號空間大小與窗口尺寸需滿足什么關(guān)系？Ws發(fā)送窗口，Wr接收窗口，k序號位數(shù)對于GBN協(xié)議：Wr=1對于典型的Ws=Wr=W的SR協(xié)議對于停-等協(xié)議，即Ws=Wr=139

第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議滑動窗口協(xié)議的窗口大小討論：1.滑動窗口協(xié)議的窗口大小影響協(xié)議哪些性能？2.哪些因素會影響滑動窗口大小的確定？性能：信道利用率吞吐率……因素：序號空間緩存大小流量控制擁塞控制……40第三節(jié)

停等協(xié)議與滑動窗口

協(xié)議第四節(jié)UDP協(xié)議李全龍UDP:用戶數(shù)據(jù)報協(xié)議[RFC768]基于InternetIP協(xié)議復(fù)用/分用簡單的錯誤校驗“Besteffort”服務(wù)，UDP段可能丟失非按序到達無連接UDP發(fā)送方和接收方之間不需要握手每個UDP段的處理獨立于其他段3為什么需要UDP?無需建立連接

(減少延遲)實現(xiàn)簡單：無需維護連接狀態(tài)頭部開銷少沒有擁塞控制:應(yīng)用可更好地控制發(fā)送時間和速率第四節(jié)UDP協(xié)議UDP:用戶數(shù)據(jù)報協(xié)議[RFC768]常用于流媒體應(yīng)用容忍丟失速率敏感UDP還用于DNSSNMP在UDP上實現(xiàn)可靠數(shù)據(jù)傳輸？在應(yīng)用層增加可靠性機制應(yīng)用特定的錯誤恢復(fù)機制例如：停等協(xié)議、滑動窗口協(xié)議43源端口號目的端口號32bits應(yīng)用數(shù)據(jù)

(報文/消息)UDP報文段格式長度校驗和UDP段的長度（包含頭部）第四節(jié)UDP協(xié)議UDP校驗和(checksum)發(fā)送方將參與校驗和計算的所有內(nèi)容視為16-bit整數(shù)序列校驗和計算：計算整數(shù)序列的和（sum）進位也要加在和的后面將和按位求反（即反碼），得到校驗和（checksum）發(fā)送方將校驗和放入校驗和字段44接收方針對收到的UDP報文段，按發(fā)送方同樣的方法構(gòu)建16位整數(shù)序列按相同算法計算整數(shù)序列的和（sum）若sum=1111111111111111，則無錯；否則，有錯目的：檢測UDP段在傳輸中是否發(fā)生錯誤（如位翻轉(zhuǎn)）第四節(jié)UDP協(xié)議UDP校驗和(checksum)3部分:偽首部

（Pseudohead）UDP首部應(yīng)用數(shù)據(jù)45UDP首部源IP地址(32)目的IP地址(32)0(8)協(xié)議/17(8)UDP總長度(16)偽首部應(yīng)用數(shù)據(jù)填充/0(8)第四節(jié)UDP協(xié)議校驗和計算示例示例：注意：最高位進位必須被加進去461111001100110011011101010101010101110111011101110111110111011101111001

0100010001000011sumchecksum回卷第四節(jié)UDP協(xié)議第五節(jié)TCP協(xié)議李全龍TCP概述點對點一個發(fā)送方，一個接收方可靠的、按序字節(jié)流流水線機制TCP擁塞控制和流量控制機制設(shè)置窗口尺寸發(fā)送方/接收方緩存48全雙工(full-duplex)同一連接中能夠傳輸雙向數(shù)據(jù)流面向連接通信雙方在發(fā)送數(shù)據(jù)之前必須建立連接。連接狀態(tài)只在連接的兩端中維護，在沿途節(jié)點中并不維護狀態(tài)。TCP連接包括：兩臺主機上的緩存、連接狀態(tài)變量、socket等流量控制機制擁塞控制第五節(jié)TCP協(xié)議TCP段結(jié)構(gòu)源端口號與目的端口號字段分別占16位多路復(fù)用/分解49第五節(jié)TCP協(xié)議TCP段結(jié)構(gòu)序號字段與確認(rèn)序號字段分別占32位對每個應(yīng)用層數(shù)據(jù)的每個字節(jié)進行編號確認(rèn)序號是期望從對方接收數(shù)據(jù)的字節(jié)序號，累計確認(rèn)50第五節(jié)TCP協(xié)議TCP段結(jié)構(gòu)首部長度字段占4位4字節(jié)為計算單位51第五節(jié)TCP協(xié)議TCP段結(jié)構(gòu)保留字段占6位目前值為052第五節(jié)TCP協(xié)議TCP段結(jié)構(gòu)6位標(biāo)志位（字段）URG=1時，表明緊急指針字段有效ACK=1時，標(biāo)識確認(rèn)序號字段有效PSH=1時，盡快將段中數(shù)據(jù)交付接

收應(yīng)用進程53RST=1時，重新建立TCP連接SYN=1時，表示該TCP段是一個建立新連接請求控制段FIN=1時，表明請求釋放TCP連接第五節(jié)TCP協(xié)議TCP段結(jié)構(gòu)接收窗口字段占16位流量控制54第五節(jié)TCP協(xié)議TCP段結(jié)構(gòu)校驗和字段占16位包括TCP偽首部、TCP首部和應(yīng)用層數(shù)據(jù)三部分55第五節(jié)TCP協(xié)議TCP段結(jié)構(gòu)緊急指針字段占16位URG=1時才有效指出緊急數(shù)據(jù)最后一個字節(jié)在數(shù)據(jù)中的位置56第五節(jié)TCP協(xié)議TCP段結(jié)構(gòu)選項字段的長度可變最大段長度MSS時間戳SACK57TCP段結(jié)構(gòu)填充字段，長度為0~3個字節(jié)取值全058第五節(jié)TCP協(xié)議TCP連接管理TCPsender和receiver在傳輸數(shù)據(jù)前需要建立連接初始化TCP變量Seq.#Buffer和流量控制信息Client：連接發(fā)起者SocketclientSocket=newSocket("hostname","portnumber");

Server:等待客戶連接請求SocketconnectionSocket=welcomeSocket.accept();59三次握手:Step1:

客戶向服務(wù)器發(fā)送

SYN報文段確定初始序號不封裝數(shù)據(jù)Step2:

服務(wù)器接收SYN段，

響應(yīng)SYNACK報文段服務(wù)器分配緩存確定服務(wù)器初始序號Step3:

客戶接收SYNACK，響應(yīng)

ACK段，可以攜帶數(shù)據(jù)第五節(jié)TCP協(xié)議TCP連接管理：建立60第五節(jié)TCP協(xié)議TCP連接管理：斷連過程61第五節(jié)TCP協(xié)議TCP連接管理62TCPclientlifecycleTCPserverlifecycle第五節(jié)TCP協(xié)議TCP:序列號和ACK63HostAHostBSeq=42,ACK=79,data=‘C’Seq=43,ACK=80Usertypes‘C’hostACKsreceiptofechoed‘C’Seq=79,ACK=43,data=‘C’簡單telnettimetime序列號:序號是段（Segment）中第1個字節(jié)的編號，而不是段的“連續(xù)”編號建立TCP連接時，雙方隨機選擇序列號ACKs:期望接收到的下一個字節(jié)的序列號累計確認(rèn)：該序列號之前的所有字節(jié)均已被正確接收到Q:

接收方如何處理亂序到達的段？A:TCP規(guī)范中沒有規(guī)定，由TCP的實現(xiàn)者做出決策第五節(jié)TCP協(xié)議TCP可靠數(shù)據(jù)傳輸概述TCP在IP層的不可靠服務(wù)基礎(chǔ)上實現(xiàn)可靠數(shù)據(jù)傳輸服務(wù)流水線機制累積確認(rèn)TCP使用單一重傳定時器觸發(fā)重傳的事件超時收到重復(fù)ACK漸進式64第五節(jié)TCP協(xié)議TCPRTT和超時65問題：如何設(shè)置定時器的超時時間？大于RTT但是RTT是變化的過短：不必要的重傳過長：對段丟失時間反應(yīng)慢問題：如何估計RTT？SampleRTT:測量從段發(fā)出去到收到ACK的時間忽略重傳SampleRTT變化測量多個SampleRTT，求平均值，形成RTT的估計值EstimatedRTTEstimatedRTT=(1-

)*EstimatedRTT+

*SampleRTT指數(shù)加權(quán)移動平均

典型值：0.125第五節(jié)TCP協(xié)議TCPRTT和超時66定時器超時時間的設(shè)置?EstimatedRTT+“安全邊界”EstimatedRTT變化大

較大的邊界測量RTT的變化值:SampleRTT與EstimatedRTT的差值定時器超時時間的設(shè)置：DevRTT=(1-

)*DevRTT+

*|SampleRTT-EstimatedRTT|(typically,

=0.25)TimeoutInterval=EstimatedRTT+4*DevRTT第五節(jié)TCP協(xié)議TCP發(fā)送方事件67從應(yīng)用層收到數(shù)據(jù)創(chuàng)建Segment序列號是Segment第一個字節(jié)的編號開啟計時器設(shè)置超時時間：TimeOutInterval超時重傳引起超時的段重啟定時器收到ACK如果確認(rèn)此前未確認(rèn)的段更新SendBase如果窗口中還有未被確認(rèn)的分組，重新啟動定時器第五節(jié)TCP協(xié)議TCP發(fā)送端程序68

NextSeqNum=InitialSeqNumSendBase=InitialSeqNum

loop(forever){

switch(event)

event:datareceivedfromapplicationabovecreateTCPsegmentwithsequencenumberNextSeqNumif(timercurrentlynotrunning)starttimerpasssegmenttoIPNextSeqNum=NextSeqNum+length(data)

event:timertimeoutretransmitnot-yet-acknowledgedsegmentwithsmallestsequencenumberstarttimer

event:ACKreceived,withACKfieldvalueofyif(y>SendBase){SendBase=yif(therearecurrentlynot-yet-acknowledgedsegments)starttimer}

}/*endofloopforever*/

第五節(jié)TCP協(xié)議TCP重傳示例69第五節(jié)TCP協(xié)議TCP重傳示例70第五節(jié)TCP協(xié)議TCPACK生成:RFC1122,RFC258171EventatReceiverArrivalofin-ordersegmentwithexpectedseq#.Alldatauptoexpectedseq#alreadyACKedArrivalofin-ordersegmentwithexpectedseq#.OneothersegmenthasACKpendingArrivalofout-of-ordersegmenthigher-than-expectseq.#.GapdetectedArrivalofsegmentthatpartiallyorcompletelyfillsgapTCPReceiveractionDelayedACK.Waitupto500msfornextsegment.Ifnonextsegment,sendACKImmediatelysendsinglecumulativeACK,ACKingbothin-ordersegmentsImmediatelysendduplicateACK,indicatingseq.#ofnextexpectedbyteImmediatesendACK,providedthatsegmentstartsatlowerendofgap第五節(jié)TCP協(xié)議快速重傳機制TCP的實現(xiàn)中，如果發(fā)生超時，超時時間間隔將重新設(shè)置，即將超時時間間隔加倍，導(dǎo)致其很大重發(fā)丟失的分組之前要等待很長時間通過重復(fù)ACK檢測分組丟失Sender會背靠背地發(fā)送多個分組如果某個分組丟失，可能會引發(fā)多個重復(fù)的ACK72如果sender收到對同一數(shù)據(jù)的3個ACK，則假定該數(shù)據(jù)之后的段已經(jīng)丟失快速重傳：在定時器超時之前即進行重傳第五節(jié)TCP協(xié)議快速重傳算法73

event:ACKreceived,withACKfieldvalueofyif(y>SendBase){SendBase=yif(therearecurrentlynot-yet-acknowledgedsegments)starttimer}else{incrementcountofdupACKsreceivedforyif(countofdupACKsreceivedfory=3){resendsegmentwithsequencenumbery}

aduplicateACKforalreadyACKedsegmentfastretransmit第五節(jié)TCP協(xié)議快速重傳示例74第五節(jié)TCP協(xié)議TCP流量控制75接收方為TCP連接分配buffer速度匹配機制上層應(yīng)用可能處理buffer中數(shù)據(jù)的速度較慢發(fā)送方不會傳輸?shù)奶唷⑻煲灾劣谘蜎]接收方（buffer溢出）flowcontrol第五節(jié)TCP協(xié)議TCP流量控制76(假定TCPreceiver丟棄亂序的segments)Buffer中的可用空間(spareroom)=RcvWindow=RcvBuffer-[LastByteRcvd-LastByteRead]Receiver通過在Segment的頭部字段將RcvWindow

告訴SenderSender限制自己已經(jīng)發(fā)送的但還未收到ACK的數(shù)據(jù)不超過接收方的空閑RcvWindow尺寸Receiver告知SenderRcvWindow=0,會出現(xiàn)什么情況？第五節(jié)TCP協(xié)議擁塞控制擁塞(Congestion)非正式定義：“太多發(fā)送主機發(fā)送了太多數(shù)據(jù)或者發(fā)送速度太快，以至于網(wǎng)絡(luò)無法處理”表現(xiàn)：分組丟失（路由器緩存溢出）分組延遲過大（在路由器緩存中排隊）發(fā)生擁塞的主要原因：緩沖區(qū)容量有限。傳輸線路的帶寬有限。網(wǎng)絡(luò)結(jié)點的處理能力有限。網(wǎng)絡(luò)中某些部分發(fā)生了故障。擁塞控制vs.流量控制top-10問題77第五節(jié)TCP協(xié)議擁塞的后果78擁塞的代價:

時延顯著增加吞吐量快速下降分組被丟棄傳輸能力被浪費第五節(jié)TCP協(xié)議擁塞控制的方法傳輸層端到端擁塞控制：網(wǎng)絡(luò)層不需要顯式的提供支持端系統(tǒng)通過觀察loss，delay等網(wǎng)絡(luò)行為判斷是否發(fā)生擁塞TCP采取這種方法網(wǎng)絡(luò)層（輔助）擁塞控制：路由器向發(fā)送方顯式地反饋網(wǎng)絡(luò)擁塞信息簡單的擁塞指示(1bit)：SNA,DECbit,TCP/IPECN,ATM)指示發(fā)送方應(yīng)該采取何種速率79第五節(jié)TCP協(xié)議TCP擁塞控制的基本原理80Sender限制發(fā)送速率LastByteSent-LastByteAcked

<=CongWinCongWin:動態(tài)調(diào)整以改變發(fā)送速率反映所感知到的網(wǎng)絡(luò)擁塞問題：如何感知網(wǎng)絡(luò)擁塞？Loss事件=timeout或3個重復(fù)ACK發(fā)生loss事件后，發(fā)送方降低速率如何合理地調(diào)整發(fā)送速率？加性增—乘性減:AIMD慢啟動:SSrate≈CongWin

RTT

Bytes/sec第五節(jié)TCP協(xié)議加性增—乘性減:AIMD原理：逐漸增加發(fā)送速率，謹(jǐn)慎探測可用帶寬，直到發(fā)生丟包方法:AIMDAdditiveIncrease:每個RTT將CongWin增大1個MSS-擁塞避免MultiplicativeDecrease:發(fā)生丟包后將CongWin減半81timecongestionwindowsize鋸齒行為:探測可用帶寬第五節(jié)TCP協(xié)議TCP慢啟動:SSTCP連接建立時，CongWin=1例：MSS=500byte,RTT=200msec初始速率=20kbps可用帶寬可能遠遠高于初始速率：希望快速增長原理：當(dāng)連接開始時，指數(shù)性增長82initialize:Congwin=1for(eachsegmentACKed)Congwin++until(losseventORCongWin>threshold)Slowstartalgorithm第五節(jié)TCP協(xié)議TCP慢啟動:SS指數(shù)性增長每個RTT將CongWin翻倍收到每個ACK進行CongWin++操作初始速率很慢，但是快速攀升83HostAonesegmentRTTHostBtimetwosegmentsfoursegments第五節(jié)TCP協(xié)議TCP慢啟動:SS84第五節(jié)TCP協(xié)議Threshold變量85Q:何時應(yīng)該指數(shù)性增長切換為線性增長(擁塞避免)?A:

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

實現(xiàn)方法:變量

Threshold

Loss事件發(fā)生時,Threshold被設(shè)為Loss事件前CongWin值的1/2。第五節(jié)TCP協(xié)議Loss事件的處理863個重復(fù)ACKs:CongWin切換到一半然后線性增長Timeout事件:CongWin直接設(shè)為1個MSS然后指數(shù)增長達到threshold后,再線性增長

3個重復(fù)ACKs表示網(wǎng)絡(luò)還能夠傳輸一些segmentstimeout事件表明擁塞更為嚴(yán)重Philosophy:第五節(jié)TCP協(xié)議TCP擁塞控制:總結(jié)WhenCongWinisbelowThreshold,senderinslow-startphase,windowgrowsexponentially.WhenCongWinisaboveThreshold,senderisincongestion-avoidancephase,windowgrowslinearly.WhenatripleduplicateACKoccurs,ThresholdsettoCongWin/2andCongWinsettoThreshold.Whentimeoutoccurs,ThresholdsettoCongWin/2andCongWinissetto1MSS.

87第五節(jié)TCP協(xié)議TCP擁塞控制88StateEventTCPSenderActionCommentarySlowStart(SS)ACKreceiptforpreviouslyunackeddataCongWin=CongWin+MSS,If(CongWin>Threshold)setstateto“CongestionAvoidance”ResultinginadoublingofCongWineveryRTTCongestionAvoidance(CA)ACKreceiptforpreviouslyunackeddataCongWin=CongWin+MSS*(MSS/CongWin)

Additiveincrease,resultinginincreaseofCongWinby1MSSeveryRTTSSorCALosseventdetectedbytripleduplicateACKThreshold=CongWin/2,CongWin=Threshold,Setstateto“CongestionAvoidance”Fastrecovery,implementingmultiplicativedecrease.CongWinwillnotdropbelow1MSS.SSorCATimeoutThreshold=CongWin/2,CongWin=1MSS,Setstateto“SlowStart”EnterslowstartSSorCADuplicateACKIncrementduplicat