TCP窗口大小与TCP拥塞控制的关系

Question

我是否纠正了TCP receive window(它是发送方的send window )与TCP立方拥塞控制无关？TCP receive window仅仅是TCP 流量控制的一个属性？

Answer 1

首先要实现的是TCP窗口大小和往返时间( RTT )限制吞吐量:每个RTT只能传输一个窗口大小。

本质上，对于较大的RTT (延迟)，您需要一个比较小的RTT更大的窗口来实现相同的吞吐量。如果你不能增加窗口，你就不能充分利用带宽。这就是为什么带宽延迟产品对于在网络规划中建模吞吐量场景非常重要的原因。

因此，拥塞控制的工作方式是相反的:由于启动缓慢，窗口以中等大小启动，并且假设有足够的带宽，则会加快速度。

在某个时候，在途中的某个地方，一个端口的容量是到达的，数据包不能立即被转发。他们需要排队。他们在路上花了更多的时间，所以ACK开始迟到了。发送者测量的RTT上升。

响应填充缓冲区，->增长RTT，窗口再次减少。发送速度慢，队列空，RTT再次下降。作为回应，窗口被允许增长，开始循环。

从理论上讲，这听起来很简单。在实践中，您必须微调精确的响应机制。请记住，TCP过去只工作在只有几个1000位/S的慢速串行调制解调器上，今天运行在多千兆/S线(几乎)上--这很容易达到7甚至8个数量级！

这就是BIC和立方体的作用所在:传统的拥塞控制，即使使用窗口缩放，也有其局限性。基本上，它在一边的拥塞和另一边的吞吐量低于潜在带宽之间振荡。

BIC和立方体试图用二次或三次函数对通道的确切拥塞行为进行建模，而不是直到拥塞结束，然后再减少阻塞，这样就可以在拥塞开始之前，在“甜蜜点”运行一个通道。模型参数连续调整为反馈参数，使模型在信道变化时发生变化。