- 博客(2316)
- 资源 (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
42597
34
原创 多路径传输(比如 MPTCP)对性能的意义
土地足够，没人想住高楼，城市总先横向扩展，当面积大到当前交通一小时可达圈外，出行成本增加，城区开始增加高度以承载更多组织复杂性，就像一个矩形，先增加宽度以增加面积，触墙后增加高度亦可继续增加面积，但在触墙那一刻的面积已达最佳性价比，再增高就消耗却无益了，所以高楼要么图个摩登，因为古代没有高层技术，要么图个景观，因为看得更远，这便是用技术的高价购置景观的性能了。综合来说 MP 协议的意义，其 active-standby 意义大于性能聚合，因为性能只能掣肘，根本无法聚合，这是个简单的道理，正如。
2025-05-18 08:52:38
1032
1
原创 BBR 的 buffer 动力学观感
BBR 动力学核心是收敛，归为一句话就是 “带宽越大 Probe 加速比越小”，这句话是收敛的原因，进一步通俗解释，大的想更大更难，是为边际收益递减，小的想更大也难，但边际收益单调递减，却仍高于大的，相对而言其加速比就更大。我也常常提到 “矩”，它是一个乘积，与一个值不同的是，它体现了两个维度的胶合，两个维度的矩针对一个维度的值，其结果就是边际收益递减了，因为两个维度的伸缩比例并不常一致，所谓矩的效应，就比如面积相同而周长不等，或周长相同而面积各异，正如力和力臂，矩不变，但费料不同。
2025-05-17 22:38:38
1568
原创 kleinrock‘s operating point 辩证考
但网络系统类似的事就不可得，除非在规模确定的数据中心，否则试图在大规模网络中去拟合某种特征就是南辕北辙，不可实时观测意味着根本就没有典型特征，只能通过大规模测试训练，找到一个均衡点，这种系统只有均衡点没有极致点，就算硬件升级一千倍，极致点也跟着上去了，还是不可达，即便均衡点也能上去，但绝对距离可能会越来越远。人类尝试过各种体制，新石器时代，古埃及，希腊罗马，春秋战国，秦汉，美苏，各种体制下，最终都会面临资源的集中，然后再平均，再集中，这不也是个锯齿？背后没什么原因和必然，可能就是随机，推荐新书。
2025-05-10 14:18:54
1888
原创 keep the pipe Just full But no fuller - BBR 与尘封 40 年的求索
作为始于 1960 年代的互联网奠基者，Kleinrock 目睹了一切(自他发表论文到他母亲扎进互联网直到 90 多岁高龄去世)，我们耳熟能详的另外几个创造者都是他的同事或学生，他抱怨道，互联网上后来出现了很多拥塞控制算法用来避免崩溃，但无论哪种，全部呈现了某种锯齿形态，不断碰到天花板，又不断跌落，同时引入大量延迟，这种情况已经持续了 40 年。这证明了当 P 最大时，系统中只有 1 个任务，这就是 “最佳操作点”，也叫最佳工作点，换句话说，系统中只有 1 个任务，不排队就最高效。我将用文字表述如下。
2025-05-08 22:53:29
2193
原创 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
2602
原创 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
1767
原创 给 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
2946
原创 再看 BBR 到 BBRv3 的公平性改进
那句废话 A = B = 1 旨在表明一个点，两个并列的 Sigmoid 函数没必要加权，也许你会觉得 “单纯 RTprop 大” 和 “单纯 RTwait 大” 需要区别对待，其实不必，因为 Sigmoid 有个激发特性，只要 RTprop 和 RTwait 没有一起大，它们和的 Sigmoid 函数就可以很小，只需调整 α2，β2，γ2 让其向右偏，这意味着 RTprop 的作用力比 RTwait 更大，反之向左偏就倾向于 RTwait 的作用力更大。也许稍微好一点，也许还不如我，谁知道呢。
2025-04-28 23:01:47
2922
原创 合理布局结构体，精打细算 cacheline
但这种优化是极度拧巴的体系结构相关，我就从公司的 x86_64 换到家里的 Apple M2，结构体宏定义就改了一大堆，站在程序的视角，它本不应该了解这么多东西，cache 是默默起作用的，但反过来，既然你想让 cache 起更大作用，那就必须理解它的细节，方能调教好它。像 TCP 处理，比如在接收路径，会频繁访问 snd_cwnd，snd_una，snd_wnd，snd_nxt，…最近又遇到这类事，还是一样的原则，“一起经常被访问的字段要紧挨着放，尽量使它们处于同一个 cacheline”。
2025-04-27 22:38:20
2665
原创 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
3457
原创 BBR 的 minRTT 采集问题
比如文初所列出的 issue，BBR 硬编码 10s 的 minrtt 窗口，一旦 minrtt 误采，10s 内将没有任何改出手段，即使基础 RTT 明显持续增大或定于新的但更大的稳定状态，BBR 也无法识别，这种状态下，它的 BDP 将被低估，从而进入 cwnd-limited 状态，最终影响吞吐。用下图紫色代表的一组样本数据来调参，获得下图绿色，蓝色两组数据(显然，代码的文字标识写反了，绿的应该是逐包抖动均值)，最底下的红线，高凸起为 minrtt 窗口维持期，低凹陷是 minrtt 新样本采集点。
2025-04-22 22:45:27
3911
原创 “小坝” 策略：始发站 buffer 控制与优化
昨天写了一篇关于 mptcp 的随笔，格调依然如故，我不是说关于 CPU，内存，锁相关的主机优化技术没用，也从没有觉得 DPDK，XDP，eBPF 等通用技术没用(我自己在这些方面也是老手)，我只是更关注网络性能本身，和 CPU 相比，即使数据中心网络传输也要慢至少一个数量级，真正的网络技术和主机根本就不在一个频道工作，这是两个领域，更何况即使是 DCN，我也从没把它当做网络看，只是看做主机总线的延伸。但在始发站，针对始发站的 buffer，却可以严格控制 buffer，避免 bufferbloat。
2025-04-20 10:48:46
4156
原创 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
4129
原创 MPTCP 的吞吐困局
我并没有设计一个非常细致的分别针对 meta_sk 和 subsk 的 tcp_notsent_lowat 控制算法，我直接取消了对 subsk 的控制，然后仅对 meta_sk 保留 tcp_notsent_lowat 控制，理由是很简单，跟上面关于 SWS 的讨论相反，调度策略给出了决策，subsk 看 tcp_notsent_lowat 后不能否决，因为这次无关全局拥塞控制，同属本机控制，打架不好看。詹氏钩无法用于高铁也是这道理，它虽普适，但列车跑不快，而高铁车厢之间严格同步车速，消除了抖动。
2025-04-19 08:58:22
4383
原创 如何解读 /proc/net/netstat
众所周知 /proc/net/netstat 很难读，且 netstat 并不是每个系统上都支持 -s，那么对齐该文件给出一个可读的输出就是一件高尚的事。有人说这种 low 活就应该让 AI 做，其实这个脚本就是 deepseek 写的，它写了很多，包括 awk，sed 的，都看不懂，也不能用，只有这个 python 的，简洁，能看懂，能用，不一般。想看什么直接执行，跟一个你想看的字段名即可，简洁高效。在刷了屏的川普，关税，AI 大模型和 RDMA 之外的一股清流，来点实用的。
2025-04-12 11:11:23
4441
原创 再看 MPTCP 时的思考
原则是一回事，实现是一回事，即便是 mptcp v1，仍不能完全避免串行化，因为本质上 TCP 就是一个串行流，多个 subflow 从 meta_sock 取数据发送或接收完数据重组拼接时，仍然要抢 meta_sock 锁，这意味着 mptcp 永远也无法实现多路径吞吐的满叠加，有趣的是，文初描述 mptcp v0 的 meta sock 串行锁竟然直接实现了 6356 原则 2，让你即使想叠加带宽而不能为之。哪怕是一团烂泥，先跑起来再说，这显然忽略了不是谁都有的试错成本，这是句毒鸡汤，烂话。
2025-04-12 10:41:56
5144
原创 信息的代价：低熵社会
举个例子，30 年前的人出来穷游(人少是不拥挤的原因，但不核心)，几乎没有任何渠道获取关于景点，住宿，地方特产的任何信息，来自不同地方不同背景人们只能依靠最适合自己的交通方式到达不同的地方，靠眼睛和道听途说获知有限信息，我抬头看到的旅社招牌和别人抬头看到的招待所牌匾几乎不可能是同一家，饭店不会是同一家，景点也不会是同一个，一切都被散列，一切都是随机的，这维持了一个高熵状态，看不到任何人头攒动的拥挤模式。所以说，共享信息才是拥堵，拥挤，拥塞的核心原因，这种时候，信息并不能提高效率，反而影响了效率。
2025-04-06 21:46:53
4841
原创 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
5062
原创 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
5567
原创 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
6354
原创 从 BBRv2 到 BBRv3
BBRv3 已经有段时间了，今天正好碰到一个 BBRv2 限制住总吞吐的问题，正好因为 cwnd_gain 所导致，徒手增大了它又带来了丢包，进一步降低了 inflight_lo，进而又限制住了 cwnd，导致无足够的数据包撑起好不容易 probe 到的 maxbw，吞吐逐渐下滑…问题是，BBRv2 好意的 probe-phase 有问题，于是就有了 BBRv3。另一方面，BBRv2 和 BBRv3，相比 BBRv1，“吞吐性能进一步降低”，“性能在变差”，但拥塞控制的首要目标是拥塞控制，不是提高吞吐。
2025-04-01 20:20:33
5984
原创 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
6167
原创 最简单最朴素的服务热升级方法
如果不嫌弃 nf_conntrack，那么它就能自动帮你把新老 session 分流，你只需要做一个 Redirect 就行了，这应该是最简单，最朴素的热升级方案了。但问题是，如今全民全面 LLM 的洪流时代，连 XDP，DPDK 都稍显老态了，谁还能记起 iptables/Netfilter。浙江温州皮鞋湿，下雨进水不会胖。还是稍微复杂了，写个简单的。
2025-03-31 10:56:29
5526
原创 服务热升级的方法
Linux 内核的 reuseport ebpf 接口非常不友好，它那个默认的 “用最后一个 item 填洞” 的逻辑无法自定义，所以就必须在外部适配它，不管是 ebpf 程序还是用户态工具程序，都需要一大堆的 map 来维护 status，这就增加了复杂性。既然你连如何 mapping 的权力都给到了，如何增删改查自己留着有啥用呢，一般而言，要么无，要么全，crud 才完美闭环。浙江温州皮鞋湿，下雨进水不会胖。但貌似有 bug …
2025-03-30 11:45:22
5729
原创 问题的根源还是解题的方案
虽然减少了骨干回源流量，但却增加了最后一公里的汇聚流量，用户访问不同网站可能都连到同一个 CDN 节点，增加了拥塞和单点故障概率，于是需要新技术解决拥塞和容错问题，同时，小网站反而失去对自主网络的控制。IPv4 地址空间有限，NAT 缓解了问题，但同时打破了 IP 网络点对点可达性初衷，破坏了端到端通信，催生了一系列新技术解决引入的问题，比如打洞(我认识一家公司的老板，TCP，UDP 打洞世界第一)，这一切本应是 IPv6 普及前的过渡，结果却成了阻碍 IPv6 的 “舒适区”。
2025-03-30 09:45:15
5622
原创 多路径 TCP 调度的另一面
之所以倒着发，为了保证慢路径后段一定与快路径解耦(确保后边的数据已经完全准备好)，即使 gap 算大了，仅靠快路径自身也能很快接上慢路径已经准备好的数据，而如果 gap 算小了，则影响更小，换句话说，即使抖动也是一瞬间，且快路径主导补洞。总之，总要拿个什么来交换成本，以获得收益，越复杂越不划算。，思路依然是让慢路径序列号往后错，但它仍倾向于精确拼接，企图两边正好配合，但这是不可能的，慢路径非常容易与快路径耦合，一旦被快路径赶上，Seq 在快慢路径交错传输和重传，就会引发持续性 HoL 抖动，而这个错开量。
2025-03-29 08:50:44
6645
1
原创 解析重塑世界
让任何一种工程实践深度依赖于充满技巧的几何辅助线是低效的，不现实的。解析几何，能描述所有几何图形，却又不认识一个几何图形，最终它表达的就是坐标系中任意一点和其它任意一点在某种用关系描述的(“几何的”)约束下的关系，这是一种递归的定义，由此，坐标轴也不再限于 x，y，由于坐标系中可表示任意数量的关系，任意维度的坐标系中都遵循同一套计算方法，这显然描述的就是世界本身了。如果没有一种可工程化硬算方法，以上这些装置就很难建模，难以受力分析，这还只是一个简单的实例，就更别提那些复杂的机械装置了。然而这有什么意义吗？
2025-03-26 22:15:27
6361
原创 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
6582
原创 吞吐与时延的博弈，超发与冗余的交换
如果按照字节做拥塞控制，从端侧看，小包流几乎不会触发拥塞控制逻辑，但却引入了另一种事件调度的控制逻辑，这一点结论在任何处理系统都有效，比如主机处理网络中断，流量和包量对主机系统产生的是两种不同的冲击，流量影响 CPU 有效利用率，包量影响 CPU 无效利用率，抖动大多由包量导致的调度差异引发。做传输协议加速，大家默认激进超发原则，却认为冗余双发不道德，其实这两个是一回事，它们本质上是一种 “矩” 内的交换，就像力和力臂交换但乘积不变一样，成本是固定的。经理和工人们青睐前者，鄙视后者。
2025-03-23 08:57:56
6685
原创 95 计费 5% 时间窗口的利用
人们上网行为是人们在真实世界行为的一个映射，受环境和周期律影响，比如天气，节假日，发薪日，赶工期，失业，例假，怀孕，搬新房，生病等等，而在大的环境约束下，热门影视剧，体育赛事，国际事件等也会关联流量的长程依赖，如何从中分析中模式的方法就是技术含量本身。典型的无脑做法是在计费周期内越往后越激进，如果到了月末用户依然请求大流量同时内容方亦有剩余每天 72 分钟，那就使劲用完，大聪明貌似好刀用在了刀刃上，但如果高峰期大家都这么干，虽然运营商赚不到钱，但网络拥塞还是用户用时间成本买单，哪哪逃不掉。
2025-03-22 22:59:29
6535
原创 BBR 和 CUBIC 对长肥管道的不同反应
好比一个老胖和一个瘦子一起坐车，一开始他们屁股接触椅子的面积差不多，但越往后老胖占地越大，并不是老胖故意挤，而是因为他体重大，车子晃动传递给他的力足以挤压更多空间，从而公平承载他的体重，如果总空间一定，两人体重的比例就是他们占用空间的比例，其实两人都觉得很挤。BDP 是个标量，它只是个数量，单位是个，字节，比特都无所谓，在控制端，它体现在 Inflight 的观测和 cwnd 的计算，它并不体现任何作用力的细节，而 BBR 与此不同，它直接控制速率而不是量(有争议，但讲它时不评价)。这也是非常明显的事。
2025-03-22 22:51:07
7195
原创 BBR 与 AIMD 的协同优化
正常稳定情况下，aimd_rate = bbr_rate，cwnd 也不会受限，但在不稳定的情况下，aimd_rate 能动态捕捉到瞬时变化，aimd cwnd 可以比 cwnd_gain·BDP 更保真，同时 β 退让了 AIMD 的 buffer 入侵性同时又不失公平性。往瓶子里灌水时，如果水管开太大，水就永远灌不满，因为水流的冲击力会把最后那点水溢出去，必须细水长流才能将瓶子灌满，但这会让水灌满的时间增加，最合理的方式就是一开始开大水龙头，等水快满的时候，逐渐关小水量。如何解释这个原理呢？
2025-03-16 10:10:31
7511
原创 数据中心传输：消除流抽象，重塑多路径
依照熵的概念，有长短，突发属性的 flow 为低熵流量，而独立的 packet 则为高熵流量，分布最均匀的流量熵值最高，最能避免作为低熵态的拥塞，这意味着流量不能有任何属性和模式，在所有等价路径均匀随机分布的 packet 是避免拥塞的唯一理想策略，利用可预测的反面，即不可预测性。结论很明显，到达过程变异越大，系统平均排队时间越久，队列平均长度一定，方差越大，越容易局部突发拥塞，交换机 buffer 若太大，则利用率不足，若太小则遭遇突发时更容易丢包。同时，这意味着 ECMP 在本质上和大象流是冲突的。
2025-03-16 08:33:27
7990
原创 网络的正则拓扑与自然生长
起初，在 1970 年代，教授们只是随意互联，然后，在 1980 年代，教授们希望构建一个分层的正则拓扑网络，再往后，运营商实现了一个松散的分层正则网络，网络开始自然野蛮生长，最后，CDN 厂商的经理们彻底破坏了网络的正则性。虹桥枢纽，HongQiao Hub，路口都是 Route，Hub 标识，仿佛进入了一台路由器内部，而事实上，虹桥 Hub 本身就能分层直连(而不仅仅是可达)世界各地(飞机)，全国各地(高铁)，全上海各地(地铁公交网约车)，全虹桥各地(公交)，这本身就是一个路由器。
2025-03-09 13:15:00
8838
原创 传输协议优化的博弈三角
此外，还有性能，成本，可靠性组成的博弈三角，甚至经典的 CAP 定理描述的一致性，可用性，分区容错性组成的博弈三角，这个三角定义了互联网本身，P 客观存在，C，A 之间做 trade-off，而 P 的客观性是定义的，互联网设计之初，本身就是需要分区容错，如果没了这个特性，类似主板那样，就无法抵御核打击了。所以说我经常听到一些一听就不靠谱的论断，比如 PR 自家的协议或面试过程中，算法可以提升多少倍的性能，同时又不增加成本，这种属于懂一点但又不是真懂的，但如果看明白了这个博弈三角，就肯定谨言慎行了。
2025-03-07 19:34:04
8150
原创 函谷关以西
司机没穿西装皮鞋在白宫被嘲笑，吵架，吵完架饭也没吃被轰走的事使人想起楚怀王，被张仪欺骗，两边倒，屡次找强国斡旋，最终失去强国地位，且被扣留，彼时彼景也是一个失败的案例，楚齐秦魏韩之间的外交，军事博弈，从智人心智视角看，简直一模一样。但实际上这并不是秦国独创的手段，代入当代的世界，这味道依然令人熟悉，从阿富汗，中东，近东巴以，经过叙利亚，土耳其到欧洲，从俄乌到远东，也有个 “秦国” 在到处军事打击，外交离间，经济封锁，利用内乱，扶植傀儡。如商鞅变法，合纵连横，六国弊在赂秦，贵族内斗，改革不彻底，等等不赘述。
2025-03-02 12:03:14
9572
原创 笛卡尔解析几何观点的形成过程
写于昨天，但遗漏一些碎语，比如说 “解析大法下，一切都是可以算出来的”，我经常对小小讲，充满恶意玄幻的平面几何题目让你证明 AB = EF，你就画出坐标系，把直线方程，焦点坐标全算出来，利用距离公式算 AB 和 EF，最后发现它们的值相等，把结论甩老师脸上。这就是分析，解析，或直接叫拆解，把问题中涉及到高深莫测的，直觉的东西丢弃，根据条件把问题涉及的每一个点的坐标算出来，问题自然就解决了，而这个计算的过程显然只是一个机械的 “体力活儿”。浙江温州皮鞋湿，下雨进水不会胖。
2025-03-01 10:51:19
9395
原创 笛卡尔方法论和解析几何的诞生
另一种证明是综合的，“它利用一连串的界说，公设，公理，命题和提问，因此要否定结论中的某些东西，它立即会表明，这些要否认的东西已包含在前提之中了。后世在事后看来，在这个具体问题中，为确定 C 的位置，笛卡儿选直线 AG 为基线，相当于一根坐标轴，点 A 为起点，相当于原点，x 是从起点量起的一根线段的长度，y 是另一根线段的长度，该线段从基线出发，与基线交成固定角 β，这可以看成另一根坐标轴，随 x 不同而改变位置，但与基线 AG 交角始终不变。就仿佛笛卡尔说，让我们看一个简单例子来说明我的方法论，“。
2025-02-28 21:05:45
10654
原创 一个原教旨的多路径 TCP
MPTCP 的路子显然把问题复杂化了，因为 MPTCP 是以 TCP 为基准的多路径协议，而不是以底层网络为基准的。前面提到过 ECMP 和 TCP 之间的互不友好，pacing 收益和中断开销的互斥，在事实上阻碍了 packet-based LB 的部署，也限制了交换机，服务器的并发性能，同时潜在增加了 bufferbloat 的概率，而适用 packet-based LB 的短突发，老鼠流又无法承受 TCP 的建连开销，向后兼容的普遍刚性意味着几乎所有基础设施若不迁就 TCP，其崭新特性难尽其功。
2025-02-27 19:28:39
9545
一个iptables的stateless NAT模块实现
2014-12-27
模块化的nf-HiPAC
2014-11-21
关于linux内核以及其他个人体会的文集
2009-09-07
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人