- 博客(2340)
- 资源 (4)
- 收藏
- 关注
RSS订阅
原创 闲谈IPv6系列文章集锦
本文总结一个目录提纲，只要是给自己看的，记录一下哪些东西已经总结过了。闲谈IPv6-6to4隧道和ISATAP隧道： https://blog.csdn.net/dog250/article/details/88644797闲谈IPv6-说说IPv6地址分配和BGP： https://blog.csdn.net/dog250/article/details/88430415闲谈IPv6...
2019-03-18 22:38:43
42671
40
原创 TCP 传输时 sk_buff 的 clone 和 unclone
如果 skb 发到真实网卡，当网卡中断通知发送完成，该 skb 即可得到释放，但本地环回的 skb 生命周期可是要长得多，比如 loopback_xmit，直接用 tx 路径的 skb 调用 netif_rx 了。至于 skb_copy，pskb_copy，自然就不必说，理解 skb_clone，skb_unclone，kfree_skb 就够了。不管这世界多么无知和操蛋，只要给我一本历史书，给我一个 TCP 疑难问题，或带我到一座可以攀登的山脚下，我就马上元气爆满！
2025-07-12 08:19:48
669
原创 关于学习的方法
我喜欢读史，经常有人问我那么一大坨年代，人名，地名，我是怎么背下来的，还是一样的道理，建立时空图景。读完题目后，脑子里都是句子和逻辑，但没有场景，只有当你将这么大一段话还原成时空中的一个场景时，它是什么才显而易见，解法自然也就有了，所以我一再强调，万能的坐标系，它真的就是万能的，因为它描述的就是世界发生的事件，时间，地点。时序图，TCP 三次握手，四次挥手，协议状态机都是这回事，换成分析 TCP 抓包的 tcptrace 图，也是这个思路，在时空中往往很容易一眼看出端倪，这是我们的眼睛进化出来的本事。
2025-07-06 09:17:28
950
原创 仅做传输层拥塞控制就够了吗?
不控制数据源，即使传输层拥塞控制再好，数据也只是转而塞在 send buffer 里，这里不塞那里塞，最终还是会影响用户体验，即使你为 send buffer 设置了 small queue，还有应用 buffer，总有一个地方会拥塞。头痛医头，脚痛医脚，大概率会造成打地鼠的局面，不要只盯着一个算法的实现本身，要盯着你的需求，你的问题，梳理你的全局架构，控制源头，把算法当工具使，不是反着来。要针对架构优化，而不是对实现优化。道理是相通的，看你如何部署，我见过太多的论文，专利，算法初看没毛病，但着眼点错了。
2025-07-05 11:14:24
1640
原创 拥塞控制的边界：从膝点到崖点
拥塞控制应该在膝点和崖点之间工作，然而膝点的滑落不可检测，而崖点的滑落则可检测，我们知道，Reno/CUBIC 等 AIMD 算法均以崖点为操作点，膝点和崖点之间就叫拥塞避免，对应 Additive Increase，而对崖点的反应就是 Multiplicative Decrease，而 BBR 则以膝点为理想操作点，但也只是理想。于是 “对丢包进行反应” 就成了拥塞控制的基调，至于如何反应，由于考虑公平性，这就需要控制论背景，而不只是一句话的事了，我们都知道，这就是 AIMD。
2025-07-04 23:30:29
1931
原创 用户进程的借壳挂靠之术
task_struct 的这种组织形式类似公司组织架构，部门间可共享资源也可资源隔离，项目组随时成立，员工自由加入和退出还可转岗，总经理有权将公司组织成任意结构，由此类比，就可理解为什么只需要调换几个字段，就可以实现进程挂靠，却又不能自由共享资源了。与组合模式的树形递归结构不同的是，Linux 的 task_struct 模型更偏向资源共享的扁平化组织，通过指针共享资源，而非嵌套包含。照这个做法，可以做点正面的事，比如借鸡生蛋，代孕，将经理的结果说成是自己的。
2025-07-04 22:48:03
982
原创 内核线程的借壳生存之术
若想玩得更花式，可用 do_mmap 在挂靠进程地址空间申请一片可执行内存(PROT_EXEC)，里面写上些代码，起一个线程挂靠于其上，用 do_mmap 申请一片 stack，构造寄存器及返回地址，执行那片代码，那片代码干什么都行，比如 “调用 insmod kthr.ko”，这样想抵赖也不足了。” 我不是搞 TCP 的，我是个工人，泥工，瓦工，木工，机修工，电工，带娃，养狗，种花，种地，做饭，理发啥都会，就是不会跳舞，我也不管这些事有没有前途，和谁都没有冲突。浙江温州皮鞋湿，下雨进水不会胖。
2025-06-28 09:38:47
1820
原创 那些不应该的优化
hlist 就是冲 Hash 的 O(1) 去的，正常情况下它一定很短，如果太长了，要么 Hash 函数不良，要么 Hash bucket 太少，首要解决 Hash 冲突问题，而不是遍历冲突链表的问题。遍历没有了，代价是每个 hlist_head 增加一个 8 字节字段，1000 个就要消耗 8KB 的空间，但这说服不了谁，没人在乎那 8KB，就算 80MB 又如何。所以 hlist_add_tail_rcu 很好，无需优化。但以上的修改却节省不了多少时间。浙江温州皮鞋湿，下雨进水不会胖。
2025-06-28 00:13:20
1654
4
原创 OpenVPN 进入 Linux 6.16 内核喽
OpenVPN 进内核不只优化了拷贝和切换(但标准程序员却总盯着这些)，更多是它以这种方式融入了丰富的 Linux 内核网络生态，比如 Netfilter，iptables/nft，eBPF/XDP，甚至还有进一步 offloading 的可能，直达现代加密硬件和加速卡。2010 年开始我基于 OpenVPN 做了 5 年多，期间做遍了各种数据面，并发以及加解密优化，寻遍了 Linux 内核协议栈的每个角落，到了 2020 年前后，我用这些手艺又吃了两年老本，对 WireGuard 做了几个手术。
2025-06-27 22:34:26
1921
原创 广域网多路径传输
广域网应用用不到超过运营商出售的带宽(如果用到就买更大的)，但广域网接入带宽总波动，不能恒常，这对直播推流，实时播放等恒常带宽需求而言非常不利，应用要不断调整编解码速率以跟随带宽波动，但波动往往随移动，位置，时间而不可预知，因此调整永远是滞后且不准的。这类多路径传输亦属于闭环控制技术，还是那个观点，这类技术为弥补资源差异而存在，随着网络基础设施推陈出新，而恒常带宽诉诸的受体感知能力有上限，再好也不会觉得更爽，资源差异逐渐天然抹平，这类控制技术也就逐渐没了必要。，但重要的是稳定性，而不是总和，
2025-06-21 10:28:13
1936
原创 西班牙大停电与 SO_REUSEPORT 一致性 Hash
Linux 内核一直没有实现一致性 Hash 选择 socket，直到 6.16-rc2，对长连接负载均衡，热升级带来了极大的复杂性，而 eBPF 技术又未竟全功，实现起来也极其复杂(看看多么麻烦：reuseport socket 热升级)，所以我才又实现了一版 reuseport 一致性 Hash，但同样没开大会，也没派池。总之不过多评价这个算法本身的优劣以及其实用场景，这也不是本文的目的，本文主要集中于它如何出问题，如何让它不容易出问题，以及真的出了问题如何控制问题蔓延的。
2025-06-21 10:12:46
2320
原创 Linux 路由下一跳与源地址选择
当涉及 ECMP 类的多下一跳选择时，本机始发数据会面临源地址选择和下一跳选择的一致性问题，先说上面第一点，源地址尚未确定时，源地址依赖下一跳，于是路由查找寻找下一跳，优先选择与下一跳 “接近”(最匹配) 的网卡 IP 作为 saddr，接下来再选 sport，为了应用 ECMP，saddr，sport 会作为 hash 输入，在多下一跳中选择一个，这次选择与确定源地址时的选择可能不一致。)IPv6 没这问题，因为 IPv6 是后来开大会设计的，有一套严格的源地址选择规范，详见 RFC3484。
2025-06-21 09:39:29
1838
原创 MPTCP 吞吐聚合的神奇方法
如果你有空间和资源，最有效的优化方案就是用它们来换，TCP 很多单机性能问题都源自端口号，序列号空间太小，加大它们便是，若要你重新设计一个新协议，你还抄 TCP，然后用一些精巧的算法再优化，那就是纯经理了。流控平衡 receiver，sender 的收发缓冲区，拥塞控制平衡 host 和网络的速率，数据包调度平衡数据流(or subflow)间时延，进程调度平衡处理器和进程时间，可见，这类算法的作用力应随资源逐渐均衡而减弱才更有性价比，道理很简单，不必为不需要的功能买单。总之，对齐了时延，调度就最简单。
2025-06-21 09:16:09
2309
原创 说说聚合路由器
再说调度和重组算法，连 iptables，Netfilter 都玩不明白，也就用用 MPTCP，有多少人能有自研协议的能力，说到开源协议魔改，也还是编译和移植，大多数好的产品也就是依仗硬件贵罢了，硬件贵，软件就不重要了，软件是兜下限的，硬件决定上限。可见时延差不离，这种结果在意料之中，就算不同运营商也差不了太多，因为路由规划都是最短路径优先，大家的路径路由统一性非常强，甚至物理传输上都是共享的，差异就在空口，各家基站也差不多，那么就看手机了。三星，iphone 是出名的高档手机，贵有贵的道理。
2025-06-15 09:59:40
2035
原创 二叉树，Hash，网络拥塞的共相解构
连同网络拥塞，当出现很费劲的操作时，总有办法施加一些控制摆脱之，无论是树的平衡操作，Hash 算法，还是路由负载均衡，拥塞控制，背后的力量都会让信息变得混乱而均匀。再看标准 Hash 结构，由于它的 Hash 函数是固定的，所有增量计算则必须重算所有节点，因此它能在内存的代价下保持一个伪装的 O(1)，若非如此，则必须处理冲突，而负载因子不敏感的冲突处理的时间复杂度是 O(n)，O(log n) 的方法对负载因子太敏感，更耗内存，交易还是省不了。我简单说，因为我的能力只能触及其形而上层面，深了我也不懂。
2025-06-14 09:47:55
2599
原创 Linux 内核 TCP 性能真的很差吗？
可见，在高速网络环境，Linux 内核 TCP 的处理实际上成了一个内核零存，task 整取的过程，若 CPU 能力一定，当整个 CPU 核全忙时，处理 TCP 的时间越多，处理业务时间越少，反之如果 CPU 花时间处理业务，留给处理 TCP 的时间就会少，如果将 task 亦看作端到端(数据视角，从数据的产生到消亡)处理一环的话，这里就是个瓶颈点，CPU 能力限制了整体吞吐的上限。在早期的应用编程模型中，阻塞接收很常见，前文提到，那时瓶颈在网络，往往求数据而不得，又没其它事务做，只能等。
2025-06-14 09:02:49
2985
原创 TCP/IP 与高速网络
可以这样理解，数据在主机生成直到网卡发送的时间是 ns 级(至多 us 级)，数据被目标主机网卡接收直到被消费的时间亦 ns 级，在这期间的网络传输时间却没有任何保底承诺，且没有任何反馈承诺，这个时间从 us 到 s 不等，如此大的时延抖动跨度，任何附加手段均无能为力，即使最大强度最理想的流控和拥塞控制附加其上，也只能将抖动压缩至 5~10ms，这对于 400Gbps+ 高速网络依然不可接受，这是 TCP/IP 网络的属性，而非缺陷。网络的核心是拓扑，只有基于全互联规则拓扑构建的网络才能彻底打破僵局。
2025-06-07 11:09:42
4048
6
原创 高速多路径传输之始末
内存拷贝并不约束时序，横着拷贝，竖着拷贝，斜着拷贝，大块拷贝，小块拷贝都非常随意，这就能有效利用好并行资源，比如多路径分别传输不同的文件块，每个文件块都映射到自己的地址，单独一个线程负责周期性查看 hole，随时 nack。所以我经常说，人们根本就不那么在乎单流最大吞吐，大部分人用不了那么大带宽，在很长一段时间，就算人们需要单流大吞吐，也用不起(在 2025 年，即便经理也不敢持续 500Mbps 跑流量)，人们在乎的是很多流的总吞吐，这至少还涉及并发能力，可以几个用户，几条流一起跑。
2025-06-07 07:45:53
3886
原创 MPTCP 聚合吞吐
但必须注意，子路径必须不能太异构，聚合 Wi-Fi，5G，4G，想都别想，不是说不能提升，而是不划算。无论如何，涉及聚合，叠加的案例，都不是简单的加法，都需要方向的一致性，同步协调性，结构稳定性三要素，而作为端到端协议，TCP 天然缺失同步协调性和结构稳定性，这些是尽力而为网络的属性特征，TCP/IP 并不具备任何调优支撑，任何的优化都可以说是粗暴的运气。这么多人频率，方向，力道均一致才能叠加速度，频率不一致会减速，方向，左右力道不一致会减速并跑偏。”，第二局就赢了，但小朋友们也缺失了体验，这怪我。
2025-06-02 10:59:29
4316
原创 scale up 不能优化 TCP 聚合性能
虽然管道可以提供 RTT_Normalized · (S1 + S2) 的带宽，但如果某时刻从左边注入这么多数据，RTT_Normalized 过后，仅流出 RTT_Normalized · |RTT2 - RTT1|/RTT2 · (S1 + S2) 数据，若要流出更多的数据，则必须在更大 RTT2 路径上更早注入数据，如果没有足够的数据提前注入，就要在右侧等待重组，该力度由 α 调节，表现为多路径调度和重组算法，由这些算法决定(前面写过，但不是本文重点)，对于可靠传输，左边不等右边等，怎么优化都没用。
2025-05-31 07:05:22
5073
1
原创 Wi-Fi 切换 5G 的时机
不管信不信，背后也没什么原因，人们每天的行为轨迹在时间序上是有规律的，观察和统计上下班打卡时间，外出跑步时间，坐地铁班次，甚至消费时间，你会惊奇地发现每天几乎都是 “那个点”，误差甚至不超过一两分钟。早上出门上班，关上家门等电梯时，家里 Wi-Fi 信号已经很微弱，但依然坚挺，没即时切到 5G，傍晚下班离开公司，走出大楼时，公司 Wi-Fi 信号已经很微弱，但依然坚挺，没即时切到 5G，这两个时间有那么一两分钟是无法上网的，除非我手工把 Wi-Fi 关闭，等走远了再打开。浙江温州皮鞋湿，下雨进水不会胖。
2025-05-30 23:52:20
5757
3
原创 Hash 的工程优势: port range 匹配
Hash 和 Tree 实际上代表了计算在空间和时间分别展开的两个方向，Hash 的 O(1) 约束下，1 倍的规模增量可带来1 次操作增量，需要 1 倍的内存来抵消这 1 次的操作以维持 O(1)，操作时间不变，对于二叉树，1 倍的规模增量同样带来 1 次操作增量(每增加 1 层，叶子节点数量增加 1 倍)，但这次操作无法抵消，时间永远随规模增加而单调递增，然而由于二叉树在操作过程中天然保序，就意味着其不真需要额外预留 1 倍空间以支撑规模。显然，x 会随内存增加向右线性延展，，而 log 曲线。
2025-05-30 23:09:14
5031
原创 中文的锚定点效应
这种褒贬锚定点效应源自中文构词法则，与英文的 “单词” 不同，中文是 “组词”，所以中文词汇其实就是全相联排列组合，不光形容词可以和名词组合，两个同类词也能组合，牛肉，猪肉，汽车，火车，自行车，牛车，西装，东装，皮鞋，布鞋，宫殿(宫为生活，殿为工作)，社稷(社为土地，稷为谷物)，全属此类，如果有一天出现一种用经理来拉的车，如何命名，很简单，“经理车” 即可。故有无相生，难易相成，长短相较，高下相倾，音声相和，前后相随”，但凡形容，总要二元区分，二元区分总要有所取舍，就在下意识里区分了褒贬。
2025-05-24 10:06:50
4692
原创 去中心化的 SDN(dSDN) 短评
电话网刚诞生时，打电话的人并不多，没有计算机，没有分时突发复用，集中式电话网已足够，这说明了没需求，即使有需求，彼时的理论和硬件均无法支撑存储转发和分组交换，统计学理论不完善，排队论尚无，离晶体管还有几十年。同理，SDN 刚被提出部署，试验网络规模小，逻辑简单，交互少，故障不扩散，少数几个控制器已足够，这说明没需求，即便有需求，2010 年代早期路由器资源尚不足以支撑稍具规模的计算，转发资源并未完全分离。所以，合足够久了才必分，分足够久了才必合，在这个足够久的时间里，需求在酝酿，能力在增长。
2025-05-24 07:51:37
4871
4
原创 多路径传输(比如 MPTCP)控制实时突发
当没有突发流量时，用单路径传输，遭遇突发流量时启用多路径实时分担剩余流量，仔细看，这是一个多么自然的方式，从溃坝，溃堤到脑出血，从长假景区，春运火车站到年前超市的临时服务点，无论自然界还是人类社会，无一例外都自发采用这种模式应对超额突发。本质上，传输路径也是种 buffer，和路由器串行的内存 buffer 不同的是，它具有时间延展性，可以理解为一种并行 buffer，好处在于，缓存数据的同时，它还能往前走。只要 “溢出” 不再，立即停止分担路径，回归单路径，如此反复。浙江温州皮鞋湿，下雨进水不会胖。
2025-05-23 23:19:22
5499
原创 多路径可靠传输协议(比如 MPTCP)为什么低效
我在十年前曾排查过多起由于多核网关并发处理 TCP 流导致其吞吐下降一到两个数量级的案例，彼时各类转发技术刚刚开始还没完全开始卷，大多数人觉得并行处理可优化一切(现在依然这样认为)，却忽略了流式传输的内在约束，这些案例正反面证明我上面的论述，换句话说，把 MPTCP 调度策略去掉，按 roundrobin or 时间戳 hash 的方式选择 Subflow，将会获得类似结局。此外，MPTCP 路径管理作为控制平面逻辑，着实为应用程序覆盖太多的新增，这也就不是什么兼容强度问题了，而是一个新东西。
2025-05-23 23:14:30
5483
原创 多路径传输(比如 MPTCP)对性能的意义
土地足够，没人想住高楼，城市总先横向扩展，当面积大到当前交通一小时可达圈外，出行成本增加，城区开始增加高度以承载更多组织复杂性，就像一个矩形，先增加宽度以增加面积，触墙后增加高度亦可继续增加面积，但在触墙那一刻的面积已达最佳性价比，再增高就消耗却无益了，所以高楼要么图个摩登，因为古代没有高层技术，要么图个景观，因为看得更远，这便是用技术的高价购置景观的性能了。综合来说 MP 协议的意义，其 active-standby 意义大于性能聚合，因为性能只能掣肘，根本无法聚合，这是个简单的道理，正如。
2025-05-18 08:52:38
5226
1
原创 BBR 的 buffer 动力学观感
BBR 动力学核心是收敛，归为一句话就是 “带宽越大 Probe 加速比越小”，这句话是收敛的原因，进一步通俗解释，大的想更大更难，是为边际收益递减，小的想更大也难，但边际收益单调递减，却仍高于大的，相对而言其加速比就更大。我也常常提到 “矩”，它是一个乘积，与一个值不同的是，它体现了两个维度的胶合，两个维度的矩针对一个维度的值，其结果就是边际收益递减了，因为两个维度的伸缩比例并不常一致，所谓矩的效应，就比如面积相同而周长不等，或周长相同而面积各异，正如力和力臂，矩不变，但费料不同。
2025-05-17 22:38:38
5660
原创 Kleinrock’s optimal point 辩证考
但网络系统类似的事就不可得，除非在规模确定的数据中心，否则试图在大规模网络中去拟合某种特征就是南辕北辙，不可实时观测意味着根本就没有典型特征，只能通过大规模测试训练，找到一个均衡点，这种系统只有均衡点没有极致点，就算硬件升级一千倍，极致点也跟着上去了，还是不可达，即便均衡点也能上去，但绝对距离可能会越来越远。人类尝试过各种体制，新石器时代，古埃及，希腊罗马，春秋战国，秦汉，美苏，各种体制下，最终都会面临资源的集中，然后再平均，再集中，这不也是个锯齿？背后没什么原因和必然，可能就是随机，推荐新书。
2025-05-10 14:18:54
5944
原创 keep the pipe Just full But no fuller - BBR 与尘封 40 年的求索
作为始于 1960 年代的互联网奠基者，Kleinrock 目睹了一切(自他发表论文到他母亲扎进互联网直到 90 多岁高龄去世)，我们耳熟能详的另外几个创造者都是他的同事或学生，他抱怨道，互联网上后来出现了很多拥塞控制算法用来避免崩溃，但无论哪种，全部呈现了某种锯齿形态，不断碰到天花板，又不断跌落，同时引入大量延迟，这种情况已经持续了 40 年。这证明了当 P 最大时，系统中只有 1 个任务，这就是 “最佳操作点”，也叫最佳工作点，换句话说，系统中只有 1 个任务，不排队就最高效。我将用文字表述如下。
2025-05-08 22:53:29
5955
原创 BBR 之 ProbeRTT 新改
BBRv1 的 ProbeRTT 看起来别扭，它激进地将 inflight 降为 4 并持续 200ms，这一方面造成了吞吐抖动，另一方面造成了发送缓冲区的 yet another bufferbloat，也因此出现了非常多的 ‘优化’，比如我曾经将 ProbeRTT 的周期从固定 10s 改成了 5～15s randomized，虽避免了全局同步，但也破坏了全局同步，而 BBR 非常依赖 ProbeRTT 时间的同步，只有同步 ProbeRTT，才能保证 minrtt 的可靠。
2025-05-02 21:38:59
6342
原创 BBR 的 RTT 公平性问题求解
回到 BDP 矢量矩的概念，它是一个符合交换律的乘积，而 BBR 测量正交量种 maxbw 最为目标起作用，因此可将 gain 与 minrtt 结合重构 BDP 矢量矩：BDP = maxbw · (gain · minrtt)，在流间公平时，maxbw 相等，gain · minrtt 亦要相等，因此根据 gain · minrtt 固定 gain 缩放 Probe 时间或者固定 minrtt 缩放 gain 就是我们直面选择的。当事情变得越来越复杂，涉及越来越多时，就停手，大概率就是方向错了。
2025-04-30 22:37:48
4251
原创 给 BBRv2/3 火上浇油的 drain-to-target
Drain phase 需要以 gain = 0.75 收缩 inflight，即满足 0.75 · new_maxbw · (minrtt + RTwait) <= new_maxbw · minrtt，解上述不等式，只要 RTwait > 1/3 · minrtt 就意味着 drain-to-target 将持续，而这非常易满足，且对 minrtt 更小的流更易满足，这说明 drain-to-target 更加伤害 minrtt 小的流，使其难以退出 Drain phase。但测试发现还是弄巧成拙了。
2025-04-29 23:07:18
7935
原创 再看 BBR 到 BBRv3 的公平性改进
那句废话 A = B = 1 旨在表明一个点，两个并列的 Sigmoid 函数没必要加权，也许你会觉得 “单纯 RTprop 大” 和 “单纯 RTwait 大” 需要区别对待，其实不必，因为 Sigmoid 有个激发特性，只要 RTprop 和 RTwait 没有一起大，它们和的 Sigmoid 函数就可以很小，只需调整 α2，β2，γ2 让其向右偏，这意味着 RTprop 的作用力比 RTwait 更大，反之向左偏就倾向于 RTwait 的作用力更大。也许稍微好一点，也许还不如我，谁知道呢。
2025-04-28 23:01:47
7661
原创 合理布局结构体，精打细算 cacheline
但这种优化是极度拧巴的体系结构相关，我就从公司的 x86_64 换到家里的 Apple M2，结构体宏定义就改了一大堆，站在程序的视角，它本不应该了解这么多东西，cache 是默默起作用的，但反过来，既然你想让 cache 起更大作用，那就必须理解它的细节，方能调教好它。像 TCP 处理，比如在接收路径，会频繁访问 snd_cwnd，snd_una，snd_wnd，snd_nxt，…最近又遇到这类事，还是一样的原则，“一起经常被访问的字段要紧挨着放，尽量使它们处于同一个 cacheline”。
2025-04-27 22:38:20
7207
原创 BBRv2，v3 吞吐为什么不如 BBRv1
2MB buffer，以 1KB mss 算，一共就是 2000 个段，按照 AIMD 理论，丢包率即 1/2000，相比 2% 的丢包率要低 40 倍，由 reno 吞吐公式可知其吞吐要高 根号 √40 倍，约等于 6.3，从图上可见，inflight 理论上跌落到 5500*0.85/6.3 = 742，从图上看，大差不差。第二点有点不可思议，一般而言，不存在版本越新性能越差的，如果有，一定是 bug，但对于 BBR 却是不争的事实。如果你不知道拥塞控制算法的性能意味着什么，建议先去了解，这里不赘述。
2025-04-24 22:08:47
8096
原创 BBR 的 minRTT 采集问题
比如文初所列出的 issue，BBR 硬编码 10s 的 minrtt 窗口，一旦 minrtt 误采，10s 内将没有任何改出手段，即使基础 RTT 明显持续增大或定于新的但更大的稳定状态，BBR 也无法识别，这种状态下，它的 BDP 将被低估，从而进入 cwnd-limited 状态，最终影响吞吐。用下图紫色代表的一组样本数据来调参，获得下图绿色，蓝色两组数据(显然，代码的文字标识写反了，绿的应该是逐包抖动均值)，最底下的红线，高凸起为 minrtt 窗口维持期，低凹陷是 minrtt 新样本采集点。
2025-04-22 22:45:27
8089
原创 “小坝” 策略：始发站 buffer 控制与优化
昨天写了一篇关于 mptcp 的随笔，格调依然如故，我不是说关于 CPU，内存，锁相关的主机优化技术没用，也从没有觉得 DPDK，XDP，eBPF 等通用技术没用(我自己在这些方面也是老手)，我只是更关注网络性能本身，和 CPU 相比，即使数据中心网络传输也要慢至少一个数量级，真正的网络技术和主机根本就不在一个频道工作，这是两个领域，更何况即使是 DCN，我也从没把它当做网络看，只是看做主机总线的延伸。但在始发站，针对始发站的 buffer，却可以严格控制 buffer，避免 bufferbloat。
2025-04-20 10:48:46
8401
原创 TCP 总是禁用分片(IP_DF，Don‘t Fragment)吗？
另一方面，IP 被标准化(RFC791)的 1981 年，理论上它可以承载 255 种传输层协议，但事实上几乎只有 TCP(RFC793) 和 UDP(RFC768)，如本文最前面所述，TCP 依靠超时可靠性判定可以自己发现问题，UDP 又不在乎可靠性问题，这种尴尬境地下，IP 分片的效用形同虚设。加之如今的底层传输网络几乎趋向同质化，在技术变革伊始，合久必分，随着技术的成熟，分久必合，这意味着 TCP/IP 沙漏的底座正在收窄，MTU 差异度越发不明显，我们可从 IPv6 规范中看出这种强硬态度的升级。
2025-04-19 10:52:51
9436
原创 MPTCP 的吞吐困局
我并没有设计一个非常细致的分别针对 meta_sk 和 subsk 的 tcp_notsent_lowat 控制算法，我直接取消了对 subsk 的控制，然后仅对 meta_sk 保留 tcp_notsent_lowat 控制，理由是很简单，跟上面关于 SWS 的讨论相反，调度策略给出了决策，subsk 看 tcp_notsent_lowat 后不能否决，因为这次无关全局拥塞控制，同属本机控制，打架不好看。詹氏钩无法用于高铁也是这道理，它虽普适，但列车跑不快，而高铁车厢之间严格同步车速，消除了抖动。
2025-04-19 08:58:22
8529
一个iptables的stateless NAT模块实现
2014-12-27
模块化的nf-HiPAC
2014-11-21
关于linux内核以及其他个人体会的文集
2009-09-07
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人