周六,由于要赶一个月底的Deadline,因此选择了在家VPN加班,大半夜就爬起来跑用例,抓数据...自然也就没有时间写文章和外出耍了...不过利用周日的午夜时间(不要问我为什么可以连续24小时不睡觉,因为我觉得吃饭睡觉是负担),我决定把工作上的事情先放下,还是要把每周至少一文补上,这已经成了习惯。由于上周实在太忙乱,所以自然根本没有更多的时间去思考一些“与工作无关且深入”的东西,我指的与工作无关

TCP BBR   拥塞控制时序图  

bbr算法比较简单也比较容易理解,所有关于它的优化也就同样不复杂了。         请注意,任何优化都只针对特定场景的,根本不存在一种放任四海而皆准的算法。我们分析Google的测试报告时,比较容易被忽视的是其bbr算法的部署场景。如果可以完美复现Google的B4网络,那么测试结果应该就跟Google是一致的,但不得不说,bbr算法内置了很多的参数(目前的版本中是写死的),Google方面有没

TCP BBR   TCP CUBIC   TCP拥塞控制  

我一再强调,BBR算法是个分界点,所有的TCP拥塞控制算法,被分为BBR之前和BBR之后的(其实发现,这并不是我个人的观点,很多人都这么认为,所有想写本文探个究竟)。当然这里的”所有“并不包括封闭的那些算法,比如垃圾公司Appex的算法,或者伟大的垃圾微软的算法。任何的算法都内含了一个进化的过程,CUBIC和Reno看起来非常不同,但是却属于同一个思想,因此可以说,CUBIC是Reno的高级版本(

TCP BBR   TCP CUBIC   拥塞控制   Van Jacobson  

本文试图给出一些与BBR算法相关但却是其之外的东西。 1.TCP拥塞的本质注意,我并没有把题目定义成网络拥塞的本质,不然又要扯泊松到达和排队论了。事实上,TCP拥塞的本质要好理解的多!TCP拥塞绝大部分是由于其”加性增,乘性减“的特性造成的!         也就是说,是TCP自己造成了拥塞!TCP加性增乘性减的特性引发了丢包,而丢包的拥塞误判带来了巨大的代价,这在深队列+AQM情形下尤其明显。

Google BBR   TCP拥塞控制   TCP BBR   CUBIC   TCP收敛  

在进入这篇文章的正文之前,我还是先交代一下背景。 1.首先,我对这次海马台风对深圳的影响非常准确,看过我朋友圈的都知道,没看过的也没必要知道,白赚了一天”在家办公“是收益,但在家办公着实效率不高,效果不好。 2.我为什么可以在周五的早上连发3篇博客,一方面为了弥补因为台风造成”在家办公“导致的时间蹉跎,另一方面,我觉的以最快的速度分享最新的东西,是一种精神,符合虔诚基督徒的信仰而不是道德约束。 3

TCP BBR   TCP CUBIC   TCP Reno   TCP拥塞控制  

先从需求谈起吧。         在上一篇文章《 Google's BBR TCP拥塞控制算法的四个变速引擎》的最后,我提到bbr算法作为一个标称功率十足的引擎需要源源不断的能源供给,而这类能源就是数据包。又提到,TCP的快速重传机制几乎只会将判断为LOST的数据包重传一次,因此当重传数据包再次丢失,滑动窗口无法滑动的时候,将会无法提供数据包发送,bbr引擎就会失速,此时只能等待TCP的超时!当然

TCP BBR   TCP RACK   TCP拥塞控制  

台风海马来临前的两个几乎通宵的夜晚,我用一篇关于BBR算法的文章的迎接海马!公司在昨晚响应深圳市停工,停课号召,发布了在家办公(请注意,不是放假...)通知...其实吧,我觉得停电才是王道,你觉得呢? 在前一篇关于bbr算法的文章《 来自Google的TCP BBR拥塞控制算法解析》(这可能是第一篇中文版的bbr算法相关的文章)中,我简述了bbr算法的框架,算是大致介绍了。本文中,我想深入bbr算

BBR拥塞控制算法   TCP BBR   TCP CUBIC   TCP  

写本文的初衷一部分来自于工作,更多的来自于发现国内几乎还没有中文版的关于TCP bbr算法的文章,我想抢个沙发。本文写于2016/10/15!         本文的写作方式可能稍有不同,之前很多关于OpenVPN,Netfilter,IP路由,TCP的文章中,我都是先罗列了问题,然后阐述如何解决这个问题。但是本文不同!本文的内容来自于我十分厌恶的一个领域,其中又牵扯到我十分厌恶的一家公司-华夏创

TCP bbr   BBR拥塞控制算法   拥塞控制算法   pacing rate