- 博客(2355)
- 资源 (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
42708
41
原创 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
3046
原创 1 小时半径如何约束人口极限
眼光放宽放长远，在智人的心智尚未进化到支持抛弃肉体而独自飞升前，相对于激情又勇敢，可怜又悲哀的万年人性，科技只是辅料，它的存在正是为了哺育这颗永不满足的心足以拖拽沉重的肉体而不气馁，科技是为了让人走得更远，而不是让人躺平，在我看来，科技的发展一定会让城市规模变大，人口增多，为人的具身属性增加范围更广的活动空间。在我看来，制约人口的不仅仅是物质资源，还有社会约束。在人口的资源决定论之外，还有很多决定人口的因素，除了通勤交通技术之外，还有24 小时总量的注意力时间占比，邓巴数等，彼此相互胶着。
2025-08-23 07:09:32
5978
原创 epoll 陷阱：隧道中的高级负担
对于 I 和 O，一心不可二用，持续的双向隧道流量需要的恰恰是解复用，即将同一个描述符的 I 和 O 解复用到不同线程，而不是复用，所以选型时第一要务就应该排除掉 select，poll，epoll，libevent 等异步多路复用技术，而为每一个 socket 简单地创建两个线程分别作阻塞 I 和 O 几乎是唯一选择，但这由于太简单而显得 low，展示不出自己运用复杂技术的能力，进而选择 epoll 等多路复用的错误技术，然后再陷入持续优化的深渊，早干嘛去了。浙江温州皮鞋湿，下雨进水不会胖。
2025-08-23 06:40:14
7091
原创 不要轻易做 iptables MASQUERAD
AI 虽好，但它不是万能的，AI 能快速搞定常见的范式编程问题，哪怕写一个极其复杂的逻辑，只要范式化，AI 都非常擅长，但这并不意味着它能正确回答该过程中的疑问，特别是冷门疑问。AI 特别擅长组织逻辑和语言，让你觉得它缜密到无懈可击，认为它是对的，这恰恰说明逻辑和语言本身就是一个大范式，正如它名字所展示，大语言模型。不是 AI 不会本文描述的问题，而是它没见过，但即使它没见过，它也要发挥它遣词造句的能力，长篇大论显得它很精通，因此很容易引起误导，特别是你在学习一个新领域，无力辨别真伪的时候。
2025-08-22 22:34:16
7697
原创 tun/tap 转发性能优化
不过这几个指令到底价值几何，还是需要量化。malloc 不满足，自己实现一个最简单的内存池，先不追求地址连续，否则还是要绕回 RingBuffer，最后陷入回绕，原子变量等细节，先实现一个操作最简单的基于 queue 的内存池，使用时从 queue 池中 dequeue 一个 block，用完后 enqueue 回池中。在设计之初，良好的设计只要性能足够，并且可扩展，如果性能不再满足需求，首要的不是优化它，而是替代它，因为这不是一个良好的设计，没有扩展性，任何需要后期投入大幅精力优化的设计都不是好的设计。
2025-08-15 23:22:29
13597
原创 难以超越的 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
11048
原创 避不开的数据拷贝(2)
如果数据是严格保序的，通用机器需无条件满足该约束，典型例子是通用处理器，即 CPU，它的处理资源必须在时间维度分割成流水线，作为数据的串行指令在其中接力通过。还有一个问题，如果必须要搬运，数据搬运过程中为什么需要 buffer，为什么不能一镜到底，推而广之，为什么要接力，转介。既然处理器是通用机器，就没有专属数据，所以数据都要从别处调来，这就涉及到了数据搬运，就有了外设的概念。总之都是数据能不动就不动，实在要动就少动，如果有谁写了一个程序，频繁做 memcpy，势必要被优化掉，不管是针对程序，还是针对人。
2025-08-09 07:49:50
19842
原创 Linux Kernel TCP 终于移除了 RFC6675
我从 2009 年开始关注涉入 Linux 内核网络，读过非常多讲网络的书，但除了《TCP/IP 详解(第二版 卷 1)》和 樊东东版《Linux 内核源码剖析：TCP/IP 实现》等个位数的版本，只要讲到 TCP 就戛然而止，我是觉得 TCP 由一大堆细节错综复杂组织而成，很少有人能完全搞清楚，书虽不如论文权威，但论文专于一个点，书则要面面俱到，有这能力和精力的反而不多。”，我相信随着 TCP 还会进一步瘦身，这种事会越来越少，与此同时，网上充斥的那些 TCP 八股文也会逐步一个个过期，不再算数。
2025-08-09 07:38:23
11792
原创 避不开的数据拷贝
哺乳动物通过血液交换气体营养，通过消化系统将食物从嘴处理到肛门，通过神经系统传递信号和指令，所有这些系统的每一次运输都有一个确定的源和目标对，比如口鼻，心脏，细胞，大脑，肌肉，即便这是个缜密的近乎确定性的网络，偶然的血压波动，血脂，血管壁畸变都会引发灾难性后果，比如心梗，脑梗，脑出血，肺栓塞，肌溶解。对比这两类结构，从进化的角度看，哺乳动物类似计算机系统，牺牲了能效和速度，换得了灵活性和适应性，属于通用系统，这启发人们若设计一个高速系统，必须反着来，牺牲灵活性和适应性，换得能效和速度，打造一个专用系统。
2025-08-03 13:23:08
18518
原创 MPTCP DSS-Checksum 对吞吐的影响
所以说，整个事情是，没有 TSO/GSO 支持的标准 mss 尺寸 TCP 收发才是正常的，TSO/GSO 引入了优化，跨层协作 batch 处理大大提升了吞吐，普遍的 TSO/GSO 支持下，人们习惯了这个优化的结论，以为常态，MPTCP 回归 mss 尺寸的收发反觉得不正常。理论上，midbox 对传输层及上层的任何干预都不应该，有一个算一个，包括 NAT，Firewall，DPI，但这初衷的背景并不符合互联网后期的现实(比如安全性)，修补是难免的。浙江温州皮鞋湿，下雨进水不会胖。
2025-08-02 07:51:41
17002
原创 TCP RTO 与丢包检测
回到原点，minrto 保守化的原因在于避免不必要的重传而加重拥塞，但它与丢包不能及时恢复相比，要两权相害取其轻，对于 block 传输，自然要优先考虑避免拥塞问题，但对于 thin stream，比如游戏，远程登录等非 capacity-seeking 传输，其 inflight 不随带宽而增加，不足以对现代网络的负载产生可观测影响，因此它们并不是拥塞控制的目标。其次，自定义 TCP 相关参数时代以来，网络环境已经发生重大变化，但这些参数的缺省值却很少发生改变，而这些缺省值往往影响 TCP 的性能。
2025-08-01 22:50:20
15997
原创 后摩尔定律时代网络传输
容量提升必然伴随着拓扑改变，数据包会经过更多的 “跳(hop)”，但路径也更多了，这意味着数据包在具体某条路径遭遇拥塞的概率增加了，却可以随时选择不同的路径，拥塞控制策略需要适应这种变化，传输协议本身也必须适应这种变化，把鸡蛋放在不同的篮子里，取消依赖，并行传输。扩展交换容量意味着要扩展路径，交换容量和交换扩展因子之间不再是 1:1 的线性关系，而是乘积关系。这个现象就像住宅办公容积率和道路的关系，只要不把立体交通引入小区或写字楼，拥堵问题就无解，因为容积和道路扩展因子不是线性关系。
2025-07-27 10:35:05
24022
原创 从单核到多核系统的网络传输
多核为达到类似 Hash 效果，在软件设计上，task 粒度必须足够小且互相无依赖，若非如此，假设存在一个前后相关联的 task 序列选择了同一个处理核，该 “大象 task” 势必引起该处理核上其它标准大小的 “老鼠 task” 饥饿，但这种相互依赖的串行 task 设计(比如 MPTCP)非常常见，无疑是受单核系统串行理念的思维定势驱使，该定势下，只是 “将串行软件适配到了多核系统”，而非 “为多核系统设计串行软件”。这很像现实调配中的 “晃荡” 动作，一碗水端平，均匀摇晃，收敛到公平。
2025-07-26 08:25:09
13289
原创 TCP/IP 哲学：端到端的 Postel 定律
智能手机允许用户进行任何操作，即使是错的或者无效的，它也尽力猜测并对准操作边界，只要不明确违规即可行，用户的操作空间扩展到了整个屏幕，配合以任意手势，针对任意操作均有可视化回应，比如屏幕下拉，下滑，左右滑，长按，此外，智能手机以独占输入精确提示用户如何操作，比如只让你输入 4 位数字，没别的选项。某种意义上，电脑失败了，智能手机却成功了，原因很简单，电脑恪守了端到端原则，作为终端，它的操作太复杂了，而智能手机同样作为终端却成功了，这背后又隐藏了什么。总结两大件，端到端原则和 Postel 定律，相铺相成。
2025-07-19 12:08:27
13299
原创 从 TSO/GSO 到多路径：TCP 分段的边界
如果进一步观测 skb 的动态，你会发现在一个简单的传输和重传场景，不断会有指向不同大小 data 的 skb 被分配，释放和调整，显得喧嚣。统观之，再看分层和 “Unix 单一职责”的哲学，它们天然就为并行而生，不管分层还是单一职责，都内含了模块化，解耦合和交互，但在路径确定的串行假设下，这些很容易被 “协作” 统一，形成所谓跨层优化，比如 TSO/GSO/LRO/GRO，但对于路径不确定的并行操作模式，这些反而是前提，天然抵触 “协作”，因为协作必带来同步。总之，有点意思，沾边了。
2025-07-19 07:50:28
13164
原创 摩尔定律与并行多路径传输
以往单核系统，比如 RFC793 TCP，故意把数据乱序会引入极大的重组，重传开销，详见 TCP 和宽容，因此标准 TCP 最怕乱序，但在多核系统，本质上就是乱序传输，那么就拆除 subflow 的 TCP 约束，直接在 packet 层面用 UDP/IP 负载 subflow，receiver 多核心采用固定结构重组。先 scale-up，再 scale-out，这是一个通用扩展范式，CPU，链路，波长，纤芯，概莫能外，对于网络传输，也是一样。现在是处理结构发生了改变，行为必须做出相应改变。
2025-07-19 07:31:55
25106
原创 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
13059
原创 关于学习的方法
我喜欢读史，经常有人问我那么一大坨年代，人名，地名，我是怎么背下来的，还是一样的道理，建立时空图景。读完题目后，脑子里都是句子和逻辑，但没有场景，只有当你将这么大一段话还原成时空中的一个场景时，它是什么才显而易见，解法自然也就有了，所以我一再强调，万能的坐标系，它真的就是万能的，因为它描述的就是世界发生的事件，时间，地点。时序图，TCP 三次握手，四次挥手，协议状态机都是这回事，换成分析 TCP 抓包的 tcptrace 图，也是这个思路，在时空中往往很容易一眼看出端倪，这是我们的眼睛进化出来的本事。
2025-07-06 09:17:28
13322
原创 仅做传输层拥塞控制就够了吗?
不控制数据源，即使传输层拥塞控制再好，数据也只是转而塞在 send buffer 里，这里不塞那里塞，最终还是会影响用户体验，即使你为 send buffer 设置了 small queue，还有应用 buffer，总有一个地方会拥塞。头痛医头，脚痛医脚，大概率会造成打地鼠的局面，不要只盯着一个算法的实现本身，要盯着你的需求，你的问题，梳理你的全局架构，控制源头，把算法当工具使，不是反着来。要针对架构优化，而不是对实现优化。道理是相通的，看你如何部署，我见过太多的论文，专利，算法初看没毛病，但着眼点错了。
2025-07-05 11:14:24
13150
原创 拥塞控制的边界：从膝点到崖点
拥塞控制应该在膝点和崖点之间工作，然而膝点的滑落不可检测，而崖点的滑落则可检测，我们知道，Reno/CUBIC 等 AIMD 算法均以崖点为操作点，膝点和崖点之间就叫拥塞避免，对应 Additive Increase，而对崖点的反应就是 Multiplicative Decrease，而 BBR 则以膝点为理想操作点，但也只是理想。于是 “对丢包进行反应” 就成了拥塞控制的基调，至于如何反应，由于考虑公平性，这就需要控制论背景，而不只是一句话的事了，我们都知道，这就是 AIMD。
2025-07-04 23:30:29
26419
原创 用户进程的借壳挂靠之术
task_struct 的这种组织形式类似公司组织架构，部门间可共享资源也可资源隔离，项目组随时成立，员工自由加入和退出还可转岗，总经理有权将公司组织成任意结构，由此类比，就可理解为什么只需要调换几个字段，就可以实现进程挂靠，却又不能自由共享资源了。与组合模式的树形递归结构不同的是，Linux 的 task_struct 模型更偏向资源共享的扁平化组织，通过指针共享资源，而非嵌套包含。照这个做法，可以做点正面的事，比如借鸡生蛋，代孕，将经理的结果说成是自己的。
2025-07-04 22:48:03
11755
原创 内核线程的借壳生存之术
若想玩得更花式，可用 do_mmap 在挂靠进程地址空间申请一片可执行内存(PROT_EXEC)，里面写上些代码，起一个线程挂靠于其上，用 do_mmap 申请一片 stack，构造寄存器及返回地址，执行那片代码，那片代码干什么都行，比如 “调用 insmod kthr.ko”，这样想抵赖也不足了。” 我不是搞 TCP 的，我是个工人，泥工，瓦工，木工，机修工，电工，带娃，养狗，种花，种地，做饭，理发啥都会，就是不会跳舞，我也不管这些事有没有前途，和谁都没有冲突。浙江温州皮鞋湿，下雨进水不会胖。
2025-06-28 09:38:47
12961
原创 那些不应该的优化
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
13287
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
12516
原创 广域网多路径传输
广域网应用用不到超过运营商出售的带宽(如果用到就买更大的)，但广域网接入带宽总波动，不能恒常，这对直播推流，实时播放等恒常带宽需求而言非常不利，应用要不断调整编解码速率以跟随带宽波动，但波动往往随移动，位置，时间而不可预知，因此调整永远是滞后且不准的。这类多路径传输亦属于闭环控制技术，还是那个观点，这类技术为弥补资源差异而存在，随着网络基础设施推陈出新，而恒常带宽诉诸的受体感知能力有上限，再好也不会觉得更爽，资源差异逐渐天然抹平，这类控制技术也就逐渐没了必要。，但重要的是稳定性，而不是总和，
2025-06-21 10:28:13
13209
原创 西班牙大停电与 SO_REUSEPORT 一致性 Hash
Linux 内核一直没有实现一致性 Hash 选择 socket，直到 6.16-rc2，对长连接负载均衡，热升级带来了极大的复杂性，而 eBPF 技术又未竟全功，实现起来也极其复杂(看看多么麻烦：reuseport socket 热升级)，所以我才又实现了一版 reuseport 一致性 Hash，但同样没开大会，也没派池。总之不过多评价这个算法本身的优劣以及其实用场景，这也不是本文的目的，本文主要集中于它如何出问题，如何让它不容易出问题，以及真的出了问题如何控制问题蔓延的。
2025-06-21 10:12:46
25120
原创 Linux 路由下一跳与源地址选择
当涉及 ECMP 类的多下一跳选择时，本机始发数据会面临源地址选择和下一跳选择的一致性问题，先说上面第一点，源地址尚未确定时，源地址依赖下一跳，于是路由查找寻找下一跳，优先选择与下一跳 “接近”(最匹配) 的网卡 IP 作为 saddr，接下来再选 sport，为了应用 ECMP，saddr，sport 会作为 hash 输入，在多下一跳中选择一个，这次选择与确定源地址时的选择可能不一致。)IPv6 没这问题，因为 IPv6 是后来开大会设计的，有一套严格的源地址选择规范，详见 RFC3484。
2025-06-21 09:39:29
13009
原创 MPTCP 吞吐聚合的神奇方法
如果你有空间和资源，最有效的优化方案就是用它们来换，TCP 很多单机性能问题都源自端口号，序列号空间太小，加大它们便是，若要你重新设计一个新协议，你还抄 TCP，然后用一些精巧的算法再优化，那就是纯经理了。流控平衡 receiver，sender 的收发缓冲区，拥塞控制平衡 host 和网络的速率，数据包调度平衡数据流(or subflow)间时延，进程调度平衡处理器和进程时间，可见，这类算法的作用力应随资源逐渐均衡而减弱才更有性价比，道理很简单，不必为不需要的功能买单。总之，对齐了时延，调度就最简单。
2025-06-21 09:16:09
12353
原创 说说聚合路由器
再说调度和重组算法，连 iptables，Netfilter 都玩不明白，也就用用 MPTCP，有多少人能有自研协议的能力，说到开源协议魔改，也还是编译和移植，大多数好的产品也就是依仗硬件贵罢了，硬件贵，软件就不重要了，软件是兜下限的，硬件决定上限。可见时延差不离，这种结果在意料之中，就算不同运营商也差不了太多，因为路由规划都是最短路径优先，大家的路径路由统一性非常强，甚至物理传输上都是共享的，差异就在空口，各家基站也差不多，那么就看手机了。三星，iphone 是出名的高档手机，贵有贵的道理。
2025-06-15 09:59:40
13771
原创 二叉树，Hash，网络拥塞的共相解构
连同网络拥塞，当出现很费劲的操作时，总有办法施加一些控制摆脱之，无论是树的平衡操作，Hash 算法，还是路由负载均衡，拥塞控制，背后的力量都会让信息变得混乱而均匀。再看标准 Hash 结构，由于它的 Hash 函数是固定的，所有增量计算则必须重算所有节点，因此它能在内存的代价下保持一个伪装的 O(1)，若非如此，则必须处理冲突，而负载因子不敏感的冲突处理的时间复杂度是 O(n)，O(log n) 的方法对负载因子太敏感，更耗内存，交易还是省不了。我简单说，因为我的能力只能触及其形而上层面，深了我也不懂。
2025-06-14 09:47:55
13115
原创 Linux 内核 TCP 性能真的很差吗？
可见，在高速网络环境，Linux 内核 TCP 的处理实际上成了一个内核零存，task 整取的过程，若 CPU 能力一定，当整个 CPU 核全忙时，处理 TCP 的时间越多，处理业务时间越少，反之如果 CPU 花时间处理业务，留给处理 TCP 的时间就会少，如果将 task 亦看作端到端(数据视角，从数据的产生到消亡)处理一环的话，这里就是个瓶颈点，CPU 能力限制了整体吞吐的上限。在早期的应用编程模型中，阻塞接收很常见，前文提到，那时瓶颈在网络，往往求数据而不得，又没其它事务做，只能等。
2025-06-14 09:02:49
12174
原创 TCP/IP 与高速网络
可以这样理解，数据在主机生成直到网卡发送的时间是 ns 级(至多 us 级)，数据被目标主机网卡接收直到被消费的时间亦 ns 级，在这期间的网络传输时间却没有任何保底承诺，且没有任何反馈承诺，这个时间从 us 到 s 不等，如此大的时延抖动跨度，任何附加手段均无能为力，即使最大强度最理想的流控和拥塞控制附加其上，也只能将抖动压缩至 5~10ms，这对于 400Gbps+ 高速网络依然不可接受，这是 TCP/IP 网络的属性，而非缺陷。网络的核心是拓扑，只有基于全互联规则拓扑构建的网络才能彻底打破僵局。
2025-06-07 11:09:42
14683
6
原创 高速多路径传输之始末
内存拷贝并不约束时序，横着拷贝，竖着拷贝，斜着拷贝，大块拷贝，小块拷贝都非常随意，这就能有效利用好并行资源，比如多路径分别传输不同的文件块，每个文件块都映射到自己的地址，单独一个线程负责周期性查看 hole，随时 nack。所以我经常说，人们根本就不那么在乎单流最大吞吐，大部分人用不了那么大带宽，在很长一段时间，就算人们需要单流大吞吐，也用不起(在 2025 年，即便经理也不敢持续 500Mbps 跑流量)，人们在乎的是很多流的总吞吐，这至少还涉及并发能力，可以几个用户，几条流一起跑。
2025-06-07 07:45:53
13260
原创 MPTCP 聚合吞吐
但必须注意，子路径必须不能太异构，聚合 Wi-Fi，5G，4G，想都别想，不是说不能提升，而是不划算。无论如何，涉及聚合，叠加的案例，都不是简单的加法，都需要方向的一致性，同步协调性，结构稳定性三要素，而作为端到端协议，TCP 天然缺失同步协调性和结构稳定性，这些是尽力而为网络的属性特征，TCP/IP 并不具备任何调优支撑，任何的优化都可以说是粗暴的运气。这么多人频率，方向，力道均一致才能叠加速度，频率不一致会减速，方向，左右力道不一致会减速并跑偏。”，第二局就赢了，但小朋友们也缺失了体验，这怪我。
2025-06-02 10:59:29
13047
原创 scale up 不能优化 TCP 聚合性能
虽然管道可以提供 RTT_Normalized · (S1 + S2) 的带宽，但如果某时刻从左边注入这么多数据，RTT_Normalized 过后，仅流出 RTT_Normalized · |RTT2 - RTT1|/RTT2 · (S1 + S2) 数据，若要流出更多的数据，则必须在更大 RTT2 路径上更早注入数据，如果没有足够的数据提前注入，就要在右侧等待重组，该力度由 α 调节，表现为多路径调度和重组算法，由这些算法决定(前面写过，但不是本文重点)，对于可靠传输，左边不等右边等，怎么优化都没用。
2025-05-31 07:05:22
14250
1
原创 Wi-Fi 切换 5G 的时机
不管信不信，背后也没什么原因，人们每天的行为轨迹在时间序上是有规律的，观察和统计上下班打卡时间，外出跑步时间，坐地铁班次，甚至消费时间，你会惊奇地发现每天几乎都是 “那个点”，误差甚至不超过一两分钟。早上出门上班，关上家门等电梯时，家里 Wi-Fi 信号已经很微弱，但依然坚挺，没即时切到 5G，傍晚下班离开公司，走出大楼时，公司 Wi-Fi 信号已经很微弱，但依然坚挺，没即时切到 5G，这两个时间有那么一两分钟是无法上网的，除非我手工把 Wi-Fi 关闭，等走远了再打开。浙江温州皮鞋湿，下雨进水不会胖。
2025-05-30 23:52:20
15743
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
15035
原创 中文的锚定点效应
这种褒贬锚定点效应源自中文构词法则，与英文的 “单词” 不同，中文是 “组词”，所以中文词汇其实就是全相联排列组合，不光形容词可以和名词组合，两个同类词也能组合，牛肉，猪肉，汽车，火车，自行车，牛车，西装，东装，皮鞋，布鞋，宫殿(宫为生活，殿为工作)，社稷(社为土地，稷为谷物)，全属此类，如果有一天出现一种用经理来拉的车，如何命名，很简单，“经理车” 即可。故有无相生，难易相成，长短相较，高下相倾，音声相和，前后相随”，但凡形容，总要二元区分，二元区分总要有所取舍，就在下意识里区分了褒贬。
2025-05-24 10:06:50
14875
原创 去中心化的 SDN(dSDN) 短评
电话网刚诞生时，打电话的人并不多，没有计算机，没有分时突发复用，集中式电话网已足够，这说明了没需求，即使有需求，彼时的理论和硬件均无法支撑存储转发和分组交换，统计学理论不完善，排队论尚无，离晶体管还有几十年。同理，SDN 刚被提出部署，试验网络规模小，逻辑简单，交互少，故障不扩散，少数几个控制器已足够，这说明没需求，即便有需求，2010 年代早期路由器资源尚不足以支撑稍具规模的计算，转发资源并未完全分离。所以，合足够久了才必分，分足够久了才必合，在这个足够久的时间里，需求在酝酿，能力在增长。
2025-05-24 07:51:37
15323
4
一个iptables的stateless NAT模块实现
2014-12-27
模块化的nf-HiPAC
2014-11-21
关于linux内核以及其他个人体会的文集
2009-09-07
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人