TCP的流量控制
使用滑动窗口进行流量控制
所谓的流量控制，就是让发送方的发送速率不要太快，让接收方来得及接收。利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。
如图说明了如何利用滑动窗口机制进行流量控制。
设主机A向主机B发送数据。假设B发送给A的rwnd (receiver window，窗口值) 是400，发送方的发送窗口不能超过接收方给出的接收窗口的数值。TCP的窗口单位是字节，不是报文段，请注意。
再设每一个报文段为100字节长，序号的初始值为seq=1。注意图中的大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值。
接收方的主机B进行了三次流量控制。第一次把窗口设置为rwnd=300，第二次减小到rwnd=100，最后减到rwnd=0，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。另外B向A发送的三个报文段都设置ACK=1，可以看出只有在ACK=1时确认号字段才有意义。
假如，B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwnd=400的报文段，然而这个报文段在传送中丢失了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。这样就死锁了。
为了解决这种死锁状态，TCP为每个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。如果窗口仍然是零，那么收到这个报文段的一方重设持续计时器；如果窗口不是零，那么死锁就不会发生了。
注意：即使是零窗口，也必须接收这几个报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段。因此上述的零窗口探测报文段也是可以被接收到的。
TCP报文段发送时机的控制
控制TCP报文的发送时机主要有以下几种机制。
1）TCP维持一个变量，它等于最大报文段长度MSS，只要缓存中存放的数据达到MSS字节就组装成一个TCP报文段发送出去。
2）由发送方的应用程序指明要求发送报文段，即TCP支持的推送(push)操作
3）发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（长度不超过MSS）发送出去。
Nagle算法
在TCP实现中广泛使用Nagle算法。算法是这样的：若发送应用进程把要发送的数据逐个字节地送到TCP的发送缓存，也就是说数据从进程到发送缓存是挤牙膏似的一点点的发送，那么就先把第一个字节发出去，等发送方收到对第一个数据字符的确认后，把数据积攒成一个大的数据块（报文段）发送出去，继续对随后到达的数据进行缓存。发送方每次只有收到接受方对前一个报文段的确认后才发送下一个报文段。
当数据到达较快而网络速率较慢时，用这样的方式可以明显的减少所用的网络带宽。
该算法还规定，当到达的数据已达到发送窗口大小的一般或已达到报文段的最大长度时，就立即发送一个报文段，这样做可以有效地提高网络的吞吐量。（吞吐量：单位时间从网络从网络输出的分组数目）
总体来说，目的是使得在发送方不发送很小的报文段的同时，接受方也不要在缓存刚刚有了一点小的空间就急忙把这个很小的窗口大小信息发送给对方。
TCP的拥塞控制
拥塞控制的原理
拥塞控制的产生
在某段时间，若对网络中的某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变差，这种情况叫做拥塞。也就是说：
$$\sum对资源的需求 > 可用资源$$
网络拥塞往往是由许多因素引起的，简单的提高节点处理机的运算速度，或者扩大结点缓存的存储空间，在很多时候并不能解决拥塞问题。例如
1）当某个结点缓存容量扩展到非常大，于是凡到达该结点的分组均可在结点的缓存队列中排队，不受任何限制。由于输出链路的容量和处理机的速度并未提高，因此在这队列中的绝大多数的分组在排队等待时间会大大增加，结果上层软件只好把他们进行重传（因为已超时）。
因此，问题的实质往往是整个系统的各个部分不匹配，只有各个部分平衡了，问题才会得到解决。
拥塞控制和流量控制的不同
所谓拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能承受现有的网络负荷。它是一个全局性的过程，涉及到所有的主机、所有的服务器，以及与降低网络传输性能有关的所有因素。
相反，流量控制往往指的是点对点通信量的控制，是个端到端的问题。流量控制所要做的就是控制发送端发送数据的速率，以便使接收端来得及接受。
拥塞控制设计
拥塞控制是很难设计的，因为它是一个动态的问题，许多情况下，甚至正是拥塞控制机制本身成为引起网络性能恶化甚至死锁的原因。从控制理论的角度来看拥塞控制这个问题，可以分为开环控制和闭环控制两种方法。开环控制就是在设计网络时事先将有关拥塞发生的所有因素考虑周到，一旦系统运行起来就不能在中途改正。
闭环控制是基于反馈环路的概念，包括如下措施：
1）监测网路系统以便检测拥塞在何时何地发生
2）把拥塞发生的信息传送到可采取行动的地方
3）调整网络系统的行动以解决出现的问题。
拥塞控制方法
因特网建议标准RFC2581定义了进行拥塞控制的四种算法，即慢开始（Slow-start)、拥塞避免（Congestion Avoidance)、快重传（Fast Retransmit）和快恢复（Fast Recovery）。我们假定：
1）数据是单方向传送，对方只传送确认报文。
2）接收方总是有足够大的缓存空间，因而发送窗口的大小由网络的拥塞程度来决定。
1. 慢开始和拥塞避免
发送报文段速率的确定，既要根据接收端的接收能力，又要从全局考虑不要使网络发生拥塞，这由接收窗口和拥塞窗口两个状态量确定。
接收端窗口（Reciver Window)又称通知窗口（Advertised Window)，是接收端根据目前的接收缓存大小所许诺的最新窗口值，是来自接收端的流量控制。
拥塞窗口 cwnd（Congestion Window）由发送端维持，是发送端根据自己估计的网络拥塞程度而设置的窗口值（发送窗口=拥塞窗口），是来自发送端的流量控制。
慢开始算法：
1）当主机开始发送数据时，如果立即将较大的发送窗口的全部数据字节都注入到网络中，那么由于不清楚网络的情况，有可能引起网络拥塞
2）比较好的方法是试探一下，即从小到达逐渐增大发送窗口，也就是由小到大逐渐增大拥塞控制窗口。可以这么理解，每经过一个传输轮次，拥塞窗口cwnd就加倍。一个传输轮次意思是：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。由此可以看出：慢开始算法的拥塞窗口的增长速度是指数级的。
3）通常在刚刚开始发送报文段时可先将拥塞窗口cwnd设置为一个最大报文段的MSS的数值。在每收到一个对新报文段确认后，将拥塞窗口增加至多一个MSS的数值，当rwind足够大的时候，为了防止拥塞窗口cwind的增长引起网络拥塞，还需要另外一个变量–慢开始门限ssthresh
用法：
cwnd < ssthresh 时，使用慢开始算法；
cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法；
cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法。
拥塞避免算法：
1）TCP连接初始化，将拥塞窗口设置为1
2）执行慢开始算法，cwind按指数规律增长，直到cwind == ssthress开始执行拥塞避免算法，cwnd按线性规律增长
3）当网络发生拥塞，把ssthresh值更新为拥塞前ssthresh值的一半，cwnd重新设置为1，按照步骤（2）执行。
2. 快重传和快恢复
一条TCP连接有时会因等待重传计时器的超时而空闲较长的时间，慢开始和拥塞避免无法很好的解决这类问题，因此提出了快重传和快恢复的拥塞控制方法。
快重传算法
首先要说明快重传算法的目的是让发送方尽早知道发生了个别报文段的丢失。快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认。即使收到了失序的报文段也要立即发出对已经收到的报文段的重复确认。如果当发送端接收到三个重复的确认ACK时，则断定分组丢失，立即重传丢失的报文段，而不必等待重传计时器超时。
慢开始算法只是在TCP建立时才使用。
快恢复算法
1）当发送方连续收到三个重复ACK时，就执行 “乘法减小” 算法，把慢开始门限设置为拥塞窗口的一半，这是为了预防网络发生拥塞
2）由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是把cwnd值设置为慢开始门限减半后的值，然后开始执行拥塞避免算法，拥塞窗口线性增大。
由此总结：在拥塞避免阶段，拥塞窗口是按照线性规律增大的，这常称为加法增大AI(Additice Increase)。而一旦出现超时或3个重复的确认，就要把门限值设置为当前拥塞窗口值的一半，并大大减小拥塞窗口的数值，这常称为“乘法减小”MD(Multiplication Decrease)。二者合在一起就是所谓的AIMD算法。
题外话：
在我看到快恢复算法的时候，产生了这样一个疑问：仅仅是丢失了一个报文段，为什么需要降低门限值、拥塞窗口值，而不是按照当前的进度、速度继续传呢？
经过反复看书思考，我得出的结论是：丢失了一个报文段意味着即将发生拥塞，但是当前还没有拥塞。为了避免发送方错误地开启慢开始算法，拥塞窗口cwnd的值又设置为1，进而降低传输效率，于是采用快恢复算法调整门限值，使用拥塞避免算法来尽可能规避拥塞，达到兼顾效率和拥塞控制的目的。
不知道想的对不对。