TCP流量控制

上篇博文我们分析了TCP的拥塞控制。TCP的拥塞控制其实是TCP通过线路上的阻塞情况来控制发送端发送数据的大小。但是还有一种情况就是接收端的处理速度不如发送端，这时候，就要使用TCP另外一个控制手段了，就是TCP的流量控制。
分析TCP的流量控制我们先讨论一下什么叫ARQ协议，ARQ协议分为停止并等待ARQ协议和连续ARQ协议。
下面是wiki对等待ARQ协议和连续ARQ协议的解释。

停止并等待协议的工作原理如下：发送点对接收点发送数据包，然后等待接收点回复ACK并且开始计时。在等待过程中，发送点停止发送新的数据包。当数据包没有成功被接收点接收时候，接收点不会发送ACK.这样发送点在等待一定时间后，重新发送数据包。反复以上步骤直到收到从接收点发送的ACK.发送点的等待时间应当至少大于传输点数据包发送时间（数据包容量除以发送点传输速度），接收点ACK接收时间（ACK容量除以接收点传输速度），数据在连接上的传送时间，接收点检验接收数据是否正确的时间之和。在实际应用当中，等待时间是这个和的2到3倍。这个协议的缺点是较长的等待时间导致低的数据传输速度。在低速传输时，对连接频道的利用率比较好，但是在高速传输时，频道的利用率会显著下降。    为了克服停止并等待ARQ协议长时间等待ACK的缺点。这个协议会连续发送一组数据包，然后再等待这些数据包的ACK.回退N重传(Go-Back-N)接收点丢弃从第一个没有收到的数据包开始的所有数据包。发送点收到NACK后，从NACK中指明的数据包开始重新发送。选择重传(Selective Repeat)发送点连续发送数据包但对每个数据包都设有个一个计时器。当在一定时间内没有收到某个数据包的ACK时，发送点只重新发送那个没有ACK的数据包。

说了一大堆其实就说停止等待ARQ是一个数据包要等到ACK确认才可以发送第二个，而连续ARQ是可以连续发送多个再确认。
下面我们再看看滑动窗口协议
滑动窗口协议时接收方维护一个滑动窗口来控制发送方的发送窗口大小的一种协议。发送端的发送窗口要注意的是发送出去，但是还没收到确认的数据，还要在发送窗口那里进行保留。而接受窗口也要临时保留好没有按序到达接受窗口的数据。具体如图

对着这幅图片，我来把整个流程梳理一下，首先接受方维护着一个接受窗口从34到53，那么发送方只能发送窗口内的数据，根据连续ARQ协议，发送方可以一口气发送34到41所有的数据。再进行确认。发送后P2指针就指向42.此时要注意，如果接收方发送了ack=42的报文，这样，p1指针也会指向42。但是图片上给出另外一种情况，就是接收方只接收到37,38,40，三个报文，此时接收方会临时存储那三个字节的数据，等待后续报文有没有其他数据传入，如果没有他会发送ack=34，让发送方重传这部分数据的人报文，同时发送方也会维护一个重传计时器，如果接收方一直没有ACK报文，他就会重传P1到P2的数据。
接收方维护一个接受方滑动窗口来进行流量控制。其实就是TCP进行流量控制的一种方式。很多人就问，那发送方怎么知道接收方窗口大小呢，其实就是在接收方报文里面有一个rwnd字段告诉发送方，联系上次阻塞窗口。我们就知道为什么接受窗口等于min(rwnd,cwmd)了。
还有一种情况我们要注意就是如果接受方不想让发送方传数据了就会发送一个rwnd=0的报文。此时如果接收方再发送一个rwnd=400在传输过程丢失了。此时不就死火了？此时会维护一个持续计时器，发送方维护一个持续计时器，如果0报文发送后时间到了，还没rwnd报文叫醒他，就发一个试探报文到接收端。。。