5.4.1 停止等待协议

• 全双工通信的双方 既是 发送方 也是 接收方。
  但本文仅考虑A发送数据而B接收数据的情况

• 停止等待
  每发送完一个分组就停止发送，等待对方的确认。
  发送方收到确认后再发送下一个分组。

• 重传计时器
  当TCP发送一个报文段时，就会创建一个 针对这个报文段的重传计时器 。
  若在 重传计时器截止时间 到来之前就收到了 对此特定报文段的确认 ，就撤销此计时器。
  若在收到 对此报文段的确认 之前 计时器截止期 到，则会重传此报文段，并将计时器复位重新计时。

1、无差错情况

A发送分组M₁，发完就暂停发送，等待B的确认。
B收到了M₁就向A发送确认。
A收到了对M₁的确认后就再发送下一个分组M₂。
同样A在收到B对M₂的确认后再发送M₃。

2、出现差错

B收到M₁时检测出了差错，则丢弃M₁，其它什么都不做（不通知A收到有差错的分组）。
或者M₁在传输过程中丢失了，B不知道，什么都不做。
上述两种情况，B不会向A发送任何信息。
但是A只要超过了一段时间未收到B的确认，那么A就认为刚才发送的分组丢失了，因而重传前面发送过的分组，即 超时重传。
超时重传需要在每发送完一个分组时设置一个 超时计时器 ，若在超时计时器到期之前收到了对方的确认，就撤销这个超时计时器。
另外要注意以下3点：
1、A在发送完一个分组后，必须要暂时保留 已发送的分组的副本 ，以备超时重传时使用，收到相应的分组确认后再清除这个暂存的副本。
2、分组和确认分组都必须进行编号，如此才能确认哪一个发送出去的分组收到了确认，而哪一个分组还没有收到确认。
3、 超时计时器设置的重传时间 应当比 数据在分组传输的平均往返时间 更长一些。
但若重传时间设定的很长，那么通信的效率会很低；若设定的很短，则会导致不必要的重传，浪费了网络资源，降低了效率。
重传时间的设定也是很复杂的。
4、不含数据的确认报文段不消耗序号。
如下图
#2，#4，#6，B的三个确认序号都是5，且都不带数据。
#7 的确认带20Byte数据，序号是5，但是下一次B的发出的报文段序号就是25了。

3、确认丢失

B所发送的对M₁的确认 丢失。
A在设定的超时重传时间内未收到确认，并无法知道是自己发送的分组出错 / 丢失了，还是B发送的确认丢失了。
A在超时计时器到期后就要重传M₁。
若B又收到了重传的分组M₁，此时会采取 两个动作 ：
1、丢弃这个重复的分组，不向上层交付；
2、向A发送确认。不能认为已经发送过确认就不再发送。A之所以重传M₁就表示A没有收到对M₁的确认。

4、确认迟到

传输过程中未出现差错，但B对分组M₁的确认迟到了。
A超时计时器超时，超时重传分组M₁；B会受到重复的M₁，丢弃重复收到的M₁，并重传确认分组。
A会受到重复的确认。A在收下这个重复的确认后就丢弃。

---

• 通常A最终总能收到对所有自己发出的分组的确认，若A不断重传分组但总是收不到确认，
  则表明通信线路太差，无法进行通信。

• 类似于上述机制的可靠传输协议叫作自动重传请求ARQ
  重传请求是自动进行的，接收方不需要请求发送重传某个出错的分组。

• 通过上述的确认和重传机制，即可实现在 不可靠的传输网络 上实现 可靠的通信 。

• 在TCP传送数据时，没有规定最大重传次数，而是通过设置一些计时器来解决有关传输失败的问题。
  而以太网规定重传16次就认为传输失败。

• 停止等待协议的优点
  简单

• 停止等待协议的缺点
  信道利用率太低。
  
  A发送分组的需要时间T_D（分组长度 / 数据率）。
  假定分组到达B后，A和B处理分组的时间忽略不计；B立即回送确认，B回送确认分组的T_A。
  可以看到：一个发送确认周期，收发双方大部分时间都在互等且信道空闲，效率很低。
  那么 信道利用率 ：
  

• 由此改进得到
  连续ARQ协议 和 滑动窗口协议