290 likes | 511 Views
可靠数据传输. 可靠数据传输. rdt_send(): 从上层调用 , ( 例如 ., 应 用程序 .). 把数据传递给 接收方上层. deliver_data(): 被 rdt 调用传 递数据给上层. udt_send(): 由 rdt 调用 , 在不可靠的通道上传输数据 receiver. rdt_rcv(): 当数据包到达接收方通道时被调用. 可靠数据传输. 发送方. 接收方. 可靠数据传输. 发展方向 : 加大力度 开发传输双方的可靠数据传输协议 (rdt) 考虑单向数据传输 但控制信息可以双向传输 !
E N D
可靠数据传输 可靠数据传输
rdt_send():从上层调用, (例如., 应 用程序.). 把数据传递给 接收方上层 deliver_data():被 rdt 调用传 递数据给上层 udt_send():由 rdt 调用, 在不可靠的通道上传输数据receiver rdt_rcv():当数据包到达接收方通道时被调用 可靠数据传输 发送方 接收方
可靠数据传输 • 发展方向: • 加大力度开发传输双方的可靠数据传输协议 (rdt) • 考虑单向数据传输 • 但控制信息可以双向传输! • 用有限状态机 (FSM) 指定发送方和接收方
Event(事件)引起状态的变迁 Actions 呈现状态的变迁 event state 2 state 1 actions 有限状态机 (FSM) 状态: 当处于某一“状态”时,下一状态由下一个事件唯一地决定
Rdt1.0: 基于可靠信道的可靠传输 • 下级信道是非常可靠的 • 没有位出错 • 没有包丢失 • 发送方和接收方独立的有限状态机(FSMs): • 发送方把数据发到下级信道 • 接收方从下级信道读取数据
Rdt2.0: 有比特错误的信道 • 下级信道把报文切割分装成包 • 回忆: UDP校验和检测出位错误 • 问题: 怎样恢复: • 确认 (ACKs):接收方明确通知发送方数据包已成功接收
Rdt2.0:有比特错误的信道 • 否定确认 (NAKs):接收方明确通知发送方数据包出错 • 发送方收到NAK后就重发数据包 • Rdt2.0的新机制 (优于Rdt1.0): • 错误检测 • 接收方反馈: 控制信息 (ACK,NAK) rcvr->发送方
暂时性冗余模型 数据包 • 序列号 • 循环冗余校验 • (CRC)或者校验和 超时 • 确认 • 否定确认, • 选择确认 • 位图 状态报告 重发 • 数据包 • FEC信息
可靠性模型 • 可靠性=> 需要增加冗余以便恢复不确定的丢失或者其它类型错误. • 两类冗余: • 空间冗余:单独备份副本 • 前向纠错(FEC)编码 • 问题: 需要巨大的额外开销,FEC也是数据包的一部分,因此如果所有数据包都丢失了就无法恢复了 • 时间冗余:如果数据包丢失或者出错就重发 • 迟钝的: 牺牲响应时间换取可靠性 • 状态报告和最佳化重发的设计是很重要的
Rdt2.0: FSM详述 接收方的FSM 发送方的FSM
Rdt2.0: In Action (未出错) 发送方的FSM 接收方的FSM
Rdt2.0: In action (出错情况) 发送方的FSM 接收方的FSM
Rdt2.0 有致命缺陷! • 如果ACK/NAK不可靠,会出现怎样的情况 • 反向信道位出错 • 发送方并不知道接收方发生了什么情况! • 如何应付? • 发送方响应/未响应接收方的ACK/NAK? • 问题:如果发送方的ACK/NAK丢失了怎么办? • 重发数据包. • 问题:如果原先的数据包被成功地发到接收方,数据包将是重复的.
Rdt2.0 致命缺陷! (续.) • 处理重复的, 错乱的ACK/NAKs: • 发送方给每个数据包加入序列号 • 一旦ACK/NAK发生错乱,发送方会重发当前数据包 • 接收方丢弃重复的数据包 (不再转发)
Rdt2.1: 讨论 • 发送方 • 给数据包加序列号 • 两个序列号(0,1)就足够了. 为什么? • 如果ACK/NAK发生错乱必须检查 • twice as many states! • state必须“记住” 是否 “当前的” 数据包有0或1序列号
Rdt2.1: 讨论 • 接收方: • 如果接收到的数据包是重复的,就必须进行检查 • 状态0或1显示了数据包是否是要准备接收的 数据包序列号 • 注意: 接收方并不知道最近的 ACK/NAK是否已经被发送方正确接收
Rdt2.2: NAK自由协议 • 和rdt2.1具有同样的功能, 仅用ACKs. • Why bother ? • 接收方发送ACK替代NAK确认最近的数据包被正确接收 • 接收方必须明确包含被确认的数据包的序列号 • 发送方收到的重复ACK导致与NAK一样的情况:重发当前数据包
Rdt2.2: NAK自由协议 发送方的FSM
Rdt3.0: 不可靠的信道 • 新的假定:下级信道同样会丢失数据包 (数据和确认) • 这样有何不同? • 校验和, 序列号, 确认, 重发将会起到一定的作用, 但还是不够的 • Q:如何处理这种丢失? • 发送方会一直等到某个数据或确认丢失为止, 然后重发
Rdt3.0: 不可靠的信道 • 方法:发送方在确认被收到之前等待一段合理的时间 • 如果还收不到确认信息就重发 • 如果数据包(或者是确认) 只是延迟了(并没有丢失): • 重发将会引起重复数据包, 但如果用了序列号就不会发生这种情况 • 接收方必须指定被确认的数据包的序列号 • 需要倒计时定时器
Rdt3.0的性能 • rdt3.0可以使用, 但性能欠佳! • 举例: 1 Gbps link, 15 ms e2e prop. delay, 1KB packet: 8kb/pkt T = = 8 microsec transmit 10**9 b/sec 8 microsec fraction of time sender busy sending = = 0.00015 Utilization = U = 30.016 msec • 1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link • 问题: 网络协议限制了物理资源的使用!
到此为止学过的机制 • 机制: • 校验和: 检查数据和确认是否完整 • 确认:“数据包被成功接收” • 重复确认: “原先的数据包被正确收到”received” • 序列号: 识别数据包或确认信息 • 双向信道中的一位序列号 • 超时限于发送方 • 可靠性: • 不进行检错的信道 • 有位错误的双向信道 • 侦查重复的数据包和确认信息 • 无否定确认 • 有包丢失的双向信道
Summary • 传输层问题 • UDP • TCP • 可靠数据传输