曲径通幽论坛

标题: 简单流控制协议(PAR 及其增强型) [打印本页]

作者: beyes 时间: 2013-1-16 01:07
标题: 简单流控制协议(PAR 及其增强型)
TCP 和 UDP 的一个最大区别就是“质量控制”。UDP 只是将消息发送出去，而无需再理会；而 TCP 则是小心的跟踪它所发送的数据以及发生在数据身上的事情。对于 TCP 主要讲究两点：
可靠性 ：确保数据实际能到达目的地，如果数据一时没法到达，那么要求能探测到这种意外，并且重新发送数据。
数据流控制 ：控制发送数据的速率，防止将接收端被“淹没”掉。
完成这些任务，就会涉及到一个重要概念 --- ”滑动窗口“，也可以称之为”滑动窗口应答系统“(sliding window acknowledgment system)。毫不夸张的说，如果能够理解滑动窗口的工作原理，那么了解 TCP 中其它的事情就不太费劲了。

不可靠协议所带来的问题：缺少反馈机制
不可靠协议的工作原理如下图所示：
[attach]1210[/attach]
像上图，不可靠协议工作时，对于所发出的消息不再理会，如果消息成功送达最好，否则丢失也就丢失了。

如果希望知道发出去的消息是否成功到达，那么一个简单的方法就是让接收端在收到消息时，给发送方返回一个确认的信息；如果接收方没有收到该确认信息，那么他就会重新发送消息。当然，发送端不可能无限等待确认消息的到来，他应该还要具有一个定时器，如果在超时未收到应答信息，才重发消息。这种思想的工作原理如下图所示：
[attach]1211[/attach]
上图所示可靠性技术很简单。设备A 每次发送消息的同时都会启动一个定时器，当设备B成功接收到消息时，就会发回一个应答；如果消息丢失，且定时器超时，那么就会重新发送消息。这种技术虽然简单，但每次只发送一次数据，这样的效率就比较低下了。

这里，称呼上面的技术为 PAR (Positive Acknowledgment with Retransmission) ，即可重传的这正向应答。

PAR 技术在交换少量数据或交换数据并不频繁的的网络中被广泛使用。

由于 PAR 只能一次发送一条消息，因此效率较低。可以给每条要发送的消息增加一个 ID 头部，以标志该表消息的身份(比如 Message#1， Message#2，Message#2 中的 #1, #2, #2 就是用来表明消息身份的消息头)，而接收端也可以分别响应这些消息。这样一来，发送端就可以一次发送多条消息了，对应于每条消息，也会有一个相应的定时器；对于发送方来说，这通常这不会有多大的负载问题。然而，当我们站在接收端的立场来看，如果发送设备不止一个(比如 10 个或更多)，并且每个设备一次都发送了许多消息，那么这势必给接收端造成很大的处理压力。为了解决这种矛盾，我们可以让接收端在应答时给发送端再回应一个“限制”信息，这相当于接收端对发送端说“我现在一次只能处理你XX条消息”。这样做，不但保证了数据的可靠性，而且还对数据的发送速率也进行了控制。工作原理如下图所示：
[attach]1212[/attach]
上图描绘的情景是：
首先，发送端本身的发送限制是一次 2 条消息。
一开始，Device B 收到 #1 和 #2 这两条消息，并将其放入自己的缓冲区。
接着，Device B 处理 #1 消息，并发送 ACK#1 和 limit = 2 表示应答，并且告知 Device A 它现在一次可以处理 2 条消息。
Device A 收到应答后，发送 #3 消息。
Device B 收到 #3，此时缓冲区中有 #2 和 #3 两条消息。
Device B 处理 #2 消息，并发送 ACK#2 和 limit = 2 表示应答。
Device A 收到应答后，发送 #4 消息。
Device B 收到 #4 ，此时缓冲区中有 #3 和 #4 两条消息。
Device B 发送 ACK#3 和 limit = 1。这说明，Device B 现在只能处理 1 条消息(#3)，因此 #4 不被系统处理而是被丢弃。
Device A 收到此应答，但不能收到上次所发送的 #4 消息的应答；由于 limit 等于 1 的缘故，它也只能等到定时器超时后再次发送 #4 消息。
超时时间到，Device A 发送 #4 消息。
Device B 收到 #4 消息，并做了处理，然后发送应答 ACK#4 以及 limit = 2 。
Device A 这时又可以一次发 2 条数据了(#5 和 #6) 。

就是这样，Device B 通过 limit 控制了来自 A 的数据流。

欢迎光临曲径通幽论坛 (http://www.groad.net/bbs/)