论滑动窗口

最近整理桌面，发现一个尘封的笔记本，顺手翻了翻，发现之前在一个无聊的会议中随手写下的思考笔记，觉得可能对大家有用，我把它分享出来。

这个笔记叫《论滑动窗口》。

以下是笔记全文：

流量控制，就是慢接收方控制快发送方的发送速率。传输控制为什么需要流量控制呢？一般来说，是因为已接收的数据，由于上层应用没有及时取用，这些数据会占用接收缓存，因此接收方需要及时地通知发送方，“您老给我发慢点，我快收不过来了……”

接收方通知发送方的方式，就是通告一个接收窗口RWND(receive window)。接收窗口只计算当前接收缓存中连续的包占据的缓存，不关心接收方收到但不连续的包占据的缓存。 这个现象与TCP流量控制的设计原理的对应的。

那就是，TCP允许接收方反悔（后来从QUIC的设计知道，对应的英文说法叫Reneging）——接收方收到某个报文后，可以丢掉，所以即使有些包已经在接收方的缓存中了，如果这些包不连续，则发送方也无法释放其占用的发送缓存。也就是说，发送方在数据被“确认”之前，都无法释放发送缓存。这里所说的确认，并不包含SACK中报告的已接收的block，因为即使SACK报告了这些已接收的包，发送方也不会释放这些缓存。不释放缓存，在滑动窗口上的体现，就是滑动窗口无法滑动。因此，TCP协议内核实现代码中的变量unack，实际上包括了接收方已收到，但不连续的包。

这就是TCP滑动窗口设计的“原罪”！换句话说，TCP需要滑动窗口机制的原因，就是因为它的Reneging设计。这些设计，会导致丢包时，如果接收方迟迟无法收到行头的报文，就会导致滑动窗口无法滑动，产生行头阻塞（Head-of-Line Blocking）现象。

如果我们设计一个新的协议，规定不允许接收方反悔（No Reneging）的话，那么“收到”就是“收到”，在这种情况下，发送方的发送缓存是可以释放掉的。因此，这些新协议并不需要滑动窗口设计，取而代之的，是一种缓存管理的机制。具体地说，就是只要接收方报告了接收缓存中收到了哪些数据包，不论这些包是否是连续的，发送方的缓存中都可以把这些包占用的缓存释放掉。

这里，就已经没有“滑动”这样的动作了！！！由于滑动窗口机制导致的行头阻塞问题不就迎刃而解了吗？

这篇笔记的背景，是我们当时正在设计基于TACK的新型协议，我们发现流量控制还可以有另一种设计方式，即No Reneging。后来学习QUIC时发现QUIC协议也是No Reneging的。只能不谦虚地说一句，人类前进的步伐有大有小，但是方向总是惊人的一致。

转载请注明原文地址：https://blog.csdn.net/sbmye/article/details/121372245
更多网络相关知识请访问李彤的博客：https://blog.csdn.net/sbmye