常用的网站建设技术有什么软件,wordpress游客变注册用户,婚嫁类网站,打码挂机网站建设前前言#xff1a;看过本节的朋友应该都知道本节长度长的吓人#xff0c;但其实内容含量和之前的差不多#xff0c;老师在本节课举的例子和解释比较多#xff0c;所以大家坚持看完是一定可以理解透彻的。本节课大部分是在提出问题和解决问题#xff0c;先明确出现的问题是… 前前言看过本节的朋友应该都知道本节长度长的吓人但其实内容含量和之前的差不多老师在本节课举的例子和解释比较多所以大家坚持看完是一定可以理解透彻的。本节课大部分是在提出问题和解决问题先明确出现的问题是什么再去看 RDT 是如何解决它的会很有帮助在 RDT 之后又引入了流水线协议去解决 RDT 利用效率问题这部分同样需要先搞清楚提出了什么问题。 前言 学习视频中科大郑烇、杨坚全套《计算机网络自顶向下方法 第7版James F.KuroseKeith W.Ross》课程 该视频是B站非常著名的计网学习视频但相信很多朋友和我一样在听完前面的部分发现信息量过大有太多无法理解的地方在我第一次点开的时候也有相同的感受但经过了一段时间项目的学习对计网有了更多的了解所以我准备在这次学习的时候做一些记录并且加入一些我的理解希望能够帮助到大家。 往期笔记可以看专栏中的内容 文章目录 3.4 可靠数据传输的原理3.4.1 实现 RDT 通信需要解决哪些问题3.4.2 RDT 1.0 - 可靠信道上传输数据3.4.3 RDT 2.0 - 在具有比特差错的信道传输数据3.4.3.1 RDT 2.13.4.3.2 RDT 2.2 - NAK FREE 3.4.4 RDT 3.0 - 在具有比特差错和分组丢失的信道上传输3.4.5 流水线协议3.4.5.1 案例3.4.5.2 滑动窗口 3.4.6 GBN 协议3.4.7 SR 协议 3.4 可靠数据传输的原理 RDTReliable Data Transfer可靠数据传输是一种通信协议旨在通过各种技术手段确保数据在通信网络中可靠地传输。RDT的实现方式可以基于不同的传输层协议如TCP或UDP。 3.4.1 实现 RDT 通信需要解决哪些问题 如果说是在传输层来实现可靠数据传输的话需要从上层收取数据将其进行封装然后交给下层但如果下层是 unreliable 的话就需要通过本层实现来解决下层不可靠的问题。
整个可靠数据传输需要解决如下的问题
完整性Integrity数据在传输过程中没有被篡改或损坏。接收方能够准确地接收到发送方发送的数据。顺序性Ordering数据包按照发送的顺序被接收方接收。即使在传输过程中发生了拥塞或丢包接收方也能够按照正确的顺序重组数据。可靠性Reliability数据包能够在不丢失的情况下被接收方接收到。如果数据包丢失或损坏可靠的传输机制会重新发送数据直到接收方正确地接收到为止。及时性Timeliness数据包能够在合理的时间内被接收方接收到避免过长的延迟或等待时间。
但如果网络层实现了其中的一部分那传输层只需要解决 剩余的部分 即可。
所以采用一种渐进的方式来讲述 RDT 的实现先假设一个可靠的传输信道再逐步减少其能实现的功能同时逐步是通过上层的协议来解决这些问题。 使用有限状态机FSM来描述发送方和接收方 是一种抽象的计算模型用于描述系统在不同状态之间的转换以及状态转换所触发的行为。有限状态机由一组状态、一组输入和一组状态转换规则组成。使用圆来表示一种状态使用连线来表示从一个状态到另一个状态的变迁连线上的标注分子表示引起状态变迁的事件分母表示状态变迁的时候要进行的动作。 3.4.2 RDT 1.0 - 可靠信道上传输数据 此时下层的信道是完全可靠的 没有比特出错没有分组丢失 此时的传输层就不需要做任何的操作只需要接收上层的数据并且封装接着将数据交给网络层即可。
此时发送方和接收方的 FSM 看懂这个图需要记住上面说的分子和分母的含义 发送方等待上层的数据上层使用 rdt_send(data) 发送数据此时发送方将数据封装并且调用下层的 udt_send() 来进行发送接收方同理接收到数据然后解封装向上层传递 3.4.3 RDT 2.0 - 在具有比特差错的信道传输数据 此时下层的信道就稍微不可靠一点了会使得发送的分组中的比特翻转过来。 此时发送方和接收方就需要通过一定的手段来找出数据中是否存在问题和解决了。
比如使用 校验和 的方式 校验和是一种简单的错误检测方法通常用于确认数据在传输过程中是否发生了错误。 它通过对数据中的每个字节进行加和运算得到一个校验值并将该校验值附加到数据中 一起传输。 接收端 在接收到数据后也计算校验和然后与发送端附加的校验和进行比较如果两者相等则说明数据在传输过程中没有发生错误如果不相等则说明数据可能已经损坏需要进行重传。 校验和虽然能够检测一部分错误但并 不是完美的错误检测方法因为存在一些情况下校验和并不能准确地检测出错误。 这篇博客里有关于 UDP 校验和形成的描述感兴趣的朋友可以去看看中科大计网学习记录笔记十四多路复用与解复用 | 无连接传输UDP 此时校验如果出错那解决方法就只能是通过 重传所以需要 将检测结果反馈给发送端 来决定是否重传当数据没有错误的时候向发送端发送 确认ACK反之发送 否定确认NAK
发送方需要等待接收方的确认消息才能决定是否重传分组或者继续发送其他分组发送端接收到 NAK 的时候就重传分组
此时发送方就有了等待上层交付数据和等待接收方返回数据两种状态 3.4.3.1 RDT 2.1 RDT 2.0 存在一个致命的缺陷既然发送的数据可能损坏那发送的 ACK 或者 NAK 是否也有可能损坏呢 此时就需要一种解决方法
发送方接收到一个无法理解的消息这个消息有两种可能ACK 或者 NAKNAK 直接重传就可以了但是得有一种方法能让接收方重传这个 ACK。
此时就采用和 NAK 同样的处理方式直接重新发送上次的分组过去。此时如果接收方发送的是 NAK 那就直接结束了但如果发送方发送的是 ACK 但是接收到了相同的分组也就知道是发送的 ACK 在传输中出现了问题直接重发 ACK 即可。为了让接收方和发送方都能认识分组所以采用编号的方式快速的判断是否是重传。 3.4.3.2 RDT 2.2 - NAK FREE 发送数据不一定一次就只发送一条数据但如果发送多条数据的其中一条出错仍然使用单调的NAK 解释的话就无法知道要重发哪一条。 停等协议Stop-and-Wait流水线协议Pipelining Protocol 同时上面又引入了编号那就有了一种新的确认错误的方式发送的编号和返回的编号是否相同比如说发送的是数据 0 但是接收方传输过来的是 ACK(1) 这时候同样可以达到标识错误。 这种改动其实对单个数据发送没有太大影响而对后续改编成连续数据的发送则有很大的帮助。
3.4.4 RDT 3.0 - 在具有比特差错和分组丢失的信道上传输 此时下层的信道可能会丢失分组比如数据会丢失或者 ACK 也可能会丢失 这样就带来了一些问题发送方不知道接收方接收到了没有因为发送的数据和发送方的 ACK 都有可能会丢失。
此时的解决方式就是采用超时重传机制发送方等待 ACK 一段时间如果没有收到就说明出现了问题此时直接重传
如果此时是数据丢失的情况重传后双方同步如果是 ACK 丢失的情况接收方接收到了重复的数据同样发送 ACK 回去此时也能同步 这个超时重传的时间设定要合理当时间设置的过长会导致错误处理不及时过低则会导致使用效率的降低
当 ACK 还没来得及过来的时候发送方就重发了信息此时接收方收到了重发再次发送一个 ACK 过去这样就会导致每次发送都是两次甚至多次的发送 3.4.5 流水线协议 此时通过 RDT 协议已经解决了网络层可能出现的所有问题但是发送一条后等待确认再发送下一条的特质使得其对信道的利用效率极低。 3.4.5.1 案例 使用发送速率为 1 Gbps 的链路进行通信端到端的传播延时为 15 ms一个分组的大小为 1kB评判一下数据传输的效率。 传输延时为 8 / 109 8 us
总延时15ms ✖ 2 8us
此时的利用率也就是总延时除以发送延时达到了 0.00027也就是说只有 0.027% 的时间在发送数据其他时间都在等待 ACK。
这样的效率显然是不尽如人意的所以在等待的时间中可以通过再次发送其他数据来增大利用率。
3.4.5.2 滑动窗口 在学习具体的流水线协议之前要先了解滑动窗口这是实现该协议的一种机制。 比如说此时有五个分组等待发送 肯定无法直接将这五个分组全部打出去因为接收方的接受能力是有限的而且下方的网络层提供的是不可靠的传输需要对错误的信息进行重传等操作。
所以需要设置一个固定大小的 缓冲区将每次只处理缓冲区域内的数据等到缓冲区域中的一部分数据处理完成通过移动缓冲区又可以处理新的数据。
假设缓冲区的大小为 3就将这三个数据全部打出 此时进入等待等到数据 0 的 ACK 收到的时候就可以移动窗口了 这样逐次进行操作直到处理完所有需要发送的分组。
以上就是滑动窗口的基本思想同样的在接收方也可以顺序的去接收一个分组或同时可接收多个分组对于这两种情况发送方又有不同的策略。
3.4.6 GBN 协议 GBNGo-Back-N当接收方一次只能接收一个分组的时候就需要使用该协议。 此时发送方只能接收分组 0当接收到分组 0 的时候将可接受的内容后移一位来接收 1同时向发送方发送 ASK。 发送方接收到 ASK 之后可以移动窗口继续发送其他分组。
这是最好的情况比如说此时通信处于如下的情况 接收方等待接收分组 2但是如果出现了某些情况导致分组 2 没有到达而是分组 3 和 分组 4 到达那这时候接收方就会 拒收 这些分组。
那这样之后分组 2 包括其以后的分组都没有收到必须通知发送方来重传最好的方式就是给分组设置定时器如果发送的分组没有收到 ASK 的话就进行重传的操作。
所以当接收方收到分组 3 的时候会返回 分组 1 的 ASK那自然分组 2 之后的所有分组在分组定时器到期后就会进行重传操作解决了分组丢失的问题。
所以当分组 2 丢失了之后就需要跳回到数个位置之前去重传所以称之为 Go Back N。
但显然因为一个分组的丢失去重传多个分组是可以优化的可以让 接收方同时可以接收多个分组 来实现这也就是接下来要说的 SR 协议。
3.4.7 SR 协议 SRSelective Repeat即选择重传协议通过让接收方接收多个分组可以实现选择性的重传分组而不需要重传 N 个分组。 此时比如说接收到了分组 2就将分组 2 先保留下来同时发送 ASK2 给发送方发送方此时给分组 2 一个标识然后只需要发送其他的未接受到 ASK 的分组即可。
这个重发操作同样是通过 定时器 来实现。
对比一下 当出错率低的时候使用 GBN因为即使是 Go Back N 带来的损失依旧很小没必要去使用复杂的 SR 协议。当链路容量很大的时候建议使用 SR因为容量大代表同时可发送的内容较多为了充分利用就会同时发送很多的分组此时如果出现错误代价会比较大。
平衡这两点考虑就可以选择出适合的协议方式。
