第3章-運(yùn)輸層課件

1、計(jì)算機(jī)網(wǎng)絡(luò)第3章 運(yùn)輸層2022年7月25日2目 錄概述和運(yùn)輸層服務(wù)多路復(fù)用與多路分解無(wú)連接傳輸 : UDP可靠數(shù)據(jù)傳輸?shù)脑砻嫦蜻B接的傳輸 : TCP擁塞控制原理TCP擁塞控制2022年7月25日33.1 概述和運(yùn)輸層服務(wù)運(yùn)輸層的功能為不同主機(jī)上運(yùn)行的應(yīng)用進(jìn)程之間提供邏輯通信(logical communication)運(yùn)輸層協(xié)議的工作內(nèi)容發(fā)送方：把應(yīng)用數(shù)據(jù)劃分成 報(bào)文段(segments),交給網(wǎng)絡(luò)層接收方：把報(bào)文段重組成應(yīng)用數(shù)據(jù)，交付給應(yīng)用層2022年7月25日43.1 概述和運(yùn)輸層服務(wù)運(yùn)輸層和網(wǎng)絡(luò)層的區(qū)別網(wǎng)絡(luò)層: 不同主機(jī)之間的邏輯通信運(yùn)輸層: 應(yīng)用進(jìn)程之間的邏輯通信類似于家庭間通信:

2、12個(gè)孩子要與另一個(gè)家庭的12個(gè)孩子相互通信進(jìn)程 = 孩子們進(jìn)程間報(bào)文 = 信封中的信箋主機(jī) = 家庭的房子運(yùn)輸協(xié)議 = 張三 和 李四網(wǎng)絡(luò)層協(xié)議 = 郵局提供的服務(wù)2022年7月25日53.1 概述和運(yùn)輸層服務(wù)上例中的幾種特殊場(chǎng)景張三和李四生病了，無(wú)法工作，換成張五和李六不同的運(yùn)輸層協(xié)議可能提供不一樣的服務(wù)郵局不承諾信件送抵的最長(zhǎng)時(shí)間運(yùn)輸層協(xié)議能夠提供的服務(wù)受到底層網(wǎng)絡(luò)協(xié)議的服務(wù)模型的限制郵局不承諾平信一定安全可靠的送達(dá)，可能在路上丟失，但張三、李四可在較長(zhǎng)時(shí)間內(nèi)沒有受到對(duì)方的回信時(shí)，再次謄寫信件，寄出在網(wǎng)絡(luò)層不提供某些服務(wù)的情況下，運(yùn)輸層自己提供2022年7月25日63.1 概述和運(yùn)輸層服

3、務(wù)因特網(wǎng)上的運(yùn)輸層協(xié)議用戶數(shù)據(jù)報(bào)協(xié)議UDP（數(shù)據(jù)報(bào)）傳輸控制協(xié)議TCP（報(bào)文段）所提供的服務(wù)進(jìn)程間數(shù)據(jù)交付差錯(cuò)檢測(cè)可靠的數(shù)據(jù)傳輸擁塞控制2022年7月25日73.2 多路復(fù)用與多路分解應(yīng)用層運(yùn)輸層網(wǎng)絡(luò)層TCP 報(bào)文段UDP用戶數(shù)據(jù)報(bào)應(yīng)用進(jìn)程TCP 復(fù)用IP 復(fù)用UDP 復(fù)用TCP 報(bào)文段UDP用戶數(shù)據(jù)報(bào)應(yīng)用進(jìn)程端口端口TCP 分用UDP 分用IP 分用IP 數(shù)據(jù)報(bào)IP 數(shù)據(jù)報(bào)發(fā)送方接收方2022年7月25日83.2 多路復(fù)用與多路分解端口端口的作用就是讓應(yīng)用層的各種應(yīng)用進(jìn)程都能將其數(shù)據(jù)通過端口向下交付給運(yùn)輸層，以及讓運(yùn)輸層知道應(yīng)當(dāng)將其報(bào)文段中的數(shù)據(jù)向上通過端口交付給應(yīng)用層相應(yīng)的進(jìn)程（或者線程）

4、從這個(gè)意義上講，端口是用來(lái)標(biāo)志應(yīng)用層的進(jìn)程（或者線程）端口用一個(gè) 16 bit 端口號(hào)進(jìn)行標(biāo)志 兩類端口一類是熟知端口，其數(shù)值一般為 01023，保留給諸如HTTP（80）、FTP（21）等熟知協(xié)議的。當(dāng)開發(fā)一種新的應(yīng)用程序時(shí)，必須為它指派一個(gè)端口號(hào)。另一類則是一般端口，用來(lái)隨時(shí)分配給請(qǐng)求通信的客戶進(jìn)程。3.2 多路復(fù)用與多路分解2022年7月25日103.2 多路復(fù)用與多路分解套接字TCP 使用“連接”(而不僅僅是“端口”)作為最基本的抽象，同時(shí)將 TCP 連接的端點(diǎn)稱為套接字(socket) 。套接字和端口、IP 地址的關(guān)系是：IP 地址3 端口號(hào)1500 3, 1500套接字(socke

5、t) 2022年7月25日113.2 多路復(fù)用與多路分解報(bào)文段（數(shù)據(jù)報(bào)）的投送主機(jī)收到IP包每個(gè)數(shù)據(jù)包都有源IP地址和目的IP地址每個(gè)數(shù)據(jù)包都攜帶一個(gè)傳輸層的數(shù)據(jù)報(bào)文段每個(gè)數(shù)據(jù)報(bào)文段都有源、目的端口號(hào)主機(jī)根據(jù)“IP地址端口號(hào)”將報(bào)文段定向到相應(yīng)的套接字源端口 #目的端口 #32 位應(yīng)用數(shù)據(jù) (報(bào)文)其他首部字段TCP/UDP 報(bào)文段格式 無(wú)連接的復(fù)用與分用根據(jù)端口號(hào)創(chuàng)建socket:DatagramSocket mySocket1 = new DatagramSocket();DatagramSocket mySocket2 = new DatagramSocket(19157);UDP so

6、cket 由一個(gè)二元組來(lái)標(biāo)識(shí): (目的IP地址, 目的端口號(hào))當(dāng)主機(jī)收到UDP報(bào)文段時(shí):檢查報(bào)文段中的目的端口號(hào)將UDP報(bào)文段定向到相應(yīng)的套接字兩個(gè)具有不同源IP地址和/或源端口，但具有相同目的IP地址和目的端口號(hào)的UDP報(bào)文段將定向到相同的套接字3.2 多路復(fù)用與多路分解無(wú)連接的復(fù)用與分用(續(xù))DatagramSocket serverSocket = new DatagramSocket(6428);客戶IP:BP2客戶 IP: AP1P1P3服務(wù)器IP: CSP: 6428DP: 9157SP: 9157DP: 6428SP: 6428DP: 5775SP: 5775DP: 6428SP

7、 提供 “返回地址”（完整的返回地址是源IP地址和源端口號(hào)）3.2 多路復(fù)用與多路分解2022年7月25日143.2 多路復(fù)用與多路分解面向連接到復(fù)用和分用TCP 套接字由一個(gè)四元組來(lái)標(biāo)識(shí) （源IP地址，源端口號(hào)，目的IP地址，目的端口號(hào)）接收方主機(jī)根據(jù)這四個(gè)值將報(bào)文段定向到相應(yīng)的套接字服務(wù)器主機(jī)同時(shí)支持多個(gè)并發(fā)的TCP套接字:每一個(gè)套接字都由其四元組來(lái)標(biāo)識(shí)2022年7月25日153.2 多路復(fù)用與多路分解面向連接到復(fù)用和分用Web服務(wù)器為每一個(gè)客戶連接都產(chǎn)生不同的套接字非持久HTTP對(duì)每一個(gè)請(qǐng)求都建立不同的套接字（會(huì)影響性能）持久HTTP在整個(gè)連接期間，客戶機(jī)和服務(wù)器之間通過同一個(gè)服務(wù)器套接

8、字交換HTTP報(bào)文2022年7月25日163.2 多路復(fù)用與多路分解舉例：多線程的WEB服務(wù)器P1客戶 IP: A客戶IP:BP2服務(wù)器IP: CP4P3SP: 9157DP: 80S-IP: AD-IP:CSP: 9157DP: 80D-IP:CS-IP: BSP: 5775DP: 80D-IP:CS-IP: B2022年7月25日173.3 無(wú)連接傳輸 : UDP一個(gè)最簡(jiǎn)單的運(yùn)輸層協(xié)議多路復(fù)用/多路分解服務(wù)差錯(cuò)檢查適應(yīng)C/S模式的簡(jiǎn)單請(qǐng)求/響應(yīng)通信需要 UDP保留各報(bào)文間的邊界，不把應(yīng)用進(jìn)程多次發(fā)送的數(shù)據(jù)合并成一個(gè)包發(fā)出去，且發(fā)包后不對(duì)該包緩存，這對(duì)簡(jiǎn)單請(qǐng)求/響應(yīng)很方便；“盡力而為”服務(wù)，

9、UDP報(bào)文段可能會(huì):丟失應(yīng)用數(shù)據(jù)不按序到達(dá)2022年7月25日183.3 無(wú)連接傳輸 : UDPUDP處理數(shù)據(jù)的流程發(fā)送方從應(yīng)用進(jìn)程得到數(shù)據(jù)附加上為多路復(fù)用/多路分解所需的源和目的端口號(hào)及差錯(cuò)檢測(cè)信息，形成報(bào)文段（數(shù)據(jù)報(bào)）遞交給網(wǎng)絡(luò)層，盡力而為的交付給接收主機(jī)接收方從網(wǎng)絡(luò)層接收?qǐng)?bào)文段（數(shù)據(jù)報(bào)）根據(jù)目的端口號(hào)，將數(shù)據(jù)交付給相應(yīng)的應(yīng)用進(jìn)程UDP通信事先無(wú)需握手，是無(wú)連接的UDP報(bào)文段之間是相互獨(dú)立的2022年7月25日193.3 無(wú)連接傳輸 : UDPUDP的優(yōu)勢(shì)無(wú)需建立連接建立連接會(huì)增加時(shí)延簡(jiǎn)單發(fā)送方和接收方無(wú)需維護(hù)連接狀態(tài)段首部開銷小TCP:20Byte vs UDP:8Byte無(wú)擁塞控制UD

10、P 可按需要隨時(shí)發(fā)送2022年7月25日203.3 無(wú)連接傳輸 : UDP部分采用UDP協(xié)議的應(yīng)用遠(yuǎn)程文件系統(tǒng)（NFS）流式多媒體因特網(wǎng)電話網(wǎng)絡(luò)管理（SNMP）選路協(xié)議（RIP）域名解析（DNS）2022年7月25日213.3 無(wú)連接傳輸 : UDPUDP大量應(yīng)用可能導(dǎo)致的嚴(yán)重后果路由器中大量的分組溢出顯著減小TCP通信的速率，甚至擠垮TCP會(huì)話使用UDP的可靠數(shù)據(jù)傳輸在應(yīng)用層實(shí)現(xiàn)數(shù)據(jù)的可靠傳輸增加了應(yīng)用進(jìn)程的實(shí)現(xiàn)難度2022年7月25日223.3 無(wú)連接傳輸 : UDPUDP報(bào)文段（數(shù)據(jù)報(bào)）的結(jié)構(gòu)源端口 #目的端口 #32 位應(yīng)用數(shù)據(jù) (報(bào)文)長(zhǎng)度檢查和包括首部在內(nèi)的UDP報(bào)文段長(zhǎng)度, （以

11、字節(jié)為單位）2022年7月25日233.3 無(wú)連接傳輸 : UDPUDP的檢查和目標(biāo)檢測(cè)收到的報(bào)文段的“差錯(cuò)” (例如, 出現(xiàn)突變的比特)發(fā)送方把報(bào)文段看作是16比特字的序列檢查和：對(duì)報(bào)文段的所有16比特字的和進(jìn)行1的補(bǔ)運(yùn)算發(fā)送方將計(jì)算校驗(yàn)和的結(jié)果寫入U(xiǎn)DP校驗(yàn)和字段中增加偽首部： (源IP地址（4字節(jié)）、目的IP地址（4字節(jié)） 、0 （1字節(jié)） 、17 （UDP協(xié)議號(hào)，1字節(jié)） 、UDP長(zhǎng)度（2字節(jié)）)接收方計(jì)算接收到的報(bào)文段的校驗(yàn)和檢查計(jì)算結(jié)果是否與收到報(bào)文段的校驗(yàn)和字段中的值相同不同 檢測(cè)到錯(cuò)誤相同 沒有檢測(cè)到錯(cuò)誤(但仍可能存在錯(cuò)誤)2022年7月25日243.3 無(wú)連接傳輸 : UDP

12、例子: 將兩個(gè)16比特字相加1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 11 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 11 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1回卷和檢查和注意：最高有效位的進(jìn)位要回卷加到結(jié)果當(dāng)中2022年7月25日253.4 可靠數(shù)據(jù)傳輸?shù)脑砜煽繑?shù)據(jù)傳輸在應(yīng)用層、運(yùn)輸層和鏈路層都很重要網(wǎng)絡(luò)中最重要的top-10問題之一!2022年7月25日263.4 可靠數(shù)據(jù)傳輸?shù)脑聿豢煽啃诺?/p>

13、的特性決定了可靠數(shù)據(jù)傳輸協(xié)議(rdt)的復(fù)雜性。2022年7月25日273.4 可靠數(shù)據(jù)傳輸?shù)脑戆l(fā)送方接收方rdt_send(): 由上層（如應(yīng)用層）調(diào)用，將數(shù)據(jù)發(fā)送給接收方的上層udt_send(): 由 rdt調(diào)用,將分組通過不可靠信道傳給接收方rdt_rcv(): 當(dāng)分組到達(dá)接收方時(shí)調(diào)用deliver_data(): 由 rdt 調(diào)用，將數(shù)據(jù)交付上層2022年7月25日283.4 可靠數(shù)據(jù)傳輸?shù)脑砦覀儗⒁?逐步地開發(fā)可靠數(shù)據(jù)傳輸協(xié)議(rdt)的發(fā)送方和接收方只考慮單向數(shù)據(jù)傳輸(unidirectional data transfer)的情況但控制信息是雙向傳輸?shù)挠糜邢逘顟B(tài)機(jī) (FSM

14、) 來(lái)描述發(fā)送方和接收方狀態(tài)1狀態(tài)2事件引起狀態(tài)變遷狀態(tài)轉(zhuǎn)換過程中的動(dòng)作狀態(tài): 由事件引起一個(gè)狀態(tài)到另一個(gè)狀態(tài)的變遷。事件動(dòng)作2022年7月25日293.4 可靠數(shù)據(jù)傳輸?shù)脑砜煽啃诺郎系目煽總鬏?rdt 1.0底層信道完全可靠不會(huì)產(chǎn)生比特錯(cuò)誤不會(huì)丟失分組分別為發(fā)送方和接收方建立FSM發(fā)送方將數(shù)據(jù)發(fā)送給底層信道接收方從底層信道接收數(shù)據(jù)packet = make_pkt(data)udt_send(packet)rdt_send(data)extract (packet,data)deliver_data(data)等待來(lái)自下層的調(diào)用rdt_rcv(packet)發(fā)送方接收方等待來(lái)自上層的調(diào)用3

15、03.4 可靠數(shù)據(jù)傳輸?shù)脑硇诺揽赡軐?dǎo)致比特出現(xiàn)差錯(cuò)時(shí)rdt 2.x第一個(gè)版本rdt 2.0假設(shè)分組比特可能受損所有傳輸?shù)姆纸M都將按序被接收，不會(huì)丟失處理機(jī)制如何判斷分組受損差錯(cuò)檢測(cè)如何通知發(fā)送方分組是否受損接收方反饋（ACK和NAK）在得知分組受損后，發(fā)送方如何處理出錯(cuò)重傳在計(jì)算機(jī)網(wǎng)絡(luò)中，基于這種重傳機(jī)制的可靠數(shù)據(jù)傳輸協(xié)議稱為自動(dòng)重傳請(qǐng)求協(xié)議（ARQ）2022年7月25日313.4 可靠數(shù)據(jù)傳輸?shù)脑韗dt 2.0的有限狀態(tài)機(jī)FSM等待來(lái)自上層的調(diào)用snkpkt = make_pkt(data, checksum)udt_send(sndpkt)extract(rcvpkt,data)del

16、iver_data(data)udt_send(ACK)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt)rdt_rcv(rcvpkt) & isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt) & isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt) & corrupt(rcvpkt)等待 ACK 或 NAK等待來(lái)自下層的調(diào)用發(fā)送方接收方rdt_send(data)L2022年7月25日323.4 可靠數(shù)據(jù)傳輸?shù)脑淼却齺?lái)自上層的調(diào)用snkpkt = make_pkt(data, checksum)udt

17、_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt)rdt_rcv(rcvpkt) & isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt) & isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt) & corrupt(rcvpkt)等待 ACK 或 NAK等待來(lái)自下層的調(diào)用rdt_send(data)L發(fā)送方接收方rdt2.0: 無(wú)差錯(cuò)的情況2022年7月25日333.4 可靠數(shù)據(jù)

18、傳輸?shù)脑淼却齺?lái)自上層的調(diào)用snkpkt = make_pkt(data, checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt)rdt_rcv(rcvpkt) & isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt) & isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt) & corrupt(rcvpkt)等待 ACK 或 NAK等待來(lái)自下層的調(diào)用rdt_s

19、end(data)L發(fā)送方接收方rdt2.0: 有差錯(cuò)的情況2022年7月25日343.4 可靠數(shù)據(jù)傳輸?shù)脑砣绾螌?shí)現(xiàn)重傳使用緩沖區(qū)緩存已發(fā)出但未收到反饋的報(bào)文段新的問題需要多大的緩沖區(qū)呢？接收方和發(fā)送方各一個(gè)報(bào)文段大小的緩沖區(qū)即可2022年7月25日353.4 可靠數(shù)據(jù)傳輸?shù)脑淼诙€(gè)版本rdt 2.1問題的引入ACK和NAK分組可能受損，而rdt 2.0沒有考慮該情況解決問題的幾種思路在人類的對(duì)話中，如果聽不清楚對(duì)方所述，會(huì)回問一句“剛才你說(shuō)什么來(lái)著？”但如果這句話仍然沒有聽清楚呢？怎么辦？雙方對(duì)著問“剛才你說(shuō)什么來(lái)著？”這就可能進(jìn)入了一個(gè)難以解困的死循環(huán)增加足夠的檢查和比特，使發(fā)送方不僅

20、可以檢查比特差錯(cuò)，還可以恢復(fù)比特差錯(cuò)收到出錯(cuò)的反饋時(shí)，不管三七二十一，直接重發(fā)當(dāng)前數(shù)據(jù)分組，但這就需要對(duì)數(shù)據(jù)分組進(jìn)行編號(hào)，以示識(shí)別 解決ACK/NAK受損問題的一個(gè)簡(jiǎn)單方法發(fā)送方對(duì)每一個(gè)分組增加序號(hào)(sequence number)發(fā)送方只重傳沒有收到ACK/NAK 的分組接收方丟棄重復(fù)分組(不向上遞交)對(duì)于停等協(xié)議，1比特序號(hào)足夠了（序號(hào)為0或1）發(fā)送方發(fā)出一個(gè)分組，然后等待接收方的應(yīng)答停止等待(stop-and-wait)3.4 可靠數(shù)據(jù)傳輸?shù)脑?022年7月25日373.4 可靠數(shù)據(jù)傳輸?shù)脑韗dt 2.1的發(fā)送方等待來(lái)自上層的調(diào)用0sndpkt = make_pkt(0, data,

21、 checksum)udt_send(sndpkt)rdt_send(data)等待 ACK 或 NAK 0udt_send(sndpkt)rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isNAK(rcvpkt) )sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)rdt_send(data)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt) udt_send(sndpkt)rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isNAK(

22、rcvpkt) )rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt) 等待來(lái)自上層的調(diào)用1等待ACK 或 NAK 1LL2022年7月25日383.4 可靠數(shù)據(jù)傳輸?shù)脑韗dt 2.1的接收方等待來(lái)自下層的0rdt_rcv(rcvpkt) & not corrupt(rcvpkt) & has_seq0(rcvpkt)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & has_seq1(rcvpkt) extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(A

23、CK, chksum)udt_send(sndpkt)等待來(lái)自下層的1rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & has_seq0(rcvpkt) extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)rdt_rcv(rcvpkt) & (corrupt(rcvpkt)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)rdt_rcv(rcvpkt) & not corrupt(rcvpkt) & has_s

24、eq1(rcvpkt)rdt_rcv(rcvpkt) & (corrupt(rcvpkt)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)2022年7月25日393.4 可靠數(shù)據(jù)傳輸?shù)脑淼谌齻€(gè)版本rdt 2.2針對(duì)rdt 2.1的改進(jìn)只使用ACK取消NAK，接收方對(duì)最后一個(gè)正確收到的分組發(fā)送 ACK接收方必須明確指出被確認(rèn)的分組的序號(hào)發(fā)送方收到的重復(fù)的ACK將按照NA

25、K來(lái)進(jìn)行處理重傳正確的分組2022年7月25日403.4 可靠數(shù)據(jù)傳輸?shù)脑淼却齺?lái)自上層的調(diào)用0sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)rdt_send(data)udt_send(sndpkt)rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) | isACK(rcvpkt,1) )rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt,0) 等待ACK0發(fā)送方部分FSM等待來(lái)自下層的0rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) &

26、 has_seq1(rcvpkt) extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK1, chksum)udt_send(sndpkt)rdt_rcv(rcvpkt) & (corrupt(rcvpkt) | has_seq1(rcvpkt)udt_send(sndpkt)接收方部分 FSML2022年7月25日413.4 可靠數(shù)據(jù)傳輸?shù)脑磲槍?duì)rdt 2.x的進(jìn)一步討論rdt 2.x實(shí)際上也解決了流控問題2022年7月25日423.4 可靠數(shù)據(jù)傳輸?shù)脑硇诺啦坏鲥e(cuò)，而且丟包時(shí)rdt 3.0假設(shè)底層信道不但可能出現(xiàn)比特差錯(cuò)

27、，而且可能會(huì)丟包需解決的問題怎樣檢測(cè)丟包發(fā)生丟包后，如何處理檢查和技術(shù)、序號(hào)、ACK、重傳如何判斷數(shù)據(jù)報(bào)丟失了呢？最簡(jiǎn)單的方法就是：耐心的等待Q: 僅僅耐心等待就夠了嗎?想一想: 缺點(diǎn)?解決方法: 發(fā)送方對(duì)ACK等待“適當(dāng)?shù)摹睍r(shí)間如果在這個(gè)時(shí)間內(nèi)沒有收到ACK則重傳如果分組或ACK僅僅是延遲到達(dá)（而非丟失）:重傳將造成重復(fù)，但序號(hào)可以解決這個(gè)問題接收方必須指出確認(rèn)的分組序號(hào)需要倒計(jì)時(shí)的計(jì)時(shí)器3.4 可靠數(shù)據(jù)傳輸?shù)脑?022年7月25日443.4 可靠數(shù)據(jù)傳輸?shù)脑韘ndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timerrd

28、t_send(data)等待ACK0rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isACK(rcvpkt,1) )等待來(lái)自上層的調(diào)用1sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timerrdt_send(data)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt,0) rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isACK(rcvpkt,0) )rdt_rcv(rcvpkt) & notcorrupt(rcv

29、pkt) & isACK(rcvpkt,1) stop_timerstop_timerudt_send(sndpkt)start_timertimeoutudt_send(sndpkt)start_timertimeoutrdt_rcv(rcvpkt)等待來(lái)自上層的調(diào)用0等待 ACK1Lrdt_rcv(rcvpkt)LLLRdt 3.0的發(fā)送方2022年7月25日453.4 可靠數(shù)據(jù)傳輸?shù)脑韗dt 3.0舉例2022年7月25日463.4 可靠數(shù)據(jù)傳輸?shù)脑韉)過早超時(shí)c)丟失ACKpkt 0ACK 0pkt 1pkt 0ACK 0發(fā)送方接收方發(fā)送分組0接收ACK0發(fā)送分組1接收ACK1發(fā)送

30、分組0接收分組0發(fā)送ACK0接收分組1發(fā)送ACK1接收分組0發(fā)送ACK0pkt 1超時(shí)重發(fā)分組1pkt 0ACK 0ACK 1pkt 0ACK 0發(fā)送方接收方發(fā)送分組0接收ACK0發(fā)送分組1接收ACK1發(fā)送分組0接收分組0發(fā)送ACK0接收分組1(檢測(cè)冗余發(fā)送ACK1)發(fā)送ACK1接收分組0發(fā)送ACK0pkt 1丟失超時(shí)重發(fā)分組1pkt 1ACK 1接收分組1發(fā)送ACK1ACK 1ACK 1接收ACK1什么也不做接收分組1(檢測(cè)冗余發(fā)送ACK1)發(fā)送ACK1rdt3.0有時(shí)也被成為比特交替協(xié)議2022年7月25日473.4 可靠數(shù)據(jù)傳輸?shù)脑韗dt 3.0的性能分析1Gbps 的鏈路, 15ms

31、 的端到端延遲, 分組大小為1KB Ttransmit=8kb/pkt109 b/sec= 8 sL (比特為單位的分組大小)R (傳輸速率, bps)=每30ms內(nèi)只能發(fā)送1KB ： 1 Gbps 的鏈路只有33kB/sec 的吞吐量網(wǎng)絡(luò)協(xié)議限制了物理資源的利用率!2022年7月25日483.4 可靠數(shù)據(jù)傳輸?shù)脑韗dt 3.0性能低下的原因首個(gè)分組的第1個(gè)比特被傳輸, t = 0發(fā)送方接收方RTT 首個(gè)分組的最后1比特被傳輸, t = L / R首個(gè)分組的第1個(gè)比特到達(dá)首個(gè)分組的最后1個(gè)比特到達(dá),發(fā)送ACKACK 到達(dá), 發(fā)送下一個(gè)分組, t = RTT + L / R2022年7月25日

32、493.4 可靠數(shù)據(jù)傳輸?shù)脑硖岣咝阅艿囊环N可行方法：流水線技術(shù)允許發(fā)送方發(fā)送多個(gè)分組而無(wú)需等待確認(rèn)必須增大序號(hào)范圍協(xié)議的發(fā)送方和接收方必須對(duì)分組進(jìn)行緩存2022年7月25日503.4 可靠數(shù)據(jù)傳輸?shù)脑砹魉€技術(shù)對(duì)性能提升的原理圖發(fā)送方接收方RTT 利用率提高3倍!首個(gè)分組的第1個(gè)比特被傳輸, t = 0首個(gè)分組的最后1比特被傳輸, t = L / RACK 到達(dá), 發(fā)送下一個(gè)分組, t = RTT + L / R首個(gè)分組的第1個(gè)比特到達(dá)首個(gè)分組的最后1個(gè)比特到達(dá),發(fā)送ACK第2個(gè)分組的最后1個(gè)比特到達(dá),發(fā)送ACK第3個(gè)分組的最后1個(gè)比特到達(dá),發(fā)送ACK0,base-1base,nextse

33、qnum-1nextseqnum,base+N-1 base+N流水線技術(shù)工作原理分組首部用k-比特字段表示序號(hào)已被傳輸?shù)€未確認(rèn)的分組的許可序號(hào)范圍可以看作是一個(gè)在序號(hào)范圍內(nèi)大小為N的“窗口(window)”3.4 可靠數(shù)據(jù)傳輸?shù)脑?1234567012發(fā)送窗口N不允許發(fā)送這些幀允許發(fā)送 5 個(gè)幀(a)01234567012不允許發(fā)送這些幀還允許發(fā)送 4 個(gè)幀N已發(fā)送(b)01234567012不允許發(fā)送這些幀N已發(fā)送(c)01234567012不允許發(fā)送這些幀還允許發(fā)送 3 個(gè)幀N已發(fā)送 已發(fā)送并已收到確認(rèn)(d)2022年7月25日533.4 可靠數(shù)據(jù)傳輸?shù)脑韱栴}：當(dāng)流水線技術(shù)中丟失一

34、個(gè)分組后，如何進(jìn)行重傳Go-Back-N（GBN）協(xié)議：其后分組全部重傳選擇重傳（SR）協(xié)議：僅重傳該分組2022年7月25日543.4 可靠數(shù)據(jù)傳輸?shù)脑鞧BN時(shí)序圖2022年7月25日553.4 可靠數(shù)據(jù)傳輸?shù)脑鞧o-Back-N協(xié)議特點(diǎn)ACK(n): 接收方對(duì)序號(hào)n之前包括n在內(nèi)的所有分組進(jìn)行確認(rèn) - “累積 ACK”對(duì)所有已發(fā)送但未確認(rèn)的分組統(tǒng)一設(shè)置一個(gè)定時(shí)器超時(shí)(n): 重傳分組n和窗口中所有序號(hào)大于n的分組失序分組: 丟棄 (不緩存) - 接收方無(wú)緩存重發(fā)按序到達(dá)的最高序號(hào)分組的ACK2022年7月25日563.4 可靠數(shù)據(jù)傳輸?shù)脑鞧o-Back-N協(xié)議等待start_time

35、rudt_send(sndpktbase)udt_send(sndpktbase+1)udt_send(sndpktnextseqnum-1)timeoutrdt_send(data) if (nextseqnum SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer /* end of loop forever */ 從應(yīng)用程序接收數(shù)據(jù)將數(shù)據(jù)封裝入報(bào)文段中，每個(gè)報(bào)文段都包含一個(gè)序號(hào)序號(hào)是該報(bào)文段第一個(gè)數(shù)據(jù)字節(jié)的字節(jié)流編號(hào)啟動(dòng)定時(shí)器超時(shí)間隔: TimeOutInterv

36、al 超時(shí)重傳認(rèn)為超時(shí)的報(bào)文段重啟定時(shí)器收到ACK如果是對(duì)以前的未確認(rèn)報(bào)文段的確認(rèn)更新SendBase如果當(dāng)前有未被確認(rèn)的報(bào)文段，TCP還要重啟定時(shí)器2022年7月25日923.5 面向連接的傳輸 : TCPTCP的幾種重傳情況由于ACK丟失而重傳時(shí)間時(shí)間由于超時(shí)過短而重傳，只重傳第一個(gè)主機(jī) ASeq=92, 8 字節(jié)數(shù)據(jù)ACK=100丟失超時(shí)主機(jī) BXSeq=92, 8 字節(jié)數(shù)據(jù)ACK=100SendBase= 100主機(jī) ASeq=100, 20 字節(jié)數(shù)據(jù)ACK=100主機(jī) BSeq=92, 8 字節(jié)數(shù)據(jù)ACK=120Seq=92, 8 字節(jié)數(shù)據(jù)Seq=92 超時(shí)ACK=120Seq=92

37、 超時(shí)SendBase= 120SendBase= 120Sendbase= 1002022年7月25日933.5 面向連接的傳輸 : TCP主機(jī) ASeq=92, 8 字節(jié)數(shù)據(jù)ACK=100丟失超時(shí)累積確認(rèn)避免了第一個(gè)報(bào)文的重傳主機(jī) BXSeq=100, 20 字節(jié)數(shù)據(jù)ACK=120時(shí)間2022年7月25日943.5 面向連接的傳輸 : TCP超時(shí)間隔加倍每一次TCP重傳均將下一次超時(shí)間隔設(shè)為先前值的兩倍超時(shí)間隔由EstimatedRTT和DevRTT決定收到上層應(yīng)用的數(shù)據(jù)收到對(duì)未確認(rèn)數(shù)據(jù)的ACK2022年7月25日953.5 面向連接的傳輸 : TCP快速重傳超時(shí)周期往往太長(zhǎng)增加重發(fā)丟失分

38、組的延時(shí)通過重復(fù)的ACK檢測(cè)丟失報(bào)文段發(fā)送方常要連續(xù)發(fā)送大量報(bào)文段如果一個(gè)報(bào)文段丟失，會(huì)引起很多連續(xù)的重復(fù)ACK.如果發(fā)送收到一個(gè)數(shù)據(jù)的3個(gè)ACK，它會(huì)認(rèn)為確認(rèn)數(shù)據(jù)之后的報(bào)文段丟失快速重傳: 在超時(shí)到來(lái)之前重傳報(bào)文段2022年7月25日963.5 面向連接的傳輸 : TCP產(chǎn)生TCP ACK的建議（RFC1122、2581） 接收方事件所期望序號(hào)的報(bào)文段按序到達(dá)。所有在期望序號(hào)及其以前的數(shù)據(jù)都已經(jīng)被確認(rèn)有期望序號(hào)的報(bào)文段按序到達(dá)。另一個(gè)按序報(bào)文段等待發(fā)送ACK比期望序號(hào)大的失序報(bào)文段到達(dá)，檢測(cè)出數(shù)據(jù)流中的間隔能部分或完全填充接收數(shù)據(jù)間隔的報(bào)文段到達(dá) TCP接收方 動(dòng)作延遲的ACK。對(duì)另一個(gè)按序

39、報(bào)文段的到達(dá)最多等待500ms。如果下一個(gè)按序報(bào)文段在這個(gè)時(shí)間間隔內(nèi)沒有到達(dá)，則發(fā)送一個(gè)ACK立即發(fā)送單個(gè)累積ACK，以確認(rèn)兩個(gè)按序報(bào)文段 立即發(fā)送冗余ACK，指明下一個(gè)期待字節(jié)的序號(hào)(也就是間隔的低端字節(jié)序號(hào))倘若該報(bào)文段起始于間隔的低端，則立即發(fā)送ACK2022年7月25日973.5 面向連接的傳輸 : TCP快速重傳的算法 event: ACK received, with ACK field value of y if (y SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) sta

40、rt timer else increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) resend segment with sequence number y 重復(fù)的ACK報(bào)文快速重傳2022年7月25日983.5 面向連接的傳輸 : TCPTCP流量控制背景TCP接收方有一個(gè)緩存，所有上交的數(shù)據(jù)全部緩存在里面應(yīng)用進(jìn)程從緩沖區(qū)中讀取數(shù)據(jù)可能很慢目標(biāo)發(fā)送方不會(huì)由于傳得太多太快而使得接收方緩存溢出手段接收方在反饋時(shí)，將緩沖區(qū)剩余空間的大小填充在報(bào)文段首部的窗口字段中，通知發(fā)送方2022

41、年7月25日993.5 面向連接的傳輸 : TCP窗口值的計(jì)算空閑空間緩存中的TCP數(shù)據(jù)RcvWindow來(lái)自IP的數(shù)據(jù)應(yīng)用進(jìn)程RcvBufferLastByteRcvd LastByteRead RcvBuffer接收方：RcvWindows = RcvBuffer LastByteRcvd - LastByteRead發(fā)送方：LastByteSent LastByteAcked RcvWindow2022年7月25日1003.5 面向連接的傳輸 : TCP一種特殊的情況接收方通知發(fā)送方RcvWindow為0，且接收方無(wú)任何數(shù)據(jù)傳送給發(fā)送方發(fā)送方持續(xù)向接受方發(fā)送只有一個(gè)字節(jié)數(shù)據(jù)的報(bào)文段，目的

42、是試探收到確認(rèn)即可前移1002003004005006007008009001012013014015016017018011發(fā)送窗口可發(fā)送不可發(fā)送指針發(fā)送端要發(fā)送 900 字節(jié)長(zhǎng)的數(shù)據(jù)，劃分為 9 個(gè) 100 字節(jié)長(zhǎng)的報(bào)文段，而發(fā)送窗口確定為 500 字節(jié)。發(fā)送端只要收到了對(duì)方的確認(rèn)，發(fā)送窗口就可前移。發(fā)送 TCP 要維護(hù)一個(gè)指針。每發(fā)送一個(gè)報(bào)文段，指針就向前移動(dòng)一個(gè)報(bào)文段的距離。TCP 流量控制舉例收到確認(rèn)即可前移1002003004005006007008009001012013014015016017018011可發(fā)送不可發(fā)送指針1002003004005006007008009001

43、012013014015016017018011發(fā)送窗口可發(fā)送不可發(fā)送指針發(fā)送窗口前移發(fā)送端已發(fā)送了 400 字節(jié)的數(shù)據(jù)，但只收到對(duì)前 200 字節(jié)數(shù)據(jù)的確認(rèn)，同時(shí)窗口大小不變?，F(xiàn)在發(fā)送端還可發(fā)送 300 字節(jié)。 已發(fā)送并被確認(rèn)已發(fā)送但未被確認(rèn)TCP 流量控制舉例1002003004005006007008009001012013014015016017018011已發(fā)送并被確認(rèn)已發(fā)送但未被確認(rèn)可發(fā)送不可發(fā)送指針1002003004005006007008009001012013014015016017018011已發(fā)送并被確認(rèn)可發(fā)送不可發(fā)送指針發(fā)送窗口前移發(fā)送窗口縮小發(fā)送端收到了對(duì)方對(duì)前 4

44、00 字節(jié)數(shù)據(jù)的確認(rèn)，但對(duì)方通知發(fā)送端必須把窗口減小到 400 字節(jié)?，F(xiàn)在發(fā)送端最多還可發(fā)送 400 字節(jié)的數(shù)據(jù)。 1: 客戶主機(jī)向服務(wù)器主機(jī)發(fā)送 TCP SYN 報(bào)文選擇初始序號(hào)無(wú)數(shù)據(jù) 2: 服務(wù)器主機(jī)收到 SYN報(bào)文, 應(yīng)答 SYN ACK 報(bào)文服務(wù)器分配緩存選擇服務(wù)器方的初始序號(hào) 3: 客戶主機(jī)收到 SYNACK報(bào)文,應(yīng)答 ACK 報(bào)文，該報(bào)文可能攜帶數(shù)據(jù)TCP連接的建立三次握手3.5 面向連接的傳輸 : TCP2022年7月25日1053.5 面向連接的傳輸 : TCPTCP連接的建立SYN, SEQ = x主機(jī) BSYN, ACK, SEQ = y, ACK= x 1ACK, SEQ

45、 = x + 1, ACK = y 1被動(dòng)打開主動(dòng)打開確認(rèn)確認(rèn)主機(jī) A連接請(qǐng)求 TCP 連接管理 關(guān)閉連接客戶端關(guān)閉套接字: clientSocket.close(); 1: 客戶端 向服務(wù)器端發(fā)送 TCP FIN 報(bào)文 2: 服務(wù)器端 收到 FIN報(bào)文, 應(yīng)答ACK報(bào)文. 關(guān)閉連接時(shí)發(fā)送 FIN報(bào)文. 3: 客戶端 收到 FIN報(bào)文,應(yīng)答 ACK報(bào)文. 進(jìn)入 “timed wait” 狀態(tài)- 將對(duì)收到的FIN報(bào)文應(yīng)答ACK報(bào)文 4: 服務(wù)器端, 收到 ACK報(bào)文. 連接關(guān)閉. 3.5 面向連接的傳輸 : TCP2022年7月25日107TCP 連接釋放的過程 FIN, SEQ = xACK,

46、 SEQ = y, ACK= x 1ACK, SEQ = x + 1, ACK = y 1應(yīng)用進(jìn)程釋放連接A 不再發(fā)送報(bào)文FIN, ACK, SEQ = y, ACK = x + 1主機(jī) B主機(jī) A通知主機(jī)應(yīng)用進(jìn)程應(yīng)用進(jìn)程釋放連接B 不再發(fā)送報(bào)文確認(rèn)確認(rèn)從 A 到 B 的連接就釋放了，連接處于半關(guān)閉狀態(tài)。相當(dāng)于 A 向 B 說(shuō)：“我已經(jīng)沒有數(shù)據(jù)要發(fā)送了。但你如果還發(fā)送數(shù)據(jù)，我仍接收?！?至此，整個(gè)連接已經(jīng)全部釋放。2022年7月25日1083.5 面向連接的傳輸 : TCPTCP連接管理的狀態(tài)序列客戶機(jī)TCP狀態(tài)序列服務(wù)器TCP狀態(tài)序列2022年7月25日1093.6 擁塞控制原理?yè)砣幕局?/p>

47、識(shí)非正式定義: “過多的源端發(fā)送了過多的數(shù)據(jù)，超出了網(wǎng)絡(luò)的處理能力”不同于流量控制現(xiàn)象：丟包 (路由器緩沖區(qū)溢出)延時(shí)長(zhǎng) (在路由器緩沖區(qū)排隊(duì))2022年7月25日1103.6 擁塞控制原理情境1兩個(gè)發(fā)送方，兩個(gè)接受方一個(gè)具有無(wú)限大緩存的路由器沒有重傳無(wú)限制的共享式輸出鏈路緩存主機(jī) Alin : 原始數(shù)據(jù)主機(jī) Blout主機(jī)D主機(jī)C2022年7月25日1113.6 擁塞控制原理情境1最大可獲得的吞吐量出現(xiàn)擁塞時(shí)延時(shí)變大擁塞代價(jià)：當(dāng)分組到達(dá)速率接近鏈路容量時(shí)，分組 經(jīng)歷的巨大排隊(duì)時(shí)延2022年7月25日1123.6 擁塞控制原理情境2一個(gè)具有有限 緩存的路由器發(fā)送方對(duì)丟失的分組進(jìn)行重傳有限的共享

48、式輸出鏈路緩存主機(jī) Alin : 原始數(shù)據(jù)主機(jī) Bloutlin : 原始數(shù)據(jù)+重傳數(shù)據(jù)主機(jī) D主機(jī) C2022年7月25日1133.6 擁塞控制原理設(shè)計(jì)期望: (goodput)“理想” 的重傳是僅僅在丟包時(shí)才發(fā)生重傳:對(duì)延遲到達(dá)(而非丟失)的分組的重傳使得 比理想情況下更大于linlout=linloutlinlout擁塞的“開銷” : 發(fā)送方必須重傳以補(bǔ)償因?yàn)榫彺嬉绯龆鴣G失的分組發(fā)送方在遇到大的時(shí)延時(shí)所進(jìn)行的不必要重傳會(huì)引起路由器轉(zhuǎn)發(fā)不必要的分組拷貝而占用其鏈路帶寬R/2R/2linlouta.R/2R/2linc.R/4R/2R/2linloutb.loutR/32022年7月25日1

49、143.6 擁塞控制原理情境3四個(gè)發(fā)送方多跳路徑超時(shí)/重傳有限的共享式輸出鏈路緩存主機(jī) Alin : 原始數(shù)據(jù)主機(jī)Bloutlin : 原始數(shù)據(jù)加重傳數(shù)據(jù)主機(jī)C主機(jī)D2022年7月25日1153.6 擁塞控制原理情境3擁塞的另一個(gè)”開銷”: 當(dāng)分組被丟棄時(shí)，該分組曾用到的所有“上游”傳輸容量被浪費(fèi)了！2022年7月25日1163.6 擁塞控制原理?yè)砣刂频姆椒ňW(wǎng)絡(luò)輔助的擁塞控制直接網(wǎng)絡(luò)反饋：路由器以阻塞分組的形式通知發(fā)送方“網(wǎng)絡(luò)擁塞了”經(jīng)由接收方的網(wǎng)絡(luò)反饋：路由器標(biāo)識(shí)從發(fā)送方流向接收方分組中的某個(gè)字段以指示擁塞的產(chǎn)生，由接收方通知發(fā)送方“網(wǎng)絡(luò)擁塞了”端到端擁塞控制網(wǎng)絡(luò)層不為擁塞控制提供任何幫助

50、和支持端系統(tǒng)通過對(duì)網(wǎng)絡(luò)行為（丟包或時(shí)延增加）的觀測(cè)判斷網(wǎng)絡(luò)是否發(fā)生擁塞目前TCP采用該種方法2022年7月25日1173.6 擁塞控制原理網(wǎng)絡(luò)輔助擁塞控制的例子：ATM ABR擁塞控制特點(diǎn)“彈性服務(wù)” 當(dāng)發(fā)送方網(wǎng)絡(luò) “輕載”時(shí): 發(fā)送方應(yīng)充分利用空閑的可用帶寬當(dāng)發(fā)送方網(wǎng)絡(luò)”擁塞”時(shí): 發(fā)送方應(yīng)將傳輸速率抑制為最小承諾傳輸速率2022年7月25日1183.6 擁塞控制原理工作機(jī)制發(fā)送方散布在數(shù)據(jù)信元中會(huì)發(fā)出若干個(gè)RM(資源管理)信元交換機(jī)可以設(shè)置RM信元中的比特 (“網(wǎng)絡(luò)輔助”) NI比特: 不得增大發(fā)送速率 (輕度擁塞)CI比特: 擁塞指示(嚴(yán)重?fù)砣?接收方會(huì)將RM信元完整地回送給發(fā)送方源 端

51、RM信元數(shù)據(jù)信元交換機(jī)交換機(jī)目的端2022年7月25日1193.6 擁塞控制原理RM信元中包含一個(gè)兩字節(jié)的顯式速率ER (explicit rate) 字段出現(xiàn)擁塞的交換機(jī)會(huì)減小經(jīng)過自己的信元中ER字段的值發(fā)送方的發(fā)送速率也因之減小為路徑支持的最小速率，可以得到最低程度的支持?jǐn)?shù)據(jù)信元中的EFCI 比特: 擁塞交換機(jī)將之置1來(lái)通知目的主機(jī)網(wǎng)絡(luò)已經(jīng)出現(xiàn)擁塞如果一個(gè)RM信元到達(dá)時(shí)之前，多數(shù)數(shù)據(jù)信元的EFCI比特置1，目的方會(huì)將返回給發(fā)送方的RM信元中CI比特置12022年7月25日1203.7 TCP擁塞控制TCP擁塞控制為端到端擁塞控制TCP進(jìn)行擁塞控制的方法每個(gè)發(fā)送方自動(dòng)感知網(wǎng)絡(luò)擁塞的程度發(fā)送方

52、根據(jù)感知的結(jié)果限制外發(fā)的流量如果前方路徑上出現(xiàn)了擁塞，則降低發(fā)送速率如果前方路徑上沒有出現(xiàn)擁塞，則增加發(fā)送速率2022年7月25日1213.7 TCP擁塞控制TCP擁塞控制需要解決的三個(gè)問題TCP發(fā)送方如何限制外發(fā)流量的速率擁塞窗口 LastByteSent-LastByteAcked minCongWin,RcvWindow發(fā)送方如何感知擁塞超時(shí)三個(gè)冗余ACK在感知到擁塞后，發(fā)送方如何調(diào)節(jié)發(fā)送速率rate = CongWin RTT Bytes/sec2022年7月25日1223.7 TCP擁塞控制TCP擁塞控制算法（Reno算法）加性增，乘性減（AIMD）出現(xiàn)丟包事件后將當(dāng)前 CongWi

53、n 大小減半，可以大大減少注入到網(wǎng)絡(luò)中的分組數(shù)當(dāng)沒有丟包事件發(fā)生，每個(gè)RTT之后將CongWin增大1個(gè)MSS使擁塞窗口緩慢增大，以防止網(wǎng)絡(luò)過早出現(xiàn)擁塞擁塞窗口時(shí)間2022年7月25日1233.7 TCP擁塞控制慢啟動(dòng)建立連接時(shí), CongWin = 1 MSS例如: MSS = 500 bytes & RTT = 200 msec初始速率 = 20 kbps可用帶寬 MSS/RTT初始階段以指數(shù)的速度增加發(fā)送速率連接初始階段，以指數(shù)的速度增加發(fā)送速率，直到發(fā)生一個(gè)丟包事件為止每過一個(gè)RTT將CongWin的值翻倍每收到一個(gè)ACK就增加Congwin總結(jié): 初始速率很低但速率的增長(zhǎng)速度很快20

54、22年7月25日1243.7 TCP擁塞控制慢啟動(dòng)主機(jī) A1個(gè)報(bào)文段RTT主機(jī) B時(shí)間兩個(gè)報(bào)文段四個(gè)報(bào)文段2022年7月25日1253.7 TCP擁塞控制對(duì)超時(shí)事件的反應(yīng)門限值設(shè)為當(dāng)前CongWin的一半（門限值初始值65kB）將CongWin設(shè)為1個(gè) MSS大小; 窗口以指數(shù)速度增大窗口增大到門限值之后，再以線性速度增大對(duì)收到3個(gè)重復(fù)ACK的反應(yīng)將CongWin減為原來(lái)的一半線性增大擁塞窗口特別說(shuō)明：早期的TCP Tahoe版本對(duì)上述兩個(gè)事件并不區(qū)分，統(tǒng)一將CongWin降為1。實(shí)際上， 3個(gè)重復(fù)的ACK相對(duì)超時(shí)來(lái)說(shuō)是一個(gè)預(yù)警信號(hào)，因此在Reno版中作了區(qū)分2022年7月25日126當(dāng) TC

55、P 連接進(jìn)行初始化時(shí)，將擁塞窗口置為 1。圖中的窗口單位不使用字節(jié)而使用報(bào)文段。慢啟動(dòng)門限的初始值設(shè)置為 16 個(gè)報(bào)文段，即 ssthresh = 16。246810121416182022004812162024傳輸次數(shù)擁塞窗口 cwnd進(jìn)入擁塞避免發(fā)生超時(shí)指數(shù)規(guī)律增長(zhǎng)線性規(guī)律增長(zhǎng)ssthresh = 16慢啟動(dòng)慢啟動(dòng)擁塞避免擁塞避免更新后的 ssthresh = 12進(jìn)入擁塞避免慢啟動(dòng)和擁塞避免算法的實(shí)現(xiàn)舉例 2022年7月25日127發(fā)送端的發(fā)送窗口不能超過擁塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我們假定接收端窗口足夠大，因此現(xiàn)在發(fā)送窗口的數(shù)值等于擁塞窗口的數(shù)值。2468

56、10121416182022004812162024傳輸次數(shù)擁塞窗口 cwnd進(jìn)入擁塞避免發(fā)生超時(shí)指數(shù)規(guī)律增長(zhǎng)線性規(guī)律增長(zhǎng)ssthresh = 16慢啟動(dòng)慢啟動(dòng)擁塞避免擁塞避免更新后的 ssthresh = 12進(jìn)入擁塞避免慢啟動(dòng)和擁塞避免算法的實(shí)現(xiàn)舉例 2022年7月25日128慢啟動(dòng)和擁塞避免算法的實(shí)現(xiàn)舉例 在執(zhí)行慢啟動(dòng)算法時(shí)，擁塞窗口 cwnd 的初始值為 1，發(fā)送第一個(gè)報(bào)文段 M0。 246810121416182022004812162024傳輸次數(shù)擁塞窗口 cwnd進(jìn)入擁塞避免發(fā)生超時(shí)指數(shù)規(guī)律增長(zhǎng)線性規(guī)律增長(zhǎng)ssthresh = 16慢啟動(dòng)慢啟動(dòng)擁塞避免擁塞避免更新后的 ssthr

57、esh = 12進(jìn)入擁塞避免2022年7月25日129慢啟動(dòng)和擁塞避免算法的實(shí)現(xiàn)舉例 246810121416182022004812162024傳輸次數(shù)擁塞窗口 cwnd進(jìn)入擁塞避免發(fā)生超時(shí)指數(shù)規(guī)律增長(zhǎng)線性規(guī)律增長(zhǎng)ssthresh = 16慢啟動(dòng)慢啟動(dòng)擁塞避免擁塞避免更新后的 ssthresh = 12進(jìn)入擁塞避免發(fā)送端收到 ACK1 （確認(rèn) M0，期望收到 M1）后，將 cwnd 從 1 增大到 2，于是發(fā)送端可以接著發(fā)送 M1 和 M2 兩個(gè)報(bào)文段。 2022年7月25日130慢啟動(dòng)和擁塞避免算法的實(shí)現(xiàn)舉例 接收端發(fā)回 ACK2 和 ACK3。發(fā)送端每經(jīng)過一個(gè)RTT，就把發(fā)送端的擁塞窗口

58、翻倍?，F(xiàn)在發(fā)送端的 cwnd 從 2 增大到 4，并可發(fā)送 M3 M6共 4個(gè)報(bào)文段。 246810121416182022004812162024傳輸次數(shù)擁塞窗口 cwnd進(jìn)入擁塞避免發(fā)生超時(shí)指數(shù)規(guī)律增長(zhǎng)線性規(guī)律增長(zhǎng)ssthresh = 16慢啟動(dòng)慢啟動(dòng)擁塞避免擁塞避免更新后的 ssthresh = 12進(jìn)入擁塞避免2022年7月25日131慢啟動(dòng)和擁塞避免算法的實(shí)現(xiàn)舉例 發(fā)送端每經(jīng)過一個(gè)RTT，就把發(fā)送端的擁塞窗口翻倍，因此擁塞窗口 cwnd 隨著傳輸次數(shù)按指數(shù)規(guī)律增長(zhǎng)。 246810121416182022004812162024傳輸次數(shù)擁塞窗口 cwnd進(jìn)入擁塞避免發(fā)生超時(shí)指數(shù)規(guī)律增長(zhǎng)

59、線性規(guī)律增長(zhǎng)ssthresh = 16慢啟動(dòng)慢啟動(dòng)擁塞避免擁塞避免更新后的 ssthresh = 12進(jìn)入擁塞避免2022年7月25日132慢啟動(dòng)和擁塞避免算法的實(shí)現(xiàn)舉例 當(dāng)擁塞窗口 cwnd 增長(zhǎng)到慢啟動(dòng)門限值 ssthresh 時(shí)(即當(dāng) cwnd = 16 )，就改為執(zhí)行擁塞避免算法，擁塞窗口按線性規(guī)律增長(zhǎng)。 246810121416182022004812162024傳輸次數(shù)擁塞窗口 cwnd進(jìn)入擁塞避免發(fā)生超時(shí)指數(shù)規(guī)律增長(zhǎng)ssthresh = 16慢啟動(dòng)慢啟動(dòng)線性規(guī)律增長(zhǎng)擁塞避免擁塞避免更新后的 ssthresh = 12進(jìn)入擁塞避免2022年7月25日133慢啟動(dòng)和擁塞避免算法的實(shí)現(xiàn)舉例 假定擁塞窗口的數(shù)值增長(zhǎng)到 24 時(shí)，網(wǎng)絡(luò)出現(xiàn)超時(shí)（表明網(wǎng)絡(luò)擁塞了）。 246810121416182022004812162024傳輸次數(shù)擁塞窗口 cwnd進(jìn)入擁塞避免發(fā)生超時(shí)指數(shù)規(guī)律增長(zhǎng)線性規(guī)律增長(zhǎng)ssthresh = 16慢啟動(dòng)慢