目录

流量控制

滑动窗口

滑动窗口为0的情况

糊涂窗口综合征

发送端解决“糊涂窗口”——Nagle算法

接收端解决“糊涂窗口”——伪零窗口响应

拥塞控制

慢启动与拥塞避免

慢启动

拥塞避免

快速重传与快恢复

快速重传

快恢复

总结

流量控制

滑动窗口

        滑动窗口主要用于进行流量控制&＃xff0c;举个例子&＃xff0c;A向B不停地发送数据&＃xff0c;如果A发送数据速度比B接收数据速度快&＃xff0c;那么最终就会出现B的接收缓存满的情况&＃xff0c;此时对于A发送并溢出的数据&＃xff0c;B是无法做出ACK应答的&＃xff0c;而A收不到ACK应答就会继续重发&＃xff0c;这样一来二去A就会发很多没有必要的报文。引起这一问题的原因&＃xff0c;主要就是A并不知道B能接收多少数据&＃xff0c;从而发送了很多B无法接收到的数据&＃xff0c;而滑动窗口则解决了这一问题。

        滑动窗口是通过TCP报文中的“窗口大小”win字段实现的&＃xff0c;对于B来说&＃xff0c;“窗口大小”反映了B下一次还能接收多少数据&＃xff08;字节为单位&＃xff09;&＃xff0c;如此&＃xff0c;B在回发给A的ACK报文中&＃xff0c;携带的确认序号指定了B下一次期望接收的数据包序号&＃xff0c;同时该ACK报文中也包含了B的窗口大小。A在收到B的ACK报文应答后&＃xff0c;可以知道B的窗口大小以及下一次应该发的报文序号&＃xff0c;根据这两条信息就可以确定A的发送窗口&＃xff08;如果只考虑流量控制的话&＃xff0c;那么发送窗口大小就等于接收窗口大小&＃xff09;&＃xff0c;而发送窗口内的数据就是下一次应该发送的数据。

滑动窗口为0的情况

       如果A仍然一直发送数据&＃xff0c;并且发送得很快&＃xff0c;而B读取数据很慢&＃xff0c;最终就会造成B窗口大小为0的情况。一旦B的窗口为0&＃xff0c;那么B回发回来的ACK报文中就会显示win&＃61;0&＃xff0c;此时A接收到了这条ACK报文&＃xff0c;就知道B不能再接收数据&＃xff0c;就不再给B发送数据了。

        而这种情况往往不会持续很久&＃xff0c;当B从缓存区中读取了一些数据后&＃xff0c;B的数据接收缓存中又有了一些存储空间&＃xff0c;也就表示B又可以再接收数据了&＃xff0c;但是此时A不知道啊&＃xff01;那该怎么去告诉A可以向B发送数据了呢&＃xff1f;一种方法是在B的接收缓存有空间时&＃xff0c;B直接向A发送ACK报文告诉A可以发送了&＃xff0c;需要注意的是&＃xff0c;A接收到这条ACK报文后是不需要发送确认的&＃xff0c;B只管发出这条报文就坐等A再发数据过来&＃xff0c;如果这条报文丢失&＃xff0c;A也就不知道此时B可以接收数据&＃xff0c;也一直在等待B&＃xff0c;双方互相等待&＃xff0c;最终就会造成死锁。

        为了解决这一问题&＃xff0c;TCP为每一个连接都设有一个持续计时器&＃xff08;persistant timer&＃xff09;。

       当A收到B的零窗口通知(win&＃61;0)&＃xff0c;A就会启动这个持续计时器。当持续计时器超时&＃xff0c;A就会向B发送一个探测报文段&＃xff08;仅携带一个字节数据&＃xff09;&＃xff08;这条报文并非是确认报文&＃xff0c;如果收不到ACK确认会重传&＃xff09;&＃xff0c;而B收到这个探测报文段&＃xff0c;就会再回发一个ACK报文&＃xff0c;这条ACK报文中给出了B当前的窗口大小。A收到了这条报文后&＃xff0c;如果发现窗口大小仍然为0&＃xff0c;那么A就会重置持续计时器重新开始计时&＃xff1b;如果窗口大小不为0&＃xff0c;那么就会恢复正常状态向B发送数据。

糊涂窗口综合征

        通过滑动窗口&＃xff0c;的确可以实现A与B端到端的数据传输流量控制&＃xff0c;但是也会有其他情况&＃xff1a;当B的数据缓存满了之后&＃xff0c;如果B的数据处理速度足够慢&＃xff0c;一次只能处理少许字节如1个字节&＃xff0c;那么此时窗口大小就为1&＃xff0c;A在探测到窗口大小为1后&＃xff0c;就会向B发送一个字节的数据包&＃xff0c;而一个数据包上只发送一个字节&＃xff0c;可见是非常浪费的&＃xff0c;如果B继续只处理一个字节&＃xff0c;那么A就会一个字节一个数据包发出来&＃xff0c;这样的话&＃xff0c;在网络上就会有很多A的“小包”&＃xff0c;这就是“糊涂窗口综合征”&＃xff0c;增大了网络传输的负担&＃xff0c;降低了网络效率。

发送端解决“糊涂窗口”——Nagle算法

       为了解决这一问题&＃xff0c;从发送方来说&＃xff0c;最直接的办法就是避免发送“小包”&＃xff0c;这就是Nagle算法的作用。

       Nagle算法的核心就是&＃xff1a;如果发送缓存区的是“小包”那就延迟发送&＃xff0c;如果是“大包”那就直接发送。

       在发送缓存中&＃xff0c;当数据一个字节一个字节地进来&＃xff0c;发送方就会先把第一个数据字节发出去&＃xff0c;把后面的数据缓存起来。当发送方收到了接收方对于第一个数据字节的确认后&＃xff0c;就会把发送缓存中的数据组成一个报文段发送出去&＃xff0c;并且对之后到达的数据继续缓存。只有等到收到前一条报文的确认后才继续发送下一条报文。这种等待前一条报文确认的过程&＃xff0c;实际上就是一种延迟&＃xff0c;通过延迟来不断积攒“小包”&＃xff0c;直到收到确认&＃xff0c;就表示延迟结束&＃xff0c;就发出这些积攒的“小包”。当然&＃xff0c;在确认还未发回时&＃xff0c;可能“小包”就已经积攒成了“大包”&＃xff0c;此时就无需再等待确认发回&＃xff0c;直接发出“大包”即可。因此&＃xff0c;Nagle算法还规定&＃xff0c;如果发送缓存中的数据已经达到了发送窗口大小的一半&＃xff0c;或者已经达到了MSS大小&＃xff0c;那么就认定其为“大包”&＃xff0c;直接发送即可。

总结来说&＃xff0c;Nagle算法会在以下两种情况下发送&＃xff1a;

1.发送缓存区中没有未被确认的数据&＃xff1b;

2.发送缓存区中的数据长度达到发送窗口大小的一半或者大于一个MSS。

否则继续缓存数据。

接收端解决“糊涂窗口”——伪零窗口响应

        Nagle算法是从发送方的角度出发来解决“糊涂窗口综合征”&＃xff0c;而从接收方角度出发也有相应办法解决&＃xff0c;其解决思路是&＃xff1a;

        当B的窗口大小降为0后&＃xff0c;即使接收缓存区中的有数据被处理&＃xff0c;如果空闲出来的窗口大小仍然只能容纳“小包”&＃xff0c;那么接收方反馈给发送方探测报文的还是“接收窗口大小为0”。换句话说&＃xff0c;只有当接收方的窗口大小能够容纳“大包”&＃xff0c;接收方才会允许发送方发送数据给它。

这里的所说的“能够容纳‘大包’的窗口大小”是指满足以下两种情况之一&＃xff1a;

1.接收缓存区足以容纳一个MSS大小的报文&＃xff1b;

2.接收缓存区有一半的空闲空间。

        以上两种方法可以配合使用来解决“糊涂窗口综合征”。不过这两种方法虽然在广域网这种网络流量大的场合有不错的效果&＃xff0c;但是在局域网这种流量小的网络中就可能显得得不偿失了。因为它们始终是通过延迟来避免“小包”传输的&＃xff0c;而在网络流量小的场合&＃xff0c;即使是传输“小包”影响也不会有多大&＃xff0c;这种延迟是没有必要的&＃xff0c;还可能导致不能及时响应请求的情况发生。

拥塞控制

        流量控制的对象往往是点对点通信量的控制&＃xff0c;通过接收端来控制发送端的数据发送速率&＃xff0c;从而使得接收端来得及接收。而拥塞控制则是针对于整个网络&＃xff0c;用来防止过多的数据注入到网络中的&＃xff0c;主要关注整个网络的输入负载是否是这个网络所能承受的。

        通过流量控制&＃xff0c;可以实现对发送窗口的控制&＃xff0c;根据接收方的接收能力来限制发送方的数据发送速率&＃xff0c;而现在还要考虑网络的拥塞状况。为了考虑拥塞状况&＃xff0c;发送方会维护一个叫做拥塞窗口cwnd的状态变量&＃xff0c;这个变量会限制发送方在一个传输轮次中所能发送的最多报文数量。这里所提到的“一个传输轮次”&＃xff0c;是指发送方将所有允许发送的报文全部发送后&＃xff0c;到收到最后一个发送报文的确认的整个过程。

       那么&＃xff0c;这个拥塞窗口与前面提到的发送窗口有什么关系呢&＃xff1f;实际上&＃xff0c;前面流量控制中提到的发送窗口是考虑接收方的接收能力&＃xff0c;其大小也就等于接收窗口&＃xff0c;而这里的拥塞窗口是考虑网络状况的&＃xff0c;因此&＃xff0c;发送方在实际发送数据时&＃xff0c;最终会取二者中较小值作为发送窗口的大小。因此&＃xff0c;拥塞控制实际上就是控制这个拥塞窗口的大小&＃xff0c;控制方法有以下4种&＃xff08;不考虑流量控制&＃xff09;&＃xff1a;

慢启动与拥塞避免

慢启动

慢启动算法原理

       慢启动的算法原理是&＃xff1a;一开始先将cwnd大小设置为1&＃xff08;1个MSS大小&＃xff09;&＃xff0c;即允许发送一个MSS大小的数据&＃xff0c;此时发出1个报文段M1。当M1确认后&＃xff0c;cwnd加1成为2&＃xff0c;允许发送2个MSS大小的数据&＃xff0c;此时就连续发出2个报文段M2、M3。当M2、M3确认后&＃xff0c;cwnd加2为4&＃xff0c;允许发送4个MSS大小的数据&＃xff0c;此时就连续发送4个报文段M4&＃xff5e;M7……如下所示&＃xff1a;

       简单来说&＃xff0c;通过慢启动算法&＃xff0c;每经过一个传输轮次&＃xff0c;当发送方收到最后一个报文段的确认后&＃xff0c;cwnd的大小就加倍&＃xff0c;由此使得大量需要连续发送的报文段“慢慢发送”而不是全部突然注入网络&＃xff0c;从而避免网络拥塞现象。

慢启动算法存在的问题

        慢启动算法使得cwnd以指数型增长&＃xff0c;没经过一次传输轮次就加倍一次&＃xff0c;而cwnd一旦增大到某个值&＃xff0c;就相当于允许连续发送很多报文段&＃xff0c;那么拥塞控制的效果也就没有了。也就是当出现网络拥塞后&＃xff0c;一旦一次发送的报文数超过了某个值&＃xff0c;那么发出的报文就容易出现超时未确认的情况&＃xff0c;而指数型增长的cwnd是很难控制的。

       举个例子&＃xff0c;cwnd加倍到一次可以连续发送16个报文段&＃xff0c;当这16个报文段全部返回确认后&＃xff0c;cwnd再次加倍为32&＃xff0c;此时暂且还没有出现拥塞的情况。到了下一轮次&＃xff0c;就该连续发送32个报文段了&＃xff0c;如果在发送第17个报文段的时候就出现了网络拥塞&＃xff0c;那么17后面的报文段就都可能超时而收不到确认&＃xff0c;发送方就会选择重发&＃xff0c;这样就只会造成网络堵塞更加严重。

        为了避免这一问题&＃xff0c;比较好的方法就是减缓cwnd的增长速度&＃xff0c;而这也就是拥塞避免算法的作用。

拥塞避免

        拥塞避免算法的思路就是减缓拥塞窗口cwnd的增长速度&＃xff0c;它的实现方式是每经过一个往返时间RTT就让cwnd加1&＃xff08;加上1个MSS的大小&＃xff09;&＃xff0c;这样就避免cwnd在轮次结束时直接加倍引起指数型增长&＃xff0c;通过拥塞避免算法&＃xff0c;使得cwnd每次只加1&＃xff0c;成为缓慢的线性增长&＃xff0c;在这种增长模式下&＃xff0c;当发送方判断出现了网络拥塞后可以立即做出反应。

慢启动与拥塞避免结合

       那么&＃xff0c;既然要减缓拥塞窗口增长速度&＃xff0c;那直接让cwnd每次自增1就可以了&＃xff0c;为什么还要用指数增长的慢启动呢&＃xff1f;

       这是因为一开始cwnd本身就比较小&＃xff0c;在较小的范围内&＃xff0c;相比缓慢的线性增长&＃xff0c;让cwnd增长更快一些也可以提高效率&＃xff0c;而cwnd越来越大&＃xff0c;当增长到某个值的时候就应当缓慢增长&＃xff0c;以此避免网络拥塞。因此&＃xff0c;慢启动算法与拥塞避免算法应当配合来使用&＃xff0c;当cwnd较小时采用慢启动算法&＃xff0c;而当cwnd较大时采用拥塞避免算法。

       因此&＃xff0c;还应当考虑二者之间的界限&＃xff0c;即何时由慢启动转为拥塞避免&＃xff0c;这就需要设置一个慢开始门限ssthresh状态变量&＃xff1a;

当cwnd

当cwnd>ssthresh时&＃xff0c;停止使用慢启动算法开始使用拥塞避免算法&＃xff1b;

当cwnd&＃61;ssthresh时&＃xff0c;既可以使用慢启动算法&＃xff0c;也可以使用拥塞避免算法。

慢启动与拥塞避免举例

       如上图所示&＃xff0c;设置ssthresh的初始值为16。在前面的几次传输轮次中采用慢启动算法&＃xff0c;此时cwnd以指数规律增长。

       第4个传输轮次结束后cwnd加倍到了16&＃xff0c;达到慢启动门限值&＃xff0c;此时采用拥塞避免算法&＃xff0c;cwnd开始线性增大。

       到了第12个传输轮次&＃xff0c;cwnd&＃61;24。报文发出后&＃xff0c;发送方突然发现有报文超时未确认&＃xff0c;尽管引起超时的情况有多种&＃xff0c;但是此时发送方只会认为是网络拥塞引起的&＃xff0c;也就是说此时的网络状况非常不好&＃xff0c;需要“缓解一下”。因此直接将cwnd降到1&＃xff0c;通过少发数据来缓解网络拥塞。除此之外&＃xff0c;发送方还会减小ssthresh值&＃xff0c;将ssthresh减少为发生拥塞时cwnd值的一半&＃xff08;如上图中cwnd&＃61;24时发生网络拥塞&＃xff0c;于是就将ssthresh减小为24的一半为12&＃xff09;&＃xff0c;这就相当于通过提前降低cwnd增长速度来缓解网络拥塞。

快速重传与快恢复

       快速重传&＃43;快恢复算法是在慢启动&＃43;拥塞避免算法上进行补充与优化的算法。       

快速重传

       在慢启动&＃43;拥塞避免算法下&＃xff0c;发送方认为发生“网络拥塞”的根据是因为发出的数据包超时未确认&＃xff0c;也就是说&＃xff0c;如果有个数据包丢了&＃xff0c;那么就必须等到超时后下一个传输轮次再进行重传&＃xff1b;而快速重传则是指&＃xff1a;它要求接收方每收到一条失序报文段就立即确认&＃xff0c;如果发送方收到了三次同一个报文的冗余ACK&＃xff0c;此时发送方就会认为该报文段丢失了&＃xff0c;那么不必等到超时计时器超时就立刻进行重传。通过快速重传可以使得网络的吞吐量提升20%。如下所示&＃xff1a;

快恢复

       对于采用快速重传的发送方来说&＃xff0c;当收到多次冗余的ACK后&＃xff0c;它虽然会认为该报文段丢失了&＃xff0c;但是它也会认为“很有可能没有发生网络阻塞”&＃xff0c;因为如果发生了网络阻塞&＃xff0c;那么也不可能收到多次冗余的ACK了。

       而在慢启动&＃43;拥塞避免算法下&＃xff0c;在报文发生了超时未确认后&＃xff0c;发送方就会认为此时肯定发生了网络拥塞&＃xff0c;因此为了缓解网络拥塞&＃xff0c;就将拥塞窗口cwnd大小会减为1&＃xff0c;然后执行慢启动。

       由于是“很有可能没有发生网络阻塞”&＃xff0c;因此对于采用快速重传的发送方来说&＃xff0c;就没必要将拥塞窗口cwnd降到1&＃xff0c;这样会做无谓的效率牺牲&＃xff1b;但是为了降低网络拥塞的可能&＃xff0c;也不能不降低cwnd。因此&＃xff0c;在这种情况下&＃xff0c;发送方就选择降低一部分cwnd&＃xff0c;那么具体降低多少呢&＃xff1f;这就是快恢复算法所做的事了&＃xff1a;

在发生3次冗余ACK后&＃xff0c;快恢复算法主要按序完成以下几件事&＃xff1a;

1.慢启动门限值ssthresh设置为发生拥塞时cwnd的一半&＃xff1b;

2.拥塞窗口大小cwnd设置为ssthresh&＃43;3&＃xff1b;&＃xff08;这里依然以一个MSS的长度为单位&＃xff0c;之所以还要再加上3&＃xff0c;是因为发送方既然收到了3次冗余&＃xff0c;那就说明前面发送的多个报文段中至少有3个报文段已经成功接收了&＃xff0c;因此这一次可以多发送3个报文段&＃xff09;

3.如果再收到相同的冗余ACK&＃xff0c;拥塞窗口大小就再加1&＃xff1b;如果收到的是新报文的ACK&＃xff0c;那么就复原慢启动门限值ssthresh&＃xff0c;然后执行第4步&＃xff1b;&＃xff08;即ssthresh再次回到发生快恢复前的状态&＃xff09;

4.执行拥塞避免算法。

慢启动&＃43;拥塞避免&＃43;快速重传&＃43;快恢复综合过程

         四种算法综合执行过程如下图所示&＃xff1a;

总结

        流量控制是从接收方的数据接收能力出发来控制发送方的数据发送速率的&＃xff1b;

        而拥塞控制是发送方考虑整个网络的状况而对其自身数据发送速率进行控制的。

        因此&＃xff0c;作为数据发送方&＃xff0c;应当同时考虑接收方的“接收窗口”rwnd以及发送方自身的“拥塞窗口”cwnd&＃xff0c;最终发送数据时采用的“发送窗口”swnd不能大于二者的较小值。即swnd≤Min(rwnd,cwnd)。

        换句话说&＃xff0c;如果rwnd

        反之&＃xff0c;如果rwnd>cwnd&＃xff0c;说明此时是网络中的拥塞状况限制了发送窗口的最大值。