- 博客(2011)
- 资源 (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
41032
30
原创 nginx 全相联结构的引申
要么把逻辑装进 task(各种 x 程)，托管给系统调度，要么自己调度，总之都是调度，不同的是，托管费省不了，task 内存开销，task 切换的 CPU 开销，无论创建多少 task，可同时运行的也不超过 CPU 核数(再次强调，task 不是资源，CPU，内存才是)，挂起的 task 就是纯消耗资源，比如 TCP 连接的 CPU 开销，不活跃长连接的内存开销。容器不是资源，进程不是资源，线程不是资源，协程不是资源，socket 不是资源，它们只是 “虚拟层”，只有 CPU 核才是资源。
2023-09-16 22:15:00
859
原创 epoll 的实现
epoll 省去了遍历开销，这意味着并发连接越大且活跃连接越少，epoll 优势越大，反之，如果所有连接都是活跃连接，epoll 反而会损失性能，看看那一大堆代码就会明白，每一条指令都是要花费 CPU 时间的，select 受 1024 限制，poll 就挺好。原因很简单，epoll 没什么神奇的。在早期没有太多的并发连接要处理，select/poll 足以应对，遍历一遍又能怎样。而实现 epoll 的基础设施在早期内核里也没有，所以支不支持的，也不是什么大家关注的事。皮鞋没有蹬上，露着白袜子。
2023-09-16 11:45:00
890
原创 BBR 带宽估计的延后累加
为过去的事，搅乱当前的安排(schedule)，不值当，那就干脆点，全部干掉好了，广义地说，maybe undo 和 maybe retrans 也不要才好，那就把 old_ack 这个 label 去掉吧。像 bbr 类 rate-based 算法，低估带宽不可怕，它自己的状态机(比如 probe up)能搞定，但高估带宽甚至直接打乱状态机的正常运行，比如 buffer 以非预期方式被占用，竟然因为高估带宽而不是 probe up，则 0.75x drain 就没用了，就像飞机失速很难改出一样。
2023-09-09 21:15:00
7870
原创 从 BBR 失速到带宽探测
理论上，迟到但正常的 ack 是下行链路的独立问题，如果当前记忆中稳定的 bw 恰好合适，上行链路 probe up 行为会造成 queuing，接下来的 drain to target 将回滚掉 probe up 的结果，相当于 probe up 做无用功，在现实的多流共存场景，probe up 行为一定会挤占些 bw 出来，伤害公平性。另一方面，确实只需要遵守一个大原则，而不是精确刻画微观。就像足球，每一场比赛从每一个细节上看是完全随机的，但结果很大程度上却是可预测的，这是既精确又模糊的艺术。
2023-09-09 11:45:00
7712
原创 谁该来负责拥塞控制
源抑制的方案和问题在 RFC 896 提到，彼时是一个端到端拥塞控制方案尚未被引入的干净时期，但现在却是端到端方案也出现了问题的浑浊时期，至少在数据中心，源抑制的思想早就落地，PFC，INT-Based cc 均是源抑制思想的体现，就像 CSMA/CD 反压本地 host，反压上一跳是一个意思。端到端拥塞控制是 1980 年代的一个创举，但它固有的 RTT 滞后性也必须接受，这种端到端方案需要从流自身提取拥塞信息，就需要流的连续性，也就是文初的描述，它无法作用于 one shot pingpong 流量。
2023-09-03 11:45:00
9245
原创 BBR cwnd_gain 的循环依赖 bug
设 delta_interval 为新老 interval 之差，则 delta_max_buffer_used = 1.5 * delivery_rate * delta_interval，保持该值为 0，算出 delta_cwnd_gain 即可，附加到用新的 cwnd_gain 进行 probe up，则始终保持 buffer 最大用量不超过 BDP 的一定比例。索性再粗暴一点，不要改代码，直接将 cwnd_gain 参数改成 3，调参即可，意思差不多，丢包多点儿，不过反正也不在乎，重传猛就行。
2023-09-02 15:15:00
12496
原创 rate-based 拥塞控制吞吐测量
f(x) 以 round 为粒度向前平滑滚动，g(x) 在一个或者几个 round 内平滑滚动，h(x) 间隔固定的足够小但又不至于样本不够的 delta(time) or delta(delivered) 捕捉细节，比如类似 bbr 那般 x rounds 的 win，三者合力刻画链路画像。如果在稳定状态，f(x) = g(x) = h(x)，T = f(x)，与当前 Linux kernel 无异。h(x) 体现的是 delivery rate or rtt 的梯度或者变化率。
2023-09-02 06:15:00
12318
原创 漫谈拥塞控制: pacing rate
总线以太网的冲突表现为交换以太网中的排队，而退避时延表现为排队时延，如果交换机 buffer 有限而 buffer overflow，则可能会引入重传时延，也可归入退避时延的等效时延。既然都一回事，那么总线以太网中出让时间槽在交换式网络中即表现为 pacing 发送，所谓 pacing 就是在发送两个连续的 packet 之间插入一段时间。话虽如此，但很多人依然觉得 burst 好，因为当他使用 pacing 的时候，吞吐确实下降了，这属实你没测量好，而不是 pacing 的锅，说到底还是算法不行。
2023-08-30 23:15:00
8140
原创 现代网络欠 TCP 一个控制信道
最后一笔数据 1460 字节，将其最后 1 个字节 copy 成 1 个或 n 个新报文，跟随着最后一个 1460 字节的报文作为护送，流量开销仅仅是 1 个或 n 个 TCP/IP 头外加 1 个字节，收益是不再需要 timer。花式护送还能检测乱序，以 1460 字节报文的后 3 字节每 1 个字节封装一个护送报文，发送顺序是 2，1，3，如果 SACK 顺序也是 2，1，3，即可立即重传 1460 字节的报文，如果不是，则有概率是乱序，那么再等等，只是别等太久。诸如此类种种，可以异想天开。
2023-08-13 22:15:00
9634
1
原创 短肥网络的 RTT 敏感性
不了解 CDN 调度机制的可做下面的简单实验：ping www.tencent.com 观察时延，找距离你南北分别 500KM 开外的朋友也 ping www.tencent.com，你会发现你们三人所在地解析出来的不同 IP 延时都在十几个 ms 左右，这意味着 CDN 总是将请求调度到距离你最近的地方。delay-based 算法基本假设，吞吐与 RTT 成反比，y = 1/x 图像可看出，x 越小，轻微 x 变化带来的 y 变化越大，短肥管道中，吞吐对 RTT 非常敏感。
2023-08-13 15:30:00
9514
原创 漫谈拥塞控制： a Decade of Wasted Bandwidth?
在这里，n 是一个参数，预估为一个连接在 buffer 里所能被容纳的报文数量，这是个前提，意味着通过 n 个连续报文采集的 RTT 波动是噪声，因为同时排在同一 buffer 里的报文应该具有相同排队时延。RTT 测量不准和抖动是造成算法带宽分配不合理的首要因素，从而引发效率和公平性问题，高估会导致丢包重传，低估影响利用率和公平性，受 a Decade of Wasted Cores 启发，对 RTT 的测量可等同而视之。看一组 RTT 采样：9，10，11，9，28，12，9，3，10，11，…
2023-08-12 13:15:00
9586
原创 漫话拥塞控制：BBR 是个单流模型
和 BBR 单流吞吐到顶即不变不同，多流大 buffer 场景，由于 B1/(B1 + B2) < (B1 + d)/(B1 + d + B2)，BBR probe up 时一定能挤占额外带宽，maxbw-filter 将记录一个偏大的 bw，而其它流并不主动降速，依然保持自身 maxbw-filter 的 bw，它们将共同在 buffer 排队，RTT 越大，inflight 越大，侵占性越强。这样收紧自身，自然就慢慢步入了多流场景了，总之，1 和 n，也是一个参数，要和其它参数联调，注意，是联调。
2023-08-12 06:45:00
9580
原创 kretprobe 和 fexit
同样一气呵成，但没了 int3。箭头指示执行顺序，一气呵成，不涉及内核数据结构锁操作，比 kretprobe 高尚，在 register 时即可将 int3 handler 和 asm_stub 摆置到位，但 int3 的开销也不小，且比 Linux kernel 的锁风格更非标。fexit 的把戏在 2020 年中那段走火入魔的时间玩过不少，没想到就是 fexit 的标准，看来多数人觉得正确的思路它就是正确的。kretprobe 孬，跟朋友简单讨论了相关主题，发现 fexit 高尚。
2023-08-07 23:15:00
11233
原创 漫话拥塞控制：Capacity-Seeking 与 QoE
另一方面，IETF117 CCWG 大会 “Guidelines for Internet Congestion Control at Endpoints” 这一趴也提到，网络拥塞是统计复用网络上必然会发生的事件，没什么大不了的，而持续的网络拥塞却是应该避免的，换句话说，瞬时拥塞是常态，持续拥塞是灾难，这两件事应该分别被处理，然而一直以来的传统算法都没将这两件事分别对待。以 bbr 为例，如果 bbr 高估有效带宽，直接结果是更多流量被注入网络，由于算法误判增加网络总流量，这是预期之外的。
2023-08-06 07:45:00
11393
原创 漫话拥塞控制：BBR
即使考虑车速公平(类比带宽公平)，高速/快速路也能高概率自组织收敛，速度太慢的汽车加速空间非常大，它有很大的概率会被加速，而本来就很快的汽车加速的空间很小，它有更大的概率会减速，最终大家的速度虽然不保证绝对公平，但几乎不会相差太多，从统计分布上看，曲线将非常高且瘦，BBR 收敛到这种情况已经非常 OK，我曾经用 buffer 加速比分析过这一段，不再赘述。驾驶汽车，前面空了就一脚油门，前面刹车灯亮了就减速，偶尔会有急躁的司机变道超车，也会有追尾，但都不是大问题，只要司机目视测速准确，一切就井然有序。
2023-08-05 10:26:04
11529
2
原创 kprobe 和 kretprobe 隐藏的秘密
很长一段时间跨越很多内核版本，多个 kretprobe_instance 以 hlist_node 的方式挂接在以 task 地址 hash 为 key 的 hlist 上，而对 hlist_node 的 CURD 必然涉及 lock，对于高频调用的热点函数，kretprobe 里的这个 lock 相当于自设的路障，hash 到同一个 bucket 的 task 同时调用一个函数时会被串行化，严重影响性能，甚至使系统 soft/hard lockup。这是一个知道的人很少的秘密。还有吗，还有，但不相关了。
2023-08-05 08:15:00
11390
原创 漫话拥塞控制：BBRv3 来啦
多年前第一次做这个，写了一个模块，上线，观察一周，发现效果比没上线好不少，结果另一个工人同样的环境打了我的脸，该工人没有上线任何新东西，指标也比上周好，难道我要把观测周期拉长到一个月吗，我要准备多少对照组，这根本就是错误的方向。但扁鹊和蔡桓公又给了另一种启示，如果一个厂商让你买他家的 cdn 服务，告诉你如果不买你的客户会因你的服务太卡而流失，跟你去医院问医生我这个要不要做手术，医生肯定会说不治将恐深，因为手术是暴利啊，但也有偶尔的情况，商家是对的，你不听，最终司命之所属，无奈何也。
2023-08-03 00:45:00
11893
4
原创 对 tcp out-of-window 的安全建议
而从 Linux 4.x 开始，对于 oow 报文的 ack 就是可回可不回的，取决于 oow 报文到达的 rate，这意味着对标准理解的松动，在我看来，与其不 care，不如 MUST NOT，不要对 oow 报文进行任何响应，连计数器都不更新！总之，对于 receiver，抵制随意的 out-of-window 报文，保护 rcv queue 数据，对于 sender，抵制随意的 in-window 报文，保护 rtx queue 数据。此外，状态防火墙要是丢掉 oow，Keepalive 就用不了。
2023-07-01 17:15:00
9084
原创 TCP 拥塞状态机演进
幸运的是，BBR 后 Linux TCP cc 框架导出了 cong_control 回调足以绕开该 loss-based 拥塞状态机，实现 cong_control 回调重写 vegas 即可实现完整的 delay-based cc。一旦检测到丢包，拥塞状态机转换，cwnd 变小，即使确认非拥塞丢包，依然要忍受小 cwnd，更严重的是，一旦 cwnd 变小，rate-based cc 几乎无法运行，因为没有足够 data 支撑 delivery rate 测量。浙江温州皮鞋湿，下雨进水不会胖。
2023-07-01 11:45:00
15080
原创 Linux TCP 调度与伸缩性
理论上讲，TCP ACK 要比 send data 更高优，特别是携带 SACK 的 ACK，TCP 规范里明确 receiver 对非连续报文需关闭 delayed ack 而立即回应，这说明 TCP 希望 sender 更快响应异常事件，落实到实现就是高优处理 ACK，但 Linux kernel 不给力，它没能做到高优处理 ACK 同时不饿死应用。事情的另一面，softirq 也可能挤压应用进程，特别在数据中心高速传输场景，Linux softirq 的调度方式表现得尤其不可伸缩。
2023-06-24 03:00:00
20574
原创 数据中心网络的电路交换域
任意一次丢包重传都伴随无用功，如果事前知道这次丢包，就没必要发它，Internet 端到端方法因为哑铃模型无法给出拥塞信息，或获取这信息时间成本很高，只能 “猜，试”，但这信息在数据中心内部非常易得，最多一个 RTT 的资源预留一定在应用容忍范围：这么想，端到端方案一定会遭遇丢包重传而浪费至少一个 RTT，如果应用不能容忍一个 RTT，就别用了。对分组交换域，采用合适大小 buffer 及流控算法即可保证低时延，对电路交换域，与针对长流的传统端到端拥塞控制不同，资源预留更高尚，可节省更多主机资源。
2023-06-17 16:45:00
8169
原创 交换机的激励式拥塞控制
尚未完全恢复，不多说。以休假为例，如果都休假，结果是工作拥塞，不能假设人人都热爱工作，因此不能靠每个人安排好休假做到高效工作，经理肯定会引入奖惩，比如休假多的绩效打折，带病上班的受奖励，休不完的假换钱。奖励好的，剩下的资源让坏的在油锅上煎熬吧，于整体资源利用率有益，反之，惩罚坏的，好的可能只是鸡头，相对好不能驱动它们更好，整体上没有高资源利用率的收敛动力。经理的视角，休假员工 “坏”，不休假员工 “好”，上述显然第二种策略更能激励员工尽量不休假，若选第一种，大概率大家都一样，或只求别当休假最多的那个。
2023-06-17 12:15:00
15078
原创 “一切皆文件“ 视角下的网卡
dev/sda 可以通过任何一个程序以任意方式读写，定义一套任意的私有格式(或文件系统)即可，而 /dev/eth0 则必须和对端共同遵守一套格式和逻辑，这同一套格式和逻辑就是 TCP/IP，将 TCP/IP 汇聚于系统本身或共享库中最直接，这取消了直接读写网卡的需求，而调用系统或共享库中协议例程的接口就是 socket。创建像 /dev/sda 一样的设备文件 /dev/eth0 读写网卡不难，像 /dev/net/tun 注册物理网卡就行，但你读写它时要自己手工做协议的封装和解封装。
2023-06-11 16:45:00
12297
2
原创 TCP 的未来-减少 ACK 的数量
从主机角度看，在 100Mbps 时代，P = 2，到了 100Gbps 时代，2 < P < 40，姑且 P = 20，网速增加了 1000 倍，P 只增加了约 10 倍，从效能上看，单位 ACK 触发的数据量在总带宽中的比重越来越小。delayed ack 之前，设 P = full_data_seg / ack = 1，之后 P = 2，开启 gro/lro 后，P = 40，由于乱序，pacing，gro/lro 未必总能理想，P 很大程度比 40 小得多。进一步聚合 data，但看得出在挣扎了。
2023-06-10 16:15:00
8773
原创 从广东电信故障看雪崩
虽然电信网络崩了，但计费系统还好，不然也不会充值成功，但如果很多人一起充值，打一波 burst，计费系统也难扛，网络恢复后，电信又集中发送故障期间憋住的短信，这波 burst 又对短信网关造成冲击…说了那么久 “控制爆炸半径”，不能光造词，举个例子，这就是。典型的通用 case，稀疏集群，每台服务器负载都高，逻辑距离远，一台挂掉，临近服务器将被导入加倍流量，一旦也垮掉，故障将加速蔓延，就像丝袜脱丝一样一发不可收拾，密度高就没这问题，每台服务器负载均不太大，且逻辑距离近，负载被周边分担吸收，这是显然的道理。
2023-06-10 10:15:00
8398
原创 重估端到端原则
网络协议倾向于字段多，字段小且紧凑，尽可能减少传输量，用 “算法技巧” 等价，如果 TCP 序列号 48 位，win 48 位，端口号 48 位，所有与 PAWS，win scale option，get unique tuple 相关的算法均不再必要，复杂性大大降低，但彼时这些复杂的 feature 反而是优势。其次，更隐秘的，回到上述 “处理器发展速度和通信传输技术发展速度的倒置”，这二者非线性不成比例地发展，单位字节的可用处理时间在变少，必须减轻主机的负担。胖端瘦网的理念大原则依旧，但需稍作改变。
2023-06-04 18:15:00
8403
原创 传输优化是非谈
以丢包重传为例，总有人比较 FEC 和 ARQ，但其实两者是等价的，不同手段而已，FEC 用空间换时间，ARQ 用时间换空间，但如果没有精确信息区分拥塞丢包 or 随机丢包，两者都换不成。但这似乎又和 “别让拥塞发生，而不是拥塞了之后去恢复” 相违背，正确的做法是减少对异常的过激反应，集中优化正常流，我们既不能每顿饭都毒检，也不要找解药，但异常必须反应，严重后果可能真的就过激，此时需要依靠自身免疫。回到开头点个题，有好的底层支撑，上层才能更好地假设，将时间片更多用在正常流，而非异常流处理。
2023-06-04 16:15:00
10010
1
原创 全局流控 or 端到端拥塞控制
罗马本是一个城邦，城邦民主是适合的，但随着西西里，北非，马其顿，西班牙，高卢进入版图，尺度变大，城邦民主制度就不再适合，这意味着城邦民主制度是不可扩展的…另一方面，网络尺寸缩小到数据中心，主机处理时延占比将变大，重传代价变大，驱使复杂性向网络转移，比如尽量不丢包代替快速恢复，网络将分担更多控制面任务，大幅卸载主机传输控制策略以平摊端到端时延，端到端原则在数据中心将被重估。网络规模小，拓扑规则，RTT 小，路由收敛快，不但能以流控代替代价高昂的丢包重传，全局控制也更容易实现多路径传输。
2023-06-03 16:45:00
8165
原创 tcp shrinking window 之进退
本质原因是 receiver 的 rcvbuff 按 byte 推进，而 rwin 按 2^win_scale 倍数推进，一开始引入 win_scale option 的时候这问题就没有考虑到，以至于事情变得越来越复杂，TCP 几乎所有问题都因此而来，而 QUIC 作为 another TCP，它几乎就是 TCP 的影子，QUIC 的优势在于它比 TCP 更容易快速迭代，它在应用程序尺度更新，而无需照顾泛化。这件事告诉我们，得到一个明确的信息，对辅助判断决策是多么有意义。浙江温州皮鞋湿，下雨进水不会胖。
2023-06-03 13:15:00
13496
原创 简评 CDN
网络核心负载随接入终端和部署服务指数增长，若没有 CDN，在更好的传输网技术准备好之前，网络早瘫了，至少瓶颈点会阻滞互联网快速扩张。我们早已严格分类成可分发和不可分发，集市里的商品可分发，而朋友的家不可分发，于是集市离人们居住的地方越来越近，通过批发支撑零售，没人愿意去远方购买一件商品，道路则让给了那些必须去远方的人。可分发一定可汇聚，可汇聚一定缓解拥塞。CDN 隔离了内容和受众，将负载和网络规模的指数关系拆解成核心负载和服务的线性关系以及边缘负载和终端的线性关系，避免了摩尔定律触顶后网络的崩溃。
2023-05-29 00:15:00
20691
原创 qoe 冗余传输
配合良好编码，无论延迟多久，哪怕少量数据包到达，receiver 即可展示，等待一个展示前的 deadline 时间后，无非模糊一点而已，receiver 将实际接收带宽反馈到 sender，sender 便可进行拥塞控制，AIMD，whatever。与文件传输不同，音视频受众是人，qoe 自带冗余：模糊的效果无碍人们理解内容，清晰只为更好的体验。而上述方法可在传输同时反馈，重复一遍，每一个包都有所有帧的信息，可以恢复所有帧，收到多少都能展示，这就是 qoe 冗余。百字短文，不谈细节。
2023-05-27 22:15:00
20590
原创 hystart++ 出炉
标准慢启动激进效果我谈过：慢启动丢包，找一个收敛函数也不难，确如 rfc 9406 所说，minrtt 变大大概率指示拥塞，将慢启动指数与 rtt 负相关，慢启动指数从 2 换成。信收敛不信测量，tcp 是端到端高熵体，对网络一无所知，过度信任测量则无法消除长尾，且可能劣化 p99。道理很简单，无法分辨误判，导致负向效应抵消了正向效应，p99 至多不变。链接，microsoft hystart++ 标准化了，此前只是一个 draft。和复杂却不精确的调参相比，我更倾向于自适应。即可，退出条件另说。
2023-05-27 14:15:00
21421
原创 Linux kernel 四象限法调度
Linux cfs 已经在 place_entity 的时候赋予被唤醒 task 优先权，但它微弱且 oneshot，很快即泯然众人，需要同时做到两点，increment 表示紧急性，update_prio 的速率表示重要性。针对 ksoftirqd 以及任何其它不确定调度造成的 SLA 违约(task 越多，时间份额越小，这太常规，太 Linux 了)，可以更大的 increment 唤醒特定 ksoftirqd(如 NET_RX_SOFTIRQ)，并更缓慢的 update_prio。
2023-05-27 11:45:00
20270
原创 卡车运输与长肥管道
EMS 不同，贵，又是公家的，口碑不好人云亦云，用的人少，配送就快，最后一公里的效率比顺丰，京东那种一车一车的配送快多了。看看 1990 年代，1980 年代甚至更早的那些软件，如 vim，emacs，tcp/ip，bsd socket，vfs，unix，从没有故意使用模式和范式，没有专门模块化，但毫无疑问它们无论功能还是性能的可扩展性，都是内在的，这些早期的 “一大坨式” 的软件几乎全部沿用到现在，承载了现代 “云计算”。但代价是时延，可不管怎样，BDP 大啊。浙江温州皮鞋湿，下雨进水不会胖。
2023-05-21 16:50:06
11524
原创 四象限法进程调度
不是得不到这些信息，如果得到了，大家会用吗？同 TCP 端到端 cc，Linux kernel 追求简单，通用，高效的调度算法，看不上对额外信息有所依赖的算法，笃信所谓纯粹技术含量，这绝对是自视清高庸人自扰，他们假装不知道，高效是尽可能精确的信息堆起来的，信息量有上限，误判后的补偿必然损失效率，换句话说就是启发必有概率误判，而误判则带来时间的浪费。拉屎是一个紧急任务，相对拉屎，工作则是重要任务，但依然要把固定时间让给拉屎，无论工作再满，拉屎时间也不能无限挤压，况且，对于一部分人，拉屎不但紧急，而且重要。
2023-05-20 16:15:00
11652
原创 交换式以太网的诞生
假设信号以光速传播，共享线缆压缩到足够短，那么只需借用 “在一个点通过一个数据包” 的时间独占介质即可，这个时间尺度很容易全局调度，相比较之下，如果在整张以太网全局调度，则调度时间大大增加，增加到光速通过网络尺寸的时间尺度，数据包通过一个大概 200 米的网络，需独占 1us 左右的时间，这将大大限制平均吞吐。值得一提的是，双绞线并不是创造甚至演化出来的，而是复用了已有的电话线。电话线早已深入人心，便宜，方便，柔软，可同轴电缆是什么，贵，安装繁琐，硬，以前的那种有线电视电缆，远不如电话线。
2023-05-20 12:15:00
11883
原创 科普 “平均工资又涨了”
现实并不像我正文中描述那般夸张，因为我们限定的是 “工资” 而非 “财富”，既然都是领工资的，说明都是打工的，经理和工人的差别而已，还扯不到老板级别，因此 “平均工资又涨了” 其实并非对普通人没有意义。无标度分形指的是，一个部门中，经理，副经理的收入属于 Pareto 分布的长尾，把他们去掉，剩下的人当中，总还有几个骨干成为这些人中收入的长尾，再把这些骨干去掉，还会有一些员工收入成为新的长尾，只要样本仍然足够，长尾总会有，二八原则永远生效。所以无标度分形才是自然的体现，均匀的正态分布才是异常。
2023-05-14 18:58:39
20837
2
原创 TCP 滑动窗口停等与多路径传输
这也许因为在 tcp 初始时期只有块文件传输和远程登录传输两种流式应用，而原罪则是 bsd socket 接口，直到现在 rcv 接口依然是一小块一小块接收，socket 下面几乎只有 tcp 和 udp(不抬杠，肯定有别的，但都很别扭，特别对于多路径逻辑，非常不好用)。同样的，flowlet 方案也是小改，算是时间版本的 mptcp，在一个相对大但又足够小的时间窗口中乱序传输，保证 receiver 按序接收，和 mptcp 一样，依然还是没有摆脱 flow 的本质。浙江温州皮鞋湿，下雨进水不会胖。
2023-05-13 12:15:00
8795
1
原创 tcp cubic 与随机丢包
AIMD 的公平收敛其实就是一个勾兑的过程，一杯葡萄汁液:橙汁为 3:1 的混合液体，如何勾兑成 2:1，就是 AIMD：先加入 1:1 液体一小勺，这就是 AI，均匀混合后舀出去相同的量，舀出去的液体中二者的比例很容易计算，这就是 MD，重复这个过程 n 次即可，数学上很容易计算 n。通用场景，不做假设，最简单最好。为判断随机丢包，不要引入过于复杂的逻辑，ACK 时钟信息量有限，判断精度必有上限，类似于硬币猜正反，因为你的信息就那么多，50% 的概率，那就随机猜即最优解，不要启发。
2023-05-13 10:45:00
13328
1
一个iptables的stateless NAT模块实现
2014-12-27
模块化的nf-HiPAC
2014-11-21
关于linux内核以及其他个人体会的文集
2009-09-07
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人