流量控制

流量控制解决的是：发送方不能把接收方压垮。

接收方收到数据后，要先放入接收缓存，再交给上层处理。若发送方连续发送太快，接收缓存可能被填满。缓存满了以后，即使后续数据在链路上传输时没有误码，接收方也可能无法接收。

900

流量控制不等于差错控制。差错控制关心数据是否出错；流量控制关心接收方是否有能力继续接收。

问题 发生原因 结果
差错控制 信道干扰、噪声、误码 数据内容不可靠
流量控制 发送过快、接收缓存或处理能力不足 正确到达的数据也可能被丢弃

接收缓存和发送限制

流量控制的核心是接收方让发送方知道自己还能发多少。

接收方能接收多少，取决于：

  • 接收缓存还有多少空位。
  • 已收到的数据能否及时交给上层。
  • 协议允许接收方同时接收多少个未交付数据。

发送方要受限制：

  • 不能无限制连续发送。
  • 已发送但未确认的数据要占据发送窗口。
  • 窗口满时，即使发送方还有数据，也必须等待确认或窗口更新。

停止等待是最保守的流量控制

停止-等待方式中，发送方每发送一个数据，就停下来等 ACK。

900

从窗口角度看：

$$
W_T=1,\quad W_R=1
$$

发送方同一时刻最多只有一个未确认数据在路上，接收方同一时刻只需要处理当前期待的数据。这样几乎不会给接收方造成缓存压力，但信道利用率很低。

滑动窗口是更一般的流量控制

滑动窗口允许发送方连续发送多个数据，但用窗口限制“已经发送、尚未确认”的数量。

窗口大小决定了流量控制的松紧：

窗口较小 窗口较大
接收方压力小 更能填满信道
发送方等待多 未确认数据多
信道利用率可能低 缓存和编号压力更大

窗口不是越大越好。窗口过小会浪费链路，窗口过大可能让接收方处理不过来，也可能让有限序号空间发生新旧数据混淆。

与可靠传输的关系

流量控制和可靠传输经常使用同一套窗口机制，但它们的目标不同。

  • 流量控制使用窗口限制发送速度。
  • 可靠传输使用确认、编号、缓存和重传保证交付结果。

因此可以这样理解：窗口本身先限制“能发多少”，在此基础上再配合 ACK、超时和重传处理“发出去后是否正确到达”。

可靠传输机制见 Reliable-Transmission；更一般的滑动窗口协议见 Sliding-Window。