滑动窗口

复习

　　有了序号、确认和重传，可靠性算是有了。但如果每发一段就停下来等确认，网速再快也跑不起来。

　　先看最朴素的“停等”方式：发一段，等它被确认，再发下一段。

　　问题很明显：大部分时间都花在等待上。 数据在路上跑，确认也在路上跑，而发送方只能干等。链路越长、往返时间越大，浪费越严重——明明还有带宽，却因为“一次只发一段”而空着。

　　滑动窗口的思路是：别停，连续发。 只要窗口没满，就一路发下去；已经发出、尚未确认的数据，可以有好几段同时在路上。

　　这里的窗口，指的就是“已经发出、但还没被确认”的那一段序号范围。它像一扇推拉窗，框住了当前“允许在途”的数据。

　　当发送方收到新的确认，说明窗口左缘的数据被对方收下，整扇窗就可以向前滑动，露出新的可发空间。

　　窗口越大，允许同时在途的数据越多，吞吐量越高；窗口越小，就越接近停等。所以窗口大小，直接决定了“能跑多快”。

　　那么，窗口能无限大吗？不行。发送方发得太快，接收方可能来不及处理；网络本身也可能受不了。于是窗口会受到两方面的限制：接收方的接收能力，和网络的承载能力。前者就是下一章的流量控制，后者则属于拥塞控制。

思考题 1

　　为什么“发一段、等确认、再发下一段”的效率很低？

思考题 2

　　滑动窗口里的“窗口”，具体指的是哪一段数据？

　　因为发送方在等待期间无事可做：数据在途中、确认也在途中，带宽被闲置。往返时间越长，浪费越大。停等没有利用“可以同时在途多段数据”这一点。

　　它指的是已经发送出去、但尚未被确认的那一段连续的序号范围。窗口左缘之前是已确认数据，右缘之后是尚未发送的数据。收到确认后，整个窗口向右滑动。

设计师 | 南国微雪