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

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

滑动窗口机制详解：

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个字节。这样，