一. 流量控制

流量控制主要考虑的是接收方的处理速度。

接收端处理数据的速度是有限的.。如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继⽽引起丢包重传等等⼀系列连锁反应。
TCP⽀持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control)。

模型

实现这样的机制主要依赖于TCP报头中的16位窗口大小以及选项中的窗口扩展因子，该机制通过控制滑动窗口的大小来控制流量。

那将窗口设置为多大合适呢？
答案是设置为接收缓冲区剩余空间的大小。

所以如何实现这个机制呢？就是在返回的ACK报文中将窗口大小设置为接收缓冲区剩余空间的大小。

窗口探测

如果返回的ACK中显示窗口大小为0了，那就说明对方的接收缓冲区已经满了，就应暂停发送数据。

那问题是：如果不发送新的数据，那就无法拿到新的ACK，就无法更新窗口大小，那这个该如何应对呢？

出现这种情况后，发送方会周期性的发送“窗口探测”包，不携带载荷，仅仅是让对方返回ACK报文，以获取新的窗口大小，如果窗口大小不是0，就可以继续发数据了。

二. 拥塞控制

拥塞控制主要考虑的是网络是否畅通。

我们知道，真实的网络十分复杂，也极有可能出现各种故障。如果出现故障（比如说网络堵塞），那发送速度就应该减缓，那发送方如何知道网络出现堵塞了呢？主要是通过“实验”的方式，如果按照某个窗口大小发送数据，出现丢包，就要减缓发送速度；如果没有丢包，就要增大发送速度

模型

拥塞控制如何实验出合适的窗口大小呢?

1. 慢启动：以一个很小的窗口值开始发送；
2. 指数增长：如果没有出现丢包，就以指数形式增大窗口大小；
3. 线性增长：增长到一定速度后，变为线性增长（避免增长过快造成堵塞）
4. 如果出现丢包，速度减半，线性增长（新版：TCP Reno版本）

TCP Tahoe版本中要求速度减小至慢启动，主要是由于当时网络环境并不发达。

总结

流量控制关注于接收方的接收能力，主要通过接收方的接收缓冲区的大小来控制窗口大小；拥塞控制主要关注于网络是否通畅，主要通过实验的方式来得到一个合适的窗口大小。由于木桶效应，实际上应该取两者中相对较小的窗口大小来作为实际的窗口大小。