TCP BBR算法与Reno/CUBIC的对比

分享一下我老师大神的人工智能教程！零基础，通俗易懂！http://blog.csdn.net/jiangjunshow

也欢迎大家转载本篇文章。分享知识，造福人民，实现我们中华民族伟大复兴！

                我一再强调，BBR算法是个分界点，所有的TCP拥塞控制算法，被分为BBR之前和BBR之后的(其实发现，这并不是我个人的观点，很多人都这么认为，所有想写本文探个究竟)。当然这里的”所有“并不包括封闭的那些算法，比如垃圾公司Appex的算法，或者伟大的垃圾微软的算法。任何的算法都内含了一个进化的过程，CUBIC和Reno看起来非常不同，但是却属于同一个思想，因此可以说，CUBIC是Reno的高级版本( 将一种锯齿换成另一种锯齿而已)，事实上，TCP拥塞控制算法一直处在不断的改进之中，起初，Reno算法，然后就是NewReno，再往后就是各种混战，直到最终落实到了CUBIC，起码在Linux平台是这么一个过程，其它的平台，也是大同小异。
        关于从Reno到CUBIC进化过程的细节，这里不谈，相信80%的人可能并不在乎，另外20%在乎的人可能比我懂得更多，所以，这里不谈。
        ...[但是我还是要把篇幅留下来]
        这里要谈的是BBR和Reno/CUBIC的一致性，这听起来可能让人觉得惊奇，它们不是有本质的区别吗？为什么要说它们的一致性呢？
        我特别感谢Van Jacobson这位大师。虽然他不认识我，我也没见过他，但是他提出的问题导致了Reno，CUBIC直到BBR的诞生，我估计Appex和微软这种只吃饭不拉屎的貔貅也是借鉴了他的思想。
        首先要声明，我并不是Google的粉丝，所以我更能采用公正的眼光看待BBR算法，虽然我一再强调它的多么多么的创新，但是这并不意味着BBR就是最好的，如果把BBR作为一个起点，类似Reno那样的起点，BBR本身也会有一个进化的过程，我希望的是大家都参与这个过程，我能做的只是抛砖引玉。我只是一个宣传者，一个鼓手。顺便说一句，我比较崇拜写出《 大教堂与集市》并且会吹笛子的Eric S· Raymond，他自称自己是一名鼓手(为什么不是笛子手呢？)。
        我们先看一下Van