- 博客(2379)
- 资源 (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
42741
41
原创 浅谈伪共享
如果你不想让 gap 那么大的空间浪费掉，你可以将它组织成 “铁定不会和 a，b 同时访问的变量”，但懂这个的又有多少，你要是这么安排了，读代码的会莫名其妙，但他们但凡将变量换个地方，性能就会下降，没人能排查出原因，然后就是加班，开会…也不限于网络收发，所有频繁的，快速的子系统，例如调度器，内存管理，均可引入类似思路，目前也有很多相关派池，虽擅长并关注，但不是我的领域，就不赘述了。依照以上宗旨，你就瞄着内核网络数据结构去拆吧，拆一个合并一个就能提一个派池，多提几个派池就能当经理。
2025-10-19 10:38:18
4070
原创 互联网“拥堵税”：拥塞暴露机制和审计
经常说的拥塞控制是端到端拥塞控制，如 TCP Reno/CUBIC，BBR，这类算法完全是自觉算法，不具备任何强制性，这便提供了一个 “不做” 的机会，若不是 Linux 内核有门槛且拥塞控制一般内置在 Linux 内核(或 Windows 内核)中，互联网或许早就由于人们为了抢占带宽而绕开拥塞控制而早早崩溃了，或者形成一种博弈均衡而不至于崩溃，但不管怎样，只要能 “不做”，互联网就不会畅通。可以说，RFC7713 展示 ConEx 是一个典型的要么严格实施，要么百无一用的标准，这是它的内在性质决定的。
2025-10-18 10:15:00
4359
原创 QoE 驱动 AIMD 拥塞控制
全受吞吐控制，一旦发生丢包，则 delivery rate 下降则视为拥塞，则降 cwnd 缓解，若偶然噪声丢包，则 delivery rate 未必下降，则 cwnd 继续遵循 AIMD 逻辑做 AI，这便是一个 loss-based 算法了，顺带还解决了历史上的甄别问题。值得注意的是，不同应用需要不同的权重，比如文件下载只需要关注吞吐，其它因素的权重为 0，这就回归到了常规的 AIMD，因为丢包后的吞吐一定会下降，又如视频会议，在线游戏相对直播而言，时延更重要，而直播的卡顿率，码率更重要。
2025-10-18 08:00:00
4562
原创 Linux TCP 最新的 ECN patch：从 ECN nonce 到 Accurate ECN
ECN 基于全链路的信任，它假设 receiver 会诚实 echo 它收到的拥塞信号，但一个 “恶意” 或 “自私” 的 receiver 可能会选择不报告该拥塞信号，因为如果它不报告拥塞，发送端就不会降速，从而可能为这个 receiver 维持更高的吞吐，这种行为显然损害了网络公平性。为一些莫须有的问题，引入协议复杂性以及处理协议僵化问题的代价是巨大的，如此会让 TCP 不再实用，反而充满了自导自演的故事，为想象的问题制造解法，就像现在好多大厂并不太懂网络的经理们制造的数据中心传输协议一样。
2025-10-12 09:00:00
13549
原创 TCP 重传的简化与 Reno 兼容性之辩
为什么最初不能没有 RTO，因为最初没有快速重传，为什么有了快速重传之后还是不能没有 RTO，因为早期快速重传无法区分原始数据和重传数据，只能 oneshot，重传一次后还是要 RTO，不然会重传风暴，那么有了 RACK呢，这就可通过时间序甄别数据发送和确认的顺序，不必区分原始数据和重传数据了，RTO就不再必要，RTO不再必要的内中逻辑是，in order 可以依靠 RACK/TLP，而 out of order 不会 delayed ack。问题的始终都在于重传谁，把这个问题解决了就行，其它的都是手段。
2025-10-12 08:15:00
11451
原创 时延抖动的物理本质
那些搞端到端算法的总幻想一种启发式算法能消除抖动，那些搞数据中心传输的整天折腾什么 lossless，pfc，都是扯淡，我早就重复过多次，信息的不确定性导致这些根本就无法等价实现，但 google 的 swift 是个正确的路，它旨在更加精确区分时延的组分，可即使这样它也只能走到那么远，换句话说，swift 只是区分了抖动的尺度，将主机这个统计复用系统和网络这另一个统计复用系统分开了而已，各自内部的信息依然是不确定的。此外，时间的本质即熵增，那么时延抖动的本质就是熵增的不确定性，即信息的缺失。
2025-10-05 17:16:49
12039
原创 TCP 的韧性：端网关系对传输协议的影响
遗憾的是，虽然 BBRv1 未经论证，我们的互联网已经灌入了比例可观的 BBRv1，它在理论上承诺反 bufferbloat，但大量流共存时，minRTT 将收敛到稳定的统计期望，而 maxBW 则取决于瞬时突发，高于所需，BBR 流几乎总以 g·minRTT·maxBW(其中 g >= 2) 为 inflight，BBR 动力学特征消失，AIMD 的统计特征也被冲刷，大比例的 g·minRTT·maxBW 像混凝土一样灌在互联网的每个角落。对于支撑本文结论的证据，我此前也表达过类似观点，即端限制流。
2025-10-02 22:31:11
12654
原创 TCP/IP 的韧性：尽力而为 & 可靠传输协议
总之，自研协议，重造轮子是赔本的。做一个可靠传输协议，如果网络不是尽力而为的，而是完全随机混沌的，那么接收顺序就是随机混沌的，可能仅呈现在时间上与发送相关的积累分布特征，但由于实际接收缓存的限制，中心极限定理失效，样本不足以呈现上述统计特征，因此这些相关性很难被利用，那么完全的 sack，nack 就是必要的，除此之外没有任何办法确定一个数据报是收到了还是在超过一个最大容忍时间后仍未收到，紧接着的问题就是该最大容忍时间是多少。基于此尽力而为的假设，可以认为互联网传输是准序的，接收端接收的序列也是准序的。
2025-09-27 11:45:00
15024
原创 TCP 的韧性：网络的无限扩展 & 主机的有限能力
总结一下，stream 适配主机的能力，又适配单路径网络的能力，与网络的规模无关，这其中的不变量就是主机的能力，app 适配人的瞬间注意力，又适配智能终端的屏幕，与人总精力，终端的性能无关，这其中的不变量是人的瞬间注意力，抓住不变量，跟住它，就得到了永恒。矛盾的点在于这破坏了无状态网络的透明性，或者反过来也成立，若网络不承诺维持主机应用的语义，主机的能力将被还原操作淹没，因为它不得不分出与网络流量成比例的能力来还原网络传输后数据的畸变，比如丢包重传，乱序重组，使用网络越多，这类处理在主机能力的占比越大。
2025-09-27 07:15:00
15774
原创 要优化流程而不是代码实现
老版本 tun/tap 转发逻辑是前任写的，MPTCP 是开源代码，事实证明，性能瓶颈出在前任的代码，而不是开源代码，当把前任的代码重构并极致优化后，留给 MPTCP 的优先空间就非常小了，这意味着大多数开源代码的性能经得起考验，多数错在自己，一开始上来就优化 MPTCP，方向就错了。一个物理的传送带该有什么行为以及多好的性能，是传送带这个结构决定的，不是由它的材料决定的，如果大家都用皮带，你就没有必要用一个新材料去重做，而必须要关心的是眼前这根传送带的运转流程，是不是有什么阻碍，如果有就解除它。
2025-09-26 21:45:00
15248
原创 TCP/IP 互联网的真相：现实网络的规律
这是系列第三篇。主宰互联网状态统计律是理解网络性能，规划容量和设计协议的基础，它们都很简单，毫无技术含量，前面两篇文字侧重讲了这些，本文在此基础上勾勒全貌。我做网络传输好多年，很早以前就宣传这些统计律的意义，但都无人问津，我曾经从这些统计律中导出了那 1000 多 if 分支的著名优化，于效果看，那是绝佳的一次优化，但于形式看，那是最糟糕的代码，但哪个更重要呢？
2025-09-21 07:15:00
23532
1
原创 TCP/IP 互联网的真相：空间域和时间域的统计学
真相是，网络既是收敛的，又是发散的，但人们既看不得发散，看到丢包和一丝抖动就大喊大叫，同时又看不见收敛，完全不知道 CLT 与 TCP/IP 有什么关系，更迷信 buffer 越大越好，这实在悲哀，而我将驱散这些悲哀。来看个相关的技术演进加深理解，从时间域的争用到空间域的包交换，整个互联网技术的迭代几乎总围绕着局部发散的时间域技术和全局收敛的空间域技术，整体表现为 burst 的调度和 buffer 的管理。的关系上升，其中 N 是时隙数，与二项分布右尾概率的结论一致，这意味着冲突是必然且频繁的。
2025-09-20 17:51:38
23567
原创 结构决定行为：用协议简化代码
，因为传送带很忙，它将一个个数据包从 tun 读出后运送到 socket 发出并在对端反过来处理，为 batch 优化，我在传送带的一端使用 sendmsg 的 scatter/gather io，在另一端我将 batch buffer 先读入一个 RingBuffer，然后在解析的过程中再将其放上传送带，我当时说这已经够好了，但今天看来并不是，持续优化无止境。核心之功就在于协议本身就定义了 batch，处理自然也就是 batch 处理，你想一个一个来都不能，正所谓结构决定行为，这是真理。
2025-09-20 10:16:45
23281
原创 TCP/IP 互联网的真相：中心极限定理与二项分布右尾概率
我会在另一篇文章中导出这个结论，但这里要理清的是，正是 AIMD 的力量让中心极限定理的采样样本随 n 反比例缩放，保证其和的均值不变，而其方差则随 n 增加而减小，从而确保了资源的收敛。的作用下，最初给出的 PDF 图像随着 n 的增加，最终被塑造成了越来越瘦高的钟形，这就是中心极限定理，除了用概率解释 PDF 的性质，还可以使用卷积，每次卷积都进一步平滑和对称化分布，不再赘述。与解释中心极限定理一样，依然忘掉泊松分布这类名词，仅考虑概率表示形式，推导出性质，利用性质解释网络的本质。
2025-09-20 09:00:00
24026
原创 从 IP over 鸽子到 TCP 的适应性
这简直跟 TCP 一模一样，TCP 靠序列号编排顺序，每个 TCP 段即一 “册”，传输中的 TCP 报文为 “帙” 的一 “卷”，接收端靠序列号做 “篇次” 恢复其位置，由于竹简书可能会被以任意方式运输，不限于用鹰(信鸽带不动)，牛车，人力，那么遇到的问题和上述送信的问题一致，可靠性处理也将一致，这背景在 1970 年代在 arpanet 上被重构，就是 TCP 诞生的背景。回顾平民送信，所谓悲观假设，即不可靠，会丢，会乱，资源受限，全是否定贬义，这是真正的最小集。可靠运输依然需要回执，但回执成本低了。
2025-09-19 20:36:34
22945
原创 从电路交换，分组交换到带宽交换
当前 OCS 如火如荼，相比光电光域，在光域做带宽交换要容易得多，而可编程光纤连接则是带宽交换的一个实例，配合 SDN 等传统技术，可实现带宽的动态分配和管理，无论从资源利用率还是从吞吐性能，时延指标来看，都能获得质的提升。从资源的角度看，带宽不足固然是拥塞的根因，但从局部看，绝大多数拥塞的直接原因来自资源分配不均，以往的想法是为流量重新换一条路，但如果带宽可以在交换机内池化，便可直接对带宽进行重分配了。1960 年代伴随分时系统发展，分组交换被提出，以排队论统计复用理论为基础，奠基了现代互联网。
2025-09-14 07:30:00
15376
原创 少即是多：从 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
13822
原创 主宰 TCP AIMD 的中心极限定理
我们的社会，城市，甚至自然界生态系统均是与 TCP/IP 互联网一样的随机的复杂自适应系统，这类系统的特点是去中心化，资源共享，分布式哑控制，没有任何措施规范个体的行为，全凭个体自主探测和适应，尽力而为，我们惊奇地发现，这类系统几乎运行得都非常和谐良好，其中的动力学正如 AIMD。，他用排队论首先证明了统计复用是可行的，奠定了互联网的统计学理论基础，在他之前，虽然人们设想了很多不同拓扑的组网方式，但大家始终无法摆脱可用性的魔鬼，人们怀疑，如此不受任何约束的，混乱的所谓分组交换网，真的行得通？
2025-09-13 07:06:05
12873
原创 性能优化的边界-不该优化什么
大开合的性能提升往往来自于粗粒度的排列组合，而不是细粒度的优化，也就是说，知道哪种场景选择哪个现成的构件去搭建系统，比优化单独构件的收益边际更高，随着边际收益递减，才需要过渡到更细粒度的优化，例如优化算法，但往往在这个时候，系统表现已经足够好了，且有能力继续优化的工人也非常稀少了。这段话意思是，绝大多数肉眼可见的性能提升来自于对既有技术构件的选型，而对细节的细粒度优化收益小到毛毛雨，而成本往往也支付给了根本没有能力做此类优化的经理和工人，换句话说，这类优化除了竞速，内卷样式的烧钱之外，并没有实际意义。
2025-09-06 10:16:09
17477
1
原创 无拥塞网络的辩证
他们美其名曰要尊重当前标准，复用当前接口，以此为理由，结果又回到以太网那一套，复用了标准，也继承了缺陷，绕了一个圈，到头来，在这里省下来的，还得到那里加倍还回去，然后嘴硬不承认，反而说这是个创新，又一个世界第一等。要么直接做完备，要么怎么都做不完备，这背后存在一种缺陷哲学，一开始做不完备是因为有缺陷，同样因为该缺陷，日后怎么做还是做不完备。遗憾的是，AIMD，BBR，ECN，PFC 都是反应式的，人们总在诸如此类之上更正修补，试图彻底解决拥塞控制的所有问题，而只要 RTProp 不为 0，这就是不可能的。
2025-09-06 09:56:57
12196
原创 乐观并发: TCP 与编程实践
但并不是说这种做法总是对的。如果退避和重试的时间总是超过自旋等待的时间，那么一把 spinlock 就是高尚的，我也经常循着 spinlock 到 rwlock 再到 rcu 的步骤优化代码，而这并不浪费我太多时间，所以相比乐观并发，这就更划算，因为和哑网络不同，主机状态对程序而言完全可见，逆熵很便宜，所以用更精确的信息控制它就能换来高性能。，也就是不论网络还是主机的不同大小的 buffer，致使 TCP 从最初的 GBN 经 SR 到 MultiPath-TCP，底层乐观并发逻辑一直没变，变的只是参数。
2025-09-05 22:22:00
12730
原创 性能优化的边界
循着高内聚，低耦合，不优化的方法论，势必会朝着仅通过 IPC 交互的微核心设计更进一步。然而众所周知，IPC 肯定没有线程间交互更快，多一次调度都是时间，可这背后还是时间尺度的问题，相比手贱心痒持续优化而成的庞大程序节省的那一点指令时间，微核心结构节省的是你的生命，因为它更简单。这意味着我需要构建最内聚，最精简，最高效的核心预制构件，然后用该构件搭建整个系统，剩下的交给操作系统，这能让我省去很多 bugfix 的调试时间，损失的只是那一丁点牙缝里抠出来的性能。人生苦短，吃点好的，干点正事。
2025-08-30 08:26:57
17278
原创 CUBIC 和 Vegas 合体新姿势
另一方面，Vegas 作为 Delay-based cc 代表，识别拥塞的能力一流，但却被先入为主的 AIMD 压制，无法与其共存，这也是硬伤，背后的原因是 Vegas 没有负反馈动力学基础，仅仅基于不精确的测量，本质上还是端不识网。前面提到过，AIMD 已经足够优秀，迄至 CUBIC 已臻于完美，但它还是无法甄别非拥塞随机丢包，导致随机丢包时表现力不够，这可以认为是硬伤，背后的原因就是信息不足，本质上是端不识网导致，任何端到端算法都有各自硬伤。浙江温州皮鞋湿，下雨进水不会胖。上上周写了一篇 AIMD(
2025-08-30 08:16:17
16182
原创 无懈可击的 TCP AIMD
如果 n = 1，为了照顾人有限的肺活量，气球容量必须至少等于人的最大肺活量，且吹得太快容易爆裂，吹得太慢换气时出气孔没气体，但 n = 3 时，一个人换气时，另外 2 人可能依然保持吹气，就这样让 n 不断增大。更直观的例子是非牛顿流体，不管形状如何，只要质量相同，在重力的作用下，它们最终肯定占据相同的占地面积，因为重心高了，重力会拉低它，将高度补偿给面积后，拉低的力度逐渐变弱，最终大家一致，就好像大家刚挤上一辆公交车时气都喘不过来，车开了点播一段时间后，就逐渐宽松且公平了，
2025-08-29 22:19:55
12617
原创 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
15042
原创 1 小时半径如何约束人口极限
眼光放宽放长远，在智人的心智尚未进化到支持抛弃肉体而独自飞升前，相对于激情又勇敢，可怜又悲哀的万年人性，科技只是辅料，它的存在正是为了哺育这颗永不满足的心足以拖拽沉重的肉体而不气馁，科技是为了让人走得更远，而不是让人躺平，在我看来，科技的发展一定会让城市规模变大，人口增多，为人的具身属性增加范围更广的活动空间。在我看来，制约人口的不仅仅是物质资源，还有社会约束。在人口的资源决定论之外，还有很多决定人口的因素，除了通勤交通技术之外，还有24 小时总量的注意力时间占比，邓巴数等，彼此相互胶着。
2025-08-23 07:09:32
18365
原创 epoll 陷阱：隧道中的高级负担
对于 I 和 O，一心不可二用，持续的双向隧道流量需要的恰恰是解复用，即将同一个描述符的 I 和 O 解复用到不同线程，而不是复用，所以选型时第一要务就应该排除掉 select，poll，epoll，libevent 等异步多路复用技术，而为每一个 socket 简单地创建两个线程分别作阻塞 I 和 O 几乎是唯一选择，但这由于太简单而显得 low，展示不出自己运用复杂技术的能力，进而选择 epoll 等多路复用的错误技术，然后再陷入持续优化的深渊，早干嘛去了。浙江温州皮鞋湿，下雨进水不会胖。
2025-08-23 06:40:14
35132
原创 不要轻易做 iptables MASQUERAD
AI 虽好，但它不是万能的，AI 能快速搞定常见的范式编程问题，哪怕写一个极其复杂的逻辑，只要范式化，AI 都非常擅长，但这并不意味着它能正确回答该过程中的疑问，特别是冷门疑问。AI 特别擅长组织逻辑和语言，让你觉得它缜密到无懈可击，认为它是对的，这恰恰说明逻辑和语言本身就是一个大范式，正如它名字所展示，大语言模型。不是 AI 不会本文描述的问题，而是它没见过，但即使它没见过，它也要发挥它遣词造句的能力，长篇大论显得它很精通，因此很容易引起误导，特别是你在学习一个新领域，无力辨别真伪的时候。
2025-08-22 22:34:16
19670
原创 tun/tap 转发性能优化
不过这几个指令到底价值几何，还是需要量化。malloc 不满足，自己实现一个最简单的内存池，先不追求地址连续，否则还是要绕回 RingBuffer，最后陷入回绕，原子变量等细节，先实现一个操作最简单的基于 queue 的内存池，使用时从 queue 池中 dequeue 一个 block，用完后 enqueue 回池中。在设计之初，良好的设计只要性能足够，并且可扩展，如果性能不再满足需求，首要的不是优化它，而是替代它，因为这不是一个良好的设计，没有扩展性，任何需要后期投入大幅精力优化的设计都不是好的设计。
2025-08-15 23:22:29
15090
原创 难以超越的 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
12502
原创 避不开的数据拷贝(2)
如果数据是严格保序的，通用机器需无条件满足该约束，典型例子是通用处理器，即 CPU，它的处理资源必须在时间维度分割成流水线，作为数据的串行指令在其中接力通过。还有一个问题，如果必须要搬运，数据搬运过程中为什么需要 buffer，为什么不能一镜到底，推而广之，为什么要接力，转介。既然处理器是通用机器，就没有专属数据，所以数据都要从别处调来，这就涉及到了数据搬运，就有了外设的概念。总之都是数据能不动就不动，实在要动就少动，如果有谁写了一个程序，频繁做 memcpy，势必要被优化掉，不管是针对程序，还是针对人。
2025-08-09 07:49:50
20975
原创 Linux Kernel TCP 终于移除了 RFC6675
我从 2009 年开始关注涉入 Linux 内核网络，读过非常多讲网络的书，但除了《TCP/IP 详解(第二版 卷 1)》和 樊东东版《Linux 内核源码剖析：TCP/IP 实现》等个位数的版本，只要讲到 TCP 就戛然而止，我是觉得 TCP 由一大堆细节错综复杂组织而成，很少有人能完全搞清楚，书虽不如论文权威，但论文专于一个点，书则要面面俱到，有这能力和精力的反而不多。”，我相信随着 TCP 还会进一步瘦身，这种事会越来越少，与此同时，网上充斥的那些 TCP 八股文也会逐步一个个过期，不再算数。
2025-08-09 07:38:23
12975
原创 避不开的数据拷贝
哺乳动物通过血液交换气体营养，通过消化系统将食物从嘴处理到肛门，通过神经系统传递信号和指令，所有这些系统的每一次运输都有一个确定的源和目标对，比如口鼻，心脏，细胞，大脑，肌肉，即便这是个缜密的近乎确定性的网络，偶然的血压波动，血脂，血管壁畸变都会引发灾难性后果，比如心梗，脑梗，脑出血，肺栓塞，肌溶解。对比这两类结构，从进化的角度看，哺乳动物类似计算机系统，牺牲了能效和速度，换得了灵活性和适应性，属于通用系统，这启发人们若设计一个高速系统，必须反着来，牺牲灵活性和适应性，换得能效和速度，打造一个专用系统。
2025-08-03 13:23:08
19622
原创 MPTCP DSS-Checksum 对吞吐的影响
所以说，整个事情是，没有 TSO/GSO 支持的标准 mss 尺寸 TCP 收发才是正常的，TSO/GSO 引入了优化，跨层协作 batch 处理大大提升了吞吐，普遍的 TSO/GSO 支持下，人们习惯了这个优化的结论，以为常态，MPTCP 回归 mss 尺寸的收发反觉得不正常。理论上，midbox 对传输层及上层的任何干预都不应该，有一个算一个，包括 NAT，Firewall，DPI，但这初衷的背景并不符合互联网后期的现实(比如安全性)，修补是难免的。浙江温州皮鞋湿，下雨进水不会胖。
2025-08-02 07:51:41
18099
原创 TCP RTO 与丢包检测
回到原点，minrto 保守化的原因在于避免不必要的重传而加重拥塞，但它与丢包不能及时恢复相比，要两权相害取其轻，对于 block 传输，自然要优先考虑避免拥塞问题，但对于 thin stream，比如游戏，远程登录等非 capacity-seeking 传输，其 inflight 不随带宽而增加，不足以对现代网络的负载产生可观测影响，因此它们并不是拥塞控制的目标。其次，自定义 TCP 相关参数时代以来，网络环境已经发生重大变化，但这些参数的缺省值却很少发生改变，而这些缺省值往往影响 TCP 的性能。
2025-08-01 22:50:20
17134
原创 后摩尔定律时代网络传输
容量提升必然伴随着拓扑改变，数据包会经过更多的 “跳(hop)”，但路径也更多了，这意味着数据包在具体某条路径遭遇拥塞的概率增加了，却可以随时选择不同的路径，拥塞控制策略需要适应这种变化，传输协议本身也必须适应这种变化，把鸡蛋放在不同的篮子里，取消依赖，并行传输。扩展交换容量意味着要扩展路径，交换容量和交换扩展因子之间不再是 1:1 的线性关系，而是乘积关系。这个现象就像住宅办公容积率和道路的关系，只要不把立体交通引入小区或写字楼，拥堵问题就无解，因为容积和道路扩展因子不是线性关系。
2025-07-27 10:35:05
24871
原创 从单核到多核系统的网络传输
多核为达到类似 Hash 效果，在软件设计上，task 粒度必须足够小且互相无依赖，若非如此，假设存在一个前后相关联的 task 序列选择了同一个处理核，该 “大象 task” 势必引起该处理核上其它标准大小的 “老鼠 task” 饥饿，但这种相互依赖的串行 task 设计(比如 MPTCP)非常常见，无疑是受单核系统串行理念的思维定势驱使，该定势下，只是 “将串行软件适配到了多核系统”，而非 “为多核系统设计串行软件”。这很像现实调配中的 “晃荡” 动作，一碗水端平，均匀摇晃，收敛到公平。
2025-07-26 08:25:09
14120
原创 TCP/IP 哲学：端到端的 Postel 定律
智能手机允许用户进行任何操作，即使是错的或者无效的，它也尽力猜测并对准操作边界，只要不明确违规即可行，用户的操作空间扩展到了整个屏幕，配合以任意手势，针对任意操作均有可视化回应，比如屏幕下拉，下滑，左右滑，长按，此外，智能手机以独占输入精确提示用户如何操作，比如只让你输入 4 位数字，没别的选项。某种意义上，电脑失败了，智能手机却成功了，原因很简单，电脑恪守了端到端原则，作为终端，它的操作太复杂了，而智能手机同样作为终端却成功了，这背后又隐藏了什么。总结两大件，端到端原则和 Postel 定律，相铺相成。
2025-07-19 12:08:27
14156
原创 从 TSO/GSO 到多路径：TCP 分段的边界
如果进一步观测 skb 的动态，你会发现在一个简单的传输和重传场景，不断会有指向不同大小 data 的 skb 被分配，释放和调整，显得喧嚣。统观之，再看分层和 “Unix 单一职责”的哲学，它们天然就为并行而生，不管分层还是单一职责，都内含了模块化，解耦合和交互，但在路径确定的串行假设下，这些很容易被 “协作” 统一，形成所谓跨层优化，比如 TSO/GSO/LRO/GRO，但对于路径不确定的并行操作模式，这些反而是前提，天然抵触 “协作”，因为协作必带来同步。总之，有点意思，沾边了。
2025-07-19 07:50:28
13680
一个iptables的stateless NAT模块实现
2014-12-27
模块化的nf-HiPAC
2014-11-21
关于linux内核以及其他个人体会的文集
2009-09-07
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人