第3讲 传输层之一 本讲目的: 本讲概述: 理解传输层服务的原理: 传输层的服务 复用/分用 无连接的传输: UDP 可靠数据传输原理 第3讲 传输层之一 本讲目的: 理解传输层服务的原理: 复用/分用 可靠数据传输 流量控制 拥塞控制 Internet传输层的实现和实例 本讲概述: 传输层的服务 复用/分用 无连接的传输: UDP 可靠数据传输原理 第3讲 传输层之一

logical end-end transport 传输服务和协议 提供运行在不同主机中进程间的逻辑通信 传输协议仅运行在端系统中 传输 vs. 网络层服务 : 网络层: 在端系统间进行通信 传输层: 在进程间进行通信 依赖于, 加强了, 网络层的服务 application transport network data link physical network data link physical network data link physical network data link physical logical end-end transport network data link physical network data link physical application transport network data link physical 第3讲 传输层之一

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

复用/分用(multiplexing/Demultiplexing) 回顾: segment （段）- 传输层实体间交换数据的单位 TPDU: 传输层数据单元 分用: 将接收到的段传递给正确的应用层进程 receiver P3 P4 application-layer data M M application transport network segment header P1 P2 M M application transport network application transport network segment H t M H n segment 第3讲 传输层之一

复用/分用 从多个应用进程获取数据, 用首部(便于随后的分用)封装数据 复用: 源端口 # 宿端口 # 其他首部字段 复用/分用: 32 bits 源端口 # 宿端口 # 其他首部字段 复用/分用: 基于发送方, 接收方的端口号, IP 地址 源, 目的端口 #s 存在于每个段中 回顾: 用于特定应用的常用端口号（well-known port number） 应用层数据 (报文) TCP/UDP 段格式 第3讲 传输层之一

复用/分用: 举例 Web客户端 主机 C 主机 A 服务器 B 端口的使用: 简单的 telnet 应用 Web 服务器 B Web客户端 source port: x dest. port: 23 Web客户端 主机 C 主机 A 服务器 B source port:23 dest. port: x Source IP: C Dest IP: B source port: y dest. port: 80 Source IP: C Dest IP: B source port: x dest. port: 80 端口的使用: 简单的 telnet 应用 Source IP: A Dest IP: B source port: x dest. port: 80 Web 服务器 B Web客户端 主机 A 端口的使用: Web 服务器 第3讲 传输层之一

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

UDP: (续) 其他 UDP用途 (why?): 经常为流媒体应用使用 允许数据丢失 对传输速率敏感 DNS SNMP 在应用程序中-专门的出错恢复机制! 32 bits 源端口 # 宿端口 # 长度, UDP 段的字节数, 包括首部 length checksum 应用层数据 (报文) UDP 数据报格式 第3讲 传输层之一

UDP 校验和（checksum） 发送方: 目标: 检测传输段中的“错误” (e.g., 位错) 接收方: 将段的内容看作一串16位整数 对接收到的段内容进行补码和计算 检查计算结果是否与收到的校验和相等: NO – 查出错误 YES – 没查出错误. 但是仍有可能存在错误? 第3讲 传输层之一

可靠数据传输原理 在应用、传输、链路层都十分重要 属于网络工程的top-10 课题之一! 不可靠传输通道的特性将决定可靠传输协议(rdt)的复杂性 第3讲 传输层之一

可靠数据传输: 开始起步 rdt_send(): 由上层进行调用, (e.g., 应用进程.). 将数据传入发送方并由其传给接收方的上层 deliver_data(): 由 rdt调用 将数据递交给上层 发送方 接收方 udt_send(): 由rdt调用, 将分组通过不可靠的信道传到接收方 rdt_rcv(): 当数据到达接受方时调用 第3讲 传输层之一

可靠数据传输: 开始起步 我们将要: 逐步发展收发双方的可靠数据传输协议 (rdt) 仅考虑单向的数据传输 但控制信息将双向流动! 使用有限状态机 (FSM) 来定义发送方, 接收方 状态: 当实体处于某个“状态”时， 下个状态只能由下个事件来转变 事件导致状态的转换 在状态转换过程中的动作 state 1 state 2 事件 动作 第3讲 传输层之一

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

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

rdt2.0: 有限状态机定义 发送方的FSM 接收方FSM 第3讲 传输层之一

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

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

rdt2.0 有一个致命的缺点! 若ACK/NAK 报文丢失? 怎么办? 管理重复的问题: 发送方将不会知道接收端发生了什么! 假如进行重传 : 可能发生数据重复 怎么办? 发送 ACK/NAK 来回应接收方的 ACK/NAK? 那么如果发送方的 ACK/NAK 丢失? 重传, 但可能可能导致重传了正确的分组! 管理重复的问题: 发送方给每个分组加上sequence number （序号） 如果ACK/NAK丢失，发送方则重传正确的分组 接收方丢弃重复的分组 (不向上递交) 停等策略 发送方法送一个分组，然后等待接收方的响应 第3讲 传输层之一

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

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

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

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

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

rdt3.0 发送方 第3讲 传输层之一

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

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

rdt3.0的性能 rdt3.0 可用, 不过性能很糟 例如: 1 Gb/s 链路, 15 ms 端对端的延迟, 1KB 分组: T = transmit = 8kb/pkt 10**9 b/sec = 8 ms 利用率 = U = = 8 microsec 30.016 msec fraction of time sender busy sending = 0.00015 1KB 分组每 30 ms -> 33kB/sec 在 1 Gb/s 链路上的吞吐量 网络协议限制了物理资源的利用! 第3讲 传输层之一

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

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

GBN: 发送方扩展的 FSM 上层调用： ACK的接收 超时事件 第3讲 传输层之一

GBN: 接收方扩展的 FSM 接收方举例: ACK-only: 总是对正确接收到的分组中按序（ in-order ）对最高 seq # 进行ACK 可以产生重复的ACKs 仅仅需要记住 expectedseqnum（预期的序号） 失序分组: 丢弃 (不缓存) -> 不进行接收缓存! 接收到的分组中按序对最高 seq # 进行ACK 第3讲 传输层之一

GBN 的运行 第3讲 传输层之一

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

选择应答: 发送方, 接收方的窗口 第3讲 传输层之一

选择应答 接收方 发送方 上层数据到达 : 分组n到达[rcvbase, rcvbase+N-1] timeout(n):第n个计时器跳 如果窗口中的下一个序号可用，发送分组 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讲 传输层之一

选择应答的运行 第3讲 传输层之一