计算机网络学习（六）传输层 Ⅲ

最新推荐文章于 2024-05-05 13:00:55 发布

-=Leessang=-

最新推荐文章于 2024-05-05 13:00:55 发布

阅读量586

点赞数 1

分类专栏：计算机网络文章标签：网络网络协议

本文链接：https://blog.csdn.net/weixin_45763536/article/details/106504766

版权

计算机网络专栏收录该内容

14 篇文章 6 订阅

订阅专栏

正在学习计算机网络课程，以下是学习《计算机网络-自顶向下方法》的一些笔记，部分图片来自mooc网哈尔滨工业大学计算机网络课程：https://www.icourse163.org/course/HIT-154005。

1.滑动窗口协议

1.1流水线机制与滑动窗口协议

rdt 3.0 是一个功能正确的协议，但它的性能不能让人满意，rdt 3.0 性能问题的核心在于它是一个停等协议。

解决问题的简单方法是：流水线技术
效率对比
- 停等操作
- 流水线机制
流水线（pipeline）技术：不使用停等方式运行，而是允许发送方发送多个分组而无需等待确认
- 必须增加序号范围
- 协议的发送方和接收方两端需要更大的存储空间以缓存分组
滑动窗口协议（sliding- window protocol）：
- 窗口：允许使用的序列号范围
- 窗口尺寸为 N ：最多有N个等待确认的消息
- 滑动：随着协议的允许，窗口在序列号空间内向前滑动
- 具体协议：GBN、SR

1.2 GBN（Go-Back-N）协议

在这里插入图片描述

基序号( send_base) 定义为最早的未确认分组的序号
下一个序号( nextseqnum) 定义为最小的未使用序号(即下一个待发分组的序号）
- 绿色段内的序号对应于已经发送并被确认的分组
- 黄色段内对应已经发送但未被确认的分组
- 蓝色段内的序号能用于那些要被立即发送的分组
- 白色段内的序号是不能被使用的分组
GBN 发送方必须响应三种类型的事件:
- 1.上层的调用
  - 当上层调用 rdt_send() 时，发送方首先检查发送窗口是否已满
  - 如果窗口未满，则产生一个分组并将其发送，并相应地更新变量。如果窗口已满，发送方只需将数据返回给上层，隐式地指示上层该窗口已满，过会儿再试
- 2.收到一个 ACK
  - 在 GBN 协议中，对序号为 n 的分组的确认采取累积确认的方式，表明接收方已正确接收到序号为 n 之前且包括 n 在内的所有分组。
- 3.超时事件
  - 就像在停等协议中那样，定时器将再次用于恢复数据或确认分组的丢失
  - 如果出现超时，发送方重传所有已发送但还未被确认过的分组
  - 如果收到一个 ACK ，但仍有已发送但未被确认的分组，则定时器被重新启动。如果没有已发送但未被确认的分组，该定时器被终止
GBN 接收方的动作：
- 如果一个序号为 n 的分组被正确接收到，并且按序(即上次交付给上层的数据是序号为 n - 1 的分组) ，则接收方为分组 n 发送一个 ACK，并将该分组中的数据部分交付到上层。
- 在所有其他情况下，接收方丢弃该分组，并为最近（序列号最大）按序接收的分组重新发送 ACK。
- 这种方法的优点是接收缓存简单，接收方不需要缓存任何失序分组，需要维护的唯一信息就是下一个按序接收的分组的序号（expectedseqnum）
- 如果分组 k 已接收并交付给上层，则所有序号比 k 小的分组也已经交付
例子：1. 窗口长度为 4
GBN 协议中综合了 TCP 可靠数据传输构件时遇到的所有技术。这些技术包括使用序号、累积确认、检验和以及超时/重传操作。
为什么先要限制窗口长度为 N 呢？为什么不允许这些分组为无限制的数目呢?—— 流量控制是对发送方施加限制的原因之一，还将在学习 TCP 拥塞控制时分析另一个原因。
1.3 SR（Selective Repeat）协议
GBN 本身也有一些情况存在着性能问题，单个分组的差错就能够引起 GBN 重传大量分组，许多分组根本没有必要重传。
选择重传（SR）
- 接收方对每个分组单独进行确认（缓存机制，缓存乱序到达的分组）
- 发送方只重传那些没有收到 ACK 的分组（为每个分组设置定时器）
SR 发送方和接收方的窗口：
SR 发送方的事件与动作
- 从上层收到数据。
  - 当从上层接收到数据后，发送方检查下一个可用于该分组的序号。
  - 如果序号位于发送方的窗口内，则将数据打包并发送；
  - 否则就像在 GBN 中一样，将数据缓存，或返回给上层以便以后传输。
- 超时。
  - 定时报用来防止丢失分组
  - 每个分组必须拥有其自己的定时器，因为超时发生后只能发送一个分组。
- 收到 ACK。
  - 如果收到 ACK，倘若该分组序号在窗口内，则发送方将那个被确认的分组标记为已接收
  - 如果该分组的序号等于 send_base ，则窗口基序号向前移动到具有最小序号的未确认分组处
  - 如果窗口移动了并且有序号落在窗口内的未发送分组，则发送这些分组。
SR 接收方的事件与动作
- 序号在[ rcv _base, rcv _base + N - 1]内的分组被正确收到
  - 在此情况下，收到的分组落在接收方的窗口内，一个选择 ACK 被回送给发送方。
  - 如果该分组以前没收到过，则缓存该分组。
  - 如果该分组的序号等于接收窗口的基序号 rcv_base ，则该分组以及以前缓存的序号连续的（起始于 rcv_base 的）分组交付给上层。然后，接收窗口接向前移动分组的编号向上交付这些分组。
- 序号在[ rcv_base - N， rcv _base - 1 ]内的分组被正确收到
  - 在此情况下，必须产生一个 ACK ，即使该分组是接收方以前已确认过的分组。
- 其他情况。忽略该分组。
一个例子说明出现丢包时 SR 的操作。注意，接收方初始时缓存了分组 3 、4、5 ，并在最终收到分组 2 时，才将它们一并交付给上层。
然而，对于哪些分组已经被正确接收，哪些没有，发送方和接收方并不总是能看到相同的结果。对 SR 协议而言，这就意味着发送方和接收方的窗口会缺乏同步，并不总是一致。这也许会产生严重的后果：
- 前提：有 4 个分组序号 0 、1 、2 、3 的有限序号范围且窗口长度为 3
- 情况a：对前 3 个分组的 ACK 丢失，因此发送方重传这些分组。因此，接收方下一步要接收序号为 0 的分组，即第一个发送分组的副本
- 情况b：对前3 个分组的 ACK 都被正确交付，发送方向前移动窗口并发送第 4、5 ，6 个分组，其序号分别为 3 、0 、1。序号为 3 的分组丢失，但序号 0 的分组到达(一个包含新数据的分组) 。
- 对于接收方而言，两种情况是等同的。没有办法区分是第一个分组的重传还是第 5 个分组的初次传输。显然，窗口长度比序号空间小 1 时协议无法工作
- 解决方法：序列号空间必须足够大，以适合整个接收方窗口和整个发送方窗口，而不存在这种重叠情况。对于SR 协议而言，窗口长度比须小于或等于序号空间大小的一半

2. 可靠级据传输机制及其用途的总结

在这里插入图片描述

我们曾假定分组在发送方与接收方之间的信道中不能被重新排序。这在发送方与接收方由单段物理线路相连的情况下，通常是一个合理的假设。然而，当连接两端的 "信道"是一个网络时，分组重新排序是可能会发生的。
分组重新排序的一个表现就是，一个具有序号或确认号 x 的分组的旧副本可能会出现，即使发送方或接收方的窗口里都没有包含 x。
出现原因就是信道可被看成基本上是在缓存分组，并在将来任意时刻自然地释放出这些分组
实际应用中采用的方法是，确保一个序号不被重新使用，直到发送方"确信"任何先前发送的序号为 x 的分组都不再在网络中为止。
通过假定一个分组在网络中的"存活"时间不会超过某个固定最大时间量来做到这一点。在高速网络的 TCP 扩展中，最长的分组寿命被假定为大约 3 分钟