3.3可靠数据传输的原理

1. 对数据传输的不可靠性研究采用渐进式的。(可靠传输–>比特差错–>比特差错+分组丢失–>…)
2. 双向的数据传输看作两个单向的数据传输，因此只考虑单向数据传输。
   二.分析过程

rdt1.0:在可靠信道上的可靠数据传输

此时，下层的信道是完全可靠的。即：

无比特出错
没有分组丢失

发送方(send,以下简称S)和接受方(receiver,以下简称S)的操作：

S将数据发送给下层信道，R从下层信道接受数据。双方基本不做与rdt有关的操作。

rdt2.0：具有比特差错(不考虑ACK/NAK出错)的信道

此时，下层的信道可能出错：如0变成1，即比特翻转。需要用校验和来检验比特差错。

怎样处理错误和恢复正常：

1. 确认(acknowledge,ACK):R显式的告诉S分组已经被正确接收
2. 否定确认(no acknowledge,NAK):R显式的告诉S分组发生差错，S收到NAK后，S重传分组。

rdt2.0中的新机制：

1. S进行差错控制编码，缓存(保存副本，以便检错重传)。
2. R使用编码检错
3. R要反馈：发送ACK,NAK到S。
4. S收到反馈后作相应动作(收到ACK，发新的；收到NAK，重发)

rdt2.0的缺陷：若ACK/NAK出错，怎么办？如发的ACK/NAK是无法识别的内容，S就不知道发生了什么事情。S自然也不知道怎么做了。为此，出现了rdt2.1.

rdt2.1:具有比特差错(ACK/NAK可能出错)的信道

针对rdt2.0中ACK/NAK出错，引入序号机制，即在S的每个分组加个序号。
编号占用一位，分组编号方式：0,1,0,1…如此交替。

当ACK/NAK出错，比如无法识别时。S会重传当前分组。此时分为两种情况。
ACK出错：重传导致分组重复，由于分组有编号。重传导致相邻两个分组编号一样，R丢弃即可。
NAK出错：重传刚好传的是R需要的分组。

S和R新增的操作：
S:

1. 在分组中加入编号，用一位编号即可。0/1
2. 检查ACK/NAK是否出错(需要EDC)
3. 记录当前分组的编号是0还是1。

R:

1. 必须检测当前收到的分组是否重复。R有一个状态位，记录当前希望接收的分组时0，还是1.

注意：R并不知道S是否正确收到了ACK/NAK。没有对ACK/NAK的确认，即无确认的确认。但是，R可以通过S发送的分组来获取S是否收到ACK/NAK.如：S发送分组(packet,记为pkt)pkt0，R发回ACK，若S发送pkt1，则说明S收到正确的ACK;若S发送pkt0，则说明S未收到正确的ACK.

对这种R发生一个分组，然后等待R的应答(一次只有一个等待确认的分组)的协议称为停等协议(Stop and Wait Protocol).

rdt2.2：无NAK的协议

功能同rdt2.1，但只使用ACK(ACK要编号:ACK0,ACK1,ACK2…)
R对最后正确接收的分组发ACK,以替代NAK。即当前分组需要发NAK时，就发上一个正确接收的分组的ACK.
当收到重复的ACK时(当前分组传输出错)，发送放重传当前分组。
这中机制为之后一次发送多个数据单位做了准备,其优点在于：
1.一次能发多个数据单位。
2.无NAK,确认机制简单了,协议也得到简化。

rdt2.2R和S做的操作和rdt2.1相同。只不过当前分组出错，R发送给S的时上一个正确接收的分组的ACK

rdt3.0:具有比特差错和分组丢失的信道

分组在传输时，若分组太多，遇到路由器，会排队等候处理，由于路由器缓存有限，队满时，会丢弃分组。因此，下层信道还可能出现分组丢失(数据或者ACK)的情况。
若分组在传输时丢失，则R会等待这个分组，S会等待这个分组的ACK。这可能导致死锁。但检验和，分组编号，ACK,重传这些机制无法处理此问题。
因此引入超时重传机制。设置一个合理的时间(通常大于RTT：超时时间太短会导致传送的ACK和分组大量重复，效率低，因此设置一个合理的超时时间很重要),当超过此时间S未收到ACK，则重传当前分组(发送放设一个倒计数定时器)。由此导致的分组重复问题可以由分组编号解决。

rdt3.0的缺陷：由于一次只发一个分组，就等待确认。对于链路容量大(链路中能装很多比特，长距离传输)的情况，它的性能很差。这时网络协议本身限制了网络物理资源的利用。(类似高速公路一个时间段里只有一辆车在跑，而大多数地方无车。此处时间段指分组的往返时延RTT)

为了弥补rdt3.0的缺陷，引入流水线协议(包括GBN协议和SR协议)。而为了分析流水线协议，引入滑动窗口协议。

• 流水线协议

• 概念：允许发送方在未得到对方确认的情况下一次发送多个分组。
• 实现条件：

• 需要用更多的bit去表示分组的序号

• n位表示分组序号，则GBN协议的$$SR<=2^n-1$$而SR协议的$$SR<=2^{n-1}$$
  SR是发送窗口大小。

• 在R和S要有缓冲区。

• S缓冲的必要性：用于超时重传，检错重传
• R缓冲的必要性：上层用户取用数据的速率不等于收到的数据速率；以及收到错误乱序的分组。

• 两个流水线协议:回退N步(Go-back-N,GBN)协议和选择重传(Selective Repeat,SR)协议。

滑动窗口(slide window)协议

关键概念

• 发送缓冲区

• 形式：它是内存中的一个区域，落入缓冲区的分组可以发送
• 功能：用于存放已发送，但还没得到确认的分组
• 必要性：需要重发时可用

• 发送缓冲区的大小：它决定一次最多可以发送多少未经确认的分组

• 停等协议=1
• 流水线协议>1,需设合理的值，不能太大，链路利用率不能超过%100

• 发送缓冲区中的分组的状态

• 未发送的：落入发送缓冲区中的分组，可以连续发送出去。
• 已经发送出去，等待确认的分组：发送缓冲区的分组只有得到确认，才能删除。

发送窗口

发送窗口的相对移动

如下图所示：第二行中上下有绿色的格子对应发送缓冲区，大下是5.而此时0，1，2发送出去未收到确认，3，4未发送出去。则发送窗口是红色格子的对应的窗口。由图：0<=发送窗口的的下<=发送缓冲区的大小。此时，发送缓冲区范围界定：后沿==发送窗口沿，结合发送缓冲区大小可以定上沿。

事实上，S收到分组确认后，是发送缓冲区不动(绿框)，分组所在的窗口左移(真正滑动过程)。这等效于窗口不动，发送缓冲区向右滑动(相对滑动)。所以之后：发送窗口滑动=发送缓冲区右移

发送窗口发送分组时的移动

• 初态：没有发送任何一个分组。

  • 后沿=前沿
  • RW=0(发送窗口大小为0)
    

• 发送窗口前沿移动:但不能超过发送缓冲区的范围。

  • 0发送出去，前沿到的1的开始处。
    
  • 1，2，3，4都发送出去，此时前沿不能再移动。
    

• 发送窗口后沿移动：条件是收到确认。移动的极限不超过前沿，结果是发送缓冲区会包含住新的分组，此时来了分组就可以发送。如下图：此时窗口5若来了分组，即可发送出去。
  

接收窗口—区别GBN和SR

接收窗口(recieving window,以下简记RW)=接收缓冲区，用于控制那些分组可以接收。只有收到的分组序号落在接收窗口内(和接收窗口包含的分组序号有对应）才接收，否则丢弃。

• RW=1,对应GBN协议，只能顺序接收。
  • 接收串口在0处,收到0号分组，正常接收，窗口向前滑动一个
  • 此时，若收到分组2，则丢弃，发送ACK0,窗口不动。

• RW>1,对应SR协议，可以乱序接收。
  • 先后收到有序的分组0，1。发送ACK0,ACK1.窗口向前滑动两个。
  • 此时收到分组3,4,5。则发送ACK3,4,5但窗口不滑动。分组也不交付。
  • 当收到分组2时。发送ACK2,窗口滑动4个，对分组排序交付。
    
• 上述两者的总结：
  • RW的滑动
    收到RW需要的最低序号的分组，RW滑动。收到高序号的分组(还有低比他低的分组没有的)缓存但不交付(rdt不允许失序)，RW不滑动。
  • R发送的确认形式
    RW=1,发送连续收到的最大的分组的确认(累计确认)
    RW>1,收到那个分组，就发哪个分组的确认(非累计确认)
    (累计确认：收到ACK2,则说明ACK0,AKC1都已经收到)

发送窗口和接收窗口的互动

主要针对SW>1的GBN(RW=1)协议和SR(RW>1)协议

• 正常情况(GBN和SR)的下收发双方的窗口互动
  (注意：下图第一个框中应该是推动SW前沿向前移动)
  
• 异常情况的下收发双方的窗口互动

  • GBN协议收到乱序分组
    

  • SR协议收到乱序分组
    

GBN和SR的对比

• 相同点：S一次可以发送多个未确认的分组(RW>1)。
• 不同点：