- 博客(2326)
- 资源 (4)
- 收藏
- 关注
RSS订阅
原创 闲谈IPv6系列文章集锦
本文总结一个目录提纲，只要是给自己看的，记录一下哪些东西已经总结过了。闲谈IPv6-6to4隧道和ISATAP隧道： https://blog.youkuaiyun.com/dog250/article/details/88644797闲谈IPv6-说说IPv6地址分配和BGP： https://blog.youkuaiyun.com/dog250/article/details/88430415闲谈IPv6...
2019-03-18 22:38:43
42626
34
原创 TCP/IP 与高速网络
可以这样理解，数据在主机生成直到网卡发送的时间是 ns 级(至多 us 级)，数据被目标主机网卡接收直到被消费的时间亦 ns 级，在这期间的网络传输时间却没有任何保底承诺，且没有任何反馈承诺，这个时间从 us 到 s 不等，如此大的时延抖动跨度，任何附加手段均无能为力，即使最大强度最理想的流控和拥塞控制附加其上，也只能将抖动压缩至 5~10ms，这对于 400Gbps+ 高速网络依然不可接受，这是 TCP/IP 网络的属性，而非缺陷。网络的核心是拓扑，只有基于全互联规则拓扑构建的网络才能彻底打破僵局。
2025-06-07 11:09:42
1286
原创 高速多路径传输之始末
内存拷贝并不约束时序，横着拷贝，竖着拷贝，斜着拷贝，大块拷贝，小块拷贝都非常随意，这就能有效利用好并行资源，比如多路径分别传输不同的文件块，每个文件块都映射到自己的地址，单独一个线程负责周期性查看 hole，随时 nack。所以我经常说，人们根本就不那么在乎单流最大吞吐，大部分人用不了那么大带宽，在很长一段时间，就算人们需要单流大吞吐，也用不起(在 2025 年，即便经理也不敢持续 500Mbps 跑流量)，人们在乎的是很多流的总吞吐，这至少还涉及并发能力，可以几个用户，几条流一起跑。
2025-06-07 07:45:53
1348
原创 MPTCP 聚合吞吐
但必须注意，子路径必须不能太异构，聚合 Wi-Fi，5G，4G，想都别想，不是说不能提升，而是不划算。无论如何，涉及聚合，叠加的案例，都不是简单的加法，都需要方向的一致性，同步协调性，结构稳定性三要素，而作为端到端协议，TCP 天然缺失同步协调性和结构稳定性，这些是尽力而为网络的属性特征，TCP/IP 并不具备任何调优支撑，任何的优化都可以说是粗暴的运气。这么多人频率，方向，力道均一致才能叠加速度，频率不一致会减速，方向，左右力道不一致会减速并跑偏。”，第二局就赢了，但小朋友们也缺失了体验，这怪我。
2025-06-02 10:59:29
1907
原创 scale up 不能优化 TCP 聚合性能
虽然管道可以提供 RTT_Normalized · (S1 + S2) 的带宽，但如果某时刻从左边注入这么多数据，RTT_Normalized 过后，仅流出 RTT_Normalized · |RTT2 - RTT1|/RTT2 · (S1 + S2) 数据，若要流出更多的数据，则必须在更大 RTT2 路径上更早注入数据，如果没有足够的数据提前注入，就要在右侧等待重组，该力度由 α 调节，表现为多路径调度和重组算法，由这些算法决定(前面写过，但不是本文重点)，对于可靠传输，左边不等右边等，怎么优化都没用。
2025-05-31 07:05:22
2669
1
原创 Wi-Fi 切换 5G 的时机
不管信不信，背后也没什么原因，人们每天的行为轨迹在时间序上是有规律的，观察和统计上下班打卡时间，外出跑步时间，坐地铁班次，甚至消费时间，你会惊奇地发现每天几乎都是 “那个点”，误差甚至不超过一两分钟。早上出门上班，关上家门等电梯时，家里 Wi-Fi 信号已经很微弱，但依然坚挺，没即时切到 5G，傍晚下班离开公司，走出大楼时，公司 Wi-Fi 信号已经很微弱，但依然坚挺，没即时切到 5G，这两个时间有那么一两分钟是无法上网的，除非我手工把 Wi-Fi 关闭，等走远了再打开。浙江温州皮鞋湿，下雨进水不会胖。
2025-05-30 23:52:20
3327
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
2877
原创 中文的锚定点效应
这种褒贬锚定点效应源自中文构词法则，与英文的 “单词” 不同，中文是 “组词”，所以中文词汇其实就是全相联排列组合，不光形容词可以和名词组合，两个同类词也能组合，牛肉，猪肉，汽车，火车，自行车，牛车，西装，东装，皮鞋，布鞋，宫殿(宫为生活，殿为工作)，社稷(社为土地，稷为谷物)，全属此类，如果有一天出现一种用经理来拉的车，如何命名，很简单，“经理车” 即可。故有无相生，难易相成，长短相较，高下相倾，音声相和，前后相随”，但凡形容，总要二元区分，二元区分总要有所取舍，就在下意识里区分了褒贬。
2025-05-24 10:06:50
2828
原创 去中心化的 SDN(dSDN) 短评
电话网刚诞生时，打电话的人并不多，没有计算机，没有分时突发复用，集中式电话网已足够，这说明了没需求，即使有需求，彼时的理论和硬件均无法支撑存储转发和分组交换，统计学理论不完善，排队论尚无，离晶体管还有几十年。同理，SDN 刚被提出部署，试验网络规模小，逻辑简单，交互少，故障不扩散，少数几个控制器已足够，这说明没需求，即便有需求，2010 年代早期路由器资源尚不足以支撑稍具规模的计算，转发资源并未完全分离。所以，合足够久了才必分，分足够久了才必合，在这个足够久的时间里，需求在酝酿，能力在增长。
2025-05-24 07:51:37
2986
1
原创 多路径传输(比如 MPTCP)控制实时突发
当没有突发流量时，用单路径传输，遭遇突发流量时启用多路径实时分担剩余流量，仔细看，这是一个多么自然的方式，从溃坝，溃堤到脑出血，从长假景区，春运火车站到年前超市的临时服务点，无论自然界还是人类社会，无一例外都自发采用这种模式应对超额突发。本质上，传输路径也是种 buffer，和路由器串行的内存 buffer 不同的是，它具有时间延展性，可以理解为一种并行 buffer，好处在于，缓存数据的同时，它还能往前走。只要 “溢出” 不再，立即停止分担路径，回归单路径，如此反复。浙江温州皮鞋湿，下雨进水不会胖。
2025-05-23 23:19:22
3422
原创 多路径可靠传输协议(比如 MPTCP)为什么低效
我在十年前曾排查过多起由于多核网关并发处理 TCP 流导致其吞吐下降一到两个数量级的案例，彼时各类转发技术刚刚开始还没完全开始卷，大多数人觉得并行处理可优化一切(现在依然这样认为)，却忽略了流式传输的内在约束，这些案例正反面证明我上面的论述，换句话说，把 MPTCP 调度策略去掉，按 roundrobin or 时间戳 hash 的方式选择 Subflow，将会获得类似结局。此外，MPTCP 路径管理作为控制平面逻辑，着实为应用程序覆盖太多的新增，这也就不是什么兼容强度问题了，而是一个新东西。
2025-05-23 23:14:30
3629
原创 多路径传输(比如 MPTCP)对性能的意义
土地足够，没人想住高楼，城市总先横向扩展，当面积大到当前交通一小时可达圈外，出行成本增加，城区开始增加高度以承载更多组织复杂性，就像一个矩形，先增加宽度以增加面积，触墙后增加高度亦可继续增加面积，但在触墙那一刻的面积已达最佳性价比，再增高就消耗却无益了，所以高楼要么图个摩登，因为古代没有高层技术，要么图个景观，因为看得更远，这便是用技术的高价购置景观的性能了。综合来说 MP 协议的意义，其 active-standby 意义大于性能聚合，因为性能只能掣肘，根本无法聚合，这是个简单的道理，正如。
2025-05-18 08:52:38
3705
1
原创 BBR 的 buffer 动力学观感
BBR 动力学核心是收敛，归为一句话就是 “带宽越大 Probe 加速比越小”，这句话是收敛的原因，进一步通俗解释，大的想更大更难，是为边际收益递减，小的想更大也难，但边际收益单调递减，却仍高于大的，相对而言其加速比就更大。我也常常提到 “矩”，它是一个乘积，与一个值不同的是，它体现了两个维度的胶合，两个维度的矩针对一个维度的值，其结果就是边际收益递减了，因为两个维度的伸缩比例并不常一致，所谓矩的效应，就比如面积相同而周长不等，或周长相同而面积各异，正如力和力臂，矩不变，但费料不同。
2025-05-17 22:38:38
4190
原创 Kleinrock’s optimal point 辩证考
但网络系统类似的事就不可得，除非在规模确定的数据中心，否则试图在大规模网络中去拟合某种特征就是南辕北辙，不可实时观测意味着根本就没有典型特征，只能通过大规模测试训练，找到一个均衡点，这种系统只有均衡点没有极致点，就算硬件升级一千倍，极致点也跟着上去了，还是不可达，即便均衡点也能上去，但绝对距离可能会越来越远。人类尝试过各种体制，新石器时代，古埃及，希腊罗马，春秋战国，秦汉，美苏，各种体制下，最终都会面临资源的集中，然后再平均，再集中，这不也是个锯齿？背后没什么原因和必然，可能就是随机，推荐新书。
2025-05-10 14:18:54
4485
原创 keep the pipe Just full But no fuller - BBR 与尘封 40 年的求索
作为始于 1960 年代的互联网奠基者，Kleinrock 目睹了一切(自他发表论文到他母亲扎进互联网直到 90 多岁高龄去世)，我们耳熟能详的另外几个创造者都是他的同事或学生，他抱怨道，互联网上后来出现了很多拥塞控制算法用来避免崩溃，但无论哪种，全部呈现了某种锯齿形态，不断碰到天花板，又不断跌落，同时引入大量延迟，这种情况已经持续了 40 年。这证明了当 P 最大时，系统中只有 1 个任务，这就是 “最佳操作点”，也叫最佳工作点，换句话说，系统中只有 1 个任务，不排队就最高效。我将用文字表述如下。
2025-05-08 22:53:29
4788
原创 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
5198
原创 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
2480
原创 给 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
5538
原创 再看 BBR 到 BBRv3 的公平性改进
那句废话 A = B = 1 旨在表明一个点，两个并列的 Sigmoid 函数没必要加权，也许你会觉得 “单纯 RTprop 大” 和 “单纯 RTwait 大” 需要区别对待，其实不必，因为 Sigmoid 有个激发特性，只要 RTprop 和 RTwait 没有一起大，它们和的 Sigmoid 函数就可以很小，只需调整 α2，β2，γ2 让其向右偏，这意味着 RTprop 的作用力比 RTwait 更大，反之向左偏就倾向于 RTwait 的作用力更大。也许稍微好一点，也许还不如我，谁知道呢。
2025-04-28 23:01:47
5541
原创 合理布局结构体，精打细算 cacheline
但这种优化是极度拧巴的体系结构相关，我就从公司的 x86_64 换到家里的 Apple M2，结构体宏定义就改了一大堆，站在程序的视角，它本不应该了解这么多东西，cache 是默默起作用的，但反过来，既然你想让 cache 起更大作用，那就必须理解它的细节，方能调教好它。像 TCP 处理，比如在接收路径，会频繁访问 snd_cwnd，snd_una，snd_wnd，snd_nxt，…最近又遇到这类事，还是一样的原则，“一起经常被访问的字段要紧挨着放，尽量使它们处于同一个 cacheline”。
2025-04-27 22:38:20
5249
原创 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
6057
原创 BBR 的 minRTT 采集问题
比如文初所列出的 issue，BBR 硬编码 10s 的 minrtt 窗口，一旦 minrtt 误采，10s 内将没有任何改出手段，即使基础 RTT 明显持续增大或定于新的但更大的稳定状态，BBR 也无法识别，这种状态下，它的 BDP 将被低估，从而进入 cwnd-limited 状态，最终影响吞吐。用下图紫色代表的一组样本数据来调参，获得下图绿色，蓝色两组数据(显然，代码的文字标识写反了，绿的应该是逐包抖动均值)，最底下的红线，高凸起为 minrtt 窗口维持期，低凹陷是 minrtt 新样本采集点。
2025-04-22 22:45:27
6373
原创 “小坝” 策略：始发站 buffer 控制与优化
昨天写了一篇关于 mptcp 的随笔，格调依然如故，我不是说关于 CPU，内存，锁相关的主机优化技术没用，也从没有觉得 DPDK，XDP，eBPF 等通用技术没用(我自己在这些方面也是老手)，我只是更关注网络性能本身，和 CPU 相比，即使数据中心网络传输也要慢至少一个数量级，真正的网络技术和主机根本就不在一个频道工作，这是两个领域，更何况即使是 DCN，我也从没把它当做网络看，只是看做主机总线的延伸。但在始发站，针对始发站的 buffer，却可以严格控制 buffer，避免 bufferbloat。
2025-04-20 10:48:46
6618
原创 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
6443
原创 MPTCP 的吞吐困局
我并没有设计一个非常细致的分别针对 meta_sk 和 subsk 的 tcp_notsent_lowat 控制算法，我直接取消了对 subsk 的控制，然后仅对 meta_sk 保留 tcp_notsent_lowat 控制，理由是很简单，跟上面关于 SWS 的讨论相反，调度策略给出了决策，subsk 看 tcp_notsent_lowat 后不能否决，因为这次无关全局拥塞控制，同属本机控制，打架不好看。詹氏钩无法用于高铁也是这道理，它虽普适，但列车跑不快，而高铁车厢之间严格同步车速，消除了抖动。
2025-04-19 08:58:22
6666
原创 如何解读 /proc/net/netstat
众所周知 /proc/net/netstat 很难读，且 netstat 并不是每个系统上都支持 -s，那么对齐该文件给出一个可读的输出就是一件高尚的事。有人说这种 low 活就应该让 AI 做，其实这个脚本就是 deepseek 写的，它写了很多，包括 awk，sed 的，都看不懂，也不能用，只有这个 python 的，简洁，能看懂，能用，不一般。想看什么直接执行，跟一个你想看的字段名即可，简洁高效。在刷了屏的川普，关税，AI 大模型和 RDMA 之外的一股清流，来点实用的。
2025-04-12 11:11:23
6725
原创 再看 MPTCP 时的思考
原则是一回事，实现是一回事，即便是 mptcp v1，仍不能完全避免串行化，因为本质上 TCP 就是一个串行流，多个 subflow 从 meta_sock 取数据发送或接收完数据重组拼接时，仍然要抢 meta_sock 锁，这意味着 mptcp 永远也无法实现多路径吞吐的满叠加，有趣的是，文初描述 mptcp v0 的 meta sock 串行锁竟然直接实现了 6356 原则 2，让你即使想叠加带宽而不能为之。哪怕是一团烂泥，先跑起来再说，这显然忽略了不是谁都有的试错成本，这是句毒鸡汤，烂话。
2025-04-12 10:41:56
7411
原创 信息的代价：低熵社会
举个例子，30 年前的人出来穷游(人少是不拥挤的原因，但不核心)，几乎没有任何渠道获取关于景点，住宿，地方特产的任何信息，来自不同地方不同背景人们只能依靠最适合自己的交通方式到达不同的地方，靠眼睛和道听途说获知有限信息，我抬头看到的旅社招牌和别人抬头看到的招待所牌匾几乎不可能是同一家，饭店不会是同一家，景点也不会是同一个，一切都被散列，一切都是随机的，这维持了一个高熵状态，看不到任何人头攒动的拥挤模式。所以说，共享信息才是拥堵，拥挤，拥塞的核心原因，这种时候，信息并不能提高效率，反而影响了效率。
2025-04-06 21:46:53
6811
原创 RFC6937 PRR 的兑换细节
如果管道收缩 1000 倍，cwnd 本是 5000，正常应该收缩到 cwnd = 5，然而按照 AIMD 标准算法，经历一次丢包后，cwnd 收缩到 β·cwnd，以 Reno 为例，即 cwnd = 2500，这显然还会继续丢包，幸运的是，PRR 可以一次性将 cwnd 收缩到 5，遗憾的是，Linux 将 cwnd = 5 又拉回了 cwnd = 2500。意味着兑换比就是 β = ssthresh / RecoverFS，收到 1 个单位数据，发送 β 单位数据。浙江温州皮鞋湿，下雨进水不会胖。
2025-04-04 19:44:56
7023
原创 Linux TCP PRR 降窗的实现问题至今没人关注
观测 AIMD，以 Reno 为例，若 cwnd = 10，遭遇丢包，则 ssthresh = cwnd / 2 = 5，cwnd = ssthresh，变为 5，以此类推，史上共有 3 类知名降窗法，分别为 RFC3517，Linux rate halving 以及 PRR，前两类无异于直接将 cwnd = ssthresh，而 PRR 则执行一个比例兑换的数据包守恒法，逐渐降到 ssthresh，具体参见。，觉得 talk is cheap 的就去看 tcp_cwnd_reduction，不多说。
2025-04-03 22:42:45
7518
原创 BBRv2/v3 详解
因此，也正是在该 phase，在 BBR_BW_PROBE_UP 之前，short-term 的 inflight_lo，bw_lo 被重置，此后在不响应丢包的前提下用 max-bw filter 中的 maxbw 作为 pacing 持续 1 个 round 填满 Pipe，Pipe 满载，一切就绪后，进入下一轮 BBR_BW_PROBE_UP phase。inflight_hi 在一系列连续的 round 中递增量分别为 1，2，4，8，16，…最后看 BBR_BW_PROBE_REFILL。
2025-04-02 19:56:14
8324
原创 从 BBRv2 到 BBRv3
BBRv3 已经有段时间了，今天正好碰到一个 BBRv2 限制住总吞吐的问题，正好因为 cwnd_gain 所导致，徒手增大了它又带来了丢包，进一步降低了 inflight_lo，进而又限制住了 cwnd，导致无足够的数据包撑起好不容易 probe 到的 maxbw，吞吐逐渐下滑…问题是，BBRv2 好意的 probe-phase 有问题，于是就有了 BBRv3。另一方面，BBRv2 和 BBRv3，相比 BBRv1，“吞吐性能进一步降低”，“性能在变差”，但拥塞控制的首要目标是拥塞控制，不是提高吞吐。
2025-04-01 20:20:33
7877
原创 reuseport socket 查找的一致性 hash
如果我需要在 n 个 reuseport socket 之间做一致性 hash 映射，我会创建 n + d 个 reuseport socket，k 可以从 1 到 n 不等，然后我的 ebpf 始终只做 index = hvalue % n 即可，这种情况下，即使 n 个 socket 中有一个挂了，后面那 d 个 standby socket 的最后一个马上就填充了退出者的位置，接管服务，可谓透明无感。核心思想是，由 ebpf 程序自行控制从哪里到哪里进行 hash，而不是有多少算多少，全部参与运算。
2025-03-31 22:32:10
8034
原创 最简单最朴素的服务热升级方法
如果不嫌弃 nf_conntrack，那么它就能自动帮你把新老 session 分流，你只需要做一个 Redirect 就行了，这应该是最简单，最朴素的热升级方案了。但问题是，如今全民全面 LLM 的洪流时代，连 XDP，DPDK 都稍显老态了，谁还能记起 iptables/Netfilter。浙江温州皮鞋湿，下雨进水不会胖。还是稍微复杂了，写个简单的。
2025-03-31 10:56:29
7406
原创 服务热升级的方法
Linux 内核的 reuseport ebpf 接口非常不友好，它那个默认的 “用最后一个 item 填洞” 的逻辑无法自定义，所以就必须在外部适配它，不管是 ebpf 程序还是用户态工具程序，都需要一大堆的 map 来维护 status，这就增加了复杂性。既然你连如何 mapping 的权力都给到了，如何增删改查自己留着有啥用呢，一般而言，要么无，要么全，crud 才完美闭环。浙江温州皮鞋湿，下雨进水不会胖。但貌似有 bug …
2025-03-30 11:45:22
7612
原创 问题的根源还是解题的方案
虽然减少了骨干回源流量，但却增加了最后一公里的汇聚流量，用户访问不同网站可能都连到同一个 CDN 节点，增加了拥塞和单点故障概率，于是需要新技术解决拥塞和容错问题，同时，小网站反而失去对自主网络的控制。IPv4 地址空间有限，NAT 缓解了问题，但同时打破了 IP 网络点对点可达性初衷，破坏了端到端通信，催生了一系列新技术解决引入的问题，比如打洞(我认识一家公司的老板，TCP，UDP 打洞世界第一)，这一切本应是 IPv6 普及前的过渡，结果却成了阻碍 IPv6 的 “舒适区”。
2025-03-30 09:45:15
7497
原创 多路径 TCP 调度的另一面
之所以倒着发，为了保证慢路径后段一定与快路径解耦(确保后边的数据已经完全准备好)，即使 gap 算大了，仅靠快路径自身也能很快接上慢路径已经准备好的数据，而如果 gap 算小了，则影响更小，换句话说，即使抖动也是一瞬间，且快路径主导补洞。总之，总要拿个什么来交换成本，以获得收益，越复杂越不划算。，思路依然是让慢路径序列号往后错，但它仍倾向于精确拼接，企图两边正好配合，但这是不可能的，慢路径非常容易与快路径耦合，一旦被快路径赶上，Seq 在快慢路径交错传输和重传，就会引发持续性 HoL 抖动，而这个错开量。
2025-03-29 08:50:44
8519
1
原创 解析重塑世界
让任何一种工程实践深度依赖于充满技巧的几何辅助线是低效的，不现实的。解析几何，能描述所有几何图形，却又不认识一个几何图形，最终它表达的就是坐标系中任意一点和其它任意一点在某种用关系描述的(“几何的”)约束下的关系，这是一种递归的定义，由此，坐标轴也不再限于 x，y，由于坐标系中可表示任意数量的关系，任意维度的坐标系中都遵循同一套计算方法，这显然描述的就是世界本身了。如果没有一种可工程化硬算方法，以上这些装置就很难建模，难以受力分析，这还只是一个简单的实例，就更别提那些复杂的机械装置了。然而这有什么意义吗？
2025-03-26 22:15:27
8241
原创 X Window System(X11)
于是，X 系统仅由三部分组成，X Server，X Client，X Protocol。我在前面聊互联网发展史和其背后的哲学时，涉及到 “网络最初是基于对等通信，逐步走向内容提供和消费”，而 X 系统在此过程中，从早期加入 C/S 一族，恰好服务于系统本身，也就是说，它是系统的组成部分，于是，X 视角下的整个网络就是一台分布式处理机。典型的场景，Windows 主机的显示器坏了，需要换一台显示器，而 X 系统可以直接显示到别人的显示器上，Windows 的窗口系统崩了，系统就崩了，X 系统只需要重启进程。
2025-03-23 11:07:09
8470
原创 吞吐与时延的博弈，超发与冗余的交换
如果按照字节做拥塞控制，从端侧看，小包流几乎不会触发拥塞控制逻辑，但却引入了另一种事件调度的控制逻辑，这一点结论在任何处理系统都有效，比如主机处理网络中断，流量和包量对主机系统产生的是两种不同的冲击，流量影响 CPU 有效利用率，包量影响 CPU 无效利用率，抖动大多由包量导致的调度差异引发。做传输协议加速，大家默认激进超发原则，却认为冗余双发不道德，其实这两个是一回事，它们本质上是一种 “矩” 内的交换，就像力和力臂交换但乘积不变一样，成本是固定的。经理和工人们青睐前者，鄙视后者。
2025-03-23 08:57:56
8568
一个iptables的stateless NAT模块实现
2014-12-27
模块化的nf-HiPAC
2014-11-21
关于linux内核以及其他个人体会的文集
2009-09-07
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人