一看就懂TCP-快速之拥塞控制

再来想想这个窗口的大小 还会和什么有关系？

除了接收方的能力之外，还和网络 带宽有关 ，但这个TCP 怎么能动态的知道网络的情况呢？

如果我们设置发送窗口，使得发送但未确认的包为为通道的容量，就能够撑满整个管道。

如图所示，假设往返时间为 8s，去 4s，回 4s，每秒发送一个包，每个包 1024byte。已经过去了 8s，则 8 个包都发出去了，其中前 4 个包已经到达接收端，但是 ACK 还没有返回，不能算发送成功。5-8 后四个包还在路上，还没被接收。
这个时候，整个管道正好撑满，在发送端，已发送未确认的为 8 个包，正好等于带宽，也即每秒发送 1 个包，乘以来回时间 8s

如果我们在这个基础上再调大窗口，使得单位时间内更多的包可以发送，会出现什么现象 呢? 多出来的包就会被 丢弃。加上缓存 ，如果时延达到一定程度，就会超时重传 。这个控制受网络影响调节流量的窗口叫做拥塞控制窗口。

但是一开始我怎么知道速度多快呢，我怎么知道应该把窗 口调整到多大呢?
一开始慢慢的倒，然后发现总能够倒进去，就可以越倒越快。这叫作慢启动。

一条 TCP 连接开始，窗口 设置为一个报文段，一次只能发送一个;当收到这一个确认的 时候，cwnd 加一，于是一次能够发送两个;当这两个的确认到来的时候，每个确认 cwnd 加一，两个确认 cwnd 加二，于是一次能够发送四个;当这四个的确认到来的时候，每个 确认 cwnd 加一，四个确认 cwnd 加四，于是一次能够发送八个。可以看出这是指数性的 增长。

涨到什么时候是个头呢?有一个值 ssthresh 为 65535 个字节，当超过这个值的时候，不能倒这么快了，可能快满了，再慢下来。

每收到一个确认后，cwnd 增加 1/cwnd，

前面我们讲过快速重传算法。当接收端发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速的重传，不必等待超时再重传。TCP 认为这种情况不严重，因 为大部分没丢，只丢了一小部分，

==================
问题：

第一个问题是丢包并不代表着通道满了，也可能是管子本来就漏水。例如公网上带宽不满也 会丢包，这个时候就认为拥塞了，退缩了，其实是不对的。
第二个问题是 TCP 的拥塞控制要等到将中间设备都填充满了，才发生丢包，从而降低速度，这时候已经晚了。其实 TCP 只要填满管道就可以了，不应该接着填，直到连缓存也填满。
为了优化这两个问题，后来有了TCP BBR 拥塞算法

它企图找到一个平衡点，就是通过不 断的加快发送速度，将管道填满，但是不要填满中间设备的缓存，因为这样时延会增加，在 这个平衡点可以很好的达到高带宽和低时延的平衡。 本文不做详细阐述了。

和我们上文讲的流量控制窗口 都在影响窗口的大小。那么有关系么？

是拥塞窗口和 滑动窗口共同控制发送的速度。