问题描述
我们将：
- 渐增式地开发可靠数据传输协议（ rdt ）的发送方和接 收方
- 只考虑单向数据传输 但控制信息是双向流动的！
- 双向的数据传输问题实际上是2个单向数据传输问题的综合
-
RDT1.0：在可靠信道上的可靠传输
下层的信道是完全可靠的
下层信道可能会出错：将分组中的比特翻转
- 用校验和来检测比特差错 问题：怎样从差错中恢复：
- 确认(ACK)：接收方显式地告诉发送方分组已被正确接收
- 否定确认( NAK): 接收方显式地告诉发送方分组发生了差错
- 发送方收到NAK后，发送方重传分组
rdt2.0中的新机制：采用差错控制编码进行差错检测
发送方不知道接收方发 生了什么事情！
- 发送方如何做？
- 重传？可能重复
- 不重传？可能死锁(或出 错)
- 需要引入新的机制
- 序号
- 处理重复：
- 发送方在每个分组中加 入序号
- 如果ACK/NAK出错，发 送方重传当前分组
- 接收方丢弃（不发给上 层）重复分组
停等协议：发送方发送一个分组， 然后等待接收方的应答
防止超时死锁 设置超时重传机制，一般设置比正常往返多一点的时间
rdt3.0的性能
- rdt3.0可以工作，但链路容量比较大的情况下，性能很差
- 链路容量比较大，一次发一个PDU 的不能够充分利用链路的传输能力
- 例：1 Gbps的链路，15 ms端-端传播延时，分组大小为1kB： Ttransmit = 8kb/pkt 109 b/sec = 8
- U sender：利用率 – 忙于发送的时间比例
- 每30ms发送1KB的分组 270kbps=33.75kB/s 的吞吐量（在1 Gbps 链路上）
- 瓶颈在于：网络协议限制了物理资源的利用！
- U sender= .008 30.008 = 0.00027 microsec L / R RTT + L / R = L (分组长度，比特) R (传输速率，bps) =
通用：滑动窗口(slide window)协议
- 发送缓冲区
- 形式：内存中的一个区域，落入缓冲区的分组可以发送
- 功能：用于存放已发送，但是没有得到确认的分组
- 必要性：需要重发时可用 发送缓冲区的大小：一次最多可以发送多少个未经确认的分组
- 停止等待协议=1
- 流水线协议>1，合理的值，不能很大，链路利用率不能够超100%
- 发送缓冲区中的分组
- 未发送的：落入发送缓冲区的分组，可以连续发送出去；
已经发送出去的、等待对方确认的分组：发送缓冲区的分组只有得到确认 才能删除
正常情况下的2个窗口互动
发送窗口
- 有新的分组落入发送缓冲区范围，发送->前沿滑动
- 来了老的低序号分组的确认->后沿向前滑动->新的分组可 以落入发送缓冲区的范围
- 接收窗口
- 收到分组，落入到接收窗口范围内，接收
- 是低序号 ，发送确认给对方
- 发送端上面来了分组->发送窗口滑动->接收窗口滑
GBN协议和SR协议的异同
- 相同之处
- 发送窗口>1
- 一次能够可发送多个 未经确认的分组
- 不同之处
- GBN :接收窗口尺寸=1
- 接收端：只能顺序接收
- 发送端：从表现来看，一旦一个 分组没有发成功，如：0,1,2,3,4 ; 假如1未成功，234都发送出去 了，要返回1再发送；GB1
- SR: 接收窗口尺寸>1
- 接收端：可以乱序接收
- 发送端：发送0,1,2,3,4，一旦1 未成功，2,3,4,已发送，无需重 发，选择性发送1
- GBN :接收窗口尺寸=1
若有收获，就点个赞吧
0 人点赞
