传输层可靠传输重传与确认停止等待协议工作原理

谈谈你对停止等待协议的理解？

停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认，在收到确认后再发下一个分组。

在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。主要包括以下几种情况：无差错情况、出现差错情况（超时重传）、确认丢失和确认迟到、确认丢失和确认迟到。

TCP会将消息拆分为许多segment的段，TCP必须保证每个发送的segment段，一定会到达对方。怎么保证呢，就通过重传与确认。

下面就介绍重传与确认这样一个思想如何演化为滑动窗口的，以及演化为滑动窗口之后，就会定义TCP中的序列号，以及确认序列号。

报文有可能丢失

设备A向设备B发送消息，连续发送了4条消息，如果第三条消息丢了之后，该怎么办呢？

PAR：Positive Acknowledgment with Retransmission

第一个简单的方法就是使用定时器来重传，发送第一个消息的时候，我会启动一个定时器，第一个消息没有发送完是不能发送第二个消息的，直到收到了B发送过来的确认之后，而且在超时定时器时间之内收到了，我就可以发送第二个消息。

发送第二个消息的时候，我又重新启动了定时器，如果在规定的时间内，没有收到第二个消息的确认，那么我就会重新发第二个消息，重发的时候就会重新修正定时器，重启定时器，这样就简单的完成了重发与确认。

这样效率低下，第一个消息没发完的时候，我是不能发第二个消息的，我必须一个一个消息这样的发，串行的效率非常的低下。

提升并发能力的 PAR 改进版

改进之后将消息标记#1 #2，当设备b来回传消息的时候，它也要明确的说我确认了是哪个消息，是第一个消息#1还是第二个消息#2呢，他必须写的很清楚，这样就可以并发的去发大量的消息了。

每个消息都有标识，#1 #2 #3，到#4的时候丢失了，这个时候定时器发现#4没有收到确认帧，我就要重发我的4号，后面4 5 6以此类推。

这里有个问题，我的B的处理能力和内存都是有限的，那么我必须限制device A，不能无限制的去发送，所以要通过limit方式去告诉它我还有几个缓冲区，我只有两个缓冲区，你只能给我发送两个消息，不能再给我发送第三个消息。

这种改进的PAR并发能力是比较强的，但是和我们的滑动窗口还是差别很大的，因为这里只是在标识消息，每一条报文和segment的段，有一个编号，但是TCP当中这里的序列号是针对每一个字节的。

Sequence 序列号/Ack 序列号

设计目的：解决应用层字节流的可靠发送

跟踪应用层的发送端数据是否送达
确定接收端有序的接收到字节流

序列号的值针对的是字节而不是报文

TCP 协议是如何保证可靠传输的？

1. 数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据。
2. 对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序，然后才交给应用层。
3. 丢弃重复数据：对于重复数据，能够丢弃重复数据。
4. 应答机制：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒。
5. 超时重发：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
6. 流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议。

可靠传输的工作原理

TCP可靠传输的实现-停止等待协议
连续ARQ协议和滑动窗口协议-改进的停止等待协议

上面是两种可靠传输的实现方法，第一种是停止等待协议，第二种是改进的停止等待协议也就是连续ARQ协议和滑动窗口协议，这两种协议相结合组成的改进的停止等待协议。

现在使用的是连续ARQ协议和滑动窗口协议，只有知道停止等待协议才能知道连续ARQ协议和滑动窗口协议的优点。

理想的传输条件特点

理想的传输条件有以下两个特点∶

1.传输信道不产生差错。（不会出现乱序的现象，或者丢包）

2.不管发送方以多快的速度发送数据，接收方总是来得及处理收到的到数据。（接收方处理不过来，让发送方发慢一点，这个时候就需要TCP协议来实现可靠传输和流量控制）

在这样的理想传输条件下，不需要采取任何措施就能够实现可靠传输。然而实际的网络都不具备以上两个理想条件。必须使用一些可靠传输协议，在不可靠的传输信道实现可靠传输。

停止等待协议

“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。
全双工通信的双方既是发送方也是接收方。

为了讨论问题的方便，我们仅考虑A发送数据，而B接收数据并发送确认。因此A叫做发送方，而B叫做接收方。

发送的时候丢失

A发送一个报文，B收到之后给个确认，说自己收到了，然后就开始发第二个，同理确认之后发送第三个。

A发送的每一个报文B都能够收到，同时确认报文A也能够收到，没有任何丢包的情况，这是无差错的情况，这就是停止等待，发一个就停止不发送第二个，等着第一个确认收到了才发第二个，这就叫做停止等待。

如果A发的时候数据包丢了，A发完数据包还不能丢掉，还需要等着，等了一个往返时间，还没有收到，那么就认为丢了，那么再将第一个重新发一遍，只要没有收到你的确认就重发，就认为你没有收到，这个重传是超时之后就自动重传了，不需要告诉A没有收到。(去的时候丢了数据包，会发生自动重传)

重传之后收到返回确认收到了，然后就按照上面的继续发第二个。

确认丢失和迟到

A发送的时候B收到了，但是确认丢了，这个时候A等了一会，到底收到没A也不知道，超时之后自动再重传一遍，这样B就重复收到了，那么就会丢弃一个重复的这个，然后再给他一个确认，那么就应该让A发送第二个了。可以看到确认丢了之后也会重传。

还有一种是确认迟到，A发了一个，确认的路可能走的比较远，在超时之后觉得应该到了，但是还是没有到，然后再发一遍，然后收到重复的M1那么就丢弃重复的，然后就给他发个确认，然后就继续发第二个数据包了，发完第二个数据包，发现第一个数据包的确认来了，收到了迟到的确认，它什么都不做，就直接丢掉了。

上面就是丢包之后相应处理，网络不可靠那么也能够保证每个数据包都能够收到，没有收到就来回重传即可。

反正重复确认和重复的包都是丢弃的

注意

在发送完一个分组后，必须暂时保留已发送的分组的副本，以备重发。（利用上面的方式发送端每发送一个数据包，不能够丢，还等着对方告诉收到之后才能删除掉发送第二个。）

分组和确认分组都必须进行编号。（发送的每一个包都必须有编号，要不然接收端怎么知道呢）

超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。

自动重传请求ARQ

通常A最终总是可以收到对所有发出的分组的确认。如果 A 不断重传分组但总是收不到确认，就说明通信线路太差，不能进行通信。使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。（如果发送端一直发，一个确认也回不来，那说明这个网不行）

像上述的这种可靠传输协议常称为自动重传请求 ARQ

（Automatic Repeat reQuest）。意思是重传的请求是自动进行的，接收方不需要请求发送方重传某个出错的分组。