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章:運輸層我們的目的:

理解運輸層服務依據的原理:復用/分解可靠數據傳輸流量控制擁塞控制學習因特網中的運輸層協議：UDPTCPTransportLayer3-3

運輸層3第3章

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

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

運輸層7運輸層vs.網絡層網絡層:

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

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

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

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

運輸層11第3章

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

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

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

主機使用IP地址&端口號將段定向到適當的套接字源端口#目的端口#32bits應用數據(報文)其他首部字段TCP/UDP段格式TransportLayer3-15

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

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

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

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

運輸層19面向連接分解TCP套接字由四元組標識:源IP地址源端口號目的IP地址目的端口號接收主機使用這四個值來將段定向到適當的套接字服務器可能支持許多并行的TCP套接字：每個套接字與一個進程聯系并且由其自己的四元組標識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面向連接并發服務器的特點TCPTCP客戶TCP客戶TCP客戶歡迎套接字TCP連接歡迎套接字僅用于接受服務請求創建連接套接字應用層23TCP套接字編程三次握手數據客戶機套接字連接套接字歡迎套接字客戶機進程服務器進程面向連接分解三次握手數據連接套接字歡迎套接字服務器進程TransportLayer3-25

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

運輸層26第3章

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

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

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

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

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

在傳輸的段中檢測“差錯”(如比特翻轉)TransportLayer3-32

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

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

運輸層36第3章

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

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

運輸層38可靠數據傳輸的原則TransportLayer3-39

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

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

calledbyrdt,totransferpacketoverunreliablechanneltoreceiverrdt_rcv():

calledwhenpacketarrivesonrcv-sideofchanneldeliver_data():

calledbyrdttodeliverdatatoupperTransportLayer3-40

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

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

運輸層41Rdt1.0:經可靠信道的可靠傳輸底層信道非常可靠無比特差錯無分組丟失順序傳送發送方、接收方的單獨FSM:發送方將數據發向底層信道接收方從底層信道讀取數據Waitforcallfromabovepacket=make_pkt(data)udt_send(packet)rdt_send(data)extract(packet,data)deliver_data(data)Waitforcallfrombelowrdt_rcv(packet)發送方接收方TransportLayer3-42

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

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

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

運輸層43rdt2.0:FSM規格參數等待來自上面的調用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-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發送方發送一個分組，然后等待接收方響應停止等待TransportLayer3-46

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

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

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

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

運輸層54rdt2.2:發送方,接收方片段等待來自上面的調用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發送方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:具有差錯和丟包的信道新假設:

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

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

運輸層58rdt3.0發送方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運行情況無丟包時的運行分組丟失發送方發送方接收方接收方TransportLayer3-60

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

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

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

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

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

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

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

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

if(nextseqnum<base+N){//發送窗還沒有滿，還有空間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對正確接收的分組總是發送具有最高按序序號的ACK可能產生冗余的ACKs僅僅需要記住期望的序號值（expectedseqnum）對失序的分組:丟棄(不緩存)->沒有接收緩沖區!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操作發送方接收方TransportLayer3-68

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

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

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

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

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

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

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

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

運輸層74第3章

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

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

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

全雙工數據:同一連接上的雙向數據流點對點

運輸層76TCP連接套接字…發送

TCP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

由實現者自行選擇實現:拋棄/緩存1002003004005001012013014011991992993994991002003004000

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

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

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

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

運輸層99RTT估計的例子

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

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

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

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

然后估算超時值:

運輸層101第3章

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

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

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

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

運輸層104TCP

發送方

(簡化的)

NextSeqNum=InitialSeqNumSendBase=InitialSeqNum

loop(forever){

switch(event)

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

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

event:ACKreceived,withACKfieldvalueofyif