5.7、TCP 可靠传输的实现

news2024/10/7 14:22:43

1、TCP基于以字节为单位的滑动窗口来实现可靠传输

TCP 基于 $\color{red}以字节为单位的滑动窗口$ 来实现可靠传输

如下所示，假定数据传输只在一个方向进行

这是发送方待发送字节的序号

假设发送方收到了来自一个接收方的确认报文段

在报文段首部中的窗口字段的值为 $20$ ，也就是接收方表明自己的接收窗口的尺寸为 $20$ 字节
确认号的值为 $31$ ，这表明接收方希望收到下一个数据的序号为 $31$ ，而序号 $30$ 为止的数据已经全部正确接受了

因此发送方根据这两个字段的值构造出自己的发送窗口

为了简单起见：假定网络不存在拥塞问题

也就是发送方在构造自己的发送窗口时，仅考虑接收方的接收窗口，而不考虑拥塞窗口

发送方在没有接收到接收方确认的情况下，可以把发送窗口内的数据一次全部发送出去

凡是已经发送过的数据，在未收到确认之前，都必须暂时保留，以便在超时重传时使用

发送窗口后沿的后面部分时已发送并收到确认的数据字节的序号

这些数据字节显然不需要保存在发送缓存中了，可以删除

发送窗口前沿的前面部分时不允许发送的数据字节的序号

2、发送窗口后沿 & 前沿移动情况

发送窗口后沿的移动情况有两种情况

不动（没有收到新的确认）
前移（收到了新的确认）

不可能向后移动，因为不能撤销已收到的确认

发送窗口前沿的移动情况有三种情况

通常是不断向前移动
不动

①没有收到新的确认。对方通知的窗口大小也不变

②收到新确认，但对方通知的窗口缩小，是发送窗口前沿正好不动
向后收缩（对方通知的窗口缩小了）
- 但 TCP 标准强烈不赞成这样做，因为很可能发送方在收到这个通知之前，就已经发送了窗口中的许多数据，现在又要收缩窗口，不让发送这些数据，显然就会产生错误

3、滑动窗口基本过程

假定发送方将发送窗口内序号 $31$ ~ $41$ 的数据封装在几个不同的数据报文段发送出去

此时发送窗口的为止并没有变

发送窗口内序号 $31$ ~ $41$ 的数据已经发送但未收到确认，而序号 $42$ ~ $50$ 的数据是允许发送但还未发送的

若编程实现：使用三个指针 P1，P2，P3 分别指向相应的字节序号

小于 P1 的是已发送并已收到确认的部分;
大于等于 P3 的是不允许发送的部分;
$\texttt{P3-P1}$ = 发送窗口的尺寸;
$\texttt{P2-P1}$ =已发送但尚未收到确认的字节数;
$\texttt{P3- P2}$ = 允许发送但当前尚未发送的字节数(又称为可用窗口或有效窗口);

在接收窗口外面到 $30$ 号为止的数据，是已经发送给过相应确认并已交付给应用进程的数据，

因此，无需在保留这些数据，可将他们从接收缓存中删除了

接收窗口内 $31$ ~ $50$ 号数据是允许接收的数据

接收窗口外 $51$ 号及其后续数据，目前不允许接收

假设发送方之前发送的封装有 $32$ ~ $33$ 号数据的报文段到达了接收方

由于数据序号落在接收窗口内，所以接收方接收它们，并将它们存入接收缓存。

但是它们是未按序到达的数据，因为 $31$ 号数据还没有到达

这有可能是丢了，也有可能是滞留在网络中的某处

注意： $\color{red}接收方只能对按序收到的数据中的最高序号给出确认$

类似于选择重传协议 SR 与回退 N 帧协议的结合版本： (可靠传输)

因此，接收方发出的确认报文段中的确认序号仍然是 $31$

也就是希望收到 $31$ 号数据

该确认报文窗口字段的值仍然是 $20$ ：表明接收方没有改变自己接收窗口的大小

发送方收到该确认报文段后，发现这是一个针对 $31$ 号数据的重复确认

就知道接收方收到了未按序到达的数据

由于这是接收方收到的第一个重复确认，因此这并不会引起发送方针对该数据的快重传

另外，接收方通知窗口的尺寸仍是 $20$ ，因此发送方保持自己的发送窗口尺为 $20$

现在，假设封装有 $31$ 号数据的报文段到达了接收方

接收方接收该报文段，将其封装的 $31$ 号数据存入接收缓存

接收方现在可将 $31$ ~ $33$ 号数据交付给应用进程

然后接收窗口向前移动 $3$ 个序号，并给发送方发送确认报文段

该确认报文窗口字段的值仍然是 $20$ ：表明接收方没有改变自己接收窗口的大小

确认号字段的值为 $34$ ：表明接收方已经收到了序号 $33$ 为止的全部数据

现在假设又有几个数据报文段到达了接收方，它们封装有 $37$ ， $48$ ，以及 $40$ 号数据

这些数据的序号虽然落在接收窗口内，但它们都是为按序到达的数据，只能先暂存在接收缓存中

假设接收方先前发送的确认报文段到达了发送方

发送方接收后，将发送窗口滑动 $3$ 个序号，发送窗口的尺寸保存不变

这样就有序号 $51$ ~ $53$ 移动到窗口内，而序号 $31$ ~ $33$ 移出了发送窗口

现在可以将 $31$ ~ $33$ 号数据从发送缓存中删除了，因为现在已经收到了接收方针对他们的确认

发送方继续将发送窗口内序号 $42$ ~ $53$ 的数据封装在几个不同的报文段中发送出去

现在发送窗口内的序号已经用完了，发送方在未收到接收方发来确认的情况下，不能再发送新的数据

序号落在接收窗口内的已发送数据，若迟迟收不到接收方的确认，则会产生超时重传

4、补充说明

虽然发送方的发送窗口是根据接收方的接收窗口设置的

但在同一时刻， $\color{red}发送方的发送窗口并不总是和接!方的接收窗口一样大$ 。
网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的。
发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。

对于 $\color{red}不按序到达的数据应如何处理$ ，TCP 并无明确规定。

如果接收方把不按序到达的数据一律丢弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利,因为发送方会重复传送较多的数据。
TCP 通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再 $\color{red}按序交付上层的应用进程$ 。

TCP 要求接收方必须有 $\color{red}累积确认和捎带确认机制$ ，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。

$\color{red}接收方不应过分推迟发送确认$ ，否则会导致发送方不必要的超时重传，这反而浪费了网络的资源。
TCP 标准规定，确认推迟的时间不应超过 $0.5$ 秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认 $\texttt{[RFC 1122]}$ 。
捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。