但是，如果我们从协议中消除它会怎样。

那么它就不会是 TCP。

流控的要点是接收主机有一个缓冲区来接收数据，而且是固定大小的。接收方告诉发送方确认消息中剩余的可用缓冲区空间。当接收 TCP 接收数据并填充缓冲区时，窗口会缩小，而当 TCP 将数据提供给应用程序并释放缓冲区空间时，窗口就会增长。如果接收方可以跟上向应用程序提供数据的速度，那么窗口就可以跟上发送方的速度。

流量控制是 TCP 所围绕的。流量控制基于在每个确认中发回的窗口。如果您不想要流量控制，那么您可以使用不同的协议。通常，您会使用 UDP 并创建一个应用层协议来实现您想要的其他 TCP 功能。这通常由程序员完成。

编辑：

RFC 793，传输控制协议解释说，流量控制是可靠通信的必要部分（我已经突出显示了相关文本）：

要在不太可靠的互联网通信系统之上提供此服务，需要以下领域的设施：

基本数据传输
可靠性
流控制
多路复用
连接
优先级和安全性

请记住，IP（IPv4 和 IPv6）是一个不可靠的协议，TCP 依赖于它

• 假设发送方/服务器以 10Gbps 的速度连接到其本地网络。
• 假设从发送方到其数据中心的 WAN 边缘路由器的网络为 10Gbit/s。
• 假设数据中心端有一个 10Gbps 的 WAN 边缘路由器和多个 100Mbps 的 WAN 电路。
• 假设其中一个辐射站点有一个 WAN 路由器，具有 100Mbps WAN 和 1Gbps LAN 连接。
• 假设接收器以 1Gbit/s 连接到该辐条站点 LAN。

作为发起者和接收者，辐条站点的客户端系统请求从数据中心的服务器下载文件。

作为响应者和发送者的服务器将很快开始以 10Gbps 的速度爆发。WAN 边缘路由器将立即填满其到 WAN 电路的出口队列/缓冲区，并且尾部丢弃将开始。

如果发送方不限制它的发送速率，WAN 路由器将继续以疯狂的速率尾部下降，有效地对 WAN 电路进行 DoS 攻击，对于给定 100Mbps 电路另一端的所有用户。

更重要的是 - 如果从发送方到接收方的网络路径可能会丢弃超过 90% 的所有数据包，则发送方将不得不在缓冲区中保留更多要发送（并可能重新发送）的数据，进一步增加服务器/发送方的系统资源需求（...为潜在的 100 个客户端/接收方进行大规模缓冲）。

这就是 TCP 中存在流量控制/拥塞避免的原因，因此发送方有一个度量标准来估计每个接收方的允许发送速率，并且它可以将丢失 ACK 和重传的速率降低到边缘或为零的水平。

这也确保了其他数据流在窄链路上竞争带宽的某种程度的公平性。

其实这不仅仅是一个理论问题。BBR 算法存在（有？）问题，该算法过于激进，并且正在使用“经典”拥塞缓解机制（如 Cubic）接管流，显然类似于此处描述的内容。AFAIR 这就是 BBRv2 调整的原因。

在这种情况下（滥用节奏），一个流以不公平的比例（取决于“攻击性”）接管整个带宽，因此除了滥用流本身之外，其他服务的运行会降级。

因此，如果您根本不要求避免流量+拥塞：这将破坏每个溢出的链接上的每个传输（包括自己的）-在（期间）干扰其他流之后，它也将不可避免地使自身溢出。

正如 Ron Maupin 在下面的评论中所指出的，这个答案是关于拥塞，而不是流量控制；然而，由于流量控制处理整个端到端通信，而拥塞考虑了网络容量，很明显，如果网络（好吧，只是将端点作为它的一部分）不能传递数据包，那么流量控制是无关紧要的。

因此答案会更复杂：

1. 如果您只想禁用（无论如何使其在实践中无效）流量控制，您可以观察到更高的网络利用率和数据包丢失，但没有其他影响 - 因为拥塞避免可能（如 BBR）使用丢弃的数据包度量来减慢根据发送者使用的拥塞控制，发送或许多不同的问题；特别是，如果发件人不使用具有丢弃弹性的 CC，则流将不稳定甚至停止，
2. 如果您的意思是禁用每个流速度控制旋钮（即，流量和拥塞控制） - 效果将如上所述，类似于 UDP 泛洪。

简而言之：禁用流量控制（窗口大到实际上是无限的）将导致过多的流量和数据包丢失[但传输本身可能（取决于使用的拥塞控制指标）完好无损；毕竟，每个丢包都应该重新传输，或者暴露丢包本身的直接影响。]

至于第二条评论 - 是的，这种区别至关重要。流量控制是主动的（和声明性的：“我可以（不）接受多少”），而拥塞控制是追溯性的（并使用“隐藏变量”，如丢弃率或 RTT）。为了完全破坏 TCP，必须将它们都停用，即至少在发送端进行滥用更改（积极/非拥塞并通过设置和保持巨大的窗口来忽略流量控制参数）；接收方不能利用流量控制来请求不公平的带宽份额。

可以用一种非常简化的形式说，虽然拥塞控制是关于公平的，但流量控制是关于无丢包的。老实说……他们俩都在工作上失败了。流量控制无法防止动态环境（如无线）中产生的随机丢包，而所有经典甚至现代的CC算法在一般意义上的“公平”上都不能很好地应对。甚至有人可能会说 TCP 已过时，这样的说法也是正确的。这些（以及许多其他）缺点在 QUIC 协议中得到了解决，该协议在 Web 浏览器中实现，以克服主导操作系统的长发布周期。修复 TCP 以赶上涉及 BBR 的现代世界 - 它具有下降弹性并具有快速收敛（动态、自适应）。而且由于 v2 不会压倒其他流并且有自己的 TCP 起搏，所以在 L2 接口上不需要 FqCoDeL qdisc。这就是现在计算流所需速度的不同元素如何交织在一起。

至于滑动窗口的“额外复杂性” - 在任何异步可变长度数据包传输协议中，无论如何您都需要某种缓冲区管理。以一种可以暴露可用窗口空间的方式构建它是一些额外的努力，但你不能完全放弃这个东西。

另外，请记住 TCP 是几十年前设计的，您认为当前的“一些小开销”在当时是一个非常巨大且不可接受的损失，可用带宽比现在慢几个数量级。那时，如果没有先进的拥塞控制，超过某个阈值的丢包率会导致流突然停止，因此不仅微小的带宽会浪费在重传上，而且无法有效利用。想想 9600 波特的固定线路，最大利用率约为 70%，当 3% 的丢包率破坏传输时；如果这样的线路很嘈杂，TCP 根本无法在它上面工作。