OSI傳輸層網絡基礎——第3章學習目標解釋傳輸層的需求；確定傳輸層在終端應用程序之間傳輸數據的過程中所扮演的角色；描述兩種TCP/IP傳輸層協議—TCP和UDP協議的作用。解釋傳輸層的關鍵功能，包括可靠性、端口尋址以及數據分段；解釋TCP和UDP協議如何發揮各自的關鍵功能；確定TCP或UDP協議的應用場合，并舉出使用每個協議的應用程序的例子。課程目錄3.1傳輸層的作用3.2TCP協議——可靠通信3.3管理TCP會話3.4UDP協議——低開銷通信3.5實驗練習3.1傳輸層的作用Transportservicesandprotocolsprovidelogicalcommunicationbetweenapp’processesrunningondifferenthoststransportprotocolsruninendsystemstransportvsnetworklayerservices:networklayer:datatransferbetweenendsystemstransportlayer:datatransferbetweenprocessesrelieson,enhances,networklayerservicesapplicationtransportnetworkdatalinkphysicalapplicationtransportnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicallogicalend-endtransport3.1.1傳輸層的作用跟蹤每個會話數據分段重組數據段標志應用程序3.1.2控制會話傳輸層的主要功能包括分段和重組會話多路復用傳輸層的其它功能面向連接的會話可靠傳輸有序的數據重構流量控制applicationtransportnetworkMP2applicationtransportnetworkMultiplexing/demultiplexingRecall:segment-unitofdataexchangedbetweentransportlayerentities

akaTPDU:transportprotocoldataunitreceiverHtHnDemultiplexing:deliveringreceivedsegmentstocorrectapplayerprocessessegmentsegmentMapplicationtransportnetworkP1MMMP3P4segmentheaderapplication-layerdataMultiplexing/demultiplexingmultiplexing/demultiplexing:basedonsender,receiverportnumbers,IPaddressessource,destport#sineachsegmentrecall:well-knownportnumbersforspecificapplicationsgatheringdatafrommultipleappprocesses,envelopingdatawithheader(laterusedfordemultiplexing)sourceport#destport#32bitsapplicationdata(message)otherheaderfieldsTCP/UDPsegmentformatMultiplexing:3.1.3端口尋址識別會話3.1.3端口尋址端口號的類型exampleshostAserverBsourceport:xdest.port:23sourceport:23dest.port:xportuse:simpletelnetappWebclienthostAWebserverBWebclienthostCSourceIP:CDestIP:Bsourceport:xdest.port:80SourceIP:CDestIP:Bsourceport:ydest.port:80portuse:WebserverSourceIP:ADestIP:Bsourceport:xdest.port:803.1.3端口尋址netstat

命令3.1.4支持可靠通信3.1.4TCP和UDP用戶數據報協議（UDP）簡單無連接低開銷盡力傳遞使用UDP的應用：域名系統(DNS)；視頻流；IP語音(VoIP)傳輸控制協議（TCP）面向連接可靠傳輸流控使用TCP的應用：Web瀏覽器；

電子郵件文件傳輸程序3.1.5分段和重組保證所傳輸數據的大小符合傳輸介質的限制要求確保不同應用程序發出的數據能在介質中多路傳輸TCP和UDP處理數據段的方式不同3.2UDP協議——低開銷通信UDP:UserDatagramProtocol[RFC768]“nofrills,”“barebones”Internettransportprotocol“besteffort”service,UDPsegmentsmaybe:lostdeliveredoutofordertoappconnectionless:nohandshakingbetweenUDPsender,receivereachUDPsegmenthandledindependentlyofothersWhyisthereaUDP?noconnectionestablishment(whichcanadddelay)simple:noconnectionstateatsender,receiversmallsegmentheadernocongestioncontrol:UDPcanblastawayasfastasdesired3.2.1UDP——低開銷與可靠性對比UDP提供基本的傳輸層功能低開銷UDP是無連接的，并且不提供復雜的重新傳輸、排序和流量控制機制使用UDP的應用:域名系統(DNS)簡單網絡管理協議(SNMP)動態主機配置協議(DHCP)路由信息協議(RIP)簡單文件傳輸協議(TFTP)網絡游戲UDP:moreoftenusedforstreamingmultimediaappslosstolerantratesensitiveotherUDPuses(why?):DNSSNMPreliabletransferoverUDP:addreliabilityatapplicationlayerapplication-specificerrorrecover!sourceport#destport#32bitsApplicationdata(message)UDPsegmentformatlengthchecksumLength,inbytesofUDPsegment,includingheaderUDPchecksumSender:treatsegmentcontentsassequenceof16-bitintegerschecksum:addition(1’scomplementsum)ofsegmentcontentssenderputschecksumvalueintoUDPchecksumfieldReceiver:computechecksumofreceivedsegmentcheckifcomputedchecksumequalschecksumfieldvalue:NO-errordetectedYES-noerrordetected.Butmaybeerrorsnonethless?Morelater….Goal:detect“errors”(e.g.,flippedbits)intransmittedsegment3.2.2UDP進程也使用端口號來標識特定的應用層進程并將數據報發送到正確的服務或應用3.2.3UDP數據報重組UDP僅僅是將接收到的數據按照先來后到的順序轉發到應用程序3.3TCP協議——可靠通信3.3.1可靠傳輸問題：發送方向接收方發送一個幀，發方如何知道發送的幀是否到達收方？確認＋超時確認（Acknowledgement，簡稱ACK）協議發給它的對等實體的一個小的控制幀，告知它已收到剛才的幀。控制幀一個無任何數據的頭部的幀超時重傳如果發送方在合理的一段時間后未收到確認，那么它重發（retransmit）原始幀。等待一段合理的時間的這個動作稱為超時（timeout）自動請求重發：使用確認和超時實現可靠傳輸的策略有時稱為自動請求重發（AutomaticRepeatRequest，ARQ）。三種ARQ方案：停止等待算法滑動窗口協議并發邏輯信道3.3.2停止等待協議最簡單的ARQ方案基本思想發送方傳輸一幀之后，在傳輸下一幀之前等待一個確認。如果在某段時間之后確認沒有到達，則發送方超時，重發原始幀。時間超時發送方接收方幀ACK（a）確認在超時前到達超時發送方接收方幀幀ACK超時(b)原始幀丟失超時發送方接收方幀ACK幀ACK超時（c）確認丟失超時發送方接收方幀ACK幀ACK超時（d）超時過快重復幀？發送方接收方幀0ACK0幀1ACK1幀0ACK0時間線序號！停止等待算法的主要缺點允許發送方每次在鏈路上只有一個未確認的幀，這可能遠遠低于鏈路的容量！舉例說明：一條往返延遲為45ms、帶寬為1.5Mbps的鏈路延遲與帶寬的乘積為67.5Kb，或大約8KB。發送方每個RTT僅能發送一幀，假設一幀為1KB。最大發送速率為BitsPerFrame

TimePerFrame=1024

8

0.045=182Kbps大約是鏈路容量的八分之一182kbps/1.5Mbps=0.121333333為完全利用鏈路希望發送方在必須等待一個確認之前最多能夠發送8幀保持管道滿載（keepingthepipefull）延遲與帶寬乘積的重要性在于，它表示可傳輸的數據總量，即希望不等待第一個確認而能夠發送的數據總量。3.3.3滑動窗口協議

－－允許管道滿載的協議1．滑動窗口算法前提假設：發送方為每一幀賦一個序號，記作SeqNum，并假設SeqNum能無限增大。發送方維護三個變量SWS發送窗口大小（sendwindowsize）給出發送方能夠發送但未確認的幀數的上界；LAR最近收到的確認幀的序號（lastacknowledgementreceived）LFS表示最近發送的幀的序號(lastframesent)發送窗口不等式發送方維持下式：LFS-LAR<=SWS<=SWSLARLFS圖2.22發送方的滑動窗口

發送進程確認當一個確認到達時，發送方向右移動LAR，允許發送方發送另一幀。定時器發送方為所發的每個幀設置一個定時器，如果定時器在ACK到達之前超時，則重發此幀。

注意：發送方必須可以存儲SWS個幀，因為在它們得到確認之前可能重發。接收方維護三個變量RWS接收窗口大小（receivewindowsize）給出接收方所能接收的無序幀數目的上界；LAF表示最大的可接收幀（largestacceptableframe）LFR表示最近收到的幀(lastframereceived)接收方不等式LAF-LFR<=RWS<=RWSLFRLAF圖2.23收方的滑動窗口

NFE接收進程當一個序號為SeqNum的幀到達時：接收判斷：LFR

seqNum

LAF？否：幀不在接收窗口內，丟棄。是：接收。確認發送與否？三種確認方式：累積確認否認幀有選擇確認累積確認SeqNumToACK：未被確認的幀的最大序號只對SeqNumToACK這一幀發確認表示序號小于等于SeqNumToACK的幀都已收到。設置LFR=SeqNumToACK調整LAF=LFR+RWSRWS＝6LFRLAF0SeqNumToACK＝12累積確認的缺點當有分組丟失時，無法保證管道滿載接收方不確認1號幀會給發送方帶來什么問題？其它確認機制否認幀接收到2號幀之后，發送1號幀的否認幀缺點：發送方超時機制的重復增加接收方實現的復雜度選擇性確認增加了實現的復雜性窗口大小的選擇發送窗口根據一段給定時間內鏈路上有多少待確認的幀來選擇；對于一個給定的延遲與帶寬的乘積，SWS是容易計算的。接收窗口可以設置為任何想要的值RWS=1，表示接收方不存儲任何錯序到達的幀；RWS=SWS，表示接收方能夠緩存發送方傳輸的任何幀。RWS>SWS,由于錯序到達的幀不可能超過SWS個，所以此設置沒有意義。在有限的頭部字段中說明幀的序號，所以序號不可能無限增大。例：一個3比特序號意味著有8個可用序號0…7，因此序號必須可重用2．有限序號和滑動窗口

可用序號數需解決的問題是：要能夠區別同一序號的不同次發送可用序號的數目必須大于所允許的待確認幀的數目發送窗口SWS<＝MaxSeqNum–1這樣就可以正確發送了嗎？取決于接收窗口的大小接收窗口RWS＝1SWS<＝MaxSeqNum–1可以正確發送RWS=SWS發送可能出錯假設：SWS=RWS=7SWS=7012345670ACKRWS=7SWS=7012345670ACKRWS=7x確認丟失會出現什么問題？錯誤分析現象ACK丟失發方超時，重發0-6幀。收方此時希望收到7，0-5幀，則會認為發方重發的幀為新幀，收下，出錯。原因：接收窗口滑動之后期望的幀序號與上一輪序號重合所致當RWS=SWS時，發送窗口的大小不能大于可用序號數的一半，即RWS+SWS<=2n

或

SWS<=2n-1結論：滑動窗口協議是在序號空間的兩半之間變換滑動窗口協議有3個不同的功能，（1）在不可靠鏈路上可靠地傳輸幀---算法的核心功能；（2）用于保持幀的傳輸順序(緩存錯序到達的幀)；（3）支持流量控制，它是一種接收方能夠控制發送方使其降低速度的反饋機制。4．幀順序和流量控制3.4TCP–創建可靠會話TCP數據段SegmentFormat(cont)Eachconnectionidentifiedwith4-tuple:(SrcPort,SrcIPAddr,DsrPort,DstIPAddr)Slidingwindow+flowcontrolacknowledgment,SequenceNum,AdvertisedWinowFlagsSYN,FIN,RESET,PUSH,URG,ACKChecksumpseudoheader+TCPheader+data3.4.1TCP服務器進程3.3.1TCP數據段重組使用序列號（sequencenumber）3.3.2TCP窗口確認使用確認號（acknowledgementnumber）期待確認3.3.3TCP重傳TCP通常只確認連續序列數據（contiguoussequence）選擇性確認（SelectiveAcknowledgements）是備選功能3.5管理TCP會話3.5.1TCP連接的建立和終止

TCPOverviewConnection-orientedByte-streamappwritesbytesTCPsendssegmentsappreadsbytes

Fullduplex

Flowcontrol:keepsenderfrom

overrunningreceiver

Congestioncontrol:keepsenderfromoverrunningnetworkApplication

processWritebytesTCPSendbufferSegmentSegmentSegmentTransmit

segmentsApplication

processReadbytesTCPReceivebuffer■■■

TCP有三種機制觸發數據段的發送：用一變量——maximumsegmentsize-MSS

它從發送進程一收到MSS字節就發送一段，TCP通常發不引起局部IP分段的段尺寸，即

MSS=MTU(直連LAN)–TCP頭–IP

由發送進程明確要求TCP發送數據段。TCP支持PUSH操作，發送進程調用它發出字節緩沖區中未發送的字節，如Telnet，每按一個字符，馬上發送定時周期性觸發段的發送，結果是段包含當前緩沖區中待發送的字節TCP會話的建立TCP會話的終止終止連接連接雙方都可以關閉連接連接的一方從ESTABLISHED到CLOESED狀態轉換有四種情況：

*本方先關閉*對方先關閉*雙方同時關閉*快速關閉CLOSEDLISTENSYN_RCVDSYN_SENTESTABLISHEDFIN_WAIT_1FIN_WAIT_2CLOSINGTIME_WAITCLOSEDLAST_ACKCLOSE_WAITActiveopen/SYNCloseClosePassiveopenSYN/SYN+ACKSend/SYNSYN/SYN+ACKACKSYN+ACK/ACKClose/FINClose/FINFIN/ACKFIN/ACKACKACKACKClose/FINFIN/ACK兩個數據段生存期后超時ACK+FIN/ACK狀態轉換圖狀態轉換過程TCP連接從創到刪要經歷10多個狀態：狀態隨事件發生而遷移，事件分三類用戶操作：Open/Send/Receive/Close接收到TCP段，特別標有SYN/ACK/FIN的超時事件3.5.2TCP流量控制

流量控制Asthetransportlayersendsdatasegments,ittriestoensurethatdataisnotlost.Areceivinghostthatisunabletoprocessdataasquicklyasitarrivescouldbeacauseofdataloss.Thereceivinghostisthenforcedtodiscardit.Flowcontrolavoidstheproblemofatransmittinghostoverflowingthebuffersinthereceivinghost.

TCPprovidesthemechanismforflowcontrolbyallowingthesendingandreceivinghosttocommunicate.Thetwohoststhenestablishadata-transferratethatisagreeabletoboth.通告窗口大小——AdvertisedWindowTCP中的滑動窗口LastByteAckedLastByteSent發送應用程序接收應用程序TCPTCPLastByteWrittenLastByteReadNextByteExpectedLastByteRcvdTCP發送緩沖區TCP接收緩沖區發送緩沖區3個指針之間的關系顯然：接收方不能應答尚未發送的字節LastByteAcked≤LastByteSentTCP不能發送應用進程尚未寫入的字節LastByteSent≤LastByteWritten注意LastByteAcked的左邊沒有字節需要緩存，因為已經確認,LastByteWritten右邊沒有字節緩存，因為還未產生LastByteAckedLastByteSent發送應用程序TCPLastByteWrittenTCP發送緩沖區接收緩沖區3個指針

NextByteExpected是按序接收所希望的下一個字節，所以：LastByteRead＜NextByteExpected

若數據按序到達，則NextByteExpected指向LastByteRcvd之后的字節，否則指向第1個數據間隔的開始，故有：NextByteExpected≤LastByteRcvd+1

LastByteRead左邊和LastByteRcvd右邊不須緩沖前者已被讀，后者還未到。接收應用程序TCPLastByteReadNextByteExpectedLastByteRcvdTCP接收緩沖區TCP的流量控制TCP接收方必須保持下面不等式LastByteRcvd-LastByteRead≤MaxRcvBuffer防止緩沖區溢出,應通告接收方窗口大小AdvertiseWindow=MaxRcvBuffer-(LastByteRcvd-LastByteRead)顯然,窗口大小與LastByteRead

成正比LastByteRcvd

反比。若讀與收等速，窗口到達最大緩沖量發送方的限制發送方必須保證它所得到的收方通告窗口關系LastByteSend

–

LastByteAcked

≤AdvertisedWindow

即:發送方要計算，限制可發送的數據(向網上跑的數據)EffectiveWindow=AdvertisedWindow–(LastByteSend-LastByteAcked)發送方的限制（cont）發方還必須確保本地進程不溢出其發緩沖區（防止上層淹沒下層），當發送進程要寫y字節到TCP,若

(LastByteWritten

–

LastByteAcked)+y＞MaxSendBuffer,

則阻塞該進程收到xBytes的確認,

允許發方把LastByteAcked

增加xBytes流控的實現動態改變通告窗口大小實現流控：該大小表示收到確認號后允許下次傳送的數據長度。等于0時就必須等待，檢測到擁塞時，要調整發送速率3.5.3TCP擁塞控制

端到端的擁塞控制如果某個網絡或連接設備接收報文的速度超出了它的處理能力，它就不能快速處理到達的報文,出現擁塞。TCP的擁塞控制的概念是每個TCP發送方時刻判斷網絡中有多少可用資源。從而確定可以安全傳送的報文數。引入幾個新的變量

CongestionWindow：擁塞窗口。允許發送方發出的未確認數據的最大字節數，不僅僅由接收方的AdvertisedWindow決定，而是由接收方窗口和擁塞窗口二者的最小值決定，即MaxWindow=MIN（AdvertisedWindow，CongestionWindow）EffectiveWindow=MaxWindow-（LastByteSent-LastByteAcked）

CongestionThreshold：擁塞閾值，用來確定是用慢啟動還是用擁塞避免算法來控制數據傳送。慢啟動和擁塞避免發送方

接收方慢啟動期間報文數的增長慢啟動何時停止增加擁塞窗口的值當發現網絡擁塞時這種增加就終止了發送方如何判斷網絡發生擁塞并且如何減少擁塞窗口的值？*

超時是發生擁塞的標志，并據此減小正在傳輸數據的速率。*每發生一次超時，發送方就將CongestionWindow

減少為原來值的一半。擁塞避免期間報文數的增長發送方接收方……擁塞避免期間報文數的增長擁塞窗口值的變化擁塞避免并不成倍地增加擁塞窗口的值，而是使用“累次增加”的方法CongestionWindow=CongestionWindow+MSS×(MSS/CongestionWindow)

CongestionWindow

隨時間增減的軌跡

t1t2t3t4

t5t6t7t8CONGESTIONWINDOW的值時間快速重傳和快速恢復發送方接收方

…

報文1報文2報文3報文4報文5報文6ACK1ACK2ACK2ACK2ACK2報文3ACK6…基于重復確認的快速重傳機制帶有快速重傳機制的TCP的行為

t1t2t3t4t5t6t7t8CONGESTIONWINDOW的值時間帶有快速重傳機制的TCP的行為帶有快速恢復機制的TCP的行為

t1t2t3t4t5t6t7t8CONGESTIONWINDOW的值時間圖6.18帶有快速恢復機制的TCP的行為流量控制與擁塞控制差別流量控制：防止發送者超過接收者的能力，流控是端到端的發送。擁塞控制：防止太多的數據注入到網絡中，從而引起交換機或鏈路超載，擁塞控制是關于主機和網絡的關系。3.5.4TCP適應性重傳

TCP的重傳機制為保證可靠傳送，若在某段時間內未收到應答則要重發該段TCP設置定時，設成是RTT的函數由于因特網上任何一對主機間,甚至同一對主機在不同時段內其RTT都是變化的，故選擇適當的RTT不容易因特網組織已經獲得使用TCP的許多經驗把這個期望的時間設置成連接兩端之間的RTT函數，稱作適應性重傳機制OriginalAlgorithm（最初的算法）

基本思想是維持一個RTT的動態平均值，并把超時值作為這個RTT的函數TCP每發段時，記下發送該段時的時間，當該段的應答到達時，記下收到的應