过量发送会影响共同路径

链路和路由器处理能力有限，多条通信共同使用它们。数据进入速度长期超过能够有效传送的速度时，会增加排队与丢失；更多重传还可能继续挤占容量。

拥塞控制调节进入网络的负载，接收窗口则保护接收方能处理的范围。远端缓冲仍有空间，并不代表中间路径不会拥塞，这两类约束可以同时生效。

参考：[1] [2]

从确认与丢失调整在途数据

TCP拥塞窗口限制尚未确认的数据量，经典算法包括慢启动、拥塞避免以及丢失后的恢复。发送方通过确认推进、丢失或超时等观察调整行为，而不是预先知道所有路由器的空余容量。

QUIC也定义丢失检测和拥塞控制，但报文编号、确认及协议组织方式与TCP不同。采用UDP承载不等于自动绕过拥塞责任，所用传输仍需要自身的控制机制。

丢包不是唯一的拥塞信号。经典ECN在端点协商支持后，让路由器可给具备ECN能力的报文设置CE标记并继续转发；TCP接收端用ECE把标记反馈给发送端，发送端作拥塞响应，再用CWR表示已经作出响应。这样可以在不靠丢弃该报文的情况下传达拥塞，但不保证以后绝不丢包，也不代表收到标记就可继续原速发送。这是RFC 3168的经典TCP机制，不能概括所有后续ECN扩展的精细反馈规则。

参考：[2] [4] [5]

算法选择并不只有一种

CUBIC使用三次函数组织拥塞窗口增长，RFC 9438在既有实现和研究基础上给出标准轨规范，并更新RFC 5681的相关允许行为。经典线性增长的描述不能代表所有现行TCP算法。

评价算法不能只看某条独享链路的最高速度。遇到延迟变化、其他流量或链路损失时，稳定性与共享方式同样重要；拥塞控制也不保证每个应用获得固定带宽或时限。

参考：[1] [3]