详解TCP的流量控制机制与拥塞控制机制

1. 一般来说，我们总是希望数据传输得更快一些，但如果发送方把数据发送得很快，而接收方来不及接收，这就可能造成数据的丢失。流量控制就是让发送方的发送速率不要太快，让接收方来得及接收。 对于成块数据流，TCP利用滑动窗口机制来实现流量的控制，对于交互数据流，TCP利用捎带ACK和Nagle算法来实现流量的控制。

2. 滑动窗口机制详解：

   1.假设A向B发送数据。在连接建立时，B告诉A，我的接收窗口(receiver window) rwnd=400。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。PS：TCP的窗口单位是字节，不是报文段。TCP连接建立时的窗口协商过程在图中没有显示出来。再设每一个报文段为100字节长，而数据报文段序号的初始值设为1。大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值。
   2.B进行了3次流量控制，第一次把窗口减少到rwnd=300，第二次又减到了rwnd=100，最后减到rwnd=0，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机重新发出一个新的窗口值为止。
   3.考虑一种特殊情况，如果B在向A发送了零窗口报文段后不久，B的接收缓存又有了一些存储空间，于是B向A发送了一个rwnd=400的报文段，然而这个报文段再传送过程中丢失了，A就一直等待B发送非零窗口的报文通知，而B一直等待A发送数据，如果没有任何措施的话，这种死锁的局面会一直延续下去。
   解决办法：TCP为每一个连接设有一个持续计时器，只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器(坚持计时器)，如持续计时器设置的时间到期，就发送一个零窗口探测报文段(携1字节的数据)，对方在收到探测报文段后，在对该报文段的确认中给出现在的窗口值，如果窗口值仍为0，则收到这个报文段的一方就重新设置持续计时器，如果窗口不为0，那么死锁的僵局就被打破了。
   4.糊涂窗口综合症：TCP接收方的缓存已满，而应用进程一次只从接收缓存中读取1字节(这样就使接收缓存空间仅腾出1字节)，然后向发送方发送确认，并把窗口设置为1个字节(但发送的数据报为40字节长)。发送方又发来1个字节的数据(发送方的IP数据报是41字节)。接收方发回确认，仍然将窗口设置为1个字节。这样，网络的效率很低。要解决这个问题，可让接收方等待一段时间，或者等到接收方缓存已有一半空闲的空间。只要出现这2种情况之一，接收方就发回确认报文，并向发送方通知当前的窗口大小。此外，发送方也不要发送太小的报文段，而是把数据报积累成足够大的报文段，或达到接收方缓存的空间的一半大小时再发送给接收端。

14.TCP中的四大定时器

1. 对于每个TCP连接，TCP一般要管理4个不同的定时器：重传定时器、坚持定时器、包活定时器、2MSL定时器。
2. 重传定时器：
   用来计算TCP报文段的超时重传时间的。每发送一个报文段就会启动重传定时器，如果在定时器时间到后还没收到对该报文段的确认，即重传该报文段，并将重传定时器复位，重新计算；如果在规定时间内收到了对该报文段的确认，则撤销该报文段的重传定时器。
3. 坚持定时器：
   为了应付零窗口大小通知可能导致的死锁问题。如果接收端在向发送端发送了零窗口报文段后不久，接收端的接收缓存又有了一些存储空间，于是接收端向发送端发送了一个非零窗口大小的报文段，然而这个报文段再传送过程中丢失了，发送端没有收到该报文段，就一直等待接收端发送非零窗口的报文通知，而接收端并不知道报文段丢失了，就会一直等待发送端发送数据，如果没有任何措施的话，这种死锁的局面会一直延续下去。
   解决：只要TCP连接的一方收到对方的零窗口通知，就启动坚持定时器。若坚持定时器设置的时间到期，就发送一个零窗口控测报文段(该报文段只有1个字节的数据，它有一个序号，但该序号永远不需要确认，因此该序号可以持续重传)，之后会出现以下3种情况：
   1.对方在收到探测报文段后，再对该报文段的确认中给出现在的窗口值，如果窗口值仍为0，则收到这个报文段的一方将坚持定时器的值加倍并重启。坚持计数器最大只能增加到约60秒，在此之后，每次收到零窗口通知，坚持计数器的值就定位60秒。
   2.对方在收到探测报文段后，在对该报文段的确认中给出现在的窗口值，如果窗口不为0，那么死锁的僵局就被打破了。
   3.该探测报文发出后，会同时启动重传定时器，如果重传定时器的时期到期，还没有接收到发来的响应，则超时重传探测报文。
4. 保活定时器：
   是为了应对2个TCP连接间出现长时间的没有数据传输的情况。如果客户已与服务器建立了TCP连接，但后来客户端主机突然故障，则服务器就不能再收到客户端传来的数据了，而服务器肯定不能这样永久地等下去，保活定时器就是用来解决这个问题的，服务端就发送一个探测报文，以后每隔75秒发送一次，如果连续发送10次探测报文段后仍没有收到客户端的响应，服务端就认为客户端出现了故障，就可以终止这个连接。
5. 2MSL定时器：
   2MSL定时器测量一个连接处于TIME-WAIT状态的时间，通常为2MSL(报文段寿命的2倍)。2MSL定时器的设置主要是为了确保发送的最后一个ACK报文段能够到达对方，并防止之前与本连接有关的由于延迟等原因而导致已失效的报文被误判为有效。

15.TCP的拥塞控制机制

1. 计算机网络中的带宽、交换节点中的缓存和处理机等，都是网络的资源，在某段时间内，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏，这就叫拥塞。
2. 所谓拥塞控制，就是防止过多的数据注入到网络上，从而使网络中的路由器或链路不致过载。要注意拥塞控制与流量控制的区别，拥塞控制是全局性的过程，涉及到所有的主机、路由器、局域网。
3. 拥塞控制的算法有：慢开始、拥塞避免、快重传、快恢复4种。
   发送方维持一个拥塞窗口的状态变量，其大小取决于网络的拥塞程度，动态地变化，而发送窗口一般取拥塞窗口和对方给出的接收窗口的最小值(为了便于描述，后面的分析中假定对方给出的接收窗口足够大，这样发送窗口等于拥塞窗口就可以了)
4. 慢开始：
   慢开始算法的核心是从小到大逐渐增大发送窗口，也就是说，从小到大逐渐增大拥塞窗口的数值。通常在刚开始发送报文段时，先把拥塞窗口设置为一个最大报文段MSS的数值，而在每收到对上一轮报文段的确认后，就把拥塞窗口的数值加倍。
   为了防止拥塞窗口增长过大引起网络拥塞，还需要维护一个满开始门限的状态变量，当拥塞窗口的值小于慢开始门限时，使用慢开始算法，一旦大于慢开始门限的值，就改用拥塞避免算法。
5. 拥塞避免：
   拥塞避免算法的思路是让拥塞窗口缓慢地增大，收到每一轮的确认后，将拥塞窗口的值加1，而不是加倍，这样拥塞窗口的值按照线性规律缓慢增长。
   无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞(没有按时收到确认)，就把慢开始门限设置为出现拥塞时发送窗口值的一半，但最小不能小于2个MSS值，而后把拥塞窗口的值重新设置为1个MSS，执行慢开始算法。
6. 快重传和快恢复
   快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认(重复发送对前面有序部分的确认)，而不是等待自己发送数据时才捎带确认，也不是累积收到的报文发送累积确认，如果发送方连续收到3个重复确认，就应该立即重传对方未收到的报文段(有收到重复确认，说明后面的报文段都送达了，只有中间丢失的报文段没送达)
   快恢复算法与快重传算法配合使用，其过程有如下2个要点：
   1.当发送方连续收到3个重复确认时，就把慢开始门限减半，这是为了预防网络发生拥塞。注意，接下来不执行慢开始算法。
   2.由于发送方现在认为网络很可能没有发生特别严重的阻塞(如果发生了严重阻塞的话，就不会一连有好几个报文段到达接收方，就不会导致接收方连续发送重复确认)，因此与慢开始不同之处是现在不执行慢开始算法(即拥塞窗口的值不设为1MSS)，而是把拥塞窗口的值设为慢开始门限减半后的值，而后开始执行拥塞避免算法，线性地增大拥塞窗口。