最近整理桌面，发现一个尘封的笔记本，顺手翻了翻，发现之前在一个无聊的会议中随手写下的思考笔记，觉得可能对大家有用，我把它分享出来。
这个笔记叫《论滑动窗口》。
以下是笔记全文：
流量控制，就是慢接收方控制快发送方的发送速率。传输控制为什么需要流量控制呢？一般来说，是因为已接收的数据，由于上层应用没有及时取用，这些数据会占用接收缓存，因此接收方需要及时地通知发送方，“您老给我发慢点，我快收不过来了……”
接收方通知发送方的方式，就是通告一个接收窗口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协议也是No Reneging的。只能不谦虚地说一句，人类前进的步伐有大有小，但是方向总是惊人的一致。
转载请注明原文地址：https://blog.csdn.net/sbmye/article/details/121372245
更多网络相关知识请访问李彤的博客：https://blog.csdn.net/sbmye
