计算机自顶向下方法第三章课件

传输服务和协议提供运行在不同主机中进程间的逻辑通信

传输协议仅运行在端系统中传输vs.网络层服务:网络层:

在端系统间进行通信传输层:

在进程间进行通信依赖于,加强了,网络层的服务applicationtransportnetworkdatalinkphysicalapplicationtransportnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicallogicalend-endtransport1第3讲

传输层之一传输服务和协议提供运行在不同主机中进程间的逻辑通信applTheblack’sTheWhite’s

mikemaryBillAnn2第3讲

传输层之一Theblack’s传输层协议Internet传输服务:可靠,按序点对点递交(TCP)拥塞控制流量控制连接建立不可靠的(“尽力而为”),无序的点对点或广播递交:UDP不能提供的服务:实时性带宽承诺可靠的广播通信applicationtransportnetworkdatalinkphysicalapplicationtransportnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicallogicalend-endtransport3第3讲

传输层之一传输层协议Internet传输服务:applicationapplicationtransportnetworkMP2applicationtransportnetwork复用/分用(multiplexing/Demultiplexing)回顾:segment（段）-传输层实体间交换数据的单位TPDU:传输层数据单元receiverHtHn分用:

将接收到的段传递给正确的应用层进程segmentsegmentMapplicationtransportnetworkP1MMMP3P4segmentheaderapplication-layerdata4第3讲

传输层之一applicationMP2application复用/分用复用/分用复用/分用:基于发送方,接收方的端口号,IP地址源,目的端口#s存在于每个段中回顾:用于特定应用的常用端口号（well-knownportnumber）从多个应用进程获取数据,用首部(便于随后的分用)封装数据源端口

#宿端口

#32bits应用层数据(报文)其他首部字段TCP/UDP段格式复用:5第3讲

传输层之一复用/分用复用/分用:从多个应用进程获取数据,用首部(便于复用/分用:举例主机A服务器Bsourceport:xdest.port:23sourceport:23dest.port:x端口的使用:简单的telnet应用Web客户端主机AWeb服务器BWeb客户端主机CSourceIP:CDestIP:Bsourceport:xdest.port:80SourceIP:CDestIP:Bsourceport:ydest.port:80端口的使用:Web服务器SourceIP:ADestIP:Bsourceport:xdest.port:806第3讲

传输层之一复用/分用:举例主机A服务器Bsourceport:UDP:用户数据报协议[RFC768]“最简约的”Internet传输协议“尽力而为的”服务,UDP数据段可以:丢失应用数据不按序到达无连接:在UDP收发双方之间,无需握手信号每个UDP数据段的操作都互相独立为什么需要UDP?无需建立连接(会增加延迟)简单:在收发双方之间没有连接状态段首较短无拥塞控制:UDP可按需要随时发送7第3讲

传输层之一UDP:用户数据报协议[RFC768]“最简约的”IUDP:(续)经常为流媒体应用使用允许数据丢失对传输速率敏感其他UDP用途(why?):DNSSNMP若需要通过UDP进行可靠传输:在应用层增加可靠性措施在应用程序中-专门的出错恢复机制!源端口#宿端口#32bits应用层数据(报文)UDP数据报格式lengthchecksum长度,UDP段的字节数,包括首部8第3讲

传输层之一UDP:(续)经常为流媒体应用使用源端口#宿端口#3UDP校验和（checksum）发送方:将段的内容看作一串16位整数checksum:作段内容的加法(补码和)发送方将补码和放入UDPchecksum字段接收方:对接收到的段内容进行补码和计算检查计算结果是否与收到的校验和相等:NO–查出错误YES–没查出错误.但是仍有可能存在错误?目标:

检测传输段中的“错误”(e.g.,位错)9第3讲

传输层之一UDP校验和（checksum）发送方:接收方:目标:检可靠数据传输原理在应用、传输、链路层都十分重要属于网络工程的top-10课题之一!不可靠传输通道的特性将决定可靠传输协议(rdt)的复杂性10第3讲

传输层之一可靠数据传输原理在应用、传输、链路层都十分重要不可靠传输通道可靠数据传输:开始起步发送方接收方rdt_send():

由上层进行调用,(e.g.,应用进程.).将数据传入发送方并由其传给接收方的上层udt_send():

由rdt调用,将分组通过不可靠的信道传到接收方rdt_rcv():

当数据到达接受方时调用deliver_data():

由rdt调用将数据递交给上层11第3讲

传输层之一可靠数据传输:开始起步发送方接收方rdt_send():可靠数据传输:开始起步我们将要:逐步发展收发双方的可靠数据传输协议(rdt)仅考虑单向的数据传输但控制信息将双向流动!使用有限状态机(FSM)来定义发送方,接收方state1state2事件导致状态的转换在状态转换过程中的动作状态:

当实体处于某个“状态”时，下个状态只能由下个事件来转变事件动作12第3讲

传输层之一可靠数据传输:开始起步我们将要:statestate事件导Rdt1.0:在可靠信道上进行可靠的数据传输所依赖的信道非常可靠不可能有位错不会丢失数据分别为发送方和接收方建立FSMs:发送方将数据送入所依赖的信道接收方从所依赖的信道读出数据13第3讲

传输层之一Rdt1.0:在可靠信道上进行可靠的数据传输所依赖的信道非Rdt2.0:在可能发送位错的信道上传输所依赖的信道有可能在分组数据中出现位错回顾:UDPchecksum可发现位错问题:如何从错误中恢复:进行确认(ACKs):

由接收方法送报文向发送方进行确认发送否认(NAKs):由接收方法送报文向发送方进行否认，说明分组有错发送方在收到NAK后进行分组重传在人类交往中是不是也有ACKs,NAKs?rdt2.0的新机制(在rdt1.0基础之上):错误检测接收方的反馈:控制信息(ACK,NAK)rcvr->sender14第3讲

传输层之一Rdt2.0:在可能发送位错的信道上传输所依赖的信道有可能rdt2.0:有限状态机定义发送方的FSM接收方FSM15第3讲

传输层之一rdt2.0:有限状态机定义发送方的FSM接收方FSM15rdt2.0:运行过程(未发现错误)发送方FSM接收方FSM16第3讲

传输层之一rdt2.0:运行过程(未发现错误)发送方FSM接收方rdt2.0:运行过程(出错情况)发送方FSM接收方FSM17第3讲

传输层之一rdt2.0:运行过程(出错情况)发送方FSM接收方FSrdt2.0有一个致命的缺点!若ACK/NAK报文丢失?发送方将不会知道接收端发生了什么!假如进行重传:可能发生数据重复怎么办?发送ACK/NAK来回应接收方的ACK/NAK?那么如果发送方的ACK/NAK丢失?重传,但可能可能导致重传了正确的分组!管理重复的问题:发送方给每个分组加上sequencenumber

（序号）如果ACK/NAK丢失，发送方则重传正确的分组接收方丢弃重复的分组(不向上递交)发送方法送一个分组，然后等待接收方的响应停等策略18第3讲

传输层之一rdt2.0有一个致命的缺点!若ACK/NAK报文丢失?rdt2.1:发送方,管理丢失的ACK/NAK19第3讲

传输层之一rdt2.1:发送方,管理丢失的ACK/NAK19第3rdt2.1:接收方,管理丢失的ACK/NAK20第3讲

传输层之一rdt2.1:接收方,管理丢失的ACK/NAK20第3rdt2.1:讨论发送方:给分组加seq#两个#’s(0,1)够否，为什么?必须查收ACK/NAK两倍的状态必须“记忆”状态，是否“正确的”分组具有0或1seq.#接收方:必须查验接收到的分组是否重复状态可以指出0或1是期望中的seq#注意:接收方不会知道最后的ACK/NAK是否为发送方正确接收21第3讲

传输层之一rdt2.1:讨论发送方:接收方:21第3讲传输层之一rdt2.2:无NAK的协议

其功能等同rdt2.1,但仅使用ACK不使用NAK,接受方只为最后正确接受的报文发送ACK接收方必须显式表明ACK的分组seq#发送方得到双重ACK导致NAK的相同结果:重传正确的分组发送方FSM!22第3讲

传输层之一rdt2.2:无NAK的协议其功能等同rdt2.1,rdt3.0:通道上可能出错和丢失数据新的假设:

所依赖的信道会丢失数据(数据或ACK)checksum,seq.#,ACK,重发机制会有帮助，但还远远不够Q:

如何处理数据丢失?发送方可以等待，当某些数据或ACK丢失时,进行重传想一想:缺点?方法:

发送方等待ACK一段“适当的”时间如果在这段时间里没有收到则进行重传如果分组(或ACK)仅仅被延迟了(没有丢失):重传将导致重复,但使用seq.#’s可以控制接收方必须定义被ACK分组的seq#需要进行倒计时23第3讲

传输层之一rdt3.0:通道上可能出错和丢失数据新的假设:所依赖的rdt3.0发送方24第3讲

传输层之一rdt3.0发送方24第3讲传输层之一rdt3.0接收方25第3讲

传输层之一rdt3.0接收方25第3讲传输层之一rdt3.0的运行26第3讲

传输层之一rdt3.0的运行26第3讲传输层之一rdt3.0的运行27第3讲

传输层之一rdt3.0的运行27第3讲传输层之一rdt3.0的性能rdt3.0可用,不过性能很糟例如:1Gb/s链路,15ms端对端的延迟,1KB分组:Ttransmit=8kb/pkt10**9b/sec=8ms利用率

=U==8microsec30.016msecfractionoftimesenderbusysending=0.000151KB分组每30ms->33kB/sec在1Gb/s链路上的吞吐量网络协议限制了物理资源的利用!28第3讲

传输层之一rdt3.0的性能rdt3.0可用,不过性能很糟Ttra流水线协议（参见p79-84）流水作业:

发送端允许发送多个,“悬在空中”,等待应答的分组必须增加顺序号的位数在发送和接收端增加缓存两种常用的流水线协议:第N个分组重发(go-Back-N),选择应答29第3讲

传输层之一流水线协议（参见p79-84）流水作业:发送端允许发送多个从第N个分组重发(Go-Back-N)发送方:在分组首部设置k位seq#使用尺寸为N的“滑动窗口(p80)”,允许连续的多个分组不被应答ACK(n):ACK所有n号之前，包括n号在内的分组--“积累式ACK”可能产生重复的ACK(见接收方)为每个未应答（in-flight）的分组设置计时器(timer)当发生超时：timeout(n):

重传n号和n号以后的所有分组30第3讲

传输层之一从第N个分组重发(Go-Back-N)发送方:ACK(n):GBN:发送方扩展的FSM上层调用：ACK的接收超时事件31第3讲

传输层之一GBN:发送方扩展的FSM上层调用：ACK的接收超时事件GBN:接收方扩展的FSM接收方举例:ACK-only:总是对正确接收到的分组中按序（in-order）对最高seq#进行ACK可以产生重复的ACKs仅仅需要记住

expectedseqnum（预期的序号）失序分组:丢弃(不缓存)->不进行接收缓存!接收到的分组中按序对最高seq#进行ACK32第3讲

传输层之一GBN:接收方扩展的FSM接收方举例:32第3讲传输GBN

的运行33第3讲

传输层之一GBN

的运行33第3讲传输层之一选择应答(SR)-p84接收方逐个对所有正确收到的分组进行应答如有必要，对接收到的（失序）分组进行缓存,以便最后对上层进行有序递交发送方仅对未收到应答的分组进行重发发送方未每个unACKed分组设置计时器发送方的窗口N个连续的seq#’s同样对已发送的seq#s,unACKed分组进行限制34第3讲

传输层之一选择应答(SR)-p84接收方逐个对所有正确收到的分组进行应选择应答:发送方,接收方的窗口35第3讲

传输层之一选择应答:发送方,接收方的窗口35第3讲传输层之一选择应答上层数据到达:如果窗口中的下一个序号可用，发送分组timeout(n):第n个计时器跳重发分组n,计时器复位ACK(n)到达[sendbase,sendbase+N]:标记分组n已经收到如n为unACKed分组中的最小值,将窗口下沿前推倒下一个unACKedseq#发送方分组n到达[rcvbase,rcvbase+N-1]发送ACK(n)失序:缓存有序:递交到上层(同时递交缓存中的其他有序分组),将窗口前推倒下一个尚未收到的分组分组n到达[rcvbase-N,rcvbase-1]虽然接收方曾经确认，但仍然需要ACK(n)其他情况:

忽略分组接收方36第3讲

传输层之一选择应答上层数据到达:发送方分组n到达[rcvbase,选择应答的运行37第3讲

传输层之一选择应答的运行37第3讲传输层之一第4讲传输层之二本讲目的:

Internet传输层的实现和实例教科书参考第8章本讲概述:面向连接的传输:TCP可靠传输流量控制连接管理TCP拥塞控制拥塞控制原则38第3讲

传输层之一第4讲传输层之二本讲目的:本讲概述:38第3讲传输TCP:概述

RFCs:793,1122,1323,2018,2581全双工数据传输:在同一连接上双向传输MSS:maximumsegmentsize（最大段字节数-1500,536,512）面向连接:

握手过程(交换控制信息)在交换数据前初始化收发双方的状态,“三次握手”流量控制:发送方的发送速度不得超过接收方的处理速度点对点:一个发送方,一个接收方

可靠,按序的字节流:无“报文边界”，无结构但有顺序流水式控制:TCP的拥塞和流量控制，设置窗口大小发送&接收缓存39第3讲

传输层之一TCP:概述RFCs:793,1122,132TCP段格式(p238)sourceport#destport#32bits应用数据(可变长度)sequencenumberacknowledgementnumberrcvrwindowsizeptrurgentdatachecksumFSRPAUheadlennotusedOptions(可变长度-MSS)URG:urgentdata（一般不用）ACK:ACK#validPSH:pushdatanow(一般不用)RST,SYN,FIN:connectionestab(setup,teardowncommands)#bytes接收方愿意接受的按发送数据的字节计算(不是按段数!)Internetchecksum(asinUDP)40第3讲

传输层之一TCP段格式(p238)sourceport#destTCPseq.#’s和ACKsSeq.#’s:该数据段第一个字节在（整个报文）字节流中“编号”ACKs:seq#为预期从对方发来的“下一个”字节的编号积累的ACKQ:

接收方如何接受失序的数据段A:TCP没有定义,-由程序设计者决定HostAHostBSeq=42,ACK=79,data=‘C’Seq=79,ACK=43,data=‘C’Seq=43,ACK=80Usertypes‘C’hostACKsreceiptofechoed‘C’hostACKsreceiptof‘C’,echoesback‘C’time简单的telnet场景41第3讲

传输层之一TCPseq.#’s和ACKsSeq.#’s:HoTCP:可靠数据传输简化的发送方,假设waitforeventwaitforeventevent:datareceivedfromapplicationaboveevent:timertimeoutforsegmentwithseq#yevent:ACKreceived,withACK#ycreate,sendsegmentretransmitsegmentACKprocessing单向数据传输无流量,拥塞控制42第3讲

传输层之一TCP:可靠数据传输简化的发送方,假设waitwaiteTCP:可靠数据传输00

sendbase=initial_sequencenumber01nextseqnum=initial_sequencenumber0203loop(forever){

04switch(event)

05event:datareceivedfromapplicationabove06createTCPsegmentwithsequencenumbernextseqnum07starttimerforsegmentnextseqnum08passsegmenttoIP09nextseqnum=nextseqnum+length(data)10event:timertimeoutforsegmentwithsequencenumbery11retransmitsegmentwithsequencenumbery12compuenewtimeoutintervalforsegmenty13restarttimerforsequencenumbery14event:ACKreceived,withACKfieldvalueofy15if(y>sendbase){/*cumulativeACKofalldatauptoy*/16cancelalltimersforsegmentswithsequencenumbers<y17sendbase=y18}19else{/*aduplicateACKforalreadyACKedsegment*/20incrementnumberofduplicateACKsreceivedfory21if(numberofduplicateACKSreceivedfory==3){22/*TCPfastretransmit*/23resendsegmentwithsequencenumbery24restarttimerforsegmenty25}26}/*endofloopforever*/

简化的TCP发送方43第3讲

传输层之一TCP:可靠数据传输00sendbase=inTCPACK规则

[RFC1122,RFC2581]事件有序数据段到达,没有缺失的段,所有其他数据段已经ACKed有序数据段到达,没有缺失的段,有一个延迟ACK等待失序数据段到达seq.#高于预期值测到间隔到达的数据段部分或全部填满了缺失的段TCP接收方的动作延迟ACK.等待500ms看是否还有数据段到达.如果没有,发送ACK立即发送一个积欠的ACK发送重复的ACK,说明seq.#为下一个期望的字节立即ACK，如果数据段处于缺失的段的较低端44第3讲

传输层之一TCPACK规则[RFC1122,RFC2581TCP:重传场景HostASeq=92,8bytesdataACK=100losstimeouttime丢失ACK场景HostBXSeq=92,8bytesdataACK=100HostASeq=100,20bytesdataACK=100Seq=92timeouttime过早超时,积欠ACKsHostBSeq=92,8bytesdataACK=120Seq=92,8bytesdataSeq=100timeoutACK=12045第3讲

传输层之一TCP:重传场景HostASeq=92,8bytesTCP流量控制接收端:

显式通知发送端(动态变化中的)自由缓存空间RcvWindow

TCP数据段的字段发送端:

需要保存已经发送,unACKed数据可少于最近收到的RcvWindow发送端不可发送的太多、太快以至于使得接收端的缓存溢出流量控制接收端缓存RcvBuffer

=接收端的TCP缓存大小RcvWindow=缓存中空闲的部分46第3讲

传输层之一TCP流量控制接收端:显式通知发送端(动态变化中的)TCP交互的往返时间（RTT）和超时Q:

如何设置TCP超时的值?应较RTT长一点注意:RTT会变！太短了:过早出现超时造成不必要的重传太长了:减缓了对数据段丢失的反应Q:

如何估算RTT?SampleRTT:

对数据段发送到收到ACK回应的时间进行测量忽略重传,积欠ACKed数据段SampleRTT

是会变化的,要使得估算的RTT“更平滑”使用若干新近的测量结果,而不仅仅是最近一次的SampleRTT47第3讲

传输层之一TCP交互的往返时间（RTT）和超时Q:如何设置TCPTCPRTT和超时(p246)EstimatedRTT=(1-x)*EstimatedRTT+x*SampleRTT指数加权移动平均（EWMA）给定样本的影响随指数形式快速递减X的典型量值:0.125或1/8设置超时EstimtedRTT

加上“安全边际(safetymargin)”如果EstimatedRTT变化较大->

加大安全边际Timeout=EstimatedRTT+4*DeviationDeviation(偏差)=(1-x)*Deviation+x*|SampleRTT-EstimatedRTT|48第3讲

传输层之一TCPRTT和超时(p246)EstimatedRTTTCP连接管理回顾:

TCP收发双方在数据交换开始之前需要建立连接初始化TCP变量:seq.#s缓存,流量控制信息(e.g.RcvWindow)客户端:

连接的发起者

SocketclientSocket=newSocket("hostname","portnumber");-JAVA服务器:

接受客户端的连接

SocketconnectionSocket=welcomeSocket.accept();(建立连接)三次握手:Step1:

客户端的endsystem向服务器发送TCPSYN控制数据段定义并初始化seq#Step2:

服务器的endsystem接收SYN,用SYNACK控制数据段回答ACKs接收到的SYN分配缓存定义server->receiver初始化seq.#Step3:客户端的endsystem向服务器发送ACKACKs接收到的连接承诺分配缓存49第3讲

传输层之一TCP连接管理回顾:TCP收发双方在数据交换开始之前需TCP连接管理(续)关闭连接:客户端关闭插口:

clientSocket.close();

Step1:

客户端endsystem发送TCPFIN控制段给服务器

Step2:

服务器收到FIN,用ACK应答.关闭连接,发送FIN.clientFINserverACKACKFINclosecloseclosedtimedwait50第3讲

传输层之一TCP连接管理(续)关闭连接:clientFINservTCP连接管理(续)Step3:

客户端收到FIN,用ACK进行应答.随着对接收到的FIN发送ACK-同时进入“timedwait（计时等待）”Step4:

服务器,接收ACK.连接关闭.注意:稍加修改,即可管理同时发生的多个FINs.clientFINserverACKACKFINclosingclosingclosedtimedwaitclosed51第3讲

传输层之一TCP连接管理(续)Step3:客户端收到FINTCP连接管理(续)TCP客户端实例的生命周期TCP服务进程的生命周期52第3讲

传输层之一TCP连接管理(续)TCP客户端实例的生命周期TCP拥塞控制原理拥塞:非正式的说法:“过多信源以过快的速率发送了过多的数据、导致网络穷于应付”不同于流量控制!后果:丢失数据分组(路由器缓存溢出)长时间的延迟(在路由器的缓存中排队)在网络发展的技术中的atop-10problem!53第3讲

传输层之一拥塞控制原理拥塞:53第3讲传输层之一缘由/代价-拥塞问题:场景1

两个发送端,两个接收端一个路由器,有限缓存无重传机制发生拥塞时的延迟可达到的最大吞吐量54第3讲

传输层之一缘由/代价-拥塞问题:场景1两个发送端,两个接收端发生拥缘由/代价-拥塞问题:场景2

一个路由器,有限缓存发送端重传丢失的分组55第3讲

传输层之一缘由/代价-拥塞问题:场景2一个路由器,有限缓存缘由/代价-拥塞问题:场景2

设计期望:(goodput)“完美的”重传仅仅是在分组丢失时:重传被延迟的(而不是丢失的)分组造成大量无意义的(比起完美的情况)对同样的linlout=linlout>linlout拥塞的“代价”:

在给定的“goodput”下需要做更多的工作(重传)不必要的重传:链路上充斥着分组的多个拷贝56第3讲

传输层之一缘由/代价-拥塞问题:场景2设计期望:缘由/代价-拥塞问题:场景3

四个发送端多步跳路径超时/重传linQ:

当和增加时发生了什么?lin57第3讲

传输层之一缘由/代价-拥塞问题:场景3四个发送端linQ:当缘由/代价-拥塞问题:场景3

另一种拥塞的“代价”:

当分组被丢弃时,所有“上游”信道为该分组所作的工作统统被浪费了!58第3讲

传输层之一缘由/代价-拥塞问题:场景3另一种拥塞的“代价”:拥塞问题的解决方案端对端的拥塞控制:没有来自网络的反馈信息对拥塞问题的了解来自于对数据丢失和延迟的推断有TCP来解决网络辅助的拥塞控制:路由器向端系统提供反馈一个比特位的说明(SNA,DECNet,TCP/IPECN,ATM)显式告知发送方所应采用的数据速率两大类拥塞控制的办法:59第3讲

传输层之一拥塞问题的解决方案端对端的拥塞控制:网络辅助的拥塞控制:两大案例研究:ATMABR拥塞控制ABR:availablebitrate（可用数据速率）:“弹性服务”如果发送方的路径“欠负载”发送端应该把带宽用足如果发送端路径拥塞:发送端将其数据速率约束到最小承诺速率RM(resourcemanagement)cells（资源管理信元）:由发送端发送,掺和在数据信元一起在RM信元中的数据位由交换机设定(“网络辅助”)NIbit:

不得增加发送速率(轻微拥塞)CIbit:

拥塞指示RM信元由接收端返回给发送端,所有数据位保持原样

60第3讲

传输层之一案例研究:ATMABR拥塞控制ABR:availab案例研究:ATMABR拥塞控制在RM信元中有2字节的ER(explicitrate)字段处于拥塞的交换机可降低信元中的ER值发送端的发送速率可以在路径上得到最低程度的支持数据信元的EFCI位:在拥塞的交换机中被设成1如果在RM信元之前的数据信元的EFCI置1,发送端将在返回的RM的RM信元中将CI置161第3讲

传输层之一案例研究:ATMABR拥塞控制在RM信元中有2字节的TCP拥塞控制端到端的控制(无需网络协助)传输速率限制由建立在数据段之上的拥塞窗口尺寸Congwin决定:w=数据段数量,每个具有MSS字节,在一个RTT周期内发送:吞吐量=

w*MSS

RTT

Bytes/secCongwin62第3讲

传输层之一TCP拥塞控制端到端的控制(无需网络协助)w=数据段数量TCP拥塞控制:两个“阶段”slowstart（慢启动）congestionavoidance（拥塞避免）

重要变量: