第3讲 传输层之一

主讲人：西安交通大学程向前第3讲传输层之一1第3讲传输层之一本讲目的:理解传输层服务的原理:复用/分用可靠数据传输流量控制拥塞控制Internet传输层的实现和实例教科书参考第8章本讲概述:传输层的服务复用/分用无连接的传输:UDP可靠数据传输原理主讲人：西安交通大学程向前第3讲传输层之一2传输服务和协议提供运行在不同主机中进程间的逻辑通信传输协议仅运行在端系统中传输vs.网络层服务:网络层:在端系统间进行通信传输层:在进程间进行通信依赖于,加强了,网络层的服务applicationtransportnetworkdatalinkphysicalapplicationtransportnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysical主讲人：西安交通大学程向前第3讲传输层之一3传输层协议Internet传输服务:可靠,按序点对点递交(TCP)拥塞控制流量控制连接建立不可靠的(“尽力而为”),无序的点对点或广播递交:UDP不能提供的服务:实时性带宽承诺可靠的广播通信applicationtransportnetworkdatalinkphysicalapplicationtransportnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysical主讲人：西安交通大学程向前第3讲传输层之一4applicationtransportnetworkMP2applicationtransportnetwork复用/分用(multiplexing/Demultiplexing)回顾:segment（段）-传输层实体间交换数据的单位TPDU:传输层数据单元receiverHtHn分用:将接收到的段传递给正确的应用层进程segmentsegmentMapplicationtransportnetworkP1MMMP3P4segmentheaderapplication-layerdata主讲人：西安交通大学程向前第3讲传输层之一5复用/分用复用/分用:基于发送方,接收方的端口号,IP地址源,目的端口#s存在于每个段中回顾:用于特定应用的常用端口号（well-knownportnumber）从多个应用进程获取数据,用首部(便于随后的分用)封装数据源端口#宿端口#32bits应用层数据(报文)其他首部字段TCP/UDP段格式复用:主讲人：西安交通大学程向前第3讲传输层之一6复用/分用:举例主机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:80主讲人：西安交通大学程向前第3讲传输层之一7UDP:用户数据报协议[RFC768]“最简约的”Internet传输协议“尽力而为的”服务,UDP数据段可以:丢失应用数据不按序到达无连接:在UDP收发双方之间,无需握手信号每个UDP数据段的操作都互相独立为什么需要UDP?无需建立连接(会增加延迟)简单:在收发双方之间没有连接状态段首较短无拥塞控制:UDP可按需要随时发送主讲人：西安交通大学程向前第3讲传输层之一8UDP:(续)经常为流媒体应用使用允许数据丢失对传输速率敏感其他UDP用途(why?):DNSSNMP若需要通过UDP进行可靠传输:在应用层增加可靠性措施在应用程序中-专门的出错恢复机制!源端口#宿端口#32bits应用层数据(报文)UDP数据报格式lengthchecksum长度,UDP段的字节数,包括首部主讲人：西安交通大学程向前第3讲传输层之一9UDP校验和（checksum）发送方:将段的内容看作一串16位整数checksum:作段内容的加法(补码和)发送方将补码和放入UDPchecksum字段接收方:对接收到的段内容进行补码和计算检查计算结果是否与收到的校验和相等:NO–查出错误YES–没查出错误.但是仍有可能存在错误?目标:检测传输段中的“错误”(e.g.,位错)主讲人：西安交通大学程向前第3讲传输层之一10可靠数据传输原理在应用、传输、链路层都十分重要属于网络工程的top-10课题之一!不可靠传输通道的特性将决定可靠传输协议(rdt)的复杂性主讲人：西安交通大学程向前第3讲传输层之一11可靠数据传输:开始起步发送方接收方rdt_send():由上层进行调用,(e.g.,应用进程.).将数据传入发送方并由其传给接收方的上层udt_send():由rdt调用,将分组通过不可靠的信道传到接收方rdt_rcv():当数据到达接受方时调用deliver_data():由rdt调用将数据递交给上层主讲人：西安交通大学程向前第3讲传输层之一12可靠数据传输:开始起步我们将要:逐步发展收发双方的可靠数据传输协议(rdt)仅考虑单向的数据传输但控制信息将双向流动!使用有限状态机(FSM)来定义发送方,接收方state1state2事件导致状态的转换在状态转换过程中的动作状态:当实体处于某个“状态”时，下个状态只能由下个事件来转变事件动作主讲人：西安交通大学程向前第3讲传输层之一13Rdt1.0:在可靠信道上进行可靠的数据传输所依赖的信道非常可靠不可能有位错不会丢失数据分别为发送方和接收方建立FSMs:发送方将数据送入所依赖的信道接收方从所依赖的信道读出数据主讲人：西安交通大学程向前第3讲传输层之一14Rdt2.0:在可能发送位错的信道上传输所依赖的信道有可能在分组数据中出现位错回顾:UDPchecksum可发现位错问题:如何从错误中恢复:进行确认(ACKs):由接收方法送报文向发送方进行确认发送否认(NAKs):由接收方法送报文向发送方进行否认，说明分组有错发送方在收到NAK后进行分组重传在人类交往中是不是也有ACKs,NAKs?rdt2.0的新机制(在rdt1.0基础之上):错误检测接收方的反馈:控制信息(ACK,NAK)rcvr-sender主讲人：西安交通大学程向前第3讲传输层之一15rdt2.0:有限状态机定义发送方的FSM接收方FSM主讲人：西安交通大学程向前第3讲传输层之一16rdt2.0:运行过程(未发现错误)发送方FSM接收方FSM主讲人：西安交通大学程向前第3讲传输层之一17rdt2.0:运行过程(出错情况)发送方FSM接收方FSM主讲人：西安交通大学程向前第3讲传输层之一18rdt2.0有一个致命的缺点!若ACK/NAK报文丢失?发送方将不会知道接收端发生了什么!假如进行重传:可能发生数据重复怎么办?发送ACK/NAK来回应接收方的ACK/NAK?那么如果发送方的ACK/NAK丢失?重传,但可能可能导致重传了正确的分组!管理重复的问题:发送方给每个分组加上sequencenumber（序号）如果ACK/NAK丢失，发送方则重传正确的分组接收方丢弃重复的分组(不向上递交)发送方法送一个分组，然后等待接收方的响应停等策略主讲人：西安交通大学程向前第3讲传输层之一19rdt2.1:发送方,管理丢失的ACK/NAK主讲人：西安交通大学程向前第3讲传输层之一20rdt2.1:接收方,管理丢失的ACK/NAK主讲人：西安交通大学程向前第3讲传输层之一21rdt2.1:讨论发送方:给分组加seq#两个#’s(0,1)够否，为什么?必须查收ACK/NAK两倍的状态必须“记忆”状态，是否“正确的”分组具有0或1seq.#接收方:必须查验接收到的分组是否重复状态可以指出0或1是期望中的seq#注意:接收方不会知道最后的ACK/NAK是否为发送方正确接收主讲人：西安交通大学程向前第3讲传输层之一22rdt2.2:无NAK的协议其功能等同rdt2.1,但仅使用ACK不使用NAK,接受方只为最后正确接受的报文发送ACK接收方必须显式表明ACK的分组seq#发送方得到双重ACK导致NAK的相同结果:重传正确的分组发送方FSM!主讲人：西安交通大学程向前第3讲传输层之一23rdt3.0:通道上可能出错和丢失数据新的假设:所依赖的信道会丢失数据(数据或ACK)checksum,seq.#,ACK,重发机制会有帮助，但还远远不够Q:如何处理数据丢失?发送方可以等待，当某些数据或ACK丢失时,进行重传想一想:缺点?方法:发送方等待ACK一段“适当的”时间如果在这段时间里没有收到则进行重传如果分组(或ACK)仅仅被延迟了(没有丢失):重传将导致重复,但使用seq.#’s可以控制接收方必须定义被ACK分组的seq#需要进行倒计时主讲人：西安交通大学程向前第3讲传输层之一24rdt3.0发送方主讲人：西安交通大学程向前第3讲传输层之一25rdt3.0的运行主讲人：西安交通大学程向前第3讲传输层之一26rdt3.0的运行主讲人：西安交通大学程向前第3讲传输层之一27rdt3.0的性能rdt3.0可用,不过性能很糟例如:1Gb/s链路,15ms端对端的延迟,1KB分组:Ttransmit=8kb/pkt10**9b/sec=8ms利用率=U==8microsec30.016msecfractionoftimesenderbusysending=0.000151KB分组每30ms-33kB/sec在1Gb/s链路上的吞吐量网络协议限制了物理资源的利用!主讲人：西安交通大学程向前第3讲传输层之一28流水线协议（参见p79-84）流水作业:发送端允许发送多个,“悬在空中”,等待应答的分组必须增加顺序号的位数在发送和接收端增加缓存两种常用的流水线协议:第N个分组重发(go-Back-N),选择应答主讲人：西安交通大学程向前第3讲传输层之一29从第N个分组重发(Go-Back-N)发送方:在分组首部设置k位seq#使用尺寸为N的“滑动窗口(p80)”,允许连续的多个分组不被应答ACK(n):ACK所有n号之前，包括n号在内的分组--“积累式ACK”可能产生重复的ACK(见接收方)为每个未应答（in-flight）的分组设置计时器(timer)当发生超时：timeout(n):重传n号和n号以后的所有分组主讲人：西安交通大学程向前第3讲传输层之一30GBN:发送方扩展的FSM上层调用：ACK的接收超时事件主讲人：西安交通大学程向前第3讲传输层之一31GBN:接收方扩展的FSM接收方举例:ACK-only:总是对正确接收到的分组中按序（in-order）对最高seq#进行ACK可以产生重复的ACKs仅仅需要记住expectedseqnum（预期的序号）失序分组:丢弃(不缓存)-不进行接收缓存!接收到的分组中按序对最高seq#进行ACK主讲人：西安交通大学程向前第3讲传输层之一32GBN的运行主讲人：西安交通大学程向前第3讲传输层之一33选择应答(SR)-p84接收方逐个对所有正确收到的分组进行应答如有必要，对接收到的（失序）分组进行缓存,以便最后对上层进行有序递交发送方仅对未收到应答的分组进行重发发送方未每个unACKed分