第3讲 传输层之一

《第3讲 传输层之一》由会员分享，可在线阅读，更多相关《第3讲 传输层之一（36页珍藏版）》请在金锄头文库上搜索。

1、第3讲 传输层之一,1,第3讲 传输层之一,本讲目的: 理解传输层服务的原理: 复用/分用 可靠数据传输 流量控制 拥塞控制 Internet传输层的实现和实例 教科书参考 第8章,本讲概述: 传输层的服务 复用/分用 无连接的传输: UDP 可靠数据传输原理,第3讲 传输层之一,2,传输服务和协议,提供运行在不同主机中进程间的逻辑通信 传输协议仅运行在端系统中 传输 vs. 网络层服务 : 网络层: 在端系统间进行通信 传输层: 在进程间进行通信 依赖于, 加强了, 网络层的服务,第3讲 传输层之一,3,传输层协议,Internet 传输服务: 可靠, 按序点对点递交 (TCP) 拥塞控制

2、流量控制 连接建立 不可靠的 (“尽力而为”), 无序的点对点或广播递交: UDP 不能提供的服务: 实时性 带宽承诺 可靠的广播通信,第3讲 传输层之一,4,P2,复用/分用(multiplexing/Demultiplexing),回顾: segment （段）- 传输层实体间交换数据的单位 TPDU: 传输层数据单元,receiver,H,t,分用: 将接收到的段传递给正确的应用层进程,segment,segment,M,P1,P3,P4,segment header,application-layer data,第3讲 传输层之一,5,复用/分用,复用/分用: 基于发送方, 接收方的端

3、口号, IP 地址 源, 目的端口 #s 存在于每个段中 回顾: 用于特定应用的常用端口号（well-known port number）,从多个应用进程获取数据, 用首部(便于随后的分用)封装数据,源端口 #,宿端口 #,32 bits,应用层数据 (报文),其他首部字段,TCP/UDP 段格式,第3讲 传输层之一,6,复用/分用: 举例,主机 A,服务器 B,端口的使用: 简单的 telnet 应用,Web客户端 主机 A,Web 服务器 B,Web客户端 主机 C,端口的使用: Web 服务器,第3讲 传输层之一,7,UDP: 用户数据报协议 RFC 768,“最简约的” Interne

4、t 传输协议 “尽力而为的” 服务, UDP 数据段可以: 丢失 应用数据不按序到达 无连接: 在UDP收发双方之间, 无需握手信号 每个 UDP 数据段的操作都互相独立,为什么需要 UDP? 无需建立连接 (会增加延迟) 简单: 在收发双方之间没有连接状态 段首较短 无拥塞控制: UDP 可按需要随时发送,第3讲 传输层之一,8,UDP: (续),经常为流媒体应用使用 允许数据丢失 对传输速率敏感 其他 UDP用途 (why?): DNS SNMP 若需要通过 UDP进行可靠传输:在应用层增加可靠性措施 在应用程序中-专门的出错恢复机制!,源端口 #,宿端口 #,32 bits,应用层数据

5、(报文),UDP 数据报格式,length,checksum,长度, UDP 段的字节数, 包括首部,第3讲 传输层之一,9,UDP 校验和（checksum）,发送方: 将段的内容看作一串16位整数 checksum: 作段内容的加法(补码和) 发送方将补码和放入 UDP checksum 字段,接收方: 对接收到的段内容进行补码和计算 检查计算结果是否与收到的校验和相等: NO 查出错误 YES 没查出错误. 但是仍有可能存在错误?,目标: 检测传输段中的“错误” (e.g., 位错),第3讲 传输层之一,10,可靠数据传输原理,在应用、传输、链路层都十分重要 属于网络工程的top-10

6、课题之一!,不可靠传输通道的特性将决定可靠传输协议(rdt)的复杂性,第3讲 传输层之一,11,可靠数据传输: 开始起步,发送方,接收方,第3讲 传输层之一,12,可靠数据传输: 开始起步,我们将要: 逐步发展收发双方的可靠数据传输协议 (rdt) 仅考虑单向的数据传输 但控制信息将双向流动! 使用有限状态机 (FSM) 来定义发送方, 接收方,事件导致状态的转换,在状态转换过程中的动作,状态: 当实体处于某个“状态”时， 下个状态只能由下个事件来转变,第3讲 传输层之一,13,Rdt1.0: 在可靠信道上进行可靠的数据传输,所依赖的信道非常可靠 不可能有位错 不会丢失数据 分别为发送方和接收

7、方建立 FSMs : 发送方将数据送入所依赖的信道 接收方从所依赖的信道读出数据,第3讲 传输层之一,14,Rdt2.0: 在可能发送位错的信道上传输,所依赖的信道有可能在分组数据中出现位错 回顾: UDP checksum 可发现位错 问题: 如何从错误中恢复 : 进行确认 (ACKs): 由接收方法送报文向发送方进行确认 发送否认 (NAKs):由接收方法送报文向发送方进行否认，说明分组有错 发送方在收到NAK后进行分组重传 在人类交往中是不是也有 ACKs, NAKs? rdt2.0的新机制 (在 rdt1.0基础之上): 错误检测 接收方的反馈: 控制信息 (ACK,NAK) rcvr

8、-sender,第3讲 传输层之一,15,rdt2.0: 有限状态机定义,发送方的FSM,接收方FSM,第3讲 传输层之一,16,rdt2.0: 运行过程 (未发现错误),发送方 FSM,接收方 FSM,第3讲 传输层之一,17,rdt2.0:运行过程 (出错情况),发送方 FSM,接收方FSM,第3讲 传输层之一,18,rdt2.0 有一个致命的缺点!,若ACK/NAK 报文丢失? 发送方将不会知道接收端发生了什么! 假如进行重传 : 可能发生数据重复 怎么办? 发送 ACK/NAK 来回应接收方的 ACK/NAK? 那么如果发送方的 ACK/NAK 丢失? 重传, 但可能可能导致重传了正确

9、的分组!,管理重复的问题: 发送方给每个分组加上sequence number （序号） 如果ACK/NAK丢失，发送方则重传正确的分组 接收方丢弃重复的分组 (不向上递交),发送方法送一个分组，然后等待接收方的响应,第3讲 传输层之一,19,rdt2.1: 发送方, 管理丢失的 ACK/NAK,第3讲 传输层之一,20,rdt2.1: 接收方, 管理丢失的 ACK/NAK,第3讲 传输层之一,21,rdt2.1: 讨论,发送方: 给分组加seq # 两个 #s (0,1) 够否，为什么? 必须查收ACK/NAK 两倍的状态 必须“ 记忆” 状态，是否 “正确的”分组具有 0 或 1 seq.

10、 #,接收方: 必须查验接收到的分组 是否重复 状态可以指出0 或 1 是期望中的 seq # 注意: 接收方不会知道最后的ACK/NAK 是否为发送方正确接收,第3讲 传输层之一,22,rdt2.2: 无 NAK的协议,其功能等同 rdt2.1, 但仅使用 ACK 不使用 NAK, 接受方只为最后正确接受的报文发送 ACK 接收方必须显式表明ACK 的分组 seq # 发送方得到双重ACK导致 NAK的相同结果: 重传正确的分组,发送方 FSM,!,第3讲 传输层之一,23,rdt3.0: 通道上可能出错和丢失数据,新的假设: 所依赖的信道会丢失数据 (数据或 ACK) checksum,

11、seq. #, ACK, 重发机制会有帮助，但还远远不够 Q: 如何处理数据丢失? 发送方可以等待，当某些数据或ACK 丢失时, 进行重传 想一想: 缺点?,方法: 发送方等待ACK一段 “适当的” 时间 如果在这段时间里没有收到则进行重传 如果分组(或 ACK)仅仅被延迟了 (没有丢失): 重传将导致重复, 但使用seq. #s 可以控制 接收方必须定义被 ACK分组的 seq # 需要进行倒计时,第3讲 传输层之一,24,rdt3.0 发送方,第3讲 传输层之一,25,rdt3.0 的运行,第3讲 传输层之一,26,rdt3.0 的运行,第3讲 传输层之一,27,rdt3.0的性能,rdt

12、3.0 可用, 不过性能很糟 例如: 1 Gb/s 链路, 15 ms 端对端的延迟, 1KB 分组:,1KB 分组每 30 ms - 33kB/sec 在 1 Gb/s 链路上的吞吐量 网络协议限制了物理资源的利用!,第3讲 传输层之一,28,流水线协议（参见p79-84）,流水作业: 发送端允许发送多个, “悬在空中”, 等待应答的分组 必须增加顺序号的位数 在发送和接收端增加缓存,两种常用的流水线协议: 第N个分组重发(go-Back-N), 选择应答,第3讲 传输层之一,29,从第N个分组重发(Go-Back-N),发送方: 在分组首部设置k位 seq # 使用尺寸为N的“滑动窗口(p

13、80)”, 允许连续的多个分组不被应答,ACK(n): ACK所有n号之前，包括n号在内的分组- “积累式ACK” 可能产生重复的ACK (见接收方) 为每个未应答（in-flight）的分组设置计时器(timer) 当发生超时：timeout(n): 重传n号和n号以后的所有分组,第3讲 传输层之一,30,GBN: 发送方扩展的 FSM,上层调用：,ACK的接收,超时事件,第3讲 传输层之一,31,GBN: 接收方扩展的 FSM,接收方举例: ACK-only: 总是对正确接收到的分组中按序（ in-order ）对最高 seq # 进行ACK 可以产生重复的ACKs 仅仅需要记住 expe

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

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