TCP可靠传输-滑动窗口接下一篇，超时重传时间的选择！！！

63 阅读 0 评论 42 点赞

我是靠谱客的博主高大小蝴蝶，最近开发中收集的这篇文章主要介绍TCP可靠传输-滑动窗口接下一篇，超时重传时间的选择！！！，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

信道利用率

在上一篇叙述停止等待协议时，我们提到了信道利用率这个概念，那么什么是信道利用率呢？

信号利用率其实就是在指定时间能能传输的数据分组的多少，我们当然是希望在保证可靠传输的情况下，使用最短的时间传输完数据。但是在使用停止等待协议时，若要传输大量的数据，那简直太浪费时间了，如图：

我们假设发送端发送数据所需的时间是Td,数据分组在信道之间往返一次所需的时间为RTT，接受发送确认信息所需的时间是Ta。因为仅仅在时间Td内才是用来传送有用的数据，所以信道利用率就可以这样计算：

由此可以看出，我们想提高信道利用率，那就得想法降低RTT+Ta的值，要达到这个目的，就需要用到接下来所要讲到的连续ARQ协议和滑动窗口协议(连续的ARQ协议其实就是滑动窗口的基本概念，不涉及细节问题)

流水线传输就是发送方可连续发送多个分组，不必发送完一个分组就停顿下来等待对方确认，显然这种方式可以获得很高的利用率。如图：

连续的ARQ协议(Automatic Repeat reQuest)--滑动窗口的基础知识

我们现在将多个分组连续发送过去，接收方会采用累计确认的方式，在接收到几个分组后，对按序到达的最后一个分组发送确认，这这时候就表示：到这个分组为止的所有分组都已经正确收到了。

如图：

分析：连续的ARQ规定，发送方每收到一个确认，就把发发送窗口向前滑动一个分组，因此，在等到下一个确认信息来之前，可能只传了一个分组过去，就向前滑动一个分组；也可能已经传过去了五个分组，就向前滑动五个分组。

累计确认的优缺点：优点是容易实现，即使确认丢失也不必重传；缺点是不能向发送方反映出接受端已经正确收到所有分组的信息。

例如：如果对方发送了五个数据分组，而中间的三个分组丢失了。这时接受放只能对前两个发出确认。发送方无法知道后边三个分组的下落，而只好把后边的三个分组都再重传一次。这句叫做回退N，表示需要再退回来重传已发送过的N个分组。可见当通信线路质量不好时，连续ARQ协议会带来很大影响。

TCP首部

在详细了解TCP的可靠传输之前，必须先了解TCP的报文段首部的格式：

链接：https://blog.csdn.net/qq_54669536/article/details/124254447

滑动窗口

滑动窗口：在TCP的首部内有个字段叫做窗口，这个窗口中有个字段叫做接收窗口数值，表示当前的自己的缓冲内存还有多大空间可以利用，接收端会将这个信息传给发送端，发送端根据这个窗口大小决定发送多少数据，发送端能发送数据的大小就是发送窗口(不能大于接收窗口)，这是根据接收端的窗口决定的，这个窗口的位置会根据发送端数据的发送和接收端对数据的确认不断向前滑动，我们称之为滑动窗口

TCP的滑动窗口是以字节为单位进行的，如图：

发送窗口表示:在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传是时使用

发送窗口的位置由窗口前沿和后沿的位置共同决定：

发送窗口后延的变化有两种情况，即不动(没有收到新的确认)和前移(收到了新的确认)。注意：发送窗口的后延不可能向后移动，因为不能撤销掉已收到的确认。

发送窗口的窗口前沿的变化也有两种情况，一是不动(没有收到新的确认，并且对方通知的窗口也不变；也有可能收到了新的确认，但窗口缩小了，缩小后的窗口正好等于原来窗口内没有发送的数据大小)；二是可能向后收缩，这是因为收到了新的确认并且新的接收窗口小于原来窗口内没有发送的数据大小。注意：TCP标准并不赞成这样做，因为很可能发送方在收到这个通知之前已经把窗口中的数据全部发送出去了，现在又要收缩窗口，不让发送这些数据，就会产生一些错误。

接下来我们来详细分析一下发送窗口和接收窗口：

我们假定三个指针：P1,P2,P3。指针都指向字节的序号，P1指向的是发送窗口的前沿序号，P2指向的是已发送但未收到确认的字段的最前沿序号，P3指向的是发送窗口的后沿序号

按正常的情况，发送窗口发送多少数据，那么确认信息中期望收到的序号应该是已发送数据的下一个数据序号，但是存在这样一个情况：发送端先发送的数据接受端没有收到，但是后发送的数据接受端正常收到了，那么接受端在发送的确认信息中期望收到的序号值还能是P2所指的方向吗？当然不行，注意接受端的确认信息是按照按序到达的数据中的最高序号给出确认，发送端虽然已经发送了31~41的数据，但是31没有被正常接收，那么确认信息中返回的确认号还是31，而不可能是后边的序号。当31被正常就收之后，我们才返回后边的序号。

再来分析一下这种情况，发送窗口内的数据已经全部发送完毕，接受端也已经全部收到，但是返回的确认信息丢失了，那么在发送端只能认为接受端没有接收到数据，此时发送端在经过一段时间后只能重传数据，并重置超时计时器。

窗口与缓存的关系

首先明确一点，发送缓存区存放的是什么？

发送应用程序传送给发送方TCP准备发送的数据
TCP已发送出去但尚未收到确认的数据，即副本

发送窗口通常只是发送缓存的一部分。已被确认的数据应当从发送缓存中删除，因此发送缓存和发送窗口的后沿是重合的，发送应用程序最后写入发送缓存的字节减去最后被确认的字节，就是还保留在发送缓存中的被写入的字节数。

接收缓存区存放的是什么？

按序到达的、但未被接受应用程序读取的数据
未按序到达的数据

接收窗口也只是接收缓存的一部分。如果接收应用程序来不及读取收到的数据，接收缓存就会被填满，使接收窗口变为0，反之，如果接收应用程序能够及时从接收缓存中读取收到的数据，接收窗口就会增大，但最大不能超过接受缓存的大小。

强调：

虽然发送窗口是按接受窗口设置的，但在同一时刻，发送窗口并不总和接收窗口一样大。这是因为通过网络传送窗口值需要一定的时间(这个时间是不确定的)。
对于不按序到达的数据，TCP是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
TCP要求接收方必须有累计确认的功能，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。但有两点要求：接收方不应过分推迟发送确认，否则会导致不必要的重传，这反而浪费了网络的资源。TCP标准规定，确认推迟的时间不应超过0.5秒，若收到一连串具有最大长度的报文段，则必须每个一个报文段就发送一个确认；二是捎带确认并不经常经常发生，因为大多数应用程序很少同时在两个方向上发送数据。

这里的最大长度其实指的就是MSS，即数据报文的最大长度，在通信双方建立连接时，每一方都会告诉对方自己期望收到的MSS，它是存储在同步报文SYN中的。

重点强调：TCP的通信的是全双工的，通信中的每一方都有自己的发送和接收报文段，因此，每一方都有自己的发送窗口和接收窗口，一定要分清

前面我们多次提到超时重传，但是究竟将超时时间设置为多少合适呢？