滑动窗口和流量控制

滑动窗口(效率机制)

前面博客中,总结了确认应答的策略,每发送一个数据段都要一个ACK确认应答,收到ACK应答后再发送下一个数据段.

这样的传输虽然保证了可靠性,但是大量的时间都消耗在等ACK了,使用滑动窗口就是缩短等待时间.

滑动窗口就是一次性发送一组数据,发送这组数据过程中,不需要等待ACK.就相当于一份等待时间等这一组ACK.我以4组为例…

我们把这组的大小,称为窗口.窗口越大,发送的数据就越多,效率就越高.

此时就需要等待四个对应的ACK,并且到达顺序是先后的,当2001的确认应答到达后,会立即发送5001-6000.如下:就像划过去一样,称为滑动窗口.

滑动窗口是一个形象的比喻,本质上就是发送一组数据过去.这样可以缩短等待时间,提升一定的效率,但还是没有UDP快的.

按照一组数据发送的过程中,数据可能会发生丢包.

1. 数据丢了
2. ACK丢了

此时就会进行超时重传.

数据丢了

只要1001-2000这个数据没有,就会一直索要1001这个数据,当客户端连续几次都收到这个数据后,就会明白1001这个数据丢了,此时就会重新传输1001-2000的数据.
在接收方有个缓冲区在接收数据:

如果接收缓冲区少了这一部分,就会一直索要这个数据,直到这份数据被补上了.

ACK丢了

当ACK丢了时,不做任何处理也是正确的,即使丢了1-1000的数据,但是收到了2001的ACK,表示之前发送的数据都接收到了,2001的ACK就隐含了1001ACK.
除非所有的ACK都丢了,否则,只是丢一部分ACK,对于可靠传输没有影响.

使用场景

当通信双方大规模传输数据,首选滑动窗口.
如果通信双方传输数据规模较小,还是使用超时重传来工作.

流量控制(可靠性机制)

滑动窗口的大小不能无限大了,这样可能会使接收方处理不过来,就会出现丢包,然后进行重传,反而影响了效率.

当A的生产速度很快时,B的消费速度就跟不上,接收缓冲区的数据就越来越多,最终就满了.

流量控制就是根据接收方的处理能力,来限制发送方的发送速度.
那么什么是接收方的处理能力呢? 就是接收缓冲区剩余空间的大小作为衡量指标.
如果剩余空间越大,应用程序消费数据速度就越快.
就会把接收缓冲区剩余空间大小通过ACK返回给发送方,来调整窗口大小.

16位窗口大小就表示了当前接收缓冲区的大小,当超过这个范围时,就会从选项中拿走窗口大小扩展因子,此时实际的窗口大小就是16位窗口大小 << 扩展因子.

小结

本篇总结了滑动窗口和流量控制对于TCP可靠传输机制的实现,希望有收获的小伙伴点点关注,多多支持!