实现可靠数据传输的主要机制

实现可靠数据传输不仅涉及到传输层，还涉及到应用层和链路层。以TCP协议为例，TCP协议提供可靠数据传输，然而网络层不提供可靠数据传输，而是尽最大努力交付，因而，如何在不可靠传输的下层上边实现可靠数据传输的上层是一个复杂的问题。

图1 可靠数据传输：服务模型和服务实现

首先考虑最简单的情况：可靠的传输频道是完美的，不会出现任何bit错误或者顺序错误。在这种情况下，用有限状态机（FSM）来表示可靠的协议如图2.

图2 传输完全可靠情况下的协议

如图2所示：

发送端上层(应用层)调用rdt_send(data)方法，该方法包含两个步骤

1)      将数据（data）封装成分组（packet）

2)      将分组发送给传输频道(网络层的不可靠传输通道)

接收端下层(网络层)调用rdt_rcv(packet)方法，该方法包含两个步骤

1)      将数据从分组中提取出来

2)      将数据分发到对应进程

上面假定了传输过程中不会发生任何错误，但是现实情况下，传输过程中出错不可避免。

因而，这里考虑会出现bit错误(但顺序是正确的)情况下的可靠传输协议。

       这里我们先介绍一下ARQ协议。ARQ协议是一种著名的基于重传的可靠传输协议，主要拥有以下能力来处理bit错误

1)      错误探测，使得接收端能够探测到数据传输发生了错误。比如UDP使用网络校验和来实现这一目的。即发送一些数据之外的bit来实现对比从而判断出错发生。

2)      接收方反馈，使得发送方能够知道接收方的状态。通过发送积极的确认(ACK)和消极的确认(NAK)，从而实现发送方与接收方的状态确认。

3)      重传机制。出错的分组将进行重传。

图3 会出现bit错误情况下的可靠传输协议

如图3所示：发送端有两个状态，等待上层应用调用状态和等待接收方发送确认消息状态。发送端将上层数据封装成分组(包含数据和校验字段)，发送给接受方，进入等待确认消息的状态。根据接收方发来的确认分组，可以分为一下两种情况。

1)      接收到了确认分组并且确认消息为积极确认。这种情况下发送端知道接收端已经正确接收到了发送分组。于是发送端进入等待上层应用调用的状态。

2)      如果接收到了确认分组然而确认消息为消极确认。发送端重传最后的分组，然后继续等待接收端发送确认消息。

发送端在等待确认消息时，不能从上层应用中获取数据，发送数据。接收端根据数据是否发送bit错误，分为两种情况处理。

       这种协议事实上存在着很大的缺陷——没有考虑到确认分组出现错误的可能性。解决这个问题的一种简单但广泛使用的方法是：在数据分组里增加一个新的字段，该字段记录了发送端发送的分组数据的序列号。因而，接收端只需要根据序列号就能知道该分组是不是重传的分组(如果是重传的分组，就会存在两个序列号一样但是时间戳不一样的分组)。

       如果数据传输频道不仅可能出现bit 错误，还存在丢包的可能。在这种情况下，需要考虑：

1)      如何监测丢包的发生

2)      发生丢包后该如何处理

不论是发送端发送的分组还是接收端发送的确认分组发送了丢包，发送端最终都不会收到任何回复。因此，发送端在等待足够长的时间后，便能够确认发生了丢包，于是进行数据重传就行了。需要进一步考虑的就是：如何确定一个合适的等待时间以确定丢包？一般来说，发送端至少需要等待一次往返时间(RTT，需要考虑在中间路由中的缓冲时间)+接收端处理分组的时间。如果由于某些原因发送了很长的延迟，虽然数据分组和确认分组都没有丢失，发送端还是重传数据，因而造成了重复的数据分组，这个问题可以用之前提到的序列号解决。计算等待时间功能有一个倒计时计时器完成。

综上：实现可靠数据传输需要考虑解决的问题主要包括：

1)      数据bit错误

2)      数据包顺序出错

3)      丢包

对应的解决机制有：

校验和、序列号、计时器和确认分组(ACK)。

总结这些机制的使用与作用如下表所示：

机制	作用
Checksum	检测一个传输分组是否发生了bit错误
Timer	实现分组的超时重传
Sequence Number	通过对数据流标记序列号，接收端可以监测丢包的发生，判断是否存在重复的分组
Acknowledgement	接收端通过确认分组通知发送端分组已经接收，并传递已经接受的数据的序列号
Windows Pipelining	提高停止-等待模型的发送利用率，控制网络拥塞

 

 

 

参考资料：《计算机网络 自顶向下方法》第六版