- 博客(2191)
- 资源 (4)
- 收藏
- 关注
RSS订阅原创 未来的拥塞控制与 Linux EEVDF 调度器
之前的调度器之所以引入那么多 “启发式” 把戏都不尽人意，就因为无论多么大的权重，很容易被那些来无影去无踪，不易捕捉的 “紧急” 小事不停打断，比如 hardirq，softirq，做过系统运维的都知道，一旦 hardirq 不均衡，softirq 高了，系统就抖动了，这是不公平的根源，也是低效的根源，但一直以来 Linux 调度器都没有把这些 “闪客” 纳入管理，这次 EEVDF 做到了，我觉得这就是一个四象限调度器。因此，难点是如何将上述算法迭代得更优秀，而不是如何钻空子。，未来该如何，谈谈我的看法。
2023-11-13 01:15:00
11917
原创 谈谈越来越无效的拥塞控制
典型的例子是 CSMA/CD 和交换机，前者场景下该比值很小，引入随机就够，别的什么都别做，就像猜硬币，盲猜 50% 就 OK，任何启发只能削弱准确性，而后者场景下该比值非常大，便可以采用精确调度的方式。和本文结合(联合，而不是反驳)的是另一个观点，随着带宽增加，app-limited 将越发可能，资源丰富时资源匮乏时的控制方式是根本不同的，早在农业时代，动力是稀缺的，人们倾向于节省动力，发展是收敛的，到了工业时代，动力是丰富的，人们倾向于不在乎甚至浪费动力，发展是粗旷野蛮的，就这个意思。
2023-11-12 20:58:56
13399
2
原创 教你如何 TCP 抢带宽
这种考虑的背后逻辑是，TCP 应用太广泛了，几乎涉及互联网的一切，互联网端 “几乎就是” TCP，如果一个随意的算法被普遍部署，稍微不慎的缺陷(不管有意的还是无心的)将伤害整个互联网传输，影响巨大。门槛问题一定要说，写个 TCP 发包(这里不再说 cc，因为除了套用了 Linux tcp cc 框架，剩下的事和拥塞控制无关，相反，它在制造拥塞)算法不难，麻烦的是很多人并不了解如何让自己的一些简单想法落地，而这个很简单，只要做过就忘不了。so，小作怡情，大作伤身，出来混早晚要还的，别玩脱手。
2023-11-11 16:45:00
12532
原创 有趣的 TCP 抢带宽行为
总有人说不受控的 udp 要比 tcp 快，其实一个优秀的 udp-based 协议并不比 tcp 快，它至少把 tcp 那些东西重新在 udp 上实现了一遍，比如 quic，最后就成了 yat-yet another tcp 了。如果放宽算法的公平性约束，抢带宽，让带宽就自然多了，非常像高速公路的场景了，你想快就快，不太过分且我也没啥急事就让让你，当然，我也一样。，很多人找我讨论，浓缩成一句话，就是 “死道友而不死贫道”，我的简历上写着这些把戏能带来什么，我的 blog 上写着这么做是多么无耻，哈哈。
2023-11-11 12:30:54
15492
1
原创 可恶的 TCP 加速
你又要说了，网络就是慢，我有办法为啥还不能用了。你想更快到深圳，坐飞机，坐高铁啊，开着你那破宝马奥迪特斯拉作死就不对了，你快了，别人躲着你就慢了，别人不躲着你，你俩都死了。和信道 “漏水” 丢包不同，拥塞丢包是正反馈，参考 codel 算法，拥塞时，发送越快，丢包越多，分分钟教你做人，立正挨打。总之，一切责任在运营商，特别最后一段，我和运营商的合同里签约了一个速率，但运营商没有兑现，我自己有办法，我没错。
2023-11-09 20:58:57
13159
1
原创 提高 bbr 的灵敏性
能在开始抗噪，但噪声持续就不是噪声了，持续时间和反应窗口负相关就能快速反应，线性回归虽显粗糙，但就是这意思，越高阶，越精确，越麻烦，而原值本就有噪声，上限再怎么也无法突破，视必要而选择，这就是自适应。所谓启发式，信息非常有限时，你能控制到什么程度，无非就是榨干这些信息，原值，导数，二阶导数，二阶导数的导数，说到底就是揭露隐藏的趋势，差不多就行了。在细微处所有大开合场面都躲过去了，却还无碍于越过第一个波动，大轮子过坑稳，小轮子坡道强，就是这意思。越多就越少，越少就越多，玩的就是负反馈。
2023-11-08 01:30:00
12998
原创 布雷斯悖论和借贷式拥塞控制
总之，负反馈也好，自抑制也罢，让占便宜的收益递减，不占便宜的吃亏递增，or 占便宜的惩罚递增，不占便宜的奖励递减，系统就会自动收敛到高效和公平，结合经济规律以及人口规律的周期性，这就是我那个 借贷式拥塞控制 的缘起和初衷。再回到最上面 wiki 的例子，如果近路不再 0 成本，而是第一天收 1 元，第二天收 2 元，第一天走原路奖励 1 远，第二天走原路奖励 2 元，结合时间货币成本自行考量，新路顺利提升了通行效率。容易发现，越宽的路，堵车时越壮观，无论多宽的路，似乎总是被填满。没有动机作恶才是最好的。
2023-11-04 01:00:00
12999
原创 闲谈自适应借贷式拥塞控制
总之用它调教你的算法就对了，我此前总是抱怨 bbr probe 会挤压带宽，但我并没有把握说当 deliver_rate < gain * pacing_rate 时将 probe 完全回退是合理的，因为还要考虑到 n 退 1，n 非常大的场景，由排队理论知道这是一定要通过 buffer 重新分配带宽的，考虑到和 aimd 共存场景就更不能完全回退了，那么借贷式算法提供了另一个自平衡视角。其次，借贷式拥塞控制算法如何动态适应带宽变化。浙江温州皮鞋湿，下雨进水不会胖。皮鞋没有蹬上，露着白袜子。
2023-11-03 02:15:00
16898
原创 rate-based 借贷式拥塞控制算法
由 bpd = pacing_rate * rtt，可得一个恒等式 rtt = bdp * (1 / pacing_rate)，而不占 buffer 时的 bdp 就是 cwnd 指示，于是可将 burst 率表示为 cwnd 的倒数，d_burst = 1 / cwnd，可乘上一个系数作可调参数，即 d_burst = beta * (1 / cwnd)，恰好保持 rtt 不变，即无 queue 的意思，注意，它既是因又是果(确实比较烧脑)。还是那句话，放大了就是马赛克，缩小了你的眼睛又看不清了。
2023-10-31 22:50:59
19825
原创 异步 AIMD 收敛
全局同步是一个有趣的共振现象，所有互不可见的参与方在独立执行相同策略时，共同进退。这是所有参与方的合力与外界环境作用的结果，环境的反作用是一视同仁的，所以这种作用和反作用具有叠加放大的趋势。和同步 AIMD 相比，异步 AIMD 消除了全局同步造成的同步浪费，一方 MD 出让资源的间隙，另一方可继续占用资源，这就是执行 RED 的理由，从上图可以一目了然看清楚。给出的一直都是同步 AIMD 收敛，所以简单，但不至于 bbr 单流情形退化成简陋。虽然我没有标注太多，它始终没有成为一团乱麻。
2023-10-30 21:21:59
19791
原创 bbr 流相互作用图示
bbr 多流相互作用非常复杂，和右下角的 AIMD 相比，毫无美感，但是看一眼左下角的 bbr 单流情况，又过于简陋，而 bbr 的核心就基于这简陋的假设。浙江温州皮鞋湿，下雨进水不会胖。
2023-10-29 12:45:00
19874
原创 bbr 的 “最优操作点”
按照单向时间分析，结论很明显，如果网络提供了 buffer 用以吸收统计突发，只能将 “当前的过多” 沿时间轴向后搬，以弥补 “未来的不足”，在不可预测的未来同样过多时，buffer 则堆积，buffer 的大小影响的只是堆积程度。前面餐厅的例子有个附加条件，好吃的餐厅才会排队，事实上这个条件完全可以去掉，任何统计复用系统，只要它将要满载，那么排队就是必然的，对于独立排队实体而言，该排队是不可预测和不可分析的(但对服务台却可以预测和分析)，即使不基于排队论分析，从单向时间也能自然推导出这一结论。
2023-10-28 13:15:00
19776
原创 《利息理论》指导 TCP 拥塞控制
名著的效果就是提供高强度思维训练，读懂就形成了反射，可融会贯通，相对而言，畅销书就没这效果，过程中可能觉得很哇塞，但主题还是散。端到端 cc 算法作为借贷实体，它有欲望和节制，希望获得更大带宽却不想消耗太多(无论是能量 or 时间)，它要不断平衡自己的策略，就像个人一样，通过不断借贷来修改自己的收入川流(《利息理论》术语)，以达最佳 ROI，或换个词，最佳效能 E = B / T(B 为吞吐，T 为 rtt)，而这就是当一条连接在最小 rtt 下获得最大带宽时达到的最佳操作点，这是 bbr 的梦想。
2023-10-28 08:31:25
19915
原创 网络拥塞控制的经济学原理
无需区分准备金和储备金作用的不同，这两种 “金” 都作为银行的 buffer 存在，以应对客户的存款和贷款需求，平滑二者之间的 gap，比如 user1 存了 100 块，user2 贷走了 50 块，此时 user1 来取他的 100 块，但银行只有 50 块，为了让 user1 正常取款而不违约，这 50 块的 gap 就由银行自己的钱来提供，这显然就是一个 “缓冲” 的作用，姑且将其称作 “备金”，类似水库，为了满足下游源源不断的用水量，必须存一部分水，这都不用解释，非常容易理解。
2023-10-21 13:15:00
11486
原创 劣币驱良币的 pacing 之殇
综上，pacing 严重影响 aimd 流的吞吐性能，并使之偏离 aimd 预期行为，不再零存整取而存零整取，取的是代价，更别谈公平收敛，pacing_rate = cwnd / rtt 闭环阻止了自身的 bufferbloat 贡献，pacing 流本身便不会主动(一种忏悔)执行 md(multiplicative-decrease) 收敛动作，被动的 md 纯被欺负。在一个活泼开放的系统中，到处都是投机，试探，收获，遇险，大概都是窦唯《高级动物》里的词，多是贬义，这是劣币之劣，但却是世界的本真。
2023-10-15 00:15:00
11964
原创 Delay-Based 拥塞控制算法
总之，这篇老论文里能找到一些被人遗忘的点，当前工作大多集中在拥塞识别和传输加速，像 bbr 这种新算法也在这两个 “传统” 方向发力，但再往前看 1989 年更 “传统” 的东西，竟然有 “新东西”，它们也许可以作为拥塞控制算法领域未来发展方向上的路标，也算是 “回归传统” 了。注意公式 2 的最右边项，当个体期望全局最优时，需获得全局信息，换句话说，全局最优要个体间互通有无，对比自私的个体最优，全局最优要额外做功，并不符合自然界最小作用量原则，这或许定性解释了为什么自私策略更普遍，因为它更简单。
2023-10-14 17:45:00
11894
原创 高速公路和 TCP/IP 的负载均衡和拥塞
TCP/IP 的负载不均衡问题归结为 IP 路由(ecmp是后来的派池，不解决根本问题)，但和高速公路导航不同的是，IP 路由是逐跳路由，具体的负载均衡情况取决于路由算法的精度，你把 RTT 加入权重，路由度量自然也就绕开了拥塞段。TCP/IP 网络传输滥用，误用，透支了 buffer，高速公路开车的人也滥用， 误用，透支了 buffer，所以我一直最讨厌的就是那些搞传输优化的人，就跟我讨厌开车的人一样，前几天去阳澄湖，碰到一个人肉占车位的，就是不让位，也不说话，低头看手机，没办法，临走前喊了一句"傻逼！
2023-10-06 16:00:00
12694
原创 高速公路堵车动力学
如上分析，TCP/IP 网络在更短时间周期内重复相同的故事，可以想像，AIMD + burst + aggressiveness 是如何破坏你的 pacing 的。以上的 case 表明，只要高速路口没封，能塞进一辆车就塞进一辆车，剩下的就交给时间和保险公司了。刹车反应时间，刹车反应很快，看见灯即可，即使这样越往后刹车必须越狠，直到几乎停止，以保证不碰撞。加速反应时间，更慢的反应时间与已加速的前车拉开更长的距离，给 SB 加塞以空间。加塞，如果没有 SB 加塞，即使车距再小，一切都会回到稳定状态。
2023-10-06 11:43:36
11867
原创 马尔萨斯《人口原理》读后
很早就知道这个理论，但原著还是第一次读，我将马尔萨斯的理论总结为 “不断膨胀的自身把自身压垮的结局”，其根源在于 “单一方向的作用下，膨胀过程中系统各部分组分的增长是不成比例的”，瞬间就想起一个 case，长胖的过程就是一个逼近马尔萨斯极限的实例，重力是单一方向的作用，由骨骼和肌肉的截面支持力支撑，人长胖的过程中是三维空间的膨胀，横向虽然没有重力作用，但这部分重量依然要转嫁到骨骼和肌肉的横截面去支撑，而横截面显然是在二维空间膨胀的，总会存在一个极限，人胖到自己的骨骼和肌肉再也撑不起自己的重量…
2023-09-29 17:45:00
12088
2
原创 chatgpt 只会死记硬背吗
四则混合运算，数学证明，普通人理解的逻辑，这些对 chatgpt 都不是问题，推而广之对 AI 都不是问题，但 AI 很难发现 “飞机就是一只蜻蜓”，“潜艇就是一条鱼”，也不会从茶壶盖被顶起想到蒸汽动力，归纳起来就是 AI 没有能力求出 x 和 y 的交集，同时又得出 “x 就是 y” 的结论，这是不符合逻辑的，x 和 y 明明就不是一个东西。代入和直觉需要第一人称，需要 “自指的边界”，这对于自由意志或许是必不可少的，一个人可以拥有自己最亲密的人几乎所有的记忆，但当这个人离开后却还是会思念。
2023-09-29 09:45:00
12017
原创 chatgpt，神经网络与拥塞控制
仍以 chatgpt 为例，它的内部结构绝不是文字信息简单堆砌塑造而成，而是表现出一定的结构，训练数据较少时，这种结构不明显，看起来就是堆砌的噪声，随着训练数据增多，好看的结构便涌现出来，这可能是语言本身的结构，也可能是人类逻辑的本质展现，但没人能解释这种涌现到底是什么，就像没人能解释意识是什么一样，它就在那里。人自出生就通过视觉，听觉，触觉不停接收信息，这些信息不停对大脑神经元结构进行塑造，触发它们不停发生变化，所有的记忆由所有神经元状态的集合决定，记忆不是在某处保存了某数据，记忆只是一个状态集。
2023-09-29 05:33:27
11645
原创 nginx 全相联结构的引申
要么把逻辑装进 task(各种 x 程)，托管给系统调度，要么自己调度，总之都是调度，不同的是，托管费省不了，task 内存开销，task 切换的 CPU 开销，无论创建多少 task，可同时运行的也不超过 CPU 核数(再次强调，task 不是资源，CPU，内存才是)，挂起的 task 就是纯消耗资源，比如 TCP 连接的 CPU 开销，不活跃长连接的内存开销。容器不是资源，进程不是资源，线程不是资源，协程不是资源，socket 不是资源，它们只是 “虚拟层”，只有 CPU 核才是资源。
2023-09-16 22:15:00
10625
原创 epoll 的实现
epoll 省去了遍历开销，这意味着并发连接越大且活跃连接越少，epoll 优势越大，反之，如果所有连接都是活跃连接，epoll 反而会损失性能，看看那一大堆代码就会明白，每一条指令都是要花费 CPU 时间的，select 受 1024 限制，poll 就挺好。原因很简单，epoll 没什么神奇的。在早期没有太多的并发连接要处理，select/poll 足以应对，遍历一遍又能怎样。而实现 epoll 的基础设施在早期内核里也没有，所以支不支持的，也不是什么大家关注的事。皮鞋没有蹬上，露着白袜子。
2023-09-16 11:45:00
10641
原创 BBR 带宽估计的延后累加
为过去的事，搅乱当前的安排(schedule)，不值当，那就干脆点，全部干掉好了，广义地说，maybe undo 和 maybe retrans 也不要才好，那就把 old_ack 这个 label 去掉吧。像 bbr 类 rate-based 算法，低估带宽不可怕，它自己的状态机(比如 probe up)能搞定，但高估带宽甚至直接打乱状态机的正常运行，比如 buffer 以非预期方式被占用，竟然因为高估带宽而不是 probe up，则 0.75x drain 就没用了，就像飞机失速很难改出一样。
2023-09-09 21:15:00
12574
原创 从 BBR 失速到带宽探测
理论上，迟到但正常的 ack 是下行链路的独立问题，如果当前记忆中稳定的 bw 恰好合适，上行链路 probe up 行为会造成 queuing，接下来的 drain to target 将回滚掉 probe up 的结果，相当于 probe up 做无用功，在现实的多流共存场景，probe up 行为一定会挤占些 bw 出来，伤害公平性。另一方面，确实只需要遵守一个大原则，而不是精确刻画微观。就像足球，每一场比赛从每一个细节上看是完全随机的，但结果很大程度上却是可预测的，这是既精确又模糊的艺术。
2023-09-09 11:45:00
12209
原创 谁该来负责拥塞控制
源抑制的方案和问题在 RFC 896 提到，彼时是一个端到端拥塞控制方案尚未被引入的干净时期，但现在却是端到端方案也出现了问题的浑浊时期，至少在数据中心，源抑制的思想早就落地，PFC，INT-Based cc 均是源抑制思想的体现，就像 CSMA/CD 反压本地 host，反压上一跳是一个意思。端到端拥塞控制是 1980 年代的一个创举，但它固有的 RTT 滞后性也必须接受，这种端到端方案需要从流自身提取拥塞信息，就需要流的连续性，也就是文初的描述，它无法作用于 one shot pingpong 流量。
2023-09-03 11:45:00
13537
原创 BBR cwnd_gain 的循环依赖 bug
设 delta_interval 为新老 interval 之差，则 delta_max_buffer_used = 1.5 * delivery_rate * delta_interval，保持该值为 0，算出 delta_cwnd_gain 即可，附加到用新的 cwnd_gain 进行 probe up，则始终保持 buffer 最大用量不超过 BDP 的一定比例。索性再粗暴一点，不要改代码，直接将 cwnd_gain 参数改成 3，调参即可，意思差不多，丢包多点儿，不过反正也不在乎，重传猛就行。
2023-09-02 15:15:00
16415
原创 rate-based 拥塞控制吞吐测量
f(x) 以 round 为粒度向前平滑滚动，g(x) 在一个或者几个 round 内平滑滚动，h(x) 间隔固定的足够小但又不至于样本不够的 delta(time) or delta(delivered) 捕捉细节，比如类似 bbr 那般 x rounds 的 win，三者合力刻画链路画像。如果在稳定状态，f(x) = g(x) = h(x)，T = f(x)，与当前 Linux kernel 无异。h(x) 体现的是 delivery rate or rtt 的梯度或者变化率。
2023-09-02 06:15:00
16140
原创 漫谈拥塞控制: pacing rate
总线以太网的冲突表现为交换以太网中的排队，而退避时延表现为排队时延，如果交换机 buffer 有限而 buffer overflow，则可能会引入重传时延，也可归入退避时延的等效时延。既然都一回事，那么总线以太网中出让时间槽在交换式网络中即表现为 pacing 发送，所谓 pacing 就是在发送两个连续的 packet 之间插入一段时间。话虽如此，但很多人依然觉得 burst 好，因为当他使用 pacing 的时候，吞吐确实下降了，这属实你没测量好，而不是 pacing 的锅，说到底还是算法不行。
2023-08-30 23:15:00
10880
原创 现代网络欠 TCP 一个控制信道
最后一笔数据 1460 字节，将其最后 1 个字节 copy 成 1 个或 n 个新报文，跟随着最后一个 1460 字节的报文作为护送，流量开销仅仅是 1 个或 n 个 TCP/IP 头外加 1 个字节，收益是不再需要 timer。花式护送还能检测乱序，以 1460 字节报文的后 3 字节每 1 个字节封装一个护送报文，发送顺序是 2，1，3，如果 SACK 顺序也是 2，1，3，即可立即重传 1460 字节的报文，如果不是，则有概率是乱序，那么再等等，只是别等太久。诸如此类种种，可以异想天开。
2023-08-13 22:15:00
12162
1
原创 短肥网络的 RTT 敏感性
不了解 CDN 调度机制的可做下面的简单实验：ping www.tencent.com 观察时延，找距离你南北分别 500KM 开外的朋友也 ping www.tencent.com，你会发现你们三人所在地解析出来的不同 IP 延时都在十几个 ms 左右，这意味着 CDN 总是将请求调度到距离你最近的地方。delay-based 算法基本假设，吞吐与 RTT 成反比，y = 1/x 图像可看出，x 越小，轻微 x 变化带来的 y 变化越大，短肥管道中，吞吐对 RTT 非常敏感。
2023-08-13 15:30:00
11958
原创 漫谈拥塞控制： a Decade of Wasted Bandwidth?
在这里，n 是一个参数，预估为一个连接在 buffer 里所能被容纳的报文数量，这是个前提，意味着通过 n 个连续报文采集的 RTT 波动是噪声，因为同时排在同一 buffer 里的报文应该具有相同排队时延。RTT 测量不准和抖动是造成算法带宽分配不合理的首要因素，从而引发效率和公平性问题，高估会导致丢包重传，低估影响利用率和公平性，受 a Decade of Wasted Cores 启发，对 RTT 的测量可等同而视之。看一组 RTT 采样：9，10，11，9，28，12，9，3，10，11，…
2023-08-12 13:15:00
11884
原创 漫话拥塞控制：BBR 是个单流模型
和 BBR 单流吞吐到顶即不变不同，多流大 buffer 场景，由于 B1/(B1 + B2) < (B1 + d)/(B1 + d + B2)，BBR probe up 时一定能挤占额外带宽，maxbw-filter 将记录一个偏大的 bw，而其它流并不主动降速，依然保持自身 maxbw-filter 的 bw，它们将共同在 buffer 排队，RTT 越大，inflight 越大，侵占性越强。这样收紧自身，自然就慢慢步入了多流场景了，总之，1 和 n，也是一个参数，要和其它参数联调，注意，是联调。
2023-08-12 06:45:00
11887
原创 kretprobe 和 fexit
同样一气呵成，但没了 int3。箭头指示执行顺序，一气呵成，不涉及内核数据结构锁操作，比 kretprobe 高尚，在 register 时即可将 int3 handler 和 asm_stub 摆置到位，但 int3 的开销也不小，且比 Linux kernel 的锁风格更非标。fexit 的把戏在 2020 年中那段走火入魔的时间玩过不少，没想到就是 fexit 的标准，看来多数人觉得正确的思路它就是正确的。kretprobe 孬，跟朋友简单讨论了相关主题，发现 fexit 高尚。
2023-08-07 23:15:00
12999
原创 漫话拥塞控制：Capacity-Seeking 与 QoE
另一方面，IETF117 CCWG 大会 “Guidelines for Internet Congestion Control at Endpoints” 这一趴也提到，网络拥塞是统计复用网络上必然会发生的事件，没什么大不了的，而持续的网络拥塞却是应该避免的，换句话说，瞬时拥塞是常态，持续拥塞是灾难，这两件事应该分别被处理，然而一直以来的传统算法都没将这两件事分别对待。以 bbr 为例，如果 bbr 高估有效带宽，直接结果是更多流量被注入网络，由于算法误判增加网络总流量，这是预期之外的。
2023-08-06 07:45:00
12567
原创 漫话拥塞控制：BBR
即使考虑车速公平(类比带宽公平)，高速/快速路也能高概率自组织收敛，速度太慢的汽车加速空间非常大，它有很大的概率会被加速，而本来就很快的汽车加速的空间很小，它有更大的概率会减速，最终大家的速度虽然不保证绝对公平，但几乎不会相差太多，从统计分布上看，曲线将非常高且瘦，BBR 收敛到这种情况已经非常 OK，我曾经用 buffer 加速比分析过这一段，不再赘述。驾驶汽车，前面空了就一脚油门，前面刹车灯亮了就减速，偶尔会有急躁的司机变道超车，也会有追尾，但都不是大问题，只要司机目视测速准确，一切就井然有序。
2023-08-05 10:26:04
12696
2
原创 kprobe 和 kretprobe 隐藏的秘密
很长一段时间跨越很多内核版本，多个 kretprobe_instance 以 hlist_node 的方式挂接在以 task 地址 hash 为 key 的 hlist 上，而对 hlist_node 的 CURD 必然涉及 lock，对于高频调用的热点函数，kretprobe 里的这个 lock 相当于自设的路障，hash 到同一个 bucket 的 task 同时调用一个函数时会被串行化，严重影响性能，甚至使系统 soft/hard lockup。这是一个知道的人很少的秘密。还有吗，还有，但不相关了。
2023-08-05 08:15:00
12130
原创 漫话拥塞控制：BBRv3 来啦
多年前第一次做这个，写了一个模块，上线，观察一周，发现效果比没上线好不少，结果另一个工人同样的环境打了我的脸，该工人没有上线任何新东西，指标也比上周好，难道我要把观测周期拉长到一个月吗，我要准备多少对照组，这根本就是错误的方向。但扁鹊和蔡桓公又给了另一种启示，如果一个厂商让你买他家的 cdn 服务，告诉你如果不买你的客户会因你的服务太卡而流失，跟你去医院问医生我这个要不要做手术，医生肯定会说不治将恐深，因为手术是暴利啊，但也有偶尔的情况，商家是对的，你不听，最终司命之所属，无奈何也。
2023-08-03 00:45:00
13488
4
原创 对 tcp out-of-window 的安全建议
而从 Linux 4.x 开始，对于 oow 报文的 ack 就是可回可不回的，取决于 oow 报文到达的 rate，这意味着对标准理解的松动，在我看来，与其不 care，不如 MUST NOT，不要对 oow 报文进行任何响应，连计数器都不更新！总之，对于 receiver，抵制随意的 out-of-window 报文，保护 rcv queue 数据，对于 sender，抵制随意的 in-window 报文，保护 rtx queue 数据。此外，状态防火墙要是丢掉 oow，Keepalive 就用不了。
2023-07-01 17:15:00
9657
原创 TCP 拥塞状态机演进
幸运的是，BBR 后 Linux TCP cc 框架导出了 cong_control 回调足以绕开该 loss-based 拥塞状态机，实现 cong_control 回调重写 vegas 即可实现完整的 delay-based cc。一旦检测到丢包，拥塞状态机转换，cwnd 变小，即使确认非拥塞丢包，依然要忍受小 cwnd，更严重的是，一旦 cwnd 变小，rate-based cc 几乎无法运行，因为没有足够 data 支撑 delivery rate 测量。浙江温州皮鞋湿，下雨进水不会胖。
2023-07-01 11:45:00
15599
一个iptables的stateless NAT模块实现
2014-12-27
模块化的nf-HiPAC
2014-11-21
关于linux内核以及其他个人体会的文集
2009-09-07
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人