TCP BBR从Linux 4.9 内核开始,就作为它内核的一部分存在了,如果想使用BBR,那么首先就是判断内核版本是否大于4.9,如果符合版本标准,那么直接启动BBR就可以了,如果低于4.9,升级内核之后启动就行了. 一,使用一键脚本安装和启动BBR. 推荐使用秋水逸冰的一键脚本,具体可以参考: https://www.cnblogs.com/sunylat/p/9521562.html 如果一键脚本不能访问,那么可以下载我在这里保存的秋水逸冰的一键脚本: https://www.cnblog

这是秋水逸冰提供的TCP BBR一键开启脚本,脚本详细说明地址: https://teddysun.com/489.html 按照说明操作就可以了,注意问题:这个脚本获取有的时候可能有问题,如果提示脚本获取失败,多执行几次就可以了. 如果脚本获取失败,那么可以把下面脚本保存到本地,随后上传到要开启TCP BBR的Linux服务器中,在root身份下执行就可以了.下面是秋水逸冰提供的TCP BBR一键开启脚本: #!/usr/bin/env bash # # Auto install latest

TCP BBR 从开启到关闭:以 Debian 9 为例 开启 执行如下命令: echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf sysctl -p 执行lsmod | grep bbr.如果输出类似下面的内容,则说明开启成功: tcp_bbr 20480 0 关

Linux kernel 4.9及以上开启TCP BBR拥塞算法 BBR 目的是要尽量跑满带宽, 并且尽量不要有排队的情况, 效果并不比速锐差 Linux kernel 4.9+ 已支持 tcp_bbr 下面简单讲述基于KVM架构VPS如何开启 安装Linux kernel 4.9以上的版本 一般安装最新版本内核 Debian 8+ / Ubuntu 14.04 下载最新内核 # wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14.1

原文地址: https://teddysun.com/489.html 最近,Google 开源了其 TCP BBR 拥塞控制算法,并提交到了 Linux 内核,从 4.9 开始,Linux 内核已经用上了该算法.根据以往的传统,Google 总是先在自家的生产环境上线运用后,才会将代码开源,此次也不例外.根据实地测试,在部署了最新版内核并开启了 TCP BBR 的机器上,网速甚至可以提升好几个数量级.于是我根据目前三大发行版的最新内核,开发了一键安装最新内核并开启 TCP 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 目的是要尽量跑满带宽, 并且尽量不要有排队的情况, 效果并不比速锐差 Linux kernel 4.9+ 已支持 tcp_bbr 下面简单讲述基于KVM架构VPS如何开启 附:OpenVZ 架构VPS开启BBR (容易导

前言 如果你有订阅一些科技新闻,应该会有看过内核在4.9当中加入了一个新的算法,来解决在有一定的丢包率的情况下的带宽稳定的问题,这个是谷歌为我们带来的干货,新的 TCP 拥塞控制算法 BBR (Bottleneck Bandwidth and RTT),谷歌一向的做法是,先上生产,然后发论文,然后有可能开源,所以这个已经合并到了内核4.9分支当中,算法带来的改变在出的测试报告当中有很详细的数据展示,这个看多了可能反而不知道到底会有什么明显改变,特别是对于我们自己的场景 那么本篇就是来做一个实践的

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

linux上要开启TCP Fast Open,内核版本至少为3.7.0, 且需要设置 /proc/sys/net/ipv4/tcp_fastopen 为3. 开启后,如果有连接进来,使用如下命令查看: grep '^TcpExt:' /proc/net/netstat | cut -d ' ' -f 91-96 | column -t 例如: [root@vmxxx ~]# grep '^TcpExt:' /proc/net/netstat | cut -d ' ' -f 91-96 | col

TCP通信的文件上传案例 本地流:客户端和服务器和本地硬盘进行读写,需要使用自己创建的字节流 网络流:客户端和服务器之间读写,必须使用Socket中提供的字节流对象 客户端工作:读取本地文件,上传到服务器,读取服务器回写的数据 明确数据源 目的地:服务器 客户端代码: package cn.learn.web; import java.io.FileInputStream; import java.io.IOException; import java.io.InputStream; impor

首先确认目前使用内核 uname -r rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm yum --enablerepo=elrepo-kernel install kernel-ml -y 查看内核列表,第一个的编号是 0 egrep ^menuentry /etc/grub2.

要求内核为4.9以上,如果不是,请升级内核. modprobe tcp_bbr echo "tcp_bbr" >> /etc/modules-load.d/modules.conf echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf

1. 准备 升级内核需要4.9 以及以上   2.  yum  内核升级       a. 添加 ELRepo 源 GPG key rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org       b. 添加 centos-7 源 rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm      c. 安装 fastestmirrot (可选

TCP BBR 是Google给出的一个改良版的tcp网络协议,相当于在已有TCP协议的基础上打了个补丁的意思,这个改良版TCP协议对拥塞控制有很好的支持,对于网络较差的环境有不错的应用场景,当然这里我们最常用的一个场景就是外网VPN上的,因为网络太差,能改进一些算一些,该协议的一些解释本文不讲,本文主要是讲一下在最新版Ubuntu18.04中如何设置bbr功能,因为在Linux4.9内核开始,bbr协议已经加入到Linux内核之中,如果所使用的Linux系统内核版本大于4.9,就可以直接启用b

BBR 目的是要尽量跑满带宽, 并且尽量不要有排队的情况, 效果并不比速锐差Linux kernel 4.9+ 已支持 tcp_bbr 下面简单讲述基于KVM架构VPS如何开启附:OpenVZ 架构VPS开启BBR (容易导致判定滥用ban机,慎用!)Debian/Ubuntu TCP BBR 魔改版 (不支持4.13.*及更新的内核)Debian 8+ / Ubuntu 14 下载最新内核,最新内核查看这里wget http://kernel.ubuntu.com/~kernel-ppa/ma

在linux里用 wget --no-check-certificate https://github.com/teddysun/across/raw/master/bbr.sh chmod +x bbr.sh ./bbr.sh 安装完成后,脚本会提示需要重启 VPS,输入 y 并回车后重启.重启完成后,进入 VPS,验证一下是否成功安装最新内核并开启 TCP BBR,输入以下命令: uname -r查看内核版本,含有 4.13 就表示OK 了 sysctl net.ipv4.tcp_avail

上个月买的vultr的vps 感觉看视频还是比较慢的 于是上网找教程开启BBR加速 在这里记录一下 以后可能会用到 BBR 是 Google 提出的一种新型拥塞控制算法,可以使 Linux 服务器显著地提高吞吐量和减少 TCP 连接的延迟. BBR解决了两个问题: 再有一定丢包率的网络链路上充分利用带宽.非常适合高延迟,高带宽的网络链路. 降低网络链路上的buffer占用率,从而降低延迟.非常适合慢速接入网络的用户. 高延迟高带宽,这不就是我吗..... 升级内核 开启 BBR 要求 4.10

最近,Google 开源了其 TCP BBR 拥塞控制算法,并提交到了 Linux 内核,从 4.9 开始,Linux 内核已经用上了该算法.根据以往的传统,Google 总是先在自家的生产环境上线运用后,才会将代码开源,此次也不例外.根据实地测试,在部署了最新版内核并开启了 TCP BBR 的机器上,网速甚至可以提升好几个数量级.于是我根据目前三大发行版的最新内核,开发了一键安装最新内核并开启 TCP BBR 脚本. 本脚本适用环境 系统支持:CentOS 6+,Debian 7+,Ubunt

背景 近期开通了一条访问美国机房的 1G 专线,用于提供行情数据备源,并基于 TCP 建立了一套数据传输服务.上线后发现一个严重的问题:应用程序发送队列中的数据大量积压,最终导致程序 OOM Kill,但观察监控发现专线带宽利用率只有 50% - 60%. 经过沟通,发现运维同事当时使用 iperf3 测试专线带宽使用的是 UDP 协议,于是在运维同事协助下使用 TCP 进行二次测试,发现了比较严重的问题: 在国内机房使用 iperf3 测试单个 socket 流量,在同机房内部(1G交换机)可

上周有同事问,延迟ACK到底对应用层会产生什么后果,我也不知道该如何作答,于是丢了一个链接: TCP之Delay ACK在Linux和Windows上实现的异同-Linux的自适应ACK: 是的,这是我几年前关于Delay ACK的分析,如今看来有些许不足,有些空洞,有些学院派,所以本文试图就着这个问题来分析一个关于Delay ACK以及带来相似后果的聚集ACK,以及ACK丢失等等的具体的场景,即ACK失速问题,简称TCP失速.   之所以会在假期写这篇文章,还有两个原因,首先感谢fcicq大神