流量控制
复习
- 滑动窗口：允许连续发送多个尚未确认的数据
- 序号与确认：接收方用确认告知收到进度
- 超时与重传：保证数据最终被送达
TL;DR
- 发送太快会压垮接收方
- 接收方通过“通告窗口”告诉发送方自己还能收多少
- 流量控制保护的是接收方
- 它常与拥塞控制一起，共同限制发送速率
正文
滑动窗口让发送方可以连续发。可如果它发得太猛，接收方会不会被“淹”了？
会。接收方的处理能力和缓冲区都是有限的。如果发送速度长期超过接收速度，数据就会堆积，缓冲区一满，后来的就被丢掉，白白重传。
接收方说了算
解决办法是让接收方来定“你能发多少”。
接收方在每一次确认里，都会附带一个通告窗口（receive window），意思是：“我还能接受这么多字节，你先别超过这个数。”
发送方于是把对方的通告窗口，作为自己滑动窗口的上限：
- 通告窗口变小：发送方放慢，少发一些
- 通告窗口变成 0：发送方暂停，不再发送新数据
- 后来窗口重新变大：发送方再继续
通过这种“随收随报”的方式，发送速度就能自动贴合接收方的处理能力。
保护谁，是两回事
这里要分清两个容易混淆的概念：
- 流量控制：怕把接收方压垮，由接收方通告窗口来限制
- 拥塞控制：怕把网络压垮，由发送方根据网络的拥塞情况来调整
两者都会限制发送速率，但保护的对象不同：一个是端点的缓冲区，一个是途中的链路和路由器。实际运行时，发送方的实际速率，通常是这两个限制里更紧的那一个决定的。
这再次体现了网络设计的层次感：同一个“发多快”的问题，站在不同位置看，会有不同的约束，最后取最严的那条。
思考题 1
流量控制与拥塞控制，保护的对象有什么不同？
思考题 2
如果发送方无视接收方的通告窗口，一直猛发，会发生什么？
小结
知识点
- 接收方缓冲区有限，发送太快会导致丢包
- 通告窗口告诉发送方还能接收多少
- 发送方的窗口受通告窗口限制
- 流量控制保护接收方，拥塞控制保护网络
参考资料
- Wikipedia(zh)：流量控制：防止发送方压垮接收方
- Wikipedia(zh)：传输控制协议：窗口与流量控制机制
思考题答案（仅供参考）
思考题 1
流量控制保护的是接收方的缓冲区，防止它来不及处理而被压垮；拥塞控制保护的是网络本身，防止过多数据涌入链路和路由器造成拥堵。两者都限制发送速率，但护的对象不同。
思考题 2
接收方的缓冲区会很快被填满，之后收到的数据只能被丢弃。发送方发了却收不到确认，只好一遍遍重传，既浪费带宽又拖慢传输，整体效率反而更差。所以无视通告窗口，最终损害的是自己。
协议
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
封面图
设计师 | 南国微雪