- 博客(2364)
- 资源 (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
42717
41
原创 从电路交换，分组交换到带宽交换
当前 OCS 如火如荼，相比光电光域，在光域做带宽交换要容易得多，而可编程光纤连接则是带宽交换的一个实例，配合 SDN 等传统技术，可实现带宽的动态分配和管理，无论从资源利用率还是从吞吐性能，时延指标来看，都能获得质的提升。从资源的角度看，带宽不足固然是拥塞的根因，但从局部看，绝大多数拥塞的直接原因来自资源分配不均，以往的想法是为流量重新换一条路，但如果带宽可以在交换机内池化，便可直接对带宽进行重分配了。1960 年代伴随分时系统发展，分组交换被提出，以排队论统计复用理论为基础，奠基了现代互联网。
2025-09-14 07:30:00
361
原创 少即是多：从 MPTCP 看优化干预的边界
一根长度为 L，截面积为 S 的厚橡皮水管，两个端点分别为 A，B，从 A 端注水，B 端出水时可充满截面积 S，假设在距离 A 端 x 处的水管上开一个面积为 y 的口漏水，若此时仍要 B 端出水时可充满截面积 S，对 A 端注水应该有何要求，从检测到漏口，A 端需要执行该要求多久，B 端才能重新充满截面积 S，与 x，y 的关系是什么？谁也没错，边界乱了。不同场景，只是为照顾某些特征，使用一些额外推算的信息优化局部指标，但在本质上，rtt 是唯一的输入信息，即便如此，仍需要对其平滑，以 srtt 算。
2025-09-13 21:42:46
374
原创 主宰 TCP AIMD 的中心极限定理
我们的社会，城市，甚至自然界生态系统均是与 TCP/IP 互联网一样的随机的复杂自适应系统，这类系统的特点是去中心化，资源共享，分布式哑控制，没有任何措施规范个体的行为，全凭个体自主探测和适应，尽力而为，我们惊奇地发现，这类系统几乎运行得都非常和谐良好，其中的动力学正如 AIMD。，他用排队论首先证明了统计复用是可行的，奠定了互联网的统计学理论基础，在他之前，虽然人们设想了很多不同拓扑的组网方式，但大家始终无法摆脱可用性的魔鬼，人们怀疑，如此不受任何约束的，混乱的所谓分组交换网，真的行得通？
2025-09-13 07:06:05
1009
原创 性能优化的边界-不该优化什么
大开合的性能提升往往来自于粗粒度的排列组合，而不是细粒度的优化，也就是说，知道哪种场景选择哪个现成的构件去搭建系统，比优化单独构件的收益边际更高，随着边际收益递减，才需要过渡到更细粒度的优化，例如优化算法，但往往在这个时候，系统表现已经足够好了，且有能力继续优化的工人也非常稀少了。这段话意思是，绝大多数肉眼可见的性能提升来自于对既有技术构件的选型，而对细节的细粒度优化收益小到毛毛雨，而成本往往也支付给了根本没有能力做此类优化的经理和工人，换句话说，这类优化除了竞速，内卷样式的烧钱之外，并没有实际意义。
2025-09-06 10:16:09
10281
1
原创 无拥塞网络的辩证
他们美其名曰要尊重当前标准，复用当前接口，以此为理由，结果又回到以太网那一套，复用了标准，也继承了缺陷，绕了一个圈，到头来，在这里省下来的，还得到那里加倍还回去，然后嘴硬不承认，反而说这是个创新，又一个世界第一等。要么直接做完备，要么怎么都做不完备，这背后存在一种缺陷哲学，一开始做不完备是因为有缺陷，同样因为该缺陷，日后怎么做还是做不完备。遗憾的是，AIMD，BBR，ECN，PFC 都是反应式的，人们总在诸如此类之上更正修补，试图彻底解决拥塞控制的所有问题，而只要 RTProp 不为 0，这就是不可能的。
2025-09-06 09:56:57
10083
原创 乐观并发: TCP 与编程实践
但并不是说这种做法总是对的。如果退避和重试的时间总是超过自旋等待的时间，那么一把 spinlock 就是高尚的，我也经常循着 spinlock 到 rwlock 再到 rcu 的步骤优化代码，而这并不浪费我太多时间，所以相比乐观并发，这就更划算，因为和哑网络不同，主机状态对程序而言完全可见，逆熵很便宜，所以用更精确的信息控制它就能换来高性能。，也就是不论网络还是主机的不同大小的 buffer，致使 TCP 从最初的 GBN 经 SR 到 MultiPath-TCP，底层乐观并发逻辑一直没变，变的只是参数。
2025-09-05 22:22:00
10835
原创 性能优化的边界
循着高内聚，低耦合，不优化的方法论，势必会朝着仅通过 IPC 交互的微核心设计更进一步。然而众所周知，IPC 肯定没有线程间交互更快，多一次调度都是时间，可这背后还是时间尺度的问题，相比手贱心痒持续优化而成的庞大程序节省的那一点指令时间，微核心结构节省的是你的生命，因为它更简单。这意味着我需要构建最内聚，最精简，最高效的核心预制构件，然后用该构件搭建整个系统，剩下的交给操作系统，这能让我省去很多 bugfix 的调试时间，损失的只是那一丁点牙缝里抠出来的性能。人生苦短，吃点好的，干点正事。
2025-08-30 08:26:57
15728
原创 CUBIC 和 Vegas 合体新姿势
另一方面，Vegas 作为 Delay-based cc 代表，识别拥塞的能力一流，但却被先入为主的 AIMD 压制，无法与其共存，这也是硬伤，背后的原因是 Vegas 没有负反馈动力学基础，仅仅基于不精确的测量，本质上还是端不识网。前面提到过，AIMD 已经足够优秀，迄至 CUBIC 已臻于完美，但它还是无法甄别非拥塞随机丢包，导致随机丢包时表现力不够，这可以认为是硬伤，背后的原因就是信息不足，本质上是端不识网导致，任何端到端算法都有各自硬伤。浙江温州皮鞋湿，下雨进水不会胖。上上周写了一篇 AIMD(
2025-08-30 08:16:17
14700
原创 无懈可击的 TCP AIMD
如果 n = 1，为了照顾人有限的肺活量，气球容量必须至少等于人的最大肺活量，且吹得太快容易爆裂，吹得太慢换气时出气孔没气体，但 n = 3 时，一个人换气时，另外 2 人可能依然保持吹气，就这样让 n 不断增大。更直观的例子是非牛顿流体，不管形状如何，只要质量相同，在重力的作用下，它们最终肯定占据相同的占地面积，因为重心高了，重力会拉低它，将高度补偿给面积后，拉低的力度逐渐变弱，最终大家一致，就好像大家刚挤上一辆公交车时气都喘不过来，车开了点播一段时间后，就逐渐宽松且公平了，
2025-08-29 22:19:55
11327
原创 packetization 思想之于 tun/tap 转发
其实我根本没有从上面第一个设计做加法，我一开始设计的就是第二个设计，我们回顾一下 TCP，它就是典型的第一个设计，直接操作字节流，也就是图 1 的 RingBuffer，在 TCP 中，这就是所谓的 scoreboard，TCP 几乎所有的复杂逻辑就是在操作该 scoreboard，snd_una，snd_nxt，…各种 pos，再看图 2，它似乎是对 TCP 做了一个 packetization，在 TCP/IP 协议中，这是 IP 完成的事，而 TCP 本身并没有任何 packetization。
2025-08-24 09:36:52
13788
原创 1 小时半径如何约束人口极限
眼光放宽放长远，在智人的心智尚未进化到支持抛弃肉体而独自飞升前，相对于激情又勇敢，可怜又悲哀的万年人性，科技只是辅料，它的存在正是为了哺育这颗永不满足的心足以拖拽沉重的肉体而不气馁，科技是为了让人走得更远，而不是让人躺平，在我看来，科技的发展一定会让城市规模变大，人口增多，为人的具身属性增加范围更广的活动空间。在我看来，制约人口的不仅仅是物质资源，还有社会约束。在人口的资源决定论之外，还有很多决定人口的因素，除了通勤交通技术之外，还有24 小时总量的注意力时间占比，邓巴数等，彼此相互胶着。
2025-08-23 07:09:32
17251
原创 epoll 陷阱：隧道中的高级负担
对于 I 和 O，一心不可二用，持续的双向隧道流量需要的恰恰是解复用，即将同一个描述符的 I 和 O 解复用到不同线程，而不是复用，所以选型时第一要务就应该排除掉 select，poll，epoll，libevent 等异步多路复用技术，而为每一个 socket 简单地创建两个线程分别作阻塞 I 和 O 几乎是唯一选择，但这由于太简单而显得 low，展示不出自己运用复杂技术的能力，进而选择 epoll 等多路复用的错误技术，然后再陷入持续优化的深渊，早干嘛去了。浙江温州皮鞋湿，下雨进水不会胖。
2025-08-23 06:40:14
18685
原创 不要轻易做 iptables MASQUERAD
AI 虽好，但它不是万能的，AI 能快速搞定常见的范式编程问题，哪怕写一个极其复杂的逻辑，只要范式化，AI 都非常擅长，但这并不意味着它能正确回答该过程中的疑问，特别是冷门疑问。AI 特别擅长组织逻辑和语言，让你觉得它缜密到无懈可击，认为它是对的，这恰恰说明逻辑和语言本身就是一个大范式，正如它名字所展示，大语言模型。不是 AI 不会本文描述的问题，而是它没见过，但即使它没见过，它也要发挥它遣词造句的能力，长篇大论显得它很精通，因此很容易引起误导，特别是你在学习一个新领域，无力辨别真伪的时候。
2025-08-22 22:34:16
19061
原创 tun/tap 转发性能优化
不过这几个指令到底价值几何，还是需要量化。malloc 不满足，自己实现一个最简单的内存池，先不追求地址连续，否则还是要绕回 RingBuffer，最后陷入回绕，原子变量等细节，先实现一个操作最简单的基于 queue 的内存池，使用时从 queue 池中 dequeue 一个 block，用完后 enqueue 回池中。在设计之初，良好的设计只要性能足够，并且可扩展，如果性能不再满足需求，首要的不是优化它，而是替代它，因为这不是一个良好的设计，没有扩展性，任何需要后期投入大幅精力优化的设计都不是好的设计。
2025-08-15 23:22:29
14467
原创 难以超越的 TCP AIMD
TCP 本身具有很强的可扩展性，从不到 1Mbps 的带宽适应到 200Gbps，在 100Mbps 之下，TCP 表现很好，从 100Mbps 长肥管道到 25Gbps，TCP 被普遍诟病但却依然适应良好，过了 40Gbps，性能瓶颈转移到了主机，但这些都不是协议的问题，200Gbps + TCP Reno + TSO/LRO + GBN + BigTCP + ZeroCopy 或许真比 200Gbps + BBR + TSO/LRO + SACK 表现更优秀。有人曾经问我，多流共存，存在最优解吗？
2025-08-15 07:03:49
11894
原创 避不开的数据拷贝(2)
如果数据是严格保序的，通用机器需无条件满足该约束，典型例子是通用处理器，即 CPU，它的处理资源必须在时间维度分割成流水线，作为数据的串行指令在其中接力通过。还有一个问题，如果必须要搬运，数据搬运过程中为什么需要 buffer，为什么不能一镜到底，推而广之，为什么要接力，转介。既然处理器是通用机器，就没有专属数据，所以数据都要从别处调来，这就涉及到了数据搬运，就有了外设的概念。总之都是数据能不动就不动，实在要动就少动，如果有谁写了一个程序，频繁做 memcpy，势必要被优化掉，不管是针对程序，还是针对人。
2025-08-09 07:49:50
20659
原创 Linux Kernel TCP 终于移除了 RFC6675
我从 2009 年开始关注涉入 Linux 内核网络，读过非常多讲网络的书，但除了《TCP/IP 详解(第二版 卷 1)》和 樊东东版《Linux 内核源码剖析：TCP/IP 实现》等个位数的版本，只要讲到 TCP 就戛然而止，我是觉得 TCP 由一大堆细节错综复杂组织而成，很少有人能完全搞清楚，书虽不如论文权威，但论文专于一个点，书则要面面俱到，有这能力和精力的反而不多。”，我相信随着 TCP 还会进一步瘦身，这种事会越来越少，与此同时，网上充斥的那些 TCP 八股文也会逐步一个个过期，不再算数。
2025-08-09 07:38:23
12651
原创 避不开的数据拷贝
哺乳动物通过血液交换气体营养，通过消化系统将食物从嘴处理到肛门，通过神经系统传递信号和指令，所有这些系统的每一次运输都有一个确定的源和目标对，比如口鼻，心脏，细胞，大脑，肌肉，即便这是个缜密的近乎确定性的网络，偶然的血压波动，血脂，血管壁畸变都会引发灾难性后果，比如心梗，脑梗，脑出血，肺栓塞，肌溶解。对比这两类结构，从进化的角度看，哺乳动物类似计算机系统，牺牲了能效和速度，换得了灵活性和适应性，属于通用系统，这启发人们若设计一个高速系统，必须反着来，牺牲灵活性和适应性，换得能效和速度，打造一个专用系统。
2025-08-03 13:23:08
19343
原创 MPTCP DSS-Checksum 对吞吐的影响
所以说，整个事情是，没有 TSO/GSO 支持的标准 mss 尺寸 TCP 收发才是正常的，TSO/GSO 引入了优化，跨层协作 batch 处理大大提升了吞吐，普遍的 TSO/GSO 支持下，人们习惯了这个优化的结论，以为常态，MPTCP 回归 mss 尺寸的收发反觉得不正常。理论上，midbox 对传输层及上层的任何干预都不应该，有一个算一个，包括 NAT，Firewall，DPI，但这初衷的背景并不符合互联网后期的现实(比如安全性)，修补是难免的。浙江温州皮鞋湿，下雨进水不会胖。
2025-08-02 07:51:41
17818
原创 TCP RTO 与丢包检测
回到原点，minrto 保守化的原因在于避免不必要的重传而加重拥塞，但它与丢包不能及时恢复相比，要两权相害取其轻，对于 block 传输，自然要优先考虑避免拥塞问题，但对于 thin stream，比如游戏，远程登录等非 capacity-seeking 传输，其 inflight 不随带宽而增加，不足以对现代网络的负载产生可观测影响，因此它们并不是拥塞控制的目标。其次，自定义 TCP 相关参数时代以来，网络环境已经发生重大变化，但这些参数的缺省值却很少发生改变，而这些缺省值往往影响 TCP 的性能。
2025-08-01 22:50:20
16839
原创 后摩尔定律时代网络传输
容量提升必然伴随着拓扑改变，数据包会经过更多的 “跳(hop)”，但路径也更多了，这意味着数据包在具体某条路径遭遇拥塞的概率增加了，却可以随时选择不同的路径，拥塞控制策略需要适应这种变化，传输协议本身也必须适应这种变化，把鸡蛋放在不同的篮子里，取消依赖，并行传输。扩展交换容量意味着要扩展路径，交换容量和交换扩展因子之间不再是 1:1 的线性关系，而是乘积关系。这个现象就像住宅办公容积率和道路的关系，只要不把立体交通引入小区或写字楼，拥堵问题就无解，因为容积和道路扩展因子不是线性关系。
2025-07-27 10:35:05
24839
原创 从单核到多核系统的网络传输
多核为达到类似 Hash 效果，在软件设计上，task 粒度必须足够小且互相无依赖，若非如此，假设存在一个前后相关联的 task 序列选择了同一个处理核，该 “大象 task” 势必引起该处理核上其它标准大小的 “老鼠 task” 饥饿，但这种相互依赖的串行 task 设计(比如 MPTCP)非常常见，无疑是受单核系统串行理念的思维定势驱使，该定势下，只是 “将串行软件适配到了多核系统”，而非 “为多核系统设计串行软件”。这很像现实调配中的 “晃荡” 动作，一碗水端平，均匀摇晃，收敛到公平。
2025-07-26 08:25:09
14094
原创 TCP/IP 哲学：端到端的 Postel 定律
智能手机允许用户进行任何操作，即使是错的或者无效的，它也尽力猜测并对准操作边界，只要不明确违规即可行，用户的操作空间扩展到了整个屏幕，配合以任意手势，针对任意操作均有可视化回应，比如屏幕下拉，下滑，左右滑，长按，此外，智能手机以独占输入精确提示用户如何操作，比如只让你输入 4 位数字，没别的选项。某种意义上，电脑失败了，智能手机却成功了，原因很简单，电脑恪守了端到端原则，作为终端，它的操作太复杂了，而智能手机同样作为终端却成功了，这背后又隐藏了什么。总结两大件，端到端原则和 Postel 定律，相铺相成。
2025-07-19 12:08:27
14109
原创 从 TSO/GSO 到多路径：TCP 分段的边界
如果进一步观测 skb 的动态，你会发现在一个简单的传输和重传场景，不断会有指向不同大小 data 的 skb 被分配，释放和调整，显得喧嚣。统观之，再看分层和 “Unix 单一职责”的哲学，它们天然就为并行而生，不管分层还是单一职责，都内含了模块化，解耦合和交互，但在路径确定的串行假设下，这些很容易被 “协作” 统一，形成所谓跨层优化，比如 TSO/GSO/LRO/GRO，但对于路径不确定的并行操作模式，这些反而是前提，天然抵触 “协作”，因为协作必带来同步。总之，有点意思，沾边了。
2025-07-19 07:50:28
13641
原创 摩尔定律与并行多路径传输
以往单核系统，比如 RFC793 TCP，故意把数据乱序会引入极大的重组，重传开销，详见 TCP 和宽容，因此标准 TCP 最怕乱序，但在多核系统，本质上就是乱序传输，那么就拆除 subflow 的 TCP 约束，直接在 packet 层面用 UDP/IP 负载 subflow，receiver 多核心采用固定结构重组。先 scale-up，再 scale-out，这是一个通用扩展范式，CPU，链路，波长，纤芯，概莫能外，对于网络传输，也是一样。现在是处理结构发生了改变，行为必须做出相应改变。
2025-07-19 07:31:55
25586
原创 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
13513
原创 关于学习的方法
我喜欢读史，经常有人问我那么一大坨年代，人名，地名，我是怎么背下来的，还是一样的道理，建立时空图景。读完题目后，脑子里都是句子和逻辑，但没有场景，只有当你将这么大一段话还原成时空中的一个场景时，它是什么才显而易见，解法自然也就有了，所以我一再强调，万能的坐标系，它真的就是万能的，因为它描述的就是世界发生的事件，时间，地点。时序图，TCP 三次握手，四次挥手，协议状态机都是这回事，换成分析 TCP 抓包的 tcptrace 图，也是这个思路，在时空中往往很容易一眼看出端倪，这是我们的眼睛进化出来的本事。
2025-07-06 09:17:28
13481
原创 仅做传输层拥塞控制就够了吗?
不控制数据源，即使传输层拥塞控制再好，数据也只是转而塞在 send buffer 里，这里不塞那里塞，最终还是会影响用户体验，即使你为 send buffer 设置了 small queue，还有应用 buffer，总有一个地方会拥塞。头痛医头，脚痛医脚，大概率会造成打地鼠的局面，不要只盯着一个算法的实现本身，要盯着你的需求，你的问题，梳理你的全局架构，控制源头，把算法当工具使，不是反着来。要针对架构优化，而不是对实现优化。道理是相通的，看你如何部署，我见过太多的论文，专利，算法初看没毛病，但着眼点错了。
2025-07-05 11:14:24
13305
原创 拥塞控制的边界：从膝点到崖点
拥塞控制应该在膝点和崖点之间工作，然而膝点的滑落不可检测，而崖点的滑落则可检测，我们知道，Reno/CUBIC 等 AIMD 算法均以崖点为操作点，膝点和崖点之间就叫拥塞避免，对应 Additive Increase，而对崖点的反应就是 Multiplicative Decrease，而 BBR 则以膝点为理想操作点，但也只是理想。于是 “对丢包进行反应” 就成了拥塞控制的基调，至于如何反应，由于考虑公平性，这就需要控制论背景，而不只是一句话的事了，我们都知道，这就是 AIMD。
2025-07-04 23:30:29
26549
原创 用户进程的借壳挂靠之术
task_struct 的这种组织形式类似公司组织架构，部门间可共享资源也可资源隔离，项目组随时成立，员工自由加入和退出还可转岗，总经理有权将公司组织成任意结构，由此类比，就可理解为什么只需要调换几个字段，就可以实现进程挂靠，却又不能自由共享资源了。与组合模式的树形递归结构不同的是，Linux 的 task_struct 模型更偏向资源共享的扁平化组织，通过指针共享资源，而非嵌套包含。照这个做法，可以做点正面的事，比如借鸡生蛋，代孕，将经理的结果说成是自己的。
2025-07-04 22:48:03
11763
原创 内核线程的借壳生存之术
若想玩得更花式，可用 do_mmap 在挂靠进程地址空间申请一片可执行内存(PROT_EXEC)，里面写上些代码，起一个线程挂靠于其上，用 do_mmap 申请一片 stack，构造寄存器及返回地址，执行那片代码，那片代码干什么都行，比如 “调用 insmod kthr.ko”，这样想抵赖也不足了。” 我不是搞 TCP 的，我是个工人，泥工，瓦工，木工，机修工，电工，带娃，养狗，种花，种地，做饭，理发啥都会，就是不会跳舞，我也不管这些事有没有前途，和谁都没有冲突。浙江温州皮鞋湿，下雨进水不会胖。
2025-06-28 09:38:47
12968
原创 那些不应该的优化
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
13378
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
12590
原创 广域网多路径传输
广域网应用用不到超过运营商出售的带宽(如果用到就买更大的)，但广域网接入带宽总波动，不能恒常，这对直播推流，实时播放等恒常带宽需求而言非常不利，应用要不断调整编解码速率以跟随带宽波动，但波动往往随移动，位置，时间而不可预知，因此调整永远是滞后且不准的。这类多路径传输亦属于闭环控制技术，还是那个观点，这类技术为弥补资源差异而存在，随着网络基础设施推陈出新，而恒常带宽诉诸的受体感知能力有上限，再好也不会觉得更爽，资源差异逐渐天然抹平，这类控制技术也就逐渐没了必要。，但重要的是稳定性，而不是总和，
2025-06-21 10:28:13
13216
原创 西班牙大停电与 SO_REUSEPORT 一致性 Hash
Linux 内核一直没有实现一致性 Hash 选择 socket，直到 6.16-rc2，对长连接负载均衡，热升级带来了极大的复杂性，而 eBPF 技术又未竟全功，实现起来也极其复杂(看看多么麻烦：reuseport socket 热升级)，所以我才又实现了一版 reuseport 一致性 Hash，但同样没开大会，也没派池。总之不过多评价这个算法本身的优劣以及其实用场景，这也不是本文的目的，本文主要集中于它如何出问题，如何让它不容易出问题，以及真的出了问题如何控制问题蔓延的。
2025-06-21 10:12:46
25137
原创 Linux 路由下一跳与源地址选择
当涉及 ECMP 类的多下一跳选择时，本机始发数据会面临源地址选择和下一跳选择的一致性问题，先说上面第一点，源地址尚未确定时，源地址依赖下一跳，于是路由查找寻找下一跳，优先选择与下一跳 “接近”(最匹配) 的网卡 IP 作为 saddr，接下来再选 sport，为了应用 ECMP，saddr，sport 会作为 hash 输入，在多下一跳中选择一个，这次选择与确定源地址时的选择可能不一致。)IPv6 没这问题，因为 IPv6 是后来开大会设计的，有一套严格的源地址选择规范，详见 RFC3484。
2025-06-21 09:39:29
13023
原创 MPTCP 吞吐聚合的神奇方法
如果你有空间和资源，最有效的优化方案就是用它们来换，TCP 很多单机性能问题都源自端口号，序列号空间太小，加大它们便是，若要你重新设计一个新协议，你还抄 TCP，然后用一些精巧的算法再优化，那就是纯经理了。流控平衡 receiver，sender 的收发缓冲区，拥塞控制平衡 host 和网络的速率，数据包调度平衡数据流(or subflow)间时延，进程调度平衡处理器和进程时间，可见，这类算法的作用力应随资源逐渐均衡而减弱才更有性价比，道理很简单，不必为不需要的功能买单。总之，对齐了时延，调度就最简单。
2025-06-21 09:16:09
12363
原创 说说聚合路由器
再说调度和重组算法，连 iptables，Netfilter 都玩不明白，也就用用 MPTCP，有多少人能有自研协议的能力，说到开源协议魔改，也还是编译和移植，大多数好的产品也就是依仗硬件贵罢了，硬件贵，软件就不重要了，软件是兜下限的，硬件决定上限。可见时延差不离，这种结果在意料之中，就算不同运营商也差不了太多，因为路由规划都是最短路径优先，大家的路径路由统一性非常强，甚至物理传输上都是共享的，差异就在空口，各家基站也差不多，那么就看手机了。三星，iphone 是出名的高档手机，贵有贵的道理。
2025-06-15 09:59:40
13806
原创 二叉树，Hash，网络拥塞的共相解构
连同网络拥塞，当出现很费劲的操作时，总有办法施加一些控制摆脱之，无论是树的平衡操作，Hash 算法，还是路由负载均衡，拥塞控制，背后的力量都会让信息变得混乱而均匀。再看标准 Hash 结构，由于它的 Hash 函数是固定的，所有增量计算则必须重算所有节点，因此它能在内存的代价下保持一个伪装的 O(1)，若非如此，则必须处理冲突，而负载因子不敏感的冲突处理的时间复杂度是 O(n)，O(log n) 的方法对负载因子太敏感，更耗内存，交易还是省不了。我简单说，因为我的能力只能触及其形而上层面，深了我也不懂。
2025-06-14 09:47:55
13119
一个iptables的stateless NAT模块实现
2014-12-27
模块化的nf-HiPAC
2014-11-21
关于linux内核以及其他个人体会的文集
2009-09-07
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人