GBN，SR与TCP可靠传输

（归纳自顶向下，考研自用）

1 GBN

在GBN当中，发送方只设置一个定时器，该定时器与当前序号=base的分组相关联，如果该定时器超时，则发送方做两件事情：①重置定时器，②重传从base到nextseqnum-1的所有分组。（因此叫做回退N帧，因为从②当中知道，此时发送方的从base和nextseqnum-1的这些分组都已经发送出去了，但是仅仅是因为为base这个序号对应的分组设置的定时器超时，就要重传从base到nextseqnum-1的所有分组。）

举例：如下图所示，本来0，1，2，3，4，5这三个分组都在发送窗口内，因此连续发送，分组0，1都顺利到达了接收方，但是分组2丢失了，因此在分组2没有被接收的时候，分组3，4，5都顺利到达了接收方，但是由于此时的expectedseqnum=2，因此接收方会把3，4，5全部都丢弃，并且每次丢弃之前会返回一个ACK1（也就是返回最后一个被正确接收的数据帧对应的确认帧）。当分组2对应的定时器超时之后，会重传2，3，4，5这四个分组，如下图。

在GBN当中，如果接收方收到一个失序的分组，会直接丢弃该分组，并且每次丢弃一个失序的分组，都会返回当前接收方按序接收到的正确的最后一个分组的ACK，就像上面的例子一样，在收到3，4，5之后，都是丢弃3，4，5并且返回ACK1，因为1号分组是接收方按序正确收到的最后一个分组。（这里就是GBN的累计确认）

2 SR

在SR当中，发送方会为每一个发送的数据帧都设置一个定时器，在接收方会接收失序的，但是在接收窗口内部的分组，并且接收方无论收到的分组是按序接收的，还是失序的分组，都会返回该分组的对应的ACK。

这里就和GBN有两点不一样：

①在GBN当中，只会设置一个定时器，该定时器与当前序号为base的分组相关联。

但是在SR当中，会给每一个发送出去的分组都设置一个定时器。

②在GBN当中，接收窗口的大小为1，如果接收到失序的分组，直接丢弃，并且返回当前最后一个正确按序接收到的分组的ACK。

但是在SR当中，接收窗口的大小大于1，如果接收到的失序的，但是落在接收窗口内部（且没有比特差错）的分组，会将该失序的分组接收，并且返回该失序分组对应的ACK。

举例如下：

如上图所示，接收窗口的大小等于4，发送窗口的大小等于4，此时发送方连续地发送了0，1，2，3这三个分组，接收方顺利地接收了0，1，但是2丢失了，3，4顺利到达。于是3，4是失序的分组，当失序分组到达接收方之后，由于该失序分组落在了接收方的接收窗口内，且没有比特差错，因此接收方也会接收3，4这两个失序的分组，并且返回ACK3和ACK4。

当接收方返回0，1的ACK0和ACK1之后，由于它们是按序到达的分组，因此当接收方顺利接收了ACK0和ACK1之后，发送窗口会依次向右滑动2格，此时4，5落在了发送窗口当中，于实发送方会连续发送4，5号分组。

当分组2对应的定时器超时之后，发送方会重传分组2。

当发送方收到ACK3之后，由于没有收到ACK2，因此发送窗口无法向右滑动。

3 累计确认

累计确认的理解容易产生一个误区，就是在GBN当中，认为累计确认是这样的“如果发送方顺序发送0，1，2分组，并且0，1，2号分组都按序到达了接收方，并且无比特错误，那么发送方只需要返回ACK2”这样的理解是错误的！！！！！

实际上累计确认不是说有一些数据分组不需要返回确认帧（例如不需要返回0，1数据分组的确认帧），而是指 “累计式的确认”，也就是说累积确认的本质是：接收方只确认 “按序到达的最后一个分组”，该确认同时意味着 “所有序号小于等于该分组的分组均已正确接收”。发送方通过这个确认值，就能知道哪些分组已被接收，哪些可能丢失。

在之前的GBN的例子当中，2号数据分组丢失以后，对于失序到达的3，4，5号数据分组，数据的接收方都返回了ACK1，因为ACK1是接收方按序到达的最后一个分组，这就是所谓的“累计确认”。

在累计确认的机制下，对于前面的“如果发送方顺序发送0，1，2分组，并且0，1，2号分组都按序到达了接收方，并且无比特错误，那么发送方只需要返回ACK2”这个例子来说，当然是可以实现的，因为发送方收到ACK2之后，因为累计确认的机制，是可以知道“2号分组是按序到达的最后一个分组”，也就是知道0，1号分组都已经到达了。但是把累计确认理解为“为了少发一些确认帧”，会忽略累计确认机制通过冗余ACK来解决丢包问题的功能。例如，如果不是接收方没有发送ACK0和ACK1，而是ACK0和ACK1在发送的过程当中丢失了，那么通过累计确认机制，发送方在收到ACK2之后，也能知道0，1号分组是被顺利接收的。

在自顶向下的所有例子当中，接收方在收到数据分组之后，都是返回了ACK确认帧的，无论是否采用了累计确认机制。

SR不采用累计确认，对于失序到达接收方，且落在了接收窗口内部，没有比特差错的分组，接收方都会返回对应的确认帧。

也就是说，在SR当中，如果接收方接收到0，2，3号分组，没有收到1号分组，那么接收方会返回ACK0，ACK2，ACK3。当发送方收到ACK3之后，并不代表3号分组以及3号分组之前的所有数据分组都已经到达了接收方。在这个例子当中，数据的发送方收到ACK3的时候，1号数据分组并没有被接收方顺利地接收。因为SR并没有采用累计确认机制，所以对于发送方发送的每一个分组而言，都必须收到其对应发ACK，才代表该数据分组被接收方顺利的接收了。

4 TCP可靠传输

4.1 TCP可靠传输机制是GBN和SR的混合体

TCP可靠传输首先不是停止等待机制，而是滑动窗口机制，其次，TCP可靠传输是GBN和SR的混合形式:

①TCP可靠传输的接收窗口大于1（这点和SR一样）。

②TCP可靠传输当中，发送方只设置一个定时器，该定时器与此时发送方第一个已发送，但是还没有收到确认的分组关联（也就是该定时器与base指向的数据帧关联，在TCP可靠传输当中，把base叫做sendbase）。（这里和GBN一样）。

但是注意：当该定时器超时之后，只会重传与该定时器关联的这个分组，也就是base指向的分组。而不是重传与该定时器关联的分组，以及该分组之后的所有（在发送窗口内的）分组。（实际上base指向的分组就是此时发送窗口当中的第一个分组，只不过在GBN当中，相当于是当定时器超时之后会重传所有发送窗口内部的分组；但是在TCP的可靠传输当中，只会重传一个分组，就是这个与定时器关联的分组。）

③TCP可靠传输当中，会接收失序到达的分组，而不是丢弃这些分组（这里和SR一样），但是当接收到失序的分组之后，和SR不一样的是，TCP收到失序分组不会返回失序分组对应的ACK，而是返回此时接收方顺序接收的最后一个数据分组。（这里又和GBN一样了，也就是在确认的时候，采用累计确认的方式）。

4.2 TCP可靠传输的接收窗口与累计确认

在上面的③当中，我们知道：在TCP可靠传输当中，TCP接收失序到达，且落在接收窗口内，没有比特差错的分组（和SR一样），但是和GBN一样，又采用累计确认的方式。

举例：发送方的窗口大小为4，接收方的窗口大小也是4。发送方发了0，1，2，3号分组，并且只给0号分组设置了定时器（TCP可靠传输当中，只设置一个定时器，该定时器与当前第一个已经发送但是还没有被确认的分组sendbase关联，在这个例子当中，开始的时候sendbase=0）。

在传输的过程当中，0，1号分组顺利到达接收方，并且没有比特差错，那么接收方依次发回ACK0和ACK1，但发送方收到ACK0之后，重置定时器，并且sendbase=1，也就是此时定时器和1号分组关联，并且发送窗口向右滑动一位，可以发送下一个0号分组。

当收到ACK1之后，重置定时器，并且base=2，此时定时器和2号分组关联，并且在收到ACK1之后，发送窗口又可以向右滑动一位，此时可以发送下一个1号分组。

但是2号分组丢失，3号分组顺利到达。那么接收方会接收3号分组，并且接收3号分组之后，由于累计确认的特性，接受方返回ACK1而不是ACK3。当发送方收到ACK1之后，而此时sendbase=2不等于1，因此发送方就知道，这个时候也是1和1之前的是按序到达的。

当定时器超时之后，接受方不是和GBN一样，重传此时发送窗口当中2之后的所有分组（也就是3，0，1），而是只重传2号分组！！

因此当重传2号分组之后，如果在重传的过程当中，下一个0号分组都已经到达了接受方了（下一个1号分组还没有到达接受方），那么当重传的2号分组到达接受方之后，在接受方，也就是2，3，0都已经按序到达了，于是，按照累计确认的规则，数据的接受方就可以发送ACK0，表示2，3，0都已经按序到达了。（这里就是累计确认，发送的是ACK0）当发送方收到了ACK0之后，就知道ACK1之前的所有的分组都已经按序到达了，因此发送窗口右移3位。

此时还有下一个1号分组还没有到达接受方，因此会设置sendbase=1，并且将此时的定时器与这个1号分组关联。如下图所示是这个例子的示意图：

以上这个例子完整的表现了以下的关于TCP可靠传输的规则：

4.3 一些有趣的情况

4.3.1 例1

如上图所示，序号为92的报文段和序号为100的报文段到达了接受方，且没有比特错误，但是序号为92的报文段的确认帧，也就是确认号为100的确认帧传的太慢了，导致它在seq=92的报文段的定时器超时之后才到达接受方，因此接收方会重传seq=92的报文段

（这里就对应了TCP可靠传输的规则：①只设置一个定时器，该定时器与当前第一个以及发出但是还没有被确认的报文段关联②当对应的定时器超时之后，只重传该定时器关联的报文段，而不是像GBN一样，会重传该报文段之后的，在发送窗口内的所有报文段。，在这个例子当中，与定时器关联的就是seq=92的报文段，而当定时器超时之后，也只是重传了seq=92的报文段，没有重传seq=100的报文段）

当seq=92重传之后，ACK=100和ACK=120依次到达发送方，而当发送方接收到ACK=120之后，就说明seq=92和seq=100的数据帧都已经被顺利的接收了，于是此时定时器实际上就可以终止了（这里就是累计确认的特点了）

当重传的seq=92的报文段到达了接受方之后，由于累计确认的特性，接受方返回此时按序到达的最后一个分组的确认帧，也就是seq=100的确认帧，如上图所示，也就是ACK=120的确认帧。

4.3.2  例2

如上图所示，这个例子也是为了解释累计确认机制，在这个例子当中，seq=92的报文段和seq=100的报文段都被接受方顺利接收了，但是ACK=100的确认帧丢失了。

首先，依据TCP可靠传输的特性，只有一个定时器，与seq=92关联。

其次，注意到在该定时器超时之前，ACK=120到达了发送方。那么依据累计确认的特性，发送方收到ACK=120的确认帧，表示ACK=120之前的所有报文段都已经被接受饭顺利接收了，因此，数据的发送方不再重传seq=92的报文段。

4.4 超时间隔加倍

就是每次重传都会把定时器的超时间隔翻一倍。

当定时器超时，可能表示此时的网络十分拥堵，导致路由器当中的分组数量太多而产生丢包。而每次定时器超时之后都把超时间隔翻倍的做法有利于减少发送方把报文段发到网络当中的频率，因此可以缓解网络的拥塞程度。

这种机制和CSMA/CD当中的机制类似。

4.5 快速重传

由于超时时间间隔加倍的机制的存在，会导致定时器的超时时间间隔越来越长。

首先考虑导致定时器超时的原因：①由于此时网络拥塞，导致排队时延大。②由于此时网络过于拥塞，路由器的缓存已经满了，因此直接丢弃分组，也就是分组直接在网络当中丢失了。

如果分组没有丢失，只是在网络当中传播的时候网络太拥塞，导致该分组可能需要在网络当中待的时间长一点，一直到定时器快要超时的时候，发送方才收到ACK，那么我们可以等一下。

但是如果某个报文段在网络当中一发出去就在前面几跳路由器当中丢失了，那么我们是否还需要傻傻的等到这个报文段对应的定时器超时之后才重传这个报文段呢？是否可以在该报文段对应的定时器没有超时之前就知道这个报文段丢失了呢？

考虑在TCP可靠传输当中，我们采用了累计确认的方式，因此可能可以通过冗余ACK的方式来知道分组确实已经丢失了。也就是说，如果发送方连续收到3个重复的ACKn，那么发送方就可以知道第n+1号分组已经丢失了。注意是收到了三个“重复的”ACKn，也就是总共收到了4个ACKn。

下面举例说明：

假设发送方需要向数据的接受饭发送0，1，2，3，4这5个数据分组。并且发送窗口和接收窗口的大小都等于4。

（1）0，1，2，3，这四个分组都在发送窗口内，因此连续地发送0，1，2，3这四个数据分组。同时，还需要设置定时器，那么在之前的分析当中，我们知道，在TCP可靠传输当中只设置一个定时器，该定时器与当前第一个已经发送，但是还没有被确认的定时器关联，因此我们知道，该定时器此时与0号分组关联。

（2）0号数据分组到达接受方并且被顺利接收。那么接收方会返回ACK0，把接收窗口右移一个分组。

（3）接收方返回ACK0，发送方收到ACK0之后，重置定时器，并且会把该定时器与1号分组关联。然后发送窗口右移一个分组，此时4号分组进入发送窗口当中，因此发送方会发送4号分组。

（4）1号分组在网络当中丢失了。

（5）2号分组顺利到达接收方，且没有比特错误。但是由于1号分组丢失，接收方没有收到1号分组就收到了2号分组，因此这个2号分组就是一个“失序”的分组。但是由于累计确认的原则，接收方只能返回此时按序到达的最后一个分组的ACK，也就是说，接收方收到2号分组之后，返回的是ACK0。

(6)3号分组顺利到达接收方，且无比特错误，那么同理知，此时接收方返回ACK0。

（7）4号分组顺利到达接收方，且无比特错误，同理，返回ACK0。

（8）发送方在1号分组对应的定时器超时之前，依次顺利接收到了3个重复的ACK0（也就是冗余ACK），因此，它就知道1号分组已经丢失了。因此在1号分组对应的定时器超时之前，发送方重发1号分组，并且重置定时器。

（9）当接收方收到重发的1号分组之后，由于累计确认的规则，因为此时发送方是按序正确收到了1，2，3，4这四个数据分组，因此会返回ACK4。并且会把发送窗口右移4个分组。

（10）当发送方收到ACK4之后，知道4号以及4号之前的所有分组都已经被顺利接收了，因此就可以把发送窗口右移4个分组了。

图片如下：在这个图当中，蓝色的框框是发送窗口，红色的框框是接收窗口