h5响应式的网站,网站怎么添加模块,wordpress端口配置,云服务器可以做两个网站滑动窗口协议、GBN、SR之间不得不说的故事 首先我们来介绍什么是滑动窗口协议 滑动窗口协议#xff08;Sliding Window Protocol#xff09;#xff0c;属于TCP协议的一种应用#xff0c;用于网络数据传输时的流量控制#xff0c;以避免拥塞的发生。该协议允许发送方在停…滑动窗口协议、GBN、SR之间不得不说的故事 首先我们来介绍什么是滑动窗口协议 滑动窗口协议Sliding Window Protocol属于TCP协议的一种应用用于网络数据传输时的流量控制以避免拥塞的发生。该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认因此该协议可以加速数据的传输提高网络吞吐量。关于TCP协议的介绍可以查看我的另外一条博文《计算机网络自顶向下》知识体系梳理 如果许多客户向主机以很快的速度发送大量的数据包但是接收方却没有如此高的接收数据的能力这个时候我们就要控制发送方的发送速度控制它不要过快要求发送方限制它已经发出但未经确认的帧的数目使得网络传输效率得以提高滑动窗口协议就是这么来的。 在任何基于自动重发请求进行错误控制的通信协议中接收方必须确认收到的数据包。 如果发送方在合理的时间内没有收到确认则重发数据。没有听到确认的发送方不知道接收方是否实际接收到分组数据可能在传输中丢失或损坏。 如果错误检测显示损坏则数据包将被接收方忽略并且不会发送确认。 因为网络传输的时延将有大量时间被用于等待确认导致传输效率低下。 定义 传输的每个部分被分配唯一的连续序列号接收方使用数字并以正确的顺序放置接收到的数据包丢弃重复的数据包并识别丢失的数据。 工作原理 简单来说第一个和第二个包发送过去后收到第一个确认包就把第三个包发送过去图示如下图片来源于网络 在这张图里我们可以看到灰色123号包已经发送完毕并且已经收到了ACK4567号包是黄色的表示已经发送的没收到ACK的意思就是也不知道对方接收到了没有但还没有收到ACK8910号包是绿色的表示还未发送白色部分表示还未读入内存要等到4-10号包收到ACK后才会有所动作。 发生丢包时 这种情况可能是我们包发过去对方的ACK丢了或者是我们的包并没有发生过去对方没有收到ACK。 此时的情况一直在等ACK如果一直等不到ACK发过来我们就会把读进缓存的ACK包也一起发送过去但这个时候窗口已经发满了说一并不能读取12号包而是在一直等待5号包的ACK。 当ACK包一直发送不过来的情况时 解决方法超时重传 ACK是要按照顺序发送的也就是说必须等到5的ACK收到才会把6-11的ACK发送过去这样做的目的是为了保持滑动窗口的顺序。 上图可以看出5号包已经接受ACK后面的678号包也发送过去窗口便继续向后移动。 GBN协议 后退N帧ARQ协议对传统的自动重传请求ARQ,Automatic Repeat reQues进行了改进从而实现了在接收到ACK之前能够连续发送多个数据包。 工作过程 GBN协议中发送方在发完一个数据帧后连续发送若干个数据帧即使在连续发送过程中收到了接收方发来的应答帧也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍未收到确认帧就要重发相应的数据帧。如当发送方发送了N个帧后若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息则该帧被判为出错或丢失此时发送方就不得不重新发送出错帧及其后的N帧 确认过程 接受帧只允许按顺序接受帧。为了减少开销累计确认允许接收端在连续收到好几个正确的确认帧后只对最后一个数据帧发确认信息或者可以在自己有数据要发送时才将对以前正确收到的帧加以捎带确认。这就是说对某一数据帧的确认就表明该数据帧和这以前所有的数据帧均已正确无误地收到了。 SR协议工作原理 SR协议是当接收方发现某帧出错后其后继续送来的正确的帧虽然不能立即递交给接收方的高层但接收方可收下来存放在一个缓冲区中同时要求发送方重新传送出错的那一帧。一旦收到重新传来的帧后就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。显然SR减少了浪费但要求接收方有足够大的缓冲区空间 举例说明 答案是C 在这里有读者肯定就要问了为什么1不重发 答案很简单因为GBN采用的是累积确认机制收到编号为2的帧时便不会再去管前面编号为1的帧是否收到。 所以重发的帧编号是在3后面的编号为4567的帧。