第3章-運輸層課件

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

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

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

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

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

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

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

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

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

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

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

12、例子: 將兩個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回卷和檢查和注意：最高有效位的進位要回卷加到結果當中2022年7月25日253.4 可靠數(shù)據(jù)傳輸?shù)脑砜煽繑?shù)據(jù)傳輸在應用層、運輸層和鏈路層都很重要網(wǎng)絡中最重要的top-10問題之一!2022年7月25日263.4 可靠數(shù)據(jù)傳輸?shù)脑聿豢煽啃诺?/p>

13、的特性決定了可靠數(shù)據(jù)傳輸協(xié)議(rdt)的復雜性。2022年7月25日273.4 可靠數(shù)據(jù)傳輸?shù)脑戆l(fā)送方接收方rdt_send(): 由上層（如應用層）調(diào)用，將數(shù)據(jù)發(fā)送給接收方的上層udt_send(): 由 rdt調(diào)用,將分組通過不可靠信道傳給接收方rdt_rcv(): 當分組到達接收方時調(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)機 (FSM

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

15、03.4 可靠數(shù)據(jù)傳輸?shù)脑硇诺揽赡軐е卤忍爻霈F(xiàn)差錯時rdt 2.x第一個版本rdt 2.0假設分組比特可能受損所有傳輸?shù)姆纸M都將按序被接收，不會丟失處理機制如何判斷分組受損差錯檢測如何通知發(fā)送方分組是否受損接收方反饋（ACK和NAK）在得知分組受損后，發(fā)送方如何處理出錯重傳在計算機網(wǎng)絡中，基于這種重傳機制的可靠數(shù)據(jù)傳輸協(xié)議稱為自動重傳請求協(xié)議（ARQ）2022年7月25日313.4 可靠數(shù)據(jù)傳輸?shù)脑韗dt 2.0的有限狀態(tài)機FSM等待來自上層的調(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等待來自下層的調(diào)用發(fā)送方接收方rdt_send(data)L2022年7月25日323.4 可靠數(shù)據(jù)傳輸?shù)脑淼却齺碜陨蠈拥恼{(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等待來自下層的調(diào)用rdt_send(data)L發(fā)送方接收方rdt2.0: 無差錯的情況2022年7月25日333.4 可靠數(shù)據(jù)

18、傳輸?shù)脑淼却齺碜陨蠈拥恼{(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等待來自下層的調(diào)用rdt_s

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

20、可以檢查比特差錯，還可以恢復比特差錯收到出錯的反饋時，不管三七二十一，直接重發(fā)當前數(shù)據(jù)分組，但這就需要對數(shù)據(jù)分組進行編號，以示識別 解決ACK/NAK受損問題的一個簡單方法發(fā)送方對每一個分組增加序號(sequence number)發(fā)送方只重傳沒有收到ACK/NAK 的分組接收方丟棄重復分組(不向上遞交)對于停等協(xié)議，1比特序號足夠了（序號為0或1）發(fā)送方發(fā)出一個分組，然后等待接收方的應答停止等待(stop-and-wait)3.4 可靠數(shù)據(jù)傳輸?shù)脑?022年7月25日373.4 可靠數(shù)據(jù)傳輸?shù)脑韗dt 2.1的發(fā)送方等待來自上層的調(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) 等待來自上層的調(diào)用1等待ACK 或 NAK 1LL2022年7月25日383.4 可靠數(shù)據(jù)傳輸?shù)脑韗dt 2.1的接收方等待來自下層的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)等待來自下層的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ù)脑淼谌齻€版本rdt 2.2針對rdt 2.1的改進只使用ACK取消NAK，接收方對最后一個正確收到的分組發(fā)送 ACK接收方必須明確指出被確認的分組的序號發(fā)送方收到的重復的ACK將按照NA

25、K來進行處理重傳正確的分組2022年7月25日403.4 可靠數(shù)據(jù)傳輸?shù)脑淼却齺碜陨蠈拥恼{(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等待來自下層的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ù)脑磲槍dt 2.x的進一步討論rdt 2.x實際上也解決了流控問題2022年7月25日423.4 可靠數(shù)據(jù)傳輸?shù)脑硇诺啦坏鲥e，而且丟包時rdt 3.0假設底層信道不但可能出現(xiàn)比特差錯

27、，而且可能會丟包需解決的問題怎樣檢測丟包發(fā)生丟包后，如何處理檢查和技術、序號、ACK、重傳如何判斷數(shù)據(jù)報丟失了呢？最簡單的方法就是：耐心的等待Q: 僅僅耐心等待就夠了嗎?想一想: 缺點?解決方法: 發(fā)送方對ACK等待“適當?shù)摹睍r間如果在這個時間內(nèi)沒有收到ACK則重傳如果分組或ACK僅僅是延遲到達（而非丟失）:重傳將造成重復，但序號可以解決這個問題接收方必須指出確認的分組序號需要倒計時的計時器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) )等待來自上層的調(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)等待來自上層的調(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ù)脑韉)過早超時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超時重發(fā)分組1pkt 0ACK 0ACK 1pkt 0ACK 0發(fā)送方接收方發(fā)送分組0接收ACK0發(fā)送分組1接收ACK1發(fā)送分組0接收分組0發(fā)送ACK0接收分組1(檢測冗余發(fā)送ACK1)發(fā)送ACK1接收分組0發(fā)送ACK0pkt 1丟失超時重發(fā)分組1pkt 1ACK 1接收分組1發(fā)送ACK1ACK 1ACK 1接收ACK1什么也不做接收分組1(檢測冗余發(fā)送ACK1)發(fā)送ACK1rdt3.0有時也被成為比特交替協(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)絡協(xié)議限制了物理資源的利用率!2022年7月25日483.4 可靠數(shù)據(jù)傳輸?shù)脑韗dt 3.0性能低下的原因首個分組的第1個比特被傳輸, t = 0發(fā)送方接收方RTT 首個分組的最后1比特被傳輸, t = L / R首個分組的第1個比特到達首個分組的最后1個比特到達,發(fā)送ACKACK 到達, 發(fā)送下一個分組, t = RTT + L / R2022年7月25日

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

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

34、個分組后，如何進行重傳Go-Back-N（GBN）協(xié)議：其后分組全部重傳選擇重傳（SR）協(xié)議：僅重傳該分組2022年7月25日543.4 可靠數(shù)據(jù)傳輸?shù)脑鞧BN時序圖2022年7月25日553.4 可靠數(shù)據(jù)傳輸?shù)脑鞧o-Back-N協(xié)議特點ACK(n): 接收方對序號n之前包括n在內(nèi)的所有分組進行確認 - “累積 ACK”對所有已發(fā)送但未確認的分組統(tǒng)一設置一個定時器超時(n): 重傳分組n和窗口中所有序號大于n的分組失序分組: 丟棄 (不緩存) - 接收方無緩存重發(fā)按序到達的最高序號分組的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 */ 從應用程序接收數(shù)據(jù)將數(shù)據(jù)封裝入報文段中，每個報文段都包含一個序號序號是該報文段第一個數(shù)據(jù)字節(jié)的字節(jié)流編號啟動定時器超時間隔: TimeOutInterv

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

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

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

39、報文段的到達最多等待500ms。如果下一個按序報文段在這個時間間隔內(nèi)沒有到達，則發(fā)送一個ACK立即發(fā)送單個累積ACK，以確認兩個按序報文段 立即發(fā)送冗余ACK，指明下一個期待字節(jié)的序號(也就是間隔的低端字節(jié)序號)倘若該報文段起始于間隔的低端，則立即發(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 重復的ACK報文快速重傳2022年7月25日983.5 面向連接的傳輸 : TCPTCP流量控制背景TCP接收方有一個緩存，所有上交的數(shù)據(jù)全部緩存在里面應用進程從緩沖區(qū)中讀取數(shù)據(jù)可能很慢目標發(fā)送方不會由于傳得太多太快而使得接收方緩存溢出手段接收方在反饋時，將緩沖區(qū)剩余空間的大小填充在報文段首部的窗口字段中，通知發(fā)送方2022

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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