BBR拥塞控制算法

BBR拥塞控制算法是Google最新研发的单边TCP拥塞控制算法

Linux 内核4.9 已引入这个BBR算法,本人在CAC测试Ubuntu 14.04 安装Linux 4.9内核,延迟优化效果和TCP连接速度提升效果明显好于锐速!

Ubuntu更新内核、开启BBR:https://github.com/iMeiji/shadowsocks_install/wiki/%E5%BC%80%E5%90%AFTCP-BBR%E6%8B%A5%E5%A1%9E%E6%8E%A7%E5%88%B6%E7%AE%97%E6%B3%95

BBR算法科普:http://blog.csdn.net/dog250/article/details/52830576

http://www.zrblog.net/15718.html

时间: 2024-11-25 14:33:31

BBR拥塞控制算法的相关文章

Google's BBR拥塞控制算法如何对抗丢包

我不知道该怎么说.总之,便舍船,从口入,我看不到黄发垂髫并怡然自乐!我不会说什么,除了咒骂!        在BBR之前,存在着两种拥塞控制算法,基于丢包的和基于时延的,不管哪一种都是基于探测的,换句话说,基于丢包的算法将丢包作为一种发现拥塞的手段,而基于时延的算法则是将时延增加作为发现拥塞的手段,它们之所以错误是因为它们的初衷就是错的: 丢包算法: 为了发现拥塞就不得不制造拥塞,这TMD的太JIBA讽刺了,为了戒毒,就必须先TMD的染上毒瘾!然而根本没毒瘾的话何谈戒毒!TCP之所以这么玩我觉得

Google's BBR拥塞控制算法模型解析

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

使用TCP时序图解释BBR拥塞控制算法的几个细节

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

在Wireshark的tcptrace图中看清TCP拥塞控制算法的细节(CUBIC/BBR算法为例)

这是一个令人愉快的周末,老婆上周从上海回来,这周末小小幼儿园组织去坪山秋游,比较远,因此大家都必须早早起来,而我更加有理由起床更早一些来完成这篇短文,因为要出去一整天,如果早上起不来,一天都没什么时间了.        另外,最近有人问我,为什么我总是喜欢在技术文章后面加一些与技术毫不相关的话,我说,咱们小时候学古文的时候,那些古代的作者不也是喜欢在文章最后写一段毫不相关的"呜呼...""嗟夫..."之类的吗?人写文章总是有感而发,所以,点题总是必要的.也有同事问,

TCP拥塞控制算法纵横谈-BBR vs Reno/CUBIC

不管是在工作中,还是平时与技术上的朋友一起讨论关于BBR的问题,都不可避免的会面对"BBR和CUBIC之间的对比"的问题,毕竟CUBIC在Linux平台是默认的拥塞算法,已经好多年了.        现在突然有了个被宣传的神乎其神的BBR算法,如果真的有那么好,那肯定要比CUBIC好,如果真的这样,到底好在哪里呢?如果不是这样,那么问题又是什么呢?我想关于BBR好在哪里这个问题是不必回答的,因为如果在效率和公平性上秒杀了CUBIC,那基本上的结果就是换掉BBR,除了理论工作者没有人会问

我对TCP CDG拥塞控制算法的改进和优化

其实这不是我的优化,我是借用了BBR之力.        借了什么力呢?这是我一再强调的,BBR最大的共享不是为Linux贡献了一个TCP拥塞控制算法(它同时在也BSD上被实现...),而是它重构了Linux TCP的实现!借助BBR对Linux TCP实现的重构,很多之前做不到的事情,现在可以做到了.        简而言之,BBR算法对Linux TCP实现的重构中,将以下三件事完全分离:1.重传哪些包:2.传输多少包:3.实际传输.拥塞控制算法侧重解决上述第2点问题.-----------

让人很容易误解的TCP拥塞控制算法

正文 很多人会认为一个好的TCP拥塞控制算法会让连接加速,这种观点是错误的,恰恰相反,所有的拥塞控制算法都是为了TCP可以在贪婪的时候悬崖勒马,大多数时候,拥塞控制是降低了数据发送的速度. 我在本文中会针对近期跟业内朋友之间的聊天记录,总结出三言两语.        TCP拥塞控制的终极目标绝对不是加快数据发送的速度,这种理解非常自私且肤浅!它的终结目标是在公平占有带宽的前提下无限度提高带宽的利用率!        如果你只关注一个独立的TCP连接本身,那么你也许永远都不可能设计出什么比较好的算

让人非常easy误解的TCP拥塞控制算法

正文 非常多人会觉得一个好的TCP拥塞控制算法会让连接加速,这样的观点是错误的.恰恰相反,全部的拥塞控制算法都是为了TCP能够在贪婪的时候悬崖勒马,大多数时候.拥塞控制是减少了数据发送的速度. 我在本文中会针对近期跟业内朋友之间的聊天记录.总结出三言两语.        TCP拥塞控制的终极目标绝对不是加快数据发送的速度,这样的理解非常自私且肤浅!它的终结目标是在公平占有带宽的前提下无限度提高带宽的利用率! 假设你仅仅关注一个独立的TCP连接本身,那么你或许永远都不可能设计出什么比較好的算法,但

TCP拥塞控制算法-从BIC到CUBIC

本文旨在帮助大家理解TCP CUBIC拥塞控制算法背后的点点滴滴以及其方程式为什么就是那样子的.一直以来,很多人都觉得CUBIC算法非常复杂,涉及到复杂的天书般的"3次曲线"...然而,CUBIC并不像大家以为的那样复杂,之所以觉得复杂是因为没有理解其历史和背景. 本文就是介绍CUBIC的历史和背景的... BIC算法 BIC算法对窗口可能的最大值进行二分查找,它基于以下的事实:1.如果发生丢包的时候,窗口的大小是W1,那么要保持线路满载却不丢包,实际的窗口最大值应该在W1以下:2.如