对 Google TCP BBR 的浅薄认识

关于 Google 发布的新的 TCP 拥塞控制算法 BBR (Bottleneck Bandwidth and RTT) 的一些记录,仍然在学习中,难免有误解。之后会持续修正和完善。 网络链路上的包比较少时,道路很通畅,这个阶段,对于一个 TCP 连接来说,它的速度由这个连接两端之间的距离决定,也可以说是由 RTT 决定。当发包速率变大,把道路基本上填满了之后,这个阶段,带宽的大小决定了这个连接的速度,这时两端之间可能就会有包要排队,延迟时间除了 RTT 还有排队时间。 BBR 目的是要尽量跑满带宽,并且尽量不要有排队的情况。 cwnd 是普通的拥塞控制算法里最终要求得的一个值,用来控制发包速率。BBR 也要求到这个值,但是它不是最主要的控制发包速率的变量,主要的变量是 pacing_rate。 这两个变量都由探测到的带宽值和 RTT 值得到,整个过程都围绕着这两个值。在 BBR…

利用 ipset 封禁大量 IP

使用 iptables 封 IP,是一种比较简单的应对网络攻击的方式,也算是比较常见。有时候可能会封禁成千上万个 IP,如果添加成千上万条规则,在一台注重性能的服务器或者本身性能就很差的设备上,这就是个问题了。ipset 就是为了避免这个问题而生的。 关于 iptables,要知道这两点。 iptables 包含几个表,每个表由链组成。默认的是 filter 表,最常用的也是 filter 表,另一个比较常用的是 nat 表。一般封 IP 就是在 filter 表的 INPUT 链添加规则。 在进行规则匹配时,是从规则列表中从头到尾一条一条进行匹配。 这像是在链表中搜索指定节点费力。ipset 提供了把这个 O(n) 的操作变成 O(1) 的方法:就是把要处理的 IP 放进一个集合,对这个集合设置一条…

好好写 Shell 脚本

shell 种类众多,并且语法各异,如果自己又不熟悉任何一种 shell 的话,就会经常感觉语法怪异,而且似乎不够严谨,甚至有时候要边搜边写,这就使得一些脚本成为了一些勉强可用的语句的拼凑,几乎不可维护。即便是一些所谓的“技术大牛”,各种高大上的词都能吹得天花乱坠的,也写不了像样的脚本,这是个蛮尴尬的事情,固然是术业有专攻,但是写个 Linux Shell 脚本,应该算是个基础(其实有可能他们连链表怎么实现都不知道)。这里主要是说最为通用的 bash,以下是几条 bash “代码规范”。 1. 及早退出 脚本的开头,#! 语句之后,加上这几行 set -o errexit set -o pipefail 第一行语句的作用是,在脚本执行过程中,如果有错误,就退出脚本,不再继续下去。如果一条语句执行完,返回值不是 0,就是错误。 第二行语句的作用是,如果脚本中有一行命令是由一个或多个管道连起来的多个命令,…

free 命令 buffers 和 cached

大多数 Linux 用户应该都知道通过 free 命令或者 cat /proc/meminfo 查看内存使用情况。 下面是 free 命令结果的一个示例: total used free shared buffers cached Mem: 2049916 1139976 909940 680 105628 381768 -/+ buffers/cache: 652580 1397336 Swap: 0 0 0 第一行 Mem 第一列值 2049916 表示总共有多少物理内存 (total) 第二列 1139976 表示已使用了多少内存 (used) 第三列表示未使用的内存 (free) 第二列和第三列,即 used 和…

Linux 信号处理

使用 sigaction 绑定信号 比较早的时候,使用 signal,现在正在逐渐被抛弃,sigaction 是更好的选择。主要是因为如下原因: signal 在不同系统的行为可能不一致,如果自定义了信号处理函数,进入信号处理函数时,对当前信号的操作可能变为默认,也可能屏蔽该信号。只有设置信号处理方式是 SIG_IGN(忽略)、SIG_DFL(默认)是可移植的。 signal 不能设置在信号处理函数执行过程中屏蔽其他信号 在多线程的进程中 signal 的效果不确定 signal 接口最主要的问题还是不可移植,其实现在 Linux 上的 signal 是对 sigaction 的一个封装。sigaction 有更灵活和强大的功能,现在通常使用 sigaction 绑定自己定义的信号处理函数,改变处理信号默认方式,当然用起来比 signal 也要复杂一点。 常见用法如下: void handler(…