《計算機自頂向下》PPT第三章

TransportLayer3-1Chapter3

運輸層ComputerNetworking:ATopDownApproach

4thedition.

JimKurose,KeithRoss

Addison-Wesley,July2007.

Anoteontheuseofthesepptslides:We’remakingtheseslidesfreelyavailabletoall(faculty,students,readers).They’reinPowerPointformsoyoucanadd,modify,anddeleteslides(includingthisone)andslidecontenttosuityourneeds.Theyobviouslyrepresentalotofworkonourpart.Inreturnforuse,weonlyaskthefollowing:Ifyouusetheseslides(e.g.,inaclass)insubstantiallyunalteredform,thatyoumentiontheirsource(afterall,we’dlikepeopletouseourbook!)Ifyoupostanyslidesinsubstantiallyunalteredformonawwwsite,thatyounotethattheyareadaptedfrom(orperhapsidenticalto)ourslides,andnoteourcopyrightofthismaterial.Thanksandenjoy!JFK/KWRAllmaterialcopyright1996-2007J.FKuroseandK.W.Ross,AllRightsReservedTransportLayer3-2

運輸層2第3章:運輸層我們的目的:

理解運輸層服務依據(jù)的原理:復用/分解可靠數(shù)據(jù)傳輸流量控制擁塞控制學習因特網(wǎng)中的運輸層協(xié)議：UDPTCPTransportLayer3-3

運輸層3第3章

要點3.1運輸層服務3.2復用與分解3.3無連接傳輸:UDP3.4可靠數(shù)據(jù)傳輸?shù)脑瓌t3.5面向連接的傳輸:TCP報文段結構可靠數(shù)據(jù)傳輸流量控制連接管理3.6擁塞控制的原則3.7TCP擁塞控制TransportLayer3-4

運輸層4運輸服務和協(xié)議在運行不同主機上應用進程之間提供邏輯通信運輸協(xié)議運行在端系統(tǒng)中發(fā)送方：將應用報文劃分為報文段，傳向網(wǎng)絡層接收方：將報文段重新裝配為報文，傳向應用層應用可供使用的運輸協(xié)議不止一個因特網(wǎng)：TCP和UDP應用層運輸層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層應用層運輸層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層邏輯端到端傳輸運輸層為相互通信的應用進程提供了邏輯通信54321運輸層提供應用進程間的邏輯通信主機A主機B應用進程應用進程路由器1路由器2AP1LAN2WANAP2AP3AP4IP層LAN1AP1AP2AP4端口端口54321IP協(xié)議的作用范圍運輸層協(xié)議TCP和UDP的作用范圍AP3TransportLayer3-6運輸層vs.網(wǎng)絡層應用進程…應用進程…IP協(xié)議的作用范圍（提供主機之間的邏輯通信）TCP和UDP協(xié)議的作用范圍（提供進程之間的邏輯通信）因特網(wǎng)TransportLayer3-7

運輸層7運輸層vs.網(wǎng)絡層網(wǎng)絡層:

主機間的邏輯通信運輸層:

進程間的邏輯通信依賴、強化網(wǎng)絡層服務運輸層只工作在端系統(tǒng)，中間路由器不處理和識別運輸層的任何信息計算機網(wǎng)絡可以有多種運輸層協(xié)議和不同的服務模型(例如因特網(wǎng)有TCP和UDP)運輸層協(xié)議所能提供的服務受到底層網(wǎng)絡協(xié)議的服務模型的限制在網(wǎng)絡層不提供相應服務的情況下，運輸層能提供某些服務如可靠和安全家庭類比:12個孩子向12個孩子發(fā)信進程=孩子應用報文=信封中的信主機=家庭運輸協(xié)議=Ann和Bill網(wǎng)絡層協(xié)議=郵政服務TransportLayer3-8

運輸層8因特網(wǎng)運輸層協(xié)議IP提供的是“盡力而為”交付服務-不可靠服務不保證交付不保證按序交付不保證數(shù)據(jù)完整UDP-“盡力而為”IP的服務的簡單擴展，增加了兩種最低限度的運輸層服務多路復用、分解(進程間交付)差錯檢測運輸層的多路復用與多路分解：將主機之間的交付擴展到進程間的交付應用層運輸層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層應用層運輸層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層邏輯端到端傳輸TransportLayer3-9

運輸層9因特網(wǎng)運輸層協(xié)議可靠的、按序的交付(TCP)復用/分解可靠數(shù)據(jù)傳輸：通過使用序號、確認和定時器流量控制擁塞控制不提供的服務:時延保證帶寬保證應用層運輸層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層應用層運輸層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層邏輯端到端傳輸運輸層向上提供可靠的和不可靠的邏輯通信信道？應用層運輸層發(fā)送進程接收進程接收進程數(shù)據(jù)數(shù)據(jù)全雙工可靠信道數(shù)據(jù)數(shù)據(jù)使用TCP協(xié)議使用UDP協(xié)議不可靠信道發(fā)送進程TransportLayer3-11

運輸層11第3章

要點3.1運輸層服務3.2復用與分解3.3無連接傳輸:UDP3.4可靠數(shù)據(jù)傳輸?shù)脑瓌t3.5面向連接的傳輸:TCP報文段結構可靠數(shù)據(jù)傳輸流量控制連接管理3.6擁塞控制的原則3.7TCP擁塞控制TransportLayer3-12

運輸層12復用/分解應用層運輸層網(wǎng)絡層鏈路層物理層P1應用層運輸層網(wǎng)絡層鏈路層物理層應用層運輸層network鏈路層物理層P2P3P4P1主機1主機2主機3=進程=套接字將接收到的段交付給正確的套接字在接收主機分解：從多個套接字收集數(shù)據(jù)，用首部封裝數(shù)據(jù)（以后用于分解）生成報文段傳遞給網(wǎng)絡在發(fā)送主機復用:端口在進程之間的通信中所起的作用應用層運輸層網(wǎng)絡層TCP報文段UDP用戶數(shù)據(jù)報應用進程TCP復用IP復用UDP復用TCP報文段UDP用戶數(shù)據(jù)報應用進程端口端口TCP分解UDP分解IP分解IP數(shù)據(jù)報IP數(shù)據(jù)報發(fā)送方接收方TransportLayer3-14

運輸層14分解工作過程運輸層多路分解的要求套接字有唯一標識符報文段有字段來指示其所要交付的套接字主機接收到得IP數(shù)據(jù)報每個數(shù)據(jù)報有源IP地址,目的地IP地址每個數(shù)據(jù)報承載1個運輸層段每個段具有源、目的端口號

主機使用IP地址&端口號將段定向到適當?shù)奶捉幼衷炊丝?目的端口#32bits應用數(shù)據(jù)(報文)其他首部字段TCP/UDP段格式TransportLayer3-15

運輸層15無連接分解生成具有端口號的套接字:DatagramSocketmySocket1=newDatagramSocket();

運輸層自動分配端口號（客戶機）DatagramSocketmySocket2=newDatagramSocket(99222);

指派端口號（服務器）UDP套接字由二元組標識:(目的地IP地址,目的地端口號)當主機接收UDP段時:在段中檢查目的地端口號將UDP段定向到具有該端口號的套接字具有不同源IP地址和/或源端口號,但是相同目的地端口號的IP數(shù)據(jù)報定向到相同的套接字源端口號的作用返回地址的一部分TransportLayer3-16

運輸層16無連接分解(續(xù))DatagramSocketserverSocket=newDatagramSocket(6428);客戶機IP:BP2客戶機IP:AP1P1P3服務器IP:CSP:6428DP:9157SP:9157DP:6428SP:6428DP:5775SP:5775DP:6428SP提供了“返回地址”UDP套接字UDPUDP服務器1UDP客戶臨時端口熟知端口UDP客戶臨時端口UDP客戶臨時端口一次一個客戶服務器只使用一個熟知端口上的套接字。課件制作人：謝希仁端口是用報文隊列來實現(xiàn)UDP端口51000UDP端口69出隊列入隊列出隊列入隊列TFTP服務器TFTP客戶UDP用戶數(shù)據(jù)報應用層運輸層TransportLayer3-19

運輸層19面向連接分解TCP套接字由四元組標識:源IP地址源端口號目的IP地址目的端口號接收主機使用這四個值來將段定向到適當?shù)奶捉幼址掌骺赡苤С衷S多并行的TCP套接字：每個套接字與一個進程聯(lián)系并且由其自己的四元組標識Web服務器對每個連接的客戶機生成不同的套接字TransportLayer3-20

運輸層20面向連接分解:多線程Web服務器客戶機IP:BP1客戶機IP:AP1P2服務器IP:CSP:9157DP:80SP:9157DP:80P4P3D-IP:CS-IP:AD-IP:CS-IP:BSP:5775DP:80D-IP:CS-IP:BTransportLayer3-21

運輸層21面向連接分解(多進程Web服務器)客戶機IP:BP1客戶機IP:AP1P2P4服務器IP:CSP:9157DP:80SP:9157DP:80P5P6P3D-IP:CS-IP:AD-IP:CS-IP:BSP:5775DP:80D-IP:CS-IP:B面向連接并發(fā)服務器的特點TCPTCP客戶TCP客戶TCP客戶歡迎套接字TCP連接歡迎套接字僅用于接受服務請求創(chuàng)建連接套接字應用層23TCP套接字編程三次握手數(shù)據(jù)客戶機套接字連接套接字歡迎套接字客戶機進程服務器進程面向連接分解三次握手數(shù)據(jù)連接套接字歡迎套接字服務器進程TransportLayer3-25

運輸層25網(wǎng)絡層的復用與分解1ICMPInternet控制消息2IGMPInternet組管理6TCP傳輸控制8EGP外部網(wǎng)關協(xié)議9IGP任何專用內部網(wǎng)關（Cisco將其用于IGRP）17UDP用戶數(shù)據(jù)報46RSVP保留協(xié)議TransportLayer3-26

運輸層26第3章

要點3.1運輸層服務3.2復用與分解3.3無連接傳輸:UDP3.4可靠數(shù)據(jù)傳輸?shù)脑瓌t3.5面向連接的傳輸:TCP報文段結構可靠數(shù)據(jù)傳輸流量控制連接管理3.6擁塞控制的原則3.7TCP擁塞控制TransportLayer3-27

運輸層27UDP:用戶數(shù)據(jù)報協(xié)議[RFC768]只做了運輸協(xié)議能夠做的最少工作，“沒有不必要的,”只有“基本要素”的互聯(lián)網(wǎng)傳輸協(xié)議除了多路復用、分解和差錯檢測幾乎沒有對IP增加別的東西“盡力而為”服務，UDP段可能：丟包對應用程序交付失序無連接:在UDP發(fā)送方和接收方之間無握手每個UDP段的處理獨立于其他段,段之間沒有順序關系運輸層向上提供可靠的和不可靠的邏輯通信信道？應用層運輸層發(fā)送進程接收進程接收進程數(shù)據(jù)數(shù)據(jù)全雙工可靠信道數(shù)據(jù)數(shù)據(jù)使用TCP協(xié)議使用UDP協(xié)議不可靠信道發(fā)送進程TransportLayer3-29

運輸層29UDP:用戶數(shù)據(jù)報協(xié)議[RFC768]為何要使用UDP協(xié)議?應用層可以更好的控制要發(fā)送的數(shù)據(jù)和時間擁塞控制在擁塞的時候會抑制發(fā)送速率TCP的可靠交付需要更長的時間，UDP能夠盡可能快地傳輸無連接創(chuàng)建(它將增加時延)簡單：在發(fā)送方、接收方無連接狀態(tài)不需要緩存、序號、確認序號、擁塞控制參數(shù)可以支持更多的客戶機段首部開銷小TCP20字節(jié)UDP8字節(jié)TransportLayer3-30

運輸層30UDP:其他UDP的應用DNSRIPSNMP常用于流式多媒體應用丟包容忍速率敏感UDP沒有擁塞控制機制帶來的問題導致?lián)砣?，帶來很高的丟包率，并且擠垮TCP會話使用UDP的應用怎么實現(xiàn)可靠傳輸:在應用層增加可靠性既實現(xiàn)可靠，又不受限于TCP的擁塞控制機制源端口#目的端口#32bits應用數(shù)據(jù)(報文)UDP段格式長度檢查和UDP段的長度，包括首部，以字節(jié)計TransportLayer3-31

運輸層31UDP檢查和發(fā)送方:將段內容處理為16比特整數(shù)序列檢查和:段內容的加法(反碼和)發(fā)送方將檢查和放入UDP檢查和字段接收方:計算接收的段的檢查和核對計算的檢查和是否等于檢查和字段的值:NO–檢測到差錯YES–無差錯檢測到。目的:

在傳輸?shù)亩沃袡z測“差錯”(如比特翻轉)TransportLayer3-32

運輸層32互聯(lián)網(wǎng)檢查和例子注意當數(shù)字作加法時，最高位進比特位的進位需要加到結果中例子:兩個16-bit整數(shù)相加1111001100110011011101010101010101110111011101110111101110111011110010100010001000011回卷和檢查和偽首部源端口目的端口長度檢驗和數(shù)據(jù)首部UDP長度源IP地址目的IP地址017IP數(shù)據(jù)報字節(jié)44112122222字節(jié)發(fā)送在前數(shù)據(jù)首部UDP用戶數(shù)據(jù)報在計算檢驗和時，臨時把“偽首部”和UDP用戶數(shù)據(jù)報連接在一起。偽首部僅僅是為了計算檢驗和。17為UDP協(xié)議號計算UDP檢驗和的例子1001100100010011→153.190000100001101000→8.1041010101100000011→171.30000111000001011→14.110000000000010001→0和170000000000001111→150000010000111111→10870000000000001101→130000000000001111→150000000000000000→0（檢驗和）0101010001000101→數(shù)據(jù)0101001101010100→數(shù)據(jù)0100100101001110→數(shù)據(jù)0100011100000000→數(shù)據(jù)和0（填充）1001011011101011→求和得出的結果0110100100010100→檢驗和04112字節(jié)偽首部8字節(jié)UDP首部7字節(jié)數(shù)據(jù)填充按二進制反碼運算求和將得出的結果求反碼全0171510871315全0數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)全0TransportLayer3-35

運輸層35UDP檢查和UDP是提供端到端的差錯檢測鏈路層的差錯檢測UDP提供差錯檢測，但是不提供差錯恢復TransportLayer3-36

運輸層36第3章

要點3.1運輸層服務3.2復用與分解3.3無連接傳輸:UDP3.4可靠數(shù)據(jù)傳輸?shù)脑瓌t3.5面向連接的傳輸:TCP報文段結構可靠數(shù)據(jù)傳輸流量控制連接管理3.6擁塞控制的原則3.7TCP擁塞控制TransportLayer3-37

運輸層37可靠數(shù)據(jù)傳輸?shù)脑瓌t在應用層、運輸層、數(shù)據(jù)鏈路層的重要性重要的網(wǎng)絡主題中的最重要的10個之一!可靠數(shù)據(jù)傳輸提供給深層實體的服務抽象是，數(shù)據(jù)通過可靠信道進行傳輸數(shù)據(jù)不損壞順序傳送這剛好是TCP所提供的服務模型實現(xiàn)這種服務抽象是可靠數(shù)據(jù)傳輸協(xié)議的責任，不可靠信道的特點決定了可靠數(shù)據(jù)傳輸協(xié)議(rdt)的復雜性TransportLayer3-38

運輸層38可靠數(shù)據(jù)傳輸?shù)脑瓌tTransportLayer3-39

運輸層39可靠數(shù)據(jù)傳輸:基本概念發(fā)送側接收側rdt_send():

calledfromabove,(e.g.,byapp.).Passeddatatobedeliveredtoreceiverupperlayerudt_send():

calledbyrdt,totransferpacketoverunreliablechanneltoreceiverrdt_rcv():

calledwhenpacketarrivesonrcv-sideofchanneldeliver_data():

calledbyrdttodeliverdatatoupperTransportLayer3-40

運輸層40可靠數(shù)據(jù)傳輸:基本概念我們將:僅考慮單向數(shù)據(jù)傳輸?shù)珔f(xié)議還是需要在兩個方向發(fā)送分組，控制信息將在兩個方向流動！使用有限狀態(tài)機(FSM)來定義發(fā)送方和接收方狀態(tài)1狀態(tài)2引起狀態(tài)變遷的事件狀態(tài)變遷所采取的行動狀態(tài):

當位于這個“狀態(tài)時”，下個狀態(tài)惟一地由下個事件決定事件動作TransportLayer3-41

運輸層41Rdt1.0:經(jīng)可靠信道的可靠傳輸?shù)讓有诺婪浅？煽繜o比特差錯無分組丟失順序傳送發(fā)送方、接收方的單獨FSM:發(fā)送方將數(shù)據(jù)發(fā)向底層信道接收方從底層信道讀取數(shù)據(jù)Waitforcallfromabovepacket=make_pkt(data)udt_send(packet)rdt_send(data)extract(packet,data)deliver_data(data)Waitforcallfrombelowrdt_rcv(packet)發(fā)送方接收方TransportLayer3-42

運輸層42Rdt2.0:具有比特差錯的信道底層的信道可能翻轉數(shù)據(jù)包中的比特檢測和檢測比特差錯怎么從錯誤中恢復確認(ACKs):

接收方告訴發(fā)送方pkt正確收到否認(NAKs):發(fā)送方當收到NAK的時候重傳pktrdt2.0

提供的新機制來處理比特差錯:差錯檢測接收方反饋:(ACK,NAK)rcvr->sender重傳ARQ自動重傳協(xié)議TransportLayer3-43

運輸層43rdt2.0:FSM規(guī)格參數(shù)等待來自上面的調用snkpkt=make_pkt(data,checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)rdt_rcv(rcvpkt)&&isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt)&&isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt)&&corrupt(rcvpkt)等待ACK或NAK等待來自下面的調用發(fā)送方接收方rdt_send(data)LTransportLayer3-44

運輸層44rdt2.0:無差錯時的操作等待來自上面的調用snkpkt=make_pkt(data,checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)rdt_rcv(rcvpkt)&&isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt)&&isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt)&&corrupt(rcvpkt)等待ACK或NAK等待來自下面的調用rdt_send(data)LTransportLayer3-45

運輸層45rdt2.0:有差錯時的情況等待來自上面的調用snkpkt=make_pkt(data,checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)rdt_rcv(rcvpkt)&&isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt)&&isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt)&&corrupt(rcvpkt)等待ACK或NAK等待來自下面的調用rdt_send(data)L發(fā)送方發(fā)送一個分組，然后等待接收方響應停止等待TransportLayer3-46

運輸層46rdt2.0有重大的缺陷!rdt2.0似乎可以運行了，但是如果ACK/NAK受損，將會出現(xiàn)何種情況？發(fā)送方不知道在接收方是否正確接收了上個分組，解決辦法：增加足夠的比特可以直接恢復比特錯誤重傳：但是不能解決問題，重傳會產(chǎn)生冗余分組，接收方不知他的ACK是否被發(fā)送方正確收到，所以無法知道收到的是新的分組還是重傳用分組序號來區(qū)分是重傳還是新的分組處理冗余:發(fā)送方對每個分組增加序列號如果ACK/NAK受損，發(fā)送方重傳當前的分組接收方丟棄(不再向上交付)冗余分組TransportLayer3-47

運輸層47rdt2.0有重大的缺陷!不能只是重傳：接收方不知收到的是新的分組還是重傳TransportLayer3-48rdt2.1:發(fā)送方處理受損的ACK/NAK正常情況分組受損TransportLayer3-49rdt2.1:發(fā)送方,處理受損的ACK/NAK反饋受損TransportLayer3-50

運輸層50rdt2.1:發(fā)送方,處理受損的ACK/NAK等待來自上面的調用0sndpkt=make_pkt(0,data,checksum)udt_send(sndpkt)rdt_send(data)等待ACK或NAKudt_send(sndpkt)rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||isNAK(rcvpkt))sndpkt=make_pkt(1,data,checksum)udt_send(sndpkt)rdt_send(data)rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||isNAK(rcvpkt))rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&isACK(rcvpkt)

等待來自上面的調用1等待ACK或NAKLLTransportLayer3-51

運輸層51rdt2.1:接收方,處理受損的ACK/NAK等待來自下面的調用0sndpkt=make_pkt(NAK,chksum)udt_send(sndpkt)rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&has_seq0(rcvpkt)rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&has_seq1(rcvpkt)

extract(rcvpkt,data)deliver_data(data)sndpkt=make_pkt(ACK,chksum)udt_send(sndpkt)等待來自下面的調用1rdt_rcv(rcvpkt)&¬corrupt(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)&¬corrupt(rcvpkt)&&has_seq1(rcvpkt)rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)sndpkt=make_pkt(ACK,chksum)udt_send(sndpkt)sndpkt=make_pkt(NAK,chksum)udt_send(sndpkt)TransportLayer3-52

運輸層52rdt2.1:討論發(fā)送方:序號seq#加入分組中兩個序號seq.#’s(0,1)將夠用.必須檢查收到的ACK/NAK是否受損狀態(tài)增加一倍狀態(tài)必須“記住”是否“當前的”分組具有0或1序號接收方:必須檢查是否接收到的分組是冗余的狀態(tài)指示是否0或1是所期待的分組序號seq#TransportLayer3-53

運輸層53rdt2.2:一種無NAK的協(xié)議與rdt2.1一樣的功能，僅使用ACK代替NAK,接收方對最后正確接收的分組發(fā)送ACK接收方必須明確地包括被確認分組的序號在發(fā)送方收到冗余的ACK導致如同NAK相同的動作：重傳當前分組TransportLayer3-54

運輸層54rdt2.2:發(fā)送方,接收方片段等待來自上面的調用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)&¬corrupt(rcvpkt)&&isACK(rcvpkt,0)

等待ACK0發(fā)送方FSM片段等待來自下面的調用0rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&has_seq1(rcvpkt)extract(rcvpkt,data)deliver_data(data)sndpkt=make_pkt(ACK，1,chksum)udt_send(sndpkt)rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||

has_seq1(rcvpkt))udt_send(sndpkt)接收方FSM片段LTransportLayer3-55rdt2.2正常情況分組受損TransportLayer3-56rdt2.2反饋受損TransportLayer3-57

運輸層57rdt3.0:具有差錯和丟包的信道新假設:

下面的信道也能丟失分組(數(shù)據(jù)或ACK)，那么協(xié)議必須解決兩個問題：怎么檢測丟包和以及發(fā)生丟包后該做些什么檢查和、序號、重傳將是有幫助的，可以解決后面這個問題檢測丟包有很多方法，現(xiàn)在我們假設由發(fā)送方來解決方法:

發(fā)送方等待ACK一段“合理的”時間如在這段時間沒有收到ACK則重傳如果分組(或ACK)只是延遲(沒有丟失)：重傳將是冗余的，但序號的使用已經(jīng)處理了該情況需要倒計數(shù)定時器TransportLayer3-58

運輸層58rdt3.0發(fā)送方sndpkt=make_pkt(0,data,checksum)udt_send(sndpkt)start_timerrdt_send(data)等待ACK0rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||isACK(rcvpkt,1))等待來自上面的調用1sndpkt=make_pkt(1,data,checksum)udt_send(sndpkt)start_timerrdt_send(data)rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&isACK(rcvpkt,0)

rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||isACK(rcvpkt,0))rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&isACK(rcvpkt,1)

stop_timerstop_timerudt_send(sndpkt)start_timertimeoutudt_send(sndpkt)start_timertimeoutrdt_rcv(rcvpkt)等待來自上面的調用0等待ACK1Lrdt_rcv(rcvpkt)LLLTransportLayer3-59

運輸層59rdt3.0運行情況無丟包時的運行分組丟失發(fā)送方發(fā)送方接收方接收方TransportLayer3-60

運輸層60rdt3.0運行情況ACK丟失過早超時發(fā)送方發(fā)送方接收方接收方TransportLayer3-61

運輸層61rdt3.0:停等協(xié)議的運行傳輸分組的第一個比特,t=0發(fā)送方接收方RTT

傳輸分組的最后一個比特,t=L/R分組第一個比特到達傳輸最后一個比特到達,發(fā)送ACKACK到達，發(fā)送下一個分組,t=RTT+L/RTransportLayer3-62

運輸層62流水線協(xié)議:增加利用率傳輸?shù)谝粋€分組比特,t=0發(fā)送者接收者RTT傳輸最后一個比特,t=L/R第一個分組比特到達分組最后一個比特到達,發(fā)送ACKACK到達,發(fā)送下一個分組,t=RTT+L/R第二個分組最后比特到達,發(fā)送ACK第三個分組最后比特到達,發(fā)送ACK利用率增加3倍!TransportLayer3-63

運輸層63流水線協(xié)議流水線:發(fā)送方允許發(fā)送多個、“傳輸中的”,還沒有應答的報文段序號的范圍必須增加發(fā)送方和/或接收方設有緩沖流水線協(xié)議的兩種形式:

回退N幀法（go-Back-N）,選擇性重傳（S-R）,TransportLayer3-64

運輸層64Go-Back-N發(fā)送方:在分組首部需要K比特序號，序號范圍是2k,“窗口”最大為N,允許N個連續(xù)的沒有應答分組發(fā)送方必須響應3類事件上層的調用：檢查發(fā)送窗口是否已滿ACK(n):確認所有的（包括序號n）的分組-“累計ACK”timeout(n):若超時，重傳窗口中的分組n及所有更高序號的分組。對每個傳輸中的分組的用同一個計時器TransportLayer3-65

運輸層65GBN:發(fā)送方擴展的FSM等待start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])…udt_send(sndpkt[nextseqnum-1])超時rdt_send(data)

if(nextseqnum<base+N){//發(fā)送窗還沒有滿，還有空間sndpkt[nextseqnum]=make_pkt(nextseqnum,data,chksum)udt_send(sndpkt[nextseqnum])if(base==nextseqnum)start_timernextseqnum++}elserefuse_data(data)base=getacknum(rcvpkt)+1(應該先與當前base比較大小)If(base==nextseqnum)stop_timerelsestart_timerrdt_rcv(rcvpkt)&¬corrupt(rcvpkt)base=1nextseqnum=1rdt_rcv(rcvpkt)&&corrupt(rcvpkt)

LTransportLayer3-66

運輸層66GBN:接收方擴展FSM對正確接收的分組總是發(fā)送具有最高按序序號的ACK可能產(chǎn)生冗余的ACKs僅僅需要記住期望的序號值（expectedseqnum）對失序的分組:丟棄(不緩存)->沒有接收緩沖區(qū)!Waitudt_send(sndpkt)defaultrdt_rcv(rcvpkt)&¬currupt(rcvpkt)&&hasseqnum(rcvpkt,expectedseqnum)extract(rcvpkt,data)deliver_data(data)sndpkt=make_pkt(expectedseqnum,ACK,chksum)udt_send(sndpkt)expectedseqnum++expectedseqnum=1sndpkt=make_pkt(expectedseqnum,ACK,chksum)L等待TransportLayer3-67

運輸層67GBN操作發(fā)送方接收方TransportLayer3-68

運輸層68選擇性重傳（SelectiveRepeat）GBN改善了信道效率，但仍然有不必要重傳問題選擇性重傳：接收方分別確認所有正確接收的報文段需要緩存分組,以便最后按序交付給給上層發(fā)送方只需要重傳沒有收到ACK的分組發(fā)送方定時器對每個沒有確認的分組計時發(fā)送窗口(同GBN)也需要限制已發(fā)送但尚未應答分組的序號TransportLayer3-69

運輸層69選擇性重傳:發(fā)送方,接收方窗口a.發(fā)送方看到的序號b.接收方看到的序號已經(jīng)確認 可用，還未發(fā)送發(fā)送，還未確認不可用可接受（窗口內）失序(已緩存)期待，還未收到

不可用窗口長度N窗口長度NTransportLayer3-70

運輸層70選擇性重傳上層傳來數(shù)據(jù):如果窗口中下一個序號可用,發(fā)送報文段timeout(n):重傳分組n,重啟其計時器ACK(n)在[sendbase,sendbase+N]:標記分組n已經(jīng)收到如果n是最小未收到應答的分組，向前滑動窗口base指針到下一個未確認序號發(fā)送方分組n在[rcvbase,rcvbase+N-1]發(fā)送ACK(n)失序:緩存按序:交付(也交付所有緩存的按序分組),向前滑動窗口到下一個未收到報文段的序號分組n在[rcvbase-N,rcvbase-1]ACK(n)其他:忽略接收方TransportLayer3-71

運輸層71選擇重傳的操作TransportLayer3-72

運輸層72選擇重傳:困難的問題例子:難以區(qū)分新分組還是重傳序號:0,1,2,3窗口長度=3接收方：在(a)和(b)兩種情況下接收方?jīng)]有發(fā)現(xiàn)差別!在(a)中不正確地將冗余的當為新的，而在(b)中不正確地將新的當作冗余的問題:

序號長度與窗口長度有什么關系?回答：窗口長度小于等于序號空間的一半TransportLayer3-73

運輸層73可靠數(shù)據(jù)傳輸機制及用途總結機制用途和說明檢驗和用于檢測在一個傳輸分組中的比特錯誤。定時器用于檢測超時/重傳一個分組，可能因為該分組（或其ACK）在信道中丟失了。由于當一個分組被時延但未丟失（過早超時），或當一個分組已被接收方收到但從接收方到發(fā)送方的ACK丟失時，可能產(chǎn)生超時事件，所以接收方可能會收到一個分組的多個冗余拷貝。序號區(qū)分不同的分組，用于為從發(fā)送方流向接收方的數(shù)據(jù)分組按順序編號。所接收分組的序號間的空隙可使該接收方檢測出丟失的分組。具有相同序號的分組可使接收方檢測出一個分組的冗余拷貝。確認接收方用于告訴發(fā)送方一個分組或一組分組已被正確地接收到了。確認報文通常攜帶著被確認的分組或多個分組的序號。確認可以是逐個的或累積的，這取決于協(xié)議。否定確認接收方用于告訴發(fā)送方某個分組未被正確地接收。否定確認報文通常攜帶著未被正確接收的分組的序號。窗口、流水線發(fā)送方也許被限制僅發(fā)送那些序號落在一個指定范圍內的分組。通過允許一次發(fā)送多個分組但未被確認，發(fā)送方的利用率可在停等操作模式的基礎上得到增加。我們很快將會看到，窗口長度可根據(jù)接收方接收和緩存報文的能力或網(wǎng)絡中的擁塞程度，或兩者情況來進行設置。TransportLayer3-74

運輸層74第3章

要點3.1運輸層服務3.2復用與分解3.3無連接傳輸:UDP3.4可靠數(shù)據(jù)傳輸?shù)脑瓌t3.5面向連接的傳輸:TCP報文段結構可靠數(shù)據(jù)傳輸流量控制連接管理3.6擁塞控制的原則3.7TCP擁塞控制

運輸層75TCP連接TCP連接包括：雙方主機上的緩存，變量，套接字面向連接:

在進行數(shù)據(jù)交換前，初始化發(fā)送方與接收方狀態(tài)，進行握手(三次握手，交換控制信息)連接狀態(tài)只保留在端系統(tǒng)，不為路由器所知

全雙工數(shù)據(jù):同一連接上的雙向數(shù)據(jù)流點對點

運輸層76TCP連接套接字…發(fā)送

TCP

報文段TCP…TCP接收緩存發(fā)送緩存報文段…報文段報文段套接字發(fā)送端接收端向發(fā)送緩存寫入數(shù)據(jù)塊從接收緩存讀取數(shù)據(jù)塊應用進程應用進程MSS:最大報文段長度,就是TCP段每次能夠傳輸?shù)淖畲髷?shù)據(jù)長度（不包括首部）。MTU:最大傳輸單元,鏈路層

運輸層77TCP報文段結構源端口#目的端口#32bits應用層數(shù)據(jù)(變長)序號確認號接收窗口緊急數(shù)據(jù)指針檢查和FSRPAU首部長度未用選項(變長)URG:緊急數(shù)據(jù)(一般不用)ACK:ACK序號有效PSH:立即提交數(shù)據(jù)(一般不用)RST,SYN,FIN:連接建立(建立和拆連)接收方允許的字節(jié)數(shù)對數(shù)據(jù)字節(jié)計數(shù)(并非對報文段計數(shù)!)因特網(wǎng)檢查和(同UDP一樣)

運輸層78TCP首部20字節(jié)的固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FIN32bitSYNRSTPSHACKURG比特08162431填充TCP數(shù)據(jù)部分TCP首部TCP報文段IP數(shù)據(jù)部分IP首部發(fā)送在前

運輸層79TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充源端口和目的端口字段——各占2字節(jié)。端口是運輸層與應用層的服務接口。運輸層的復用和分用功能都要通過端口才能實現(xiàn)。

運輸層80TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充序號字段——占4字節(jié)。TCP連接中傳送的數(shù)據(jù)流中的每一個字節(jié)都編上一個序號。序號字段的值則指的是本報文段所發(fā)送的數(shù)據(jù)的第一個字節(jié)的序號。

運輸層81TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充確認號字段——占4字節(jié)，是期望收到對方的下一個報文段的數(shù)據(jù)的第一個字節(jié)的序號。

運輸層82TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充數(shù)據(jù)偏移(首部長度)——占4bit，它指出TCP報文段的數(shù)據(jù)起始處距離TCP報文段的起始處有多遠?！皵?shù)據(jù)偏移”的單位不是字節(jié)而是32bit字（4字節(jié)為計算單位）。

運輸層83TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充保留字段——占6bit，保留為今后使用，但目前應置為0。

運輸層84TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充緊急比特URG——當URG1時，表明緊急指針字段有效。它告訴系統(tǒng)此報文段中有緊急數(shù)據(jù)，應盡快傳送(相當于高優(yōu)先級的數(shù)據(jù))。

運輸層85TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充確認比特ACK——只有當ACK1時確認號字段才有效。當ACK0時，確認號無效。

運輸層86TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充推送比特PSH(PuSH)——接收TCP收到推送比特置1的報文段，就盡快地交付給接收應用進程，而不再等到整個緩存都填滿了后再向上交付。

運輸層87TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充復位比特RST(ReSeT)——當RST1時，表明TCP連接中出現(xiàn)嚴重差錯（如由于主機崩潰或其他原因），必須釋放連接，然后再重新建立運輸連接。

運輸層88TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充同步比特SYN——同步比特SYN置為1，就表示這是一個連接請求或連接接受報文。

運輸層89TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充終止比特FIN(FINal)——用來釋放一個連接。當FIN1時，表明此報文段的發(fā)送端的數(shù)據(jù)已發(fā)送完畢，并要求釋放運輸連接。

運輸層90TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充窗口字段——占2字節(jié)。窗口字段用來控制對方發(fā)送的數(shù)據(jù)量，單位為字節(jié)。TCP連接的一端根據(jù)設置的緩存空間大小確定自己的接收窗口大小，然后通知對方以確定對方的發(fā)送窗口的上限。

運輸層91TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充檢驗和——占2字節(jié)。檢驗和字段檢驗的范圍包括首部和數(shù)據(jù)這兩部分。在計算檢驗和時，要在TCP報文段的前面加上12字節(jié)的偽首部。

運輸層92TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充緊急指針字段——占16bit。緊急指針指出在本報文段中的緊急數(shù)據(jù)的最后一個字節(jié)的序號。

運輸層93TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充選項字段——長度可變。協(xié)商最大報文段長度

MSS(MaximumSegmentSize)。MSS告訴對方TCP：“我的緩存所能接收的報文段的數(shù)據(jù)字段的最大長度是MSS個字節(jié)?！盡SS是TCP報文段中的數(shù)據(jù)字段的最大長度。數(shù)據(jù)字段加上TCP首部才等于整個的TCP報文段。

運輸層94TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充填充字段——這是為了使整個首部長度是4字節(jié)的整數(shù)倍。

運輸層95TCP序號和確認號序號:報文段中第1個數(shù)據(jù)字節(jié)在字節(jié)流中的位置編號確認號:期望從對方收到下一個字節(jié)的序號累計確認圖3-30的例子問題：接收方如何處理失序報文段？回答：TCP規(guī)范沒有說明，

由實現(xiàn)者自行選擇實現(xiàn):拋棄/緩存1002003004005001012013014011991992993994991002003004000

運輸層96TCP往返時延(RTT)的估計與超時問題:如何設置TCP超時值?應大于RTT但RTT是變化的太短:過早超時不必要的重傳太長:對報文段的丟失響應太慢問題:如何估計RTT?SampleRTT:

從發(fā)送報文段到接收到ACK的測量時間忽略重傳SampleRTT會變化,希望估計的RTT“較平滑”平均最近的測量值,并不僅僅是當前SampleRTT

運輸層97計算RTT忽略重傳報文的原因TCP報文段1沒有收到確認。重傳（即報文段2）后，收到了確認報文段ACK。如何判定此確認報文段是對原來的報文段1的確認，還是對重傳的報文段2的確認？往返時延RTT?發(fā)送一個TCP報文段超時重傳TCP報文段收到ACK時間12往返時延RTT?是對哪一個報文段的確認？

運輸層98EstimatedRTT=(1-)*EstimatedRTT+*SampleRTT指數(shù)加權移動平均(Exponentialweightedmovingaverage)過去的樣本指數(shù)級衰減來產(chǎn)生影響典型值:=0.125TCP往返時延估計與超時(續(xù))

運輸層99RTT估計的例子

運輸層100TCP往返時延估計與超時(續(xù))設置超時間隔EstimtedRTT

加“安全余量”EstimatedRTT大變化->更大的安全余量首先估算EstimatedRTT與SampleRTT之間差值有多大:

TimeoutInterval=EstimatedRTT+4*DevRTTDevRTT=(1-)*DevRTT+

*|SampleRTT-EstimatedRTT|(典型地,=0.25)

然后估算超時值:

運輸層101第3章

要點3.5面向連接的傳輸:TCP報文段結構可靠數(shù)據(jù)傳輸流量控制連接管理3.6擁塞控制的原則3.7TCP擁塞控制機制TCP吞吐量TCP公平性時延模型3.1運輸層服務3.2復用與分解3.3無連接傳輸:UDP3.4可靠數(shù)據(jù)傳輸?shù)脑瓌trdt1rdt2rdt3流水線協(xié)議

運輸層102TCP可靠數(shù)據(jù)傳輸TCP在IP不可靠服務的基礎上創(chuàng)建可靠數(shù)據(jù)傳輸服務TCP可靠機制是GBN和SR的混合體流水線發(fā)送報文段（GBN和SR）累計確認（GBN）TCP使用單個重傳計時器（GBN）只重傳一個報文緩存亂序報文（SR）選擇確認機制（SR）(某些版本的TCP)先考慮簡化的TCP發(fā)送方:

忽略重復ACK忽略流量控制，擁塞控制

運輸層103TCP發(fā)送方事件1.從應用層接收數(shù)據(jù):根據(jù)序號創(chuàng)建報文段序號是報文段中第一個數(shù)據(jù)字節(jié)的數(shù)據(jù)流編號如果未啟動，啟動計時器(考慮計時器用于最早的沒有確認的報文段)超時間隔:TimeOutInterval=EstimatedRTT+4*DevRTT2.超時:重傳導致超時的報文段重新啟動計時器3.收到確認：如果確認了先前未被確認的報文段更新被確認的報文段序號send_base如果還有未被確認的報文段，重新啟動計時器

運輸層104TCP

發(fā)送方

(簡化的)

NextSeqNum=InitialSeqNumSendBase=InitialSeqNum

loop(forever){

switch(event)

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

event:timertimeoutretransmitnot-yet-acknowledgedsegmentwithsmallestsequencenumbery（注意只有一個包）starttimer

event:ACKreceived,withACKfieldvalueofyif