TCP的拥塞控制和流量控制

• 拥塞控制
• 流量控制

拥塞控制

a)拥塞
计算机网络中的带宽，交换节点中的缓存以及处理机制，称这为网络资源，当某一时间段，网络资源的需求量超过其提供量，网络的性能就会变坏，称这样的状况为拥塞。其实可以对比生活中的公路行车，不管车道再多，再高峰期或者由于车祸总会导致堵车的现象。国家可以通过单双号去限制出行量，但网路用户显然是无法被限制的，因此在用户数量无法限制，资源又有限的情况下只能通过降低服务质量来达到为每个用户提供服务。
我们需要明白拥塞的控制是一个动态的过程，像增加网路资源，这样静态的方法显然无法对动态的情况进行有效的调控。通过类比增加车道也无法保证同行畅通这点很容易想清楚。
拥塞控制是一个全局的过程，它不像下面提到的流量控制是一个点对点的控制。
b)拥塞控制
TCP的拥塞控制由四个算法构成：慢启动，拥塞避免，快速重传，快速恢复
在发送方维持了一个拥塞窗口的状态量，其状态的大小取决于网路的拥塞程度，并且动态的变化，发送方让发送窗口的大小等于拥塞窗口的大小，但考虑到接受方接受窗口的情况，发送窗口有可能小于拥塞窗口的大小。
简单来说，拥塞窗口反映了网路的承载能力，但你实际发送的量还是需要考虑你接受方的能力。
a)慢启动
在一开始时发送端显然是不知道当前网路资源的利用状况，所以需要一个探测的过程，虽然说是慢启动但是实际的增长确是指数增长，并不慢，这是从1开始增长，起点比较低。
举个例子，一开始 1 2 4 8 16…如果带宽是m，显然log2(w)的时间就可以满足。
b)拥塞避免
显然当你采用慢启动的方式去增长时，在很短的时间内，就会达到阻塞，慢启动保证了可以很快的利用网络资源,TCP设置了一个临界值，当达到这样的一个临界值时，采用线性增长的方式去增长，也就是进入到拥塞避免的阶段，对于大多数TCO来说，这样的值是65535，采用线性增长去慢慢接近网络的最佳值。
备注：当达到临界值时，将会试探性的发送segment，如果服务器没有响应，则认为网络状态不佳，需要降低临界值，或者直接从1开始。
c)快速重传
快速重传的机制时，当发送方连续收到三个重复确认就应当立即重传对方未接受到的报文，不必等待设置的重传计时器到期。这样的做法显然是对传输效率的一种优化。
d)快速恢复
其实快速恢复并不是单独存在的，它是快速重传的后续处理。上面我们知道当连续收到三个重复确认时需要重传，但是如果存在更多的确认重复在，显然当前网路传输效率是有问题的，出现了大量的丢包，
快速恢复就是重新调整拥塞窗口的一种算法。
1)当发送方连续收到三个确认时，窗口减半，乘法减小算法，
2)考虑到可以收到连续三个重复确认，网络并没有进入到拥塞，所以进入到拥塞避免阶段。

如何检测拥塞？
TCP为每一个报文段设置了一个重传定时器(RTO)，当RTO超时还没有收到确认，重传，显然RTO超时没有收到确认，同时也没有收到连续三个确认重传，可以推断出，网络进入到拥塞，发生了丢包。
这是采用乘法减小，还有丢包，设置为1，以慢启动重新开始。
TCP整体的拥塞窗口设计原则是，积式减小，和式增大。
为什么，没收到一个ACK，拥塞窗口会加1?
在用一时间内，网络传输中的数据包是恒定的，当收到一个ACK时，代表旧包离开，可以处理新包，于是将拥塞窗口加1。

流量控制

a)滑动窗口
TCP协议为了提高通信管道的利用率，并没有使用停止等待协议，而是采用了ARQ协议，就是可以连续发送若干个分组然后等待，而不是发送一个分组然后等待。
TCP的发送端和接收端都维持了两个滑动窗口。
b)流量控制
流量控制的目的就是让发送方不要传输的太快让接收方来得及接收数据，通过我们对滑动窗口的认识，我们明白可以利用滑动窗口的机制来达到流量控制的机制，发送方发送窗口的大小不可以大过接收方窗口的大小。
特殊情况:如果接收方没有足够的缓存可以使用，就会发送零窗口大小的报文，此时按照规定发送方窗口的大小就会被设置为0，发送端显然会停止发送，之后接收方有了足够的缓存，发送了非零窗口大小的报文，但这个报文中途丢失，那么发送方显然发送窗口的大小会是0，无法发送数据，导致死锁。
为解决这样的问题，显然在接收到接收端的零窗口报文时，发送端需要知道我什么时候可以继续发送，这时TCP协议规定在就收到零窗口的报文时，接收端会周期性的发送一个零窗口的探测报文(即使是零窗口，也必须接受零窗口探测报文，确认报文，紧急报文)
c)传输效率和Nagle算法
TCP的传输数据分为交互数据和块数据，交互数据一般是交互数据的命令，一般比较小。那么这样对网络的利用率就很小。
数据传输使用Nagle算法：就是规定一个TCP连接最多只能有一个未被确认的未完成的分组，在该分组的确认到达之前不能发送其他分组。
这是有可能产生这样一个问题，当接收方的缓存已经满时，交互的引用程序，一次只从缓存中读取了一个字节，然后向发送端发送确认消息，显然此时滑动窗口的大小是1，这样的效率是比较低的，称这样的现象为糊涂窗口综合症。
为解决这样的问题，我们可以很自然的想到，我们可以等缓存使用的较多时在发送应答，这样滑动窗口的大小就会比较大，因此可以选择让接收方等待一段时间再发送应答(延迟应答)。

有关TCP详解可以参照下面的博客。
https://blog.csdn.net/rock_joker/article/details/76769404