计算机网络讨论课TCP可靠传输实现

计算机网络第四次讨论课

题目：TCP可靠传输的实现

学生所在班级：通信四班第四组

小组组长：张瞾（查阅资料、PPT制作，贡献率为21%）

组员：郑岚方（查阅资料、PPT制作，贡献率为21%）

蒲琼（查阅资料、论文撰写，贡献率为20%）

邱悦（查阅资料、论文撰写，贡献率为19%）

陈春（查阅资料、论文撰写，贡献率为19%）

教务处

2017年4月8日

一、以字节为单位的滑动窗口

1.1 TCP使用滑动窗口机制的原因

（1）当网络连接的两端速度不匹配时，发送端的发送速度快于接收端的处理能力时，便会出现快速的发送端将慢速的接收端淹没的现象，导致数据丢失。（2）为了防止由于发送端与接收端之间的不匹配而引起数据丢失，TCP采用滑动窗口进行流量控制。

（3）发送数据一方可以在一定条件下连续发送若干个分组，而不必每次发送都要在前一个分组的确认信息收到后进行。

1.2滑动窗口与固定窗口的比较

当滑动窗口为1时，即为停止等待协议。

图1.1（a）停止等待协议传输机制图1.1（b）连续ARQ协议传输机制1.2发送方滑动窗口

假定A收到了B发来的确认报文段，其中窗口值是20字节，而确认号是31。根据这两个数据，A就可以构造出自己的发送窗口。示例如下所示：

图1.2发送方A的发送窗口

发送方A的发送窗口确切含义是：在没有收到B确认的情况下，A可以把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时传送中使用。

发送窗口里面的序号表示允许发送的序号。窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，但接收方必须来得及处理这些收到的数据。

发送窗口后沿左侧的数据表示已发送且已收到了确认的数据部分，这些数据不需要再保留。而发送窗口前沿右侧的数据表示不允许发送部分数据，因为接收方没有为这部分数据保留可存放的缓存空间。

发送窗口的位置由窗口前沿和后沿的位置共同确定。发送窗口后沿的变化情况有两种可能：

即不动（没有收到新的确认）和前移（收到了新的确认）。发送窗口后沿不可能向后移动，因为不能撤销掉已收到的确认。发送窗口前沿通常是不断向前移动，但也有可能不动。这对应于两种情况：一是没有收到新的确认，对方通知的窗口大小也不便；二是收到了新的确认但对方通知的窗口缩小了，使得发送窗口前沿正好不动。

1.4指明窗口状态的指针

要描述一个发送窗口的状态需要三个指针P1,P2和P3,，指针都指向字节的

序列号。示意图如下所示：

图1.3指明窗口状态的各指针示意图

这三个指针指向的几个部分的意义如下：

小于P1的是已发送并已收到确认的部分，大于P3的是不允许发送的部分。

P3－P1=A的发送窗口

P2－P1=已发送但尚未收到确认的字节数

P3－P2=允许发送但尚未发送的字节数

当窗口A收到确认信息后，发送窗口向前滑动，示意图如下所示：

图1.4发送窗口向前滑动示意图

1.5接收方B的接收窗口

图1.5 接收窗口B示意图

B的接收窗口大小是20。在接收窗口外面，到33号为止的数据是已经发送过确认，并且已经交付给主机了。因此B可以不再保留这些数据。接收窗口内的序号是允许接收的。

现在假定B收到了序号为31的数据，并把31到33的数据交付给主机，然后B删除这些数据。接着把接收窗口向前移动3个序号，同时给A发送确认。A 收到B的确认后，就可以把发送窗口向前滑动3个序号，但指针P2不动。

A在继续发送完后面的数据后，指针P2向前移动和P3重合，发送窗口内的序号都已用完，但还没有再收到确认。由于A的发送窗口已满，可用窗口减小到零，因此必须停止发送。示意图如下所示：

图1.6 发送窗口已满示意图

若发送窗口内所有数据都已正确到达B，B也早已发出了确认，但这些确认滞留在网络中。为了保证可靠传输，A只能认为B还没收到这些数据。于是，A 在经过一段时间后就重传这部分数据，直到收到B的确认位置。如果A收到的确认号落在发送窗口内，A就可以是发送窗口继续向前滑动，并发送新的数据。

1.6发送缓存

示意图如下所示：

图1.7发送缓存示意图

发送缓存用来暂时存放：

●发送应用程序传送给发送方 TCP 准备发送的数据；

● TCP 已发送出但尚未收到确认的数据。

1.7接收缓存

示意图如下所示：

图1.8接收缓存示意图

1.8注意要点

● A 的发送窗口并不总是和 B 的接收窗口一样大（因为有一定的时间滞后）。

●TCP 对不按序到达的数据应的处理，通常是先临时存放在接收窗口中，等到

字节流中所缺少的字节收到后，再按序交付上层的应用进程。

●TCP 要求接收方必须有累积确认的功能，这样可以减小传输开销。

二、超时重传时间的选择

2.1TCP 保留了 RTT 的一个加权平均往返时间 RTTS

第一次测量到 RTT 样本时，RTTS 值就取为所测量到的 RTT 样本值。以后每测量到一个新的 RTT 样本，就按下式重新计算一次 RTTS：新的 RTTS = (1 - α ) * (旧的 RTTS) +α*(新的 RTT 样本) 式中 0≤α≤1

2.2超市重传时间ROT

超时计时器设置的超时传送时间RTO应略大于上面所得出的加权平均往返时间RTTS。RFC2988建议使用下式计算TRO：

RTO=RTTS+4×RTTD

RTTD是RTT的偏差的加权平均，它与RTTS和新的RTT样本之差有关。RFC2988

建议当第一次测量时RTTD值取为测量到的RTT样本值的一半。在以后的测量中，则使用下式计算加权平均的RTTD：

新的RTTD=（1－β）×（旧的RTTD）+β×∣RTTS—新的RTT样本∣

这里β是一个小于1的系数，推荐值是0.25。

2.3往返时间的测量相当复杂

TCP 报文段 1 没有收到确认。重传（即报文段 2）后，收到了确认报文段 ACK。如何判定此确认报文段是对原来的报文段 1 的确认，还是对重传的报文段 2 的确认？

图2.1往返时间示意图

2.4 Karn 算法

在计算平均往返时间 RTT 时，只要报文段重传了，就不采用其往返时间样本。

这样得出的加权平均平均往返时间 RTTS 和超时重传时间 RTO 就较准确。

三、选择确认SACK

若收到的报文无差错，只是未按照序号，中间还缺少一些序号的数据，而只传送缺少的数据而不重传已经确认到达接收方的数据的方法之一就是选择确认。

现举例说明选择确认的工作原理。TCP的接收方在接受对方发送过来的数据字节流的序号不连续，结果就形成了一些不连续的字节块。比如，接收方收到了前面的的字节流不连续的字节流不连续的两个字节块（如图3.1）。如果这些字节的序号都在接收窗口之内，那么接收方就先收下这些数据，但要把这些信息准确告诉发送方，使发送方不要再重复发送这些已收到的数据。我们知道，TCP的首部没有那个字段能够提供字块的信息边界信息。RFC2018规定，如果要选择确认，那么在建立TCP连接时，就要在TCP首部的现象中加上“允许SACK”的选项，而双方必须都事先商定好。如果使用选择确认，那么原来首部中的“确认号

字段”的用法不便。只是以后再TCP报文段的首部中都增加了SACK选项，以便报告收到的不连续的字节块的边界。

然而，SACK文档并没有指明发送方应当怎样相应SACK。因此大多数的实现还是重传所有未被确认的数据块。

图3.1不连续接收情况示意图

默认情况下TCP采取的是累积确认机制，这时如果发生了报文乱序到达，

接收方只会重复确认最后一个按序到达的报文段，为此发送方的处理只能是

重复按序到达接收方的报文段之后的那个报文段，因而它无法准确知道哪些

报文段到达了，哪些没有到达。

考虑以下情景，发送方的窗口状态如下(图3.2)：

图3.2发送窗口示意图

如上图所示，主机A通过TCP发送10个长度都为100字节的报文段给主机B，其序号分别为0,100,200,300,400,500,600,00,800,900（图中以字0-9代替）。主机B收到了序号为0和序号为100的报文段，但是序号为200,300,400的丢失了。之后主机B又收到了报文段

500,600,700,800,900。当收到后续这些分组时，主机B只能对报文段100继续进行确认，即发送确认号为200的ACK。主机A收到这样的确认时，能重传的唯一报文段就是报文段200，在报文段200的确认被收到之前发送窗口是无法移动的，这时状况就会很糟糕，发送方每重传一个丢失的报文段，接收方就确认一个（由于是累积确认的，所以情况可能更糟，接收方每次都在等待一段时间后才发送确认），然后发送窗口向前移动一个，这个过程一直持续到报文段200,300,400都被接收方到。显然这种工作方式效率很低，降低了吞吐量。

SACK是TCP选项，它使得接收方能告诉发送方哪些报文段丢失，哪些报文段重传了，哪些报文段已经提前收到等信息。根据这些信息TCP就可以只重传哪些真正丢失的报文段。

需要注意的是只有收到失序的分组时才会可能会发送SACK，TCP的ACK还是建立在累积确认的基础上的。也就是说如果收到的报文段与期望收到的报文段的序号相同就会发送累积的ACK，SACK只是针对失序到达的报文段的。

SACK包括了两个TCP选项，一个选项用于标识是否支持SACK，是在TCP 连接建立时时发送；另一种选项则包含了具体的SACK信息。

四、参考文献

[1]谢希仁.计算机网络（第6版） [M].北京：电子工业出版社.2012

[2]谢希仁.计算机网络释疑与习题解答[M].北京：电子工业出版社.2012