当我们使用TCP，从客户端发送数据到服务器，这个过程会是怎样的呢？
首先，当然是耳熟能详的三次握手过程，那当连接建立之后，就一股脑发送所有数据吗？
当然不是，一下子发送太多数据，接收端可能没有那么大的空间，就浪费了流量。
TCP使用滑动窗口来管理发送方和接收方之间的数据传输量。滑动窗口通过控制未确认数据包的数量，确保发送方发出的包不会超出接收方的处理能力。
滑动窗口
滑动窗口的工作机制如下：
- TCP在每个ACK包中，通知对方自己目前能接收多少数据，即TCP头部中的窗口大小(三次握手期间的ACK也会包含窗口大小)。
- 发送方可以在这个窗口大小内，连续发送多个数据包，而不必等待每个数据包的确认。
- 当发送方收到接收方的
ACK确认，窗口就会向前滑动，允许发送方继续发送新的数据包。
在某个时间段，发送方的TCP数据流如下图所示，可以分成4个部分：
- 已发送且已确认的数据：这部分数据已经没用了，不再需要保存。
- 已发送但未确认的数据：需要保存在缓冲区里，如果丢包了，可以进行重传。
- 未发送，允许发送的数据：没有超过接收方缓冲区，可以发送数据。
- 未发送，不允许发送的数据：超过对方缓冲区，不可以发送。
滑动窗口的优点：
- 高效利用带宽：滑动窗口允许发送方连续发送多个数据包，而无需等待每个数据包的确认，从而提高了带宽利用率。
- 流量控制：通过动态调整窗口大小，滑动窗口机制能有效控制数据流量，防止网络拥堵。
窗口满的情况
在接收方看来，数据可以分成三个部分：
- 成功接收并确认的数据
- 未收到但可以接收的数据
-
未收到且不可接收的数据
tcp_rwnd.png
未收到但可以接收的部分，就是接收方的窗口大小。
接收方收到数据后，会存放到缓冲区中，等待上层应用获取数据(socket调用read函数)。
如果上层应用繁忙，读取效率较低，那么这个窗口就会慢慢变小，甚至会变成0，也就是窗口满的情况。
这时候，接收方会发送一个ZeroWindow的包，告诉发送方，这边已经不能再接收数据了，发送方就不再发送数据。
等到缓冲区的数据被读取之后，接收方会发一个WindowUpdate的ACK，告诉发送方自己最新的窗口大小，发送方就可以继续发送数据了。
但是这里有个问题，如果这个WindowUpdate的包丢失了的话，发送方就只能继续保持0窗口，数据在这里就卡住不再发送了。
为了解决这个问题，TCP设置了定时探测，发送ZeroWindowProbe，获取接收端最新的窗口大小。
TCP协议本身并没有一个明确的
Window Full标记。然而，在实际使用中，有些网络监测工具和协议分析器（例如Wireshark）会标识或标记某些数据包，以表明发送方的发送窗口已经完全被使用。这种标记主要是用来帮助用户理解和分析TCP连接中的流量控制和拥塞控制情况。
糊涂窗口综合症
当接收方缓冲区满时，窗口关闭，如果应用层读取了一个字节的数据，此时缓冲区就有了一个字节的空间，这时候立刻发送WindowUpdate通知发送方的话，那发送方就可能发一个字节的数据过来，一个TCP包只包含一个字节的数据，这效率就很低下。
这种情况下，这个连接的窗口一直保持在很小的状态，称作糊涂窗口综合症。
为了解决这个问题，当窗口大小小于min(MSS，缓存空间/2) ，也就是小于MSS与1/2缓存大小中的最小值时，就会向发送方通告窗口为 0，也就阻止了发送方再发数据过来。
等到接收方处理了一些数据后，窗口大小 >= MSS，或者接收方缓存空间有一半可以使用，才更新窗口大小，让发送方发送数据过来。
拥塞控制
滑动窗口控制的是一个TCP连接的流量，避免发送方的数据填满接收方的缓存。但是，网络上不只一个TCP连接，如果不加以控制的话，就可能发生数据的拥堵，拥堵导致丢包，丢包需要重传，则又加大了拥堵。
所以，TCP使用了拥塞控制来避免数据填满整个网络。
拥塞窗口 cwnd 是发送方维护的一个的状态变量，它会根据网络的拥塞程度动态变化的 。当cwnd=n时，表示发送方可以发送n个MSS大小的数据
拥塞控制主要是四个算法：
- 慢启动
- 拥塞避免
- 快速重传
- 快速恢复
慢启动
慢启动的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加cwnd的大小，其算法如下：
- 建立连接后，初始化
cwnd为1，可以发送1个MSS数据。 - 每次收到
ACK，则将cwnd加1。 -
cwnd达到某一个阈值ssthresh（slow start threshold）后，不再使用慢启动，改用拥塞避免算法。
从上图中，可以看到，每一个rtt时间，cwnd都会翻倍，从而快速地增长。在良好的网络环境下，可以很快达到阈值，进入拥塞避免算法。
在一些现代操作系统中（如 Linux 和 Windows），TCP 初始拥塞窗口的默认值为 10 个 MSS。这使得发送方在建立连接后的初始数据传输中，可以一次发送多达 10 个 MSS 的数据包，而不必经历传统的慢启动阶段。
拥塞避免
慢启动时，起点低，但指数增长，速度快，达到一定程度后，就不能再继续指数增长，以防止拥塞。拥塞避免的想法就是，在一个rtt时间内，让cwnd不是翻倍，而是加一，缓慢增长。
那么，如何让cwnd在一个rtt中加一呢？在慢启动算法中，在某一轮次，cwnd=n，此时连续发送n个MSS，每次收到ACK则cwnd+1，收到n个则cwnd+n，形成翻倍的效果。同理，只要在每次收到ACK时，将cwnd+1改成cwnd+1/n，那么在n个ACK后，则形成cwnd+1的结果。
在慢启动和拥塞避免阶段，如果出现超时，则重发超时的数据，然后处理如下：
- 将
ssthresh设为cwnd/2 - 将
cwnd设为1 - 进入慢启动算法
快速重传
当检测是否丢包时，每次都要等待超时的发生，会浪费很长时间，因此引入了快速重传：发送方只要收到3个重复的ACK，即认为丢包发生，此时会立即重传丢失的包，而不再等待超时的出现。
快速恢复
为了解决丢包后进入慢启动引起的效率降低，在快速重传的基础上，又引入了快速恢复，在发生快速重传之后，拥塞控制如下处理：
- 将
ssthresh设为cwnd/2。 - 将
cwnd设为ssthresh+3（+3是因为已经收到3个重复的ACK）。 - 如果再收到重复的ACK，则
cwnd+1。 - 如果收到新的ACK，则快速恢复结束，进入拥塞避免。
