網(wǎng)絡(luò)基礎(chǔ)3-傳輸層

OSI傳輸層網(wǎng)絡(luò)基礎(chǔ)——第3章學(xué)習(xí)目標(biāo)解釋傳輸層的需求；確定傳輸層在終端應(yīng)用程序之間傳輸數(shù)據(jù)的過程中所扮演的角色；描述兩種TCP/IP傳輸層協(xié)議—TCP和UDP協(xié)議的作用。解釋傳輸層的關(guān)鍵功能，包括可靠性、端口尋址以及數(shù)據(jù)分段；解釋TCP和UDP協(xié)議如何發(fā)揮各自的關(guān)鍵功能；確定TCP或UDP協(xié)議的應(yīng)用場合，并舉出使用每個協(xié)議的應(yīng)用程序的例子。課程目錄3.1傳輸層的作用3.2TCP協(xié)議——可靠通信3.3管理TCP會話3.4UDP協(xié)議——低開銷通信3.5實(shí)驗(yàn)練習(xí)3.1傳輸層的作用Transportservicesandprotocolsprovidelogicalcommunicationbetweenapp’processesrunningondifferenthoststransportprotocolsruninendsystemstransportvsnetworklayerservices:networklayer:datatransferbetweenendsystemstransportlayer:datatransferbetweenprocessesrelieson,enhances,networklayerservicesapplicationtransportnetworkdatalinkphysicalapplicationtransportnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicallogicalend-endtransport3.1.1傳輸層的作用跟蹤每個會話數(shù)據(jù)分段重組數(shù)據(jù)段標(biāo)志應(yīng)用程序3.1.2控制會話傳輸層的主要功能包括分段和重組會話多路復(fù)用傳輸層的其它功能面向連接的會話可靠傳輸有序的數(shù)據(jù)重構(gòu)流量控制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用戶數(shù)據(jù)報(bào)協(xié)議（UDP）簡單無連接低開銷盡力傳遞使用UDP的應(yīng)用：域名系統(tǒng)(DNS)；視頻流；IP語音(VoIP)傳輸控制協(xié)議（TCP）面向連接可靠傳輸流控使用TCP的應(yīng)用：Web瀏覽器；

電子郵件文件傳輸程序3.1.5分段和重組保證所傳輸數(shù)據(jù)的大小符合傳輸介質(zhì)的限制要求確保不同應(yīng)用程序發(fā)出的數(shù)據(jù)能在介質(zhì)中多路傳輸TCP和UDP處理數(shù)據(jù)段的方式不同3.2UDP協(xié)議——低開銷通信UDP:UserDatagramProtocol[RFC768]“nofrills,”“barebones”Internettransportprotocol“besteffort”service,UDPsegmentsmaybe:lostdeliveredoutofordertoappconnectionless:nohandshakingbetweenUDPsender,receivereachUDPsegmenthandledindependentlyofothersWhyisthereaUDP?noconnectionestablishment(whichcanadddelay)simple:noconnectionstateatsender,receiversmallsegmentheadernocongestioncontrol:UDPcanblastawayasfastasdesired3.2.1UDP——低開銷與可靠性對比UDP提供基本的傳輸層功能低開銷UDP是無連接的，并且不提供復(fù)雜的重新傳輸、排序和流量控制機(jī)制使用UDP的應(yīng)用:域名系統(tǒng)(DNS)簡單網(wǎng)絡(luò)管理協(xié)議(SNMP)動態(tài)主機(jī)配置協(xié)議(DHCP)路由信息協(xié)議(RIP)簡單文件傳輸協(xié)議(TFTP)網(wǎng)絡(luò)游戲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進(jìn)程也使用端口號來標(biāo)識特定的應(yīng)用層進(jìn)程并將數(shù)據(jù)報(bào)發(fā)送到正確的服務(wù)或應(yīng)用3.2.3UDP數(shù)據(jù)報(bào)重組UDP僅僅是將接收到的數(shù)據(jù)按照先來后到的順序轉(zhuǎn)發(fā)到應(yīng)用程序3.3TCP協(xié)議——可靠通信3.3.1可靠傳輸問題：發(fā)送方向接收方發(fā)送一個幀，發(fā)方如何知道發(fā)送的幀是否到達(dá)收方？確認(rèn)＋超時確認(rèn)（Acknowledgement，簡稱ACK）協(xié)議發(fā)給它的對等實(shí)體的一個小的控制幀，告知它已收到剛才的幀?？刂茙粋€無任何數(shù)據(jù)的頭部的幀超時重傳如果發(fā)送方在合理的一段時間后未收到確認(rèn)，那么它重發(fā)（retransmit）原始幀。等待一段合理的時間的這個動作稱為超時（timeout）自動請求重發(fā)：使用確認(rèn)和超時實(shí)現(xiàn)可靠傳輸?shù)牟呗杂袝r稱為自動請求重發(fā)（AutomaticRepeatRequest，ARQ）。三種ARQ方案：停止等待算法滑動窗口協(xié)議并發(fā)邏輯信道3.3.2停止等待協(xié)議最簡單的ARQ方案基本思想發(fā)送方傳輸一幀之后，在傳輸下一幀之前等待一個確認(rèn)。如果在某段時間之后確認(rèn)沒有到達(dá)，則發(fā)送方超時，重發(fā)原始幀。時間超時發(fā)送方接收方幀ACK（a）確認(rèn)在超時前到達(dá)超時發(fā)送方接收方幀幀ACK超時(b)原始幀丟失超時發(fā)送方接收方幀ACK幀ACK超時（c）確認(rèn)丟失超時發(fā)送方接收方幀ACK幀ACK超時（d）超時過快重復(fù)幀？發(fā)送方接收方幀0ACK0幀1ACK1幀0ACK0時間線序號！停止等待算法的主要缺點(diǎn)允許發(fā)送方每次在鏈路上只有一個未確認(rèn)的幀，這可能遠(yuǎn)遠(yuǎn)低于鏈路的容量！舉例說明：一條往返延遲為45ms、帶寬為1.5Mbps的鏈路延遲與帶寬的乘積為67.5Kb，或大約8KB。發(fā)送方每個RTT僅能發(fā)送一幀，假設(shè)一幀為1KB。最大發(fā)送速率為BitsPerFrame

TimePerFrame=1024

8

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

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

發(fā)送進(jìn)程確認(rèn)當(dāng)一個確認(rèn)到達(dá)時，發(fā)送方向右移動LAR，允許發(fā)送方發(fā)送另一幀。定時器發(fā)送方為所發(fā)的每個幀設(shè)置一個定時器，如果定時器在ACK到達(dá)之前超時，則重發(fā)此幀。

注意：發(fā)送方必須可以存儲SWS個幀，因?yàn)樵谒鼈兊玫酱_認(rèn)之前可能重發(fā)。接收方維護(hù)三個變量RWS接收窗口大小（receivewindowsize）給出接收方所能接收的無序幀數(shù)目的上界；LAF表示最大的可接收幀（largestacceptableframe）LFR表示最近收到的幀(lastframereceived)接收方不等式LAF-LFR<=RWS<=RWSLFRLAF圖2.23收方的滑動窗口

NFE接收進(jìn)程當(dāng)一個序號為SeqNum的幀到達(dá)時：接收判斷：LFR

seqNum

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

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

或

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

TCPOverviewConnection-orientedByte-streamappwritesbytesTCPsendssegmentsappreadsbytes

Fullduplex

Flowcontrol:keepsenderfrom

overrunningreceiver

Congestioncontrol:keepsenderfromoverrunningnetworkApplication

processWritebytesTCPSendbufferSegmentSegmentSegmentTransmit

segmentsApplication

processReadbytesTCPReceivebuffer■■■

TCP有三種機(jī)制觸發(fā)數(shù)據(jù)段的發(fā)送：用一變量——maximumsegmentsize-MSS

它從發(fā)送進(jìn)程一收到MSS字節(jié)就發(fā)送一段，TCP通常發(fā)不引起局部IP分段的段尺寸，即

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

由發(fā)送進(jìn)程明確要求TCP發(fā)送數(shù)據(jù)段。TCP支持PUSH操作，發(fā)送進(jìn)程調(diào)用它發(fā)出字節(jié)緩沖區(qū)中未發(fā)送的字節(jié)，如Telnet，每按一個字符，馬上發(fā)送定時周期性觸發(fā)段的發(fā)送，結(jié)果是段包含當(dāng)前緩沖區(qū)中待發(fā)送的字節(jié)TCP會話的建立TCP會話的終止終止連接連接雙方都可以關(guān)閉連接連接的一方從ESTABLISHED到CLOESED狀態(tài)轉(zhuǎn)換有四種情況：

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

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

TCPprovidesthemechanismforflowcontrolbyallowingthesendingandreceivinghosttocommunicate.Thetwohoststhenestablishadata-transferratethatisagreeabletoboth.通告窗口大小——AdvertisedWindowTCP中的滑動窗口LastByteAckedLastByteSent發(fā)送應(yīng)用程序接收應(yīng)用程序TCPTCPLastByteWrittenLastByteReadNextByteExpectedLastByteRcvdTCP發(fā)送緩沖區(qū)TCP接收緩沖區(qū)發(fā)送緩沖區(qū)3個指針之間的關(guān)系顯然：接收方不能應(yīng)答尚未發(fā)送的字節(jié)LastByteAcked≤LastByteSentTCP不能發(fā)送應(yīng)用進(jìn)程尚未寫入的字節(jié)LastByteSent≤LastByteWritten注意LastByteAcked的左邊沒有字節(jié)需要緩存，因?yàn)橐呀?jīng)確認(rèn),LastByteWritten右邊沒有字節(jié)緩存，因?yàn)檫€未產(chǎn)生LastByteAckedLastByteSent發(fā)送應(yīng)用程序TCPLastByteWrittenTCP發(fā)送緩沖區(qū)接收緩沖區(qū)3個指針

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

若數(shù)據(jù)按序到達(dá)，則NextByteExpected指向LastByteRcvd之后的字節(jié)，否則指向第1個數(shù)據(jù)間隔的開始，故有：NextByteExpected≤LastByteRcvd+1

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

成正比LastByteRcvd

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

–

LastByteAcked

≤AdvertisedWindow

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

(LastByteWritten

–

LastByteAcked)+y＞MaxSendBuffer,

則阻塞該進(jìn)程收到xBytes的確認(rèn),

允許發(fā)方把LastByteAcked

增加xBytes流控的實(shí)現(xiàn)動態(tài)改變通告窗口大小實(shí)現(xiàn)流控：該大小表示收到確認(rèn)號后允許下次傳送的數(shù)據(jù)長度。等于0時就必須等待，檢測到擁塞時，要調(diào)整發(fā)送速率3.5.3TCP擁塞控制

端到端的擁塞控制如果某個網(wǎng)絡(luò)或連接設(shè)備接收報(bào)文的速度超出了它的處理能力，它就不能快速處理到達(dá)的報(bào)文,出現(xiàn)擁塞。TCP的擁塞控制的概念是每個TCP發(fā)送方時刻判斷網(wǎng)絡(luò)中有多少可用資源。從而確定可以安全傳送的報(bào)文數(shù)。引入幾個新的變量

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

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

接收方慢啟動期間報(bào)文數(shù)的增長慢啟動何時停止增加擁塞窗口的值當(dāng)發(fā)現(xiàn)網(wǎng)絡(luò)擁塞時這種增加就終止了發(fā)送方如何判斷網(wǎng)絡(luò)發(fā)生擁塞并且如何減少擁塞窗口的值？*

超時是發(fā)生擁塞的標(biāo)志，并據(jù)此減小正在傳輸數(shù)據(jù)的速率。*每發(fā)生一次超時，發(fā)送方就將CongestionWindow

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

CongestionWindow

隨時間增減的軌跡

t1t2t3t4

t5t6t7t8CONGESTIONWINDOW的值時間快速重傳和快速恢復(fù)發(fā)送方接收方

…

報(bào)文1報(bào)文2報(bào)文3報(bào)文4報(bào)文5報(bào)文6ACK1ACK2ACK2ACK2ACK2報(bào)文3ACK6…基于重復(fù)確認(rèn)的快速重傳機(jī)制帶有快速重傳機(jī)制的TCP的行為

t1t2t3t4t5t6t7t8CONGESTIONWINDOW的值時間帶有快速重傳機(jī)制的TCP的行為帶有快速恢復(fù)機(jī)制的TCP的行為

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

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

基本思想是維持一個RTT的動態(tài)平均值，并把超時值作為這個RTT的函數(shù)TCP每發(fā)段時，記下發(fā)送該段時的時間，當(dāng)該段的應(yīng)答到達(dá)時，記下收到的應(yīng)