自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+

TCP/IP

TCP, QUIC 传输优化

  • 博客(2299)
  • 资源 (4)
  • 收藏
  • 关注

原创 闲谈IPv6系列文章集锦

本文总结一个目录提纲,只要是给自己看的,记录一下哪些东西已经总结过了。闲谈IPv6-6to4隧道和ISATAP隧道: https://blog.youkuaiyun.com/dog250/article/details/88644797闲谈IPv6-说说IPv6地址分配和BGP: https://blog.youkuaiyun.com/dog250/article/details/88430415闲谈IPv6...

2019-03-18 22:38:43 42521 34

原创 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 241

原创 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 685

原创 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 1489

原创 从 BBRv2 到 BBRv3

BBRv3 已经有段时间了,今天正好碰到一个 BBRv2 限制住总吞吐的问题,正好因为 cwnd_gain 所导致,徒手增大了它又带来了丢包,进一步降低了 inflight_lo,进而又限制住了 cwnd,导致无足够的数据包撑起好不容易 probe 到的 maxbw,吞吐逐渐下滑…问题是,BBRv2 好意的 probe-phase 有问题,于是就有了 BBRv3。另一方面,BBRv2 和 BBRv3,相比 BBRv1,“吞吐性能进一步降低”,“性能在变差”,但拥塞控制的首要目标是拥塞控制,不是提高吞吐。

2025-04-01 20:20:33 1526

原创 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 1786

原创 最简单最朴素的服务热升级方法

如果不嫌弃 nf_conntrack,那么它就能自动帮你把新老 session 分流,你只需要做一个 Redirect 就行了,这应该是最简单,最朴素的热升级方案了。但问题是,如今全民全面 LLM 的洪流时代,连 XDP,DPDK 都稍显老态了,谁还能记起 iptables/Netfilter。浙江温州皮鞋湿,下雨进水不会胖。还是稍微复杂了,写个简单的。

2025-03-31 10:56:29 1522

原创 服务热升级的方法

Linux 内核的 reuseport ebpf 接口非常不友好,它那个默认的 “用最后一个 item 填洞” 的逻辑无法自定义,所以就必须在外部适配它,不管是 ebpf 程序还是用户态工具程序,都需要一大堆的 map 来维护 status,这就增加了复杂性。既然你连如何 mapping 的权力都给到了,如何增删改查自己留着有啥用呢,一般而言,要么无,要么全,crud 才完美闭环。浙江温州皮鞋湿,下雨进水不会胖。但貌似有 bug …

2025-03-30 11:45:22 1805

原创 问题的根源还是解题的方案

虽然减少了骨干回源流量,但却增加了最后一公里的汇聚流量,用户访问不同网站可能都连到同一个 CDN 节点,增加了拥塞和单点故障概率,于是需要新技术解决拥塞和容错问题,同时,小网站反而失去对自主网络的控制。IPv4 地址空间有限,NAT 缓解了问题,但同时打破了 IP 网络点对点可达性初衷,破坏了端到端通信,催生了一系列新技术解决引入的问题,比如打洞(我认识一家公司的老板,TCP,UDP 打洞世界第一),这一切本应是 IPv6 普及前的过渡,结果却成了阻碍 IPv6 的 “舒适区”。

2025-03-30 09:45:15 1828

原创 多路径 TCP 调度的另一面

之所以倒着发,为了保证慢路径后段一定与快路径解耦(确保后边的数据已经完全准备好),即使 gap 算大了,仅靠快路径自身也能很快接上慢路径已经准备好的数据,而如果 gap 算小了,则影响更小,换句话说,即使抖动也是一瞬间,且快路径主导补洞。总之,总要拿个什么来交换成本,以获得收益,越复杂越不划算。,思路依然是让慢路径序列号往后错,但它仍倾向于精确拼接,企图两边正好配合,但这是不可能的,慢路径非常容易与快路径耦合,一旦被快路径赶上,Seq 在快慢路径交错传输和重传,就会引发持续性 HoL 抖动,而这个错开量。

2025-03-29 08:50:44 2875 1

原创 解析重塑世界

让任何一种工程实践深度依赖于充满技巧的几何辅助线是低效的,不现实的。解析几何,能描述所有几何图形,却又不认识一个几何图形,最终它表达的就是坐标系中任意一点和其它任意一点在某种用关系描述的(“几何的”)约束下的关系,这是一种递归的定义,由此,坐标轴也不再限于 x,y,由于坐标系中可表示任意数量的关系,任意维度的坐标系中都遵循同一套计算方法,这显然描述的就是世界本身了。如果没有一种可工程化硬算方法,以上这些装置就很难建模,难以受力分析,这还只是一个简单的实例,就更别提那些复杂的机械装置了。然而这有什么意义吗?

2025-03-26 22:15:27 2698

原创 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 2956

原创 吞吐与时延的博弈,超发与冗余的交换

如果按照字节做拥塞控制,从端侧看,小包流几乎不会触发拥塞控制逻辑,但却引入了另一种事件调度的控制逻辑,这一点结论在任何处理系统都有效,比如主机处理网络中断,流量和包量对主机系统产生的是两种不同的冲击,流量影响 CPU 有效利用率,包量影响 CPU 无效利用率,抖动大多由包量导致的调度差异引发。做传输协议加速,大家默认激进超发原则,却认为冗余双发不道德,其实这两个是一回事,它们本质上是一种 “矩” 内的交换,就像力和力臂交换但乘积不变一样,成本是固定的。经理和工人们青睐前者,鄙视后者。

2025-03-23 08:57:56 3086

原创 95 计费 5% 时间窗口的利用

人们上网行为是人们在真实世界行为的一个映射,受环境和周期律影响,比如天气,节假日,发薪日,赶工期,失业,例假,怀孕,搬新房,生病等等,而在大的环境约束下,热门影视剧,体育赛事,国际事件等也会关联流量的长程依赖,如何从中分析中模式的方法就是技术含量本身。典型的无脑做法是在计费周期内越往后越激进,如果到了月末用户依然请求大流量同时内容方亦有剩余每天 72 分钟,那就使劲用完,大聪明貌似好刀用在了刀刃上,但如果高峰期大家都这么干,虽然运营商赚不到钱,但网络拥塞还是用户用时间成本买单,哪哪逃不掉。

2025-03-22 22:59:29 3109

原创 BBR 和 CUBIC 对长肥管道的不同反应

好比一个老胖和一个瘦子一起坐车,一开始他们屁股接触椅子的面积差不多,但越往后老胖占地越大,并不是老胖故意挤,而是因为他体重大,车子晃动传递给他的力足以挤压更多空间,从而公平承载他的体重,如果总空间一定,两人体重的比例就是他们占用空间的比例,其实两人都觉得很挤。BDP 是个标量,它只是个数量,单位是个,字节,比特都无所谓,在控制端,它体现在 Inflight 的观测和 cwnd 的计算,它并不体现任何作用力的细节,而 BBR 与此不同,它直接控制速率而不是量(有争议,但讲它时不评价)。这也是非常明显的事。

2025-03-22 22:51:07 3854

原创 BBR 与 AIMD 的协同优化

正常稳定情况下,aimd_rate = bbr_rate,cwnd 也不会受限,但在不稳定的情况下,aimd_rate 能动态捕捉到瞬时变化,aimd cwnd 可以比 cwnd_gain·BDP 更保真,同时 β 退让了 AIMD 的 buffer 入侵性同时又不失公平性。往瓶子里灌水时,如果水管开太大,水就永远灌不满,因为水流的冲击力会把最后那点水溢出去,必须细水长流才能将瓶子灌满,但这会让水灌满的时间增加,最合理的方式就是一开始开大水龙头,等水快满的时候,逐渐关小水量。如何解释这个原理呢?

2025-03-16 10:10:31 4325

原创 数据中心传输:消除流抽象,重塑多路径

依照熵的概念,有长短,突发属性的 flow 为低熵流量,而独立的 packet 则为高熵流量,分布最均匀的流量熵值最高,最能避免作为低熵态的拥塞,这意味着流量不能有任何属性和模式,在所有等价路径均匀随机分布的 packet 是避免拥塞的唯一理想策略,利用可预测的反面,即不可预测性。结论很明显,到达过程变异越大,系统平均排队时间越久,队列平均长度一定,方差越大,越容易局部突发拥塞,交换机 buffer 若太大,则利用率不足,若太小则遭遇突发时更容易丢包。同时,这意味着 ECMP 在本质上和大象流是冲突的。

2025-03-16 08:33:27 4857

原创 网络的正则拓扑与自然生长

起初,在 1970 年代,教授们只是随意互联,然后,在 1980 年代,教授们希望构建一个分层的正则拓扑网络,再往后,运营商实现了一个松散的分层正则网络,网络开始自然野蛮生长,最后,CDN 厂商的经理们彻底破坏了网络的正则性。虹桥枢纽,HongQiao Hub,路口都是 Route,Hub 标识,仿佛进入了一台路由器内部,而事实上,虹桥 Hub 本身就能分层直连(而不仅仅是可达)世界各地(飞机),全国各地(高铁),全上海各地(地铁公交网约车),全虹桥各地(公交),这本身就是一个路由器。

2025-03-09 13:15:00 5723

原创 传输协议优化的博弈三角

此外,还有性能,成本,可靠性组成的博弈三角,甚至经典的 CAP 定理描述的一致性,可用性,分区容错性组成的博弈三角,这个三角定义了互联网本身,P 客观存在,C,A 之间做 trade-off,而 P 的客观性是定义的,互联网设计之初,本身就是需要分区容错,如果没了这个特性,类似主板那样,就无法抵御核打击了。所以说我经常听到一些一听就不靠谱的论断,比如 PR 自家的协议或面试过程中,算法可以提升多少倍的性能,同时又不增加成本,这种属于懂一点但又不是真懂的,但如果看明白了这个博弈三角,就肯定谨言慎行了。

2025-03-07 19:34:04 5369

原创 函谷关以西

司机没穿西装皮鞋在白宫被嘲笑,吵架,吵完架饭也没吃被轰走的事使人想起楚怀王,被张仪欺骗,两边倒,屡次找强国斡旋,最终失去强国地位,且被扣留,彼时彼景也是一个失败的案例,楚齐秦魏韩之间的外交,军事博弈,从智人心智视角看,简直一模一样。但实际上这并不是秦国独创的手段,代入当代的世界,这味道依然令人熟悉,从阿富汗,中东,近东巴以,经过叙利亚,土耳其到欧洲,从俄乌到远东,也有个 “秦国” 在到处军事打击,外交离间,经济封锁,利用内乱,扶植傀儡。如商鞅变法,合纵连横,六国弊在赂秦,贵族内斗,改革不彻底,等等不赘述。

2025-03-02 12:03:14 6723

原创 笛卡尔解析几何观点的形成过程

写于昨天,但遗漏一些碎语,比如说 “解析大法下,一切都是可以算出来的”,我经常对小小讲,充满恶意玄幻的平面几何题目让你证明 AB = EF,你就画出坐标系,把直线方程,焦点坐标全算出来,利用距离公式算 AB 和 EF,最后发现它们的值相等,把结论甩老师脸上。这就是分析,解析,或直接叫拆解,把问题中涉及到高深莫测的,直觉的东西丢弃,根据条件把问题涉及的每一个点的坐标算出来,问题自然就解决了,而这个计算的过程显然只是一个机械的 “体力活儿”。浙江温州皮鞋湿,下雨进水不会胖。

2025-03-01 10:51:19 6845

原创 笛卡尔方法论和解析几何的诞生

另一种证明是综合的,“它利用一连串的界说,公设,公理,命题和提问,因此要否定结论中的某些东西,它立即会表明,这些要否认的东西已包含在前提之中了。后世在事后看来,在这个具体问题中,为确定 C 的位置,笛卡儿选直线 AG 为基线,相当于一根坐标轴,点 A 为起点,相当于原点,x 是从起点量起的一根线段的长度,y 是另一根线段的长度,该线段从基线出发,与基线交成固定角 β,这可以看成另一根坐标轴,随 x 不同而改变位置,但与基线 AG 交角始终不变。就仿佛笛卡尔说,让我们看一个简单例子来说明我的方法论,“。

2025-02-28 21:05:45 8173

原创 一个原教旨的多路径 TCP

MPTCP 的路子显然把问题复杂化了,因为 MPTCP 是以 TCP 为基准的多路径协议,而不是以底层网络为基准的。前面提到过 ECMP 和 TCP 之间的互不友好,pacing 收益和中断开销的互斥,在事实上阻碍了 packet-based LB 的部署,也限制了交换机,服务器的并发性能,同时潜在增加了 bufferbloat 的概率,而适用 packet-based LB 的短突发,老鼠流又无法承受 TCP 的建连开销,向后兼容的普遍刚性意味着几乎所有基础设施若不迁就 TCP,其崭新特性难尽其功。

2025-02-27 19:28:39 7125

原创 测度实践下的泰勒展开

我自己曾经在某些时间段厚此薄彼,但后来发现二者是正交的,没有材料结构,几何,力学的中国科技虽精巧,看起来却不壮观,没有算法和省力把戏的欧美科技虽然在体系结构上宏大,内核却显得笨拙,但二者结合,在体系结构上配合精巧的算法,搞不好就能有更大突破了 …因为给定的标尺是任意的,如果它不能准测目标,就需要换一把精度更高的标尺继续测量,直到准测或者达到目标精度,在此过程中,不能准测的后果即引入准测外的新类型,例如减法不能准测目标,需要负数来弥补,除法不能准测,需要小数来弥补。在上述的测量过程中,我不断用。

2025-02-26 11:35:52 7424

原创 移动指数平均(EMA)—从几何约束到老汤陈酿

如左图,若 β 很小,一族直线斜率小,(1 - β) 则较大,震荡范围大,均值受 new value 的修正影响大,反之如右图,一族直线比较陡,越大的 β 越倾向于把序列往历史均值压,因为它削减了 (1 - β) 的动态震荡范围,只能一点点慢慢地趋向 new value,若该 new value 是一个燥点,就过滤掉了。在不能随时获取足量食材和调料,且量化计量很粗糙的旧时,采用 “每次留一点旧的,下次续一点新的” 方式可以抵抗随机波动,确保味道的稳定性。,特别是最后的操作实例。

2025-02-25 17:36:08 6915

原创 Little 定律与重力模型:网络与现实世界的社会学模型

我曾说网络传输优化,拥塞控制更体现为一个社会学问题而不是一个纯技术问题,所以自然也就没有确定那一剂苦口良药。但依然可以通过一些社会学模型去认识这类问题的本质,从而逼近更好的解法。为什么拥塞一定会发生,为什么 buffer 一定会被填满,为什么带宽一定会被用尽,为什么路上一定有车,这些问题本质上都是同类问题,背后的动力学是同一个。我从 Little 系统(满足 Little 定律的系统)和社会物理学的重力模型切入,更深入的还请自行思考。重力模型说的是,两地之间的人口流动量与规模正相关、与距离负相关:Tij=k

2025-02-24 11:47:25 7706

原创 从“One More Lane Bro.”到网络优化:如何让数据 “尽快离开”

在人间,我们瞻前顾后,既要也要还要,却不得不放弃,我们没有大自然那样无限的试错机会,也负担不了无限的试错成本,在有限的生命周期的时空中,我们必须权衡,我们做不到收敛比 = 1,但却可以接近它,在接近它的诸多方略中,有无数的工作可以做,或曰算法。首当其冲的是接收端附近的接收能力,因为这是数据包离开网络的地方,加上 “附近” 修饰是为了强调最后几跳转发的分发能力,而对于接收端而言,端到端流量控制起决定作用,其次是网络核心处的瓶颈链路,因为它降低了数据包的通过率,从而引发排队时延的增加。

2025-02-17 10:34:42 8871

原创 自反馈与流量震荡:从 TCP/IP 路由到交通导航

我曾经建议用每天特定时间段改一套参数或切一个算法替换修改拥塞控制算法代码的建议被否决,经理的理由是 “状态需要实时计算”,“历史信息是过时的”,照这么说,所有信息都是历史信息,根本就不存在实时信息,然而事实是,人们的行为并非完全随机的,在长时间尺度看,完全是可预测的,正如每个人的生活都很规律一样,所有人行为的合集也很规律,流量也是,不管是交通流量,还是 TCP/IP 网络流量。我问我老婆,如果现在只有一个机会切换到宁洛,后面切不回来了,如何,前面拐还是不拐,相信实时的导航还是相信没事就看地图看路况的我。

2025-02-14 11:12:09 9492

原创 加油口,电梯门的对称性对 TCP/IP 传输协议的启示

类似的例子还有多侧开门的电梯,这让楼层布局摆脱了电梯井的位置约束,从而可以设计出更加多样性的楼层布局,设电梯的四边门编号为 1,2,3,4,比如经理在大厅从电梯 1 号门进入,到达目标楼层可以从背向的 3 号门走出,这就允许目标楼层在任何方向敞开,大大缩短了穿皮鞋走路的距离。如果所有车辆加油口都在同一侧,加油站的加油机就只能给一边的车加油,高峰期容易造成拥堵,加油效率低下,或者加长一根加油管,用飞线的方式跨过紧靠加油机的车辆为远离加油机的车辆加油,资源浪费。所有类似设计背后的哲学很简单,就是对称性。

2025-02-12 11:37:07 9827

原创 TCP 端口号为何位于首部前四个字节?协议设计的智慧与启示

这个过程一直持续到最后端口字段,由于 UDP 也需要它来解复用,这两个字段本不属于 IP,自然不能往前挪,但由于当时只有 TCP 和 UDP 两个协议,且 TCP 和 UDP 都需要端口,就判断它虽不属于最小公共集,但属于独立解复用的 “子层”,这样它们就紧挨着 IP 的最后,处在 IP 和 TCP/UDP 之间,所以还是挪了,这就造成了如今 TCP,UDP 协议头的格局,端口处在最前面的 4 个字节。回到文初的问题,现在可以一句话回答了,“为什么在TCP首部中要把TCP的端口号放入最开始的四个字节?

2025-02-11 12:06:06 10739

原创 TCP 丢包恢复策略:代价权衡与优化迷局

再看 SACK,从相关 RFC 中我们看到 TCP SACK 谨慎到鉴别 scoreboard 每一个段的状态,虽然 RACK 后有所松散,但依然保持谨慎的底色,这意味着作为 GBN 反面的 SACK 不希望浪费一个段的带宽,但如此复杂的状态鉴定显然需要更多 CPU,如果你发明了一个更加 “高效” 的 SACK 算法,希望丢包能更加快速恢复,势必要冒险重传不该重传的段,精确鉴定省不了,多发的额外重传段却浪费了带宽。还有另一类丢包值得关注,即拥塞丢包,它不是问题,相反,它是功能。

2025-02-04 10:24:45 10802

原创 探秘 TCP TLP:从背景到实现

如果发送的是新数据,该新数据诱导了对端足够的 sack 并触发了 FR,那么没有任何无用功,但如果没有新数据,重传了队列中最后一个数据包,而该数据包恰好补足了空洞,它没有触发 FR,但确实发生了丢包恢复,按照 congestion control 原则,此时应该执行收敛降窗动作:ssthresh = β*cwnd & cwnd = ssthresh。而 QUIC 做这件事非常简单,QUIC 对每包编号,可轻松区别一次重传是不是无效的,因此它的实现就非常简单,多一行代码不多,这又是结构决定行为的例子。

2025-01-28 18:53:46 11354 1

原创 探寻 RoCE 无损传输:从 PFC 到后备存储

至于拥塞缓解的方式,方法不一,可以依靠前向 ECN,也可以依靠后向直通源抑制(直接发 pause 到源),或者其它,这本就与无损是解耦合的。p 一般由两部分组成,静态的链路误码和动态的 buffer 溢出,其中链路误码目前随着线缆产品质量的提高已经足够低,甚至可以忽略,这极大提高了 AIMD-based 数据流的传输性能,比任何算法在效果上都要好,但对于 buffer 溢出,却让工人们处在两难之间,增加 buffer 可以降低 buffer 溢出丢包率,但却要付出时延增加的代价。,其中 p 为丢包率。

2025-01-26 18:16:05 10734

原创 导航的 “精确之误“:道路拥堵的 SPF 成因与解决

从上海到周口,进入 G15 后,导航提示发现一条更短耗时的路线,问是否切换,坚决不切换,一路走到黑,果然避开了拥堵,因为大多数同一方向的,看不懂地图的人都会选择相信导航切换,结果那条 “更近” 的路就堵了,然后导航发现它堵了之后,还会再提示切回来…导航应该只给出 “路径 1 可达”,“路径 2 可达”,“路径 3 可达”,…导航会基于实时事件计算路径时间,而这个时间会影响司机用户的选路决策,这个决策反过来又会影响道路的实时路况,然后如此反复颠簸,ECMP 从此被破坏,鸡屎也不留,用手殴,净肉球。

2025-01-25 18:17:56 10562

原创 从 VJ 拥塞控制到 BBR:ACK 自时钟和 pacing

固定时刻,pacing 的不同意味着对链路 buffer 的抢占力不同,特别是竞争流抢占周期小于 pacing 周期(比如 1 个 RTT)时尤为严重,高速公路维持安全车距与此类似,如果你保持车距,总会有车加塞插入,你若坚持保持车距就不得不继续退让,最终维持不住原有时速,事实上很少有人会遵守安全车距的规则,在网络传输中也一样,保持 pacing 可能会丢失吞吐,进而丢失 pacing,BBR 的做法是维持一个 maxbw-win,大约 10-round,在此期间不理会由于 pacing 丢失的吞吐。

2025-01-25 17:24:57 11173

原创 从对等通信到万维网:通信模型变迁与拥塞求解

人的行动速度大约在 3km/h(步行) 到 700km/h(飞机),多数集中在 80km/h 以下,这种尺度下所有行为都是公平的,而借助于现代通信工具,人获取信息的时间尺度却完全不在一个数量级(通过 IM,朋友圈,微博,dy,大量人几乎一瞬间获得相同的信息,并在同一时刻行动),于是就会出现非常多的人一起涌入同一处的场景。但 Web 万维网不同,它的节点是文档,连接是超链接,这是一个虚拟的,overlay 于互联网之上的,几乎可无限扩展的优先连接网络,而优先连接正是幂律成因之一。这种通信模型就是对等通信。

2025-01-21 20:30:14 11494

原创 从 TCP/IP 演进看按序流与性能

只有一条鼠标线,一条串口线时,没人会想到排队调度和拥塞控制,更不会有人设计一个专门进行排序重组的保序软件层,人们甚至会采用丑陋的硬编码,一个字符一个字符停等,只求一个完整的 “hello” 通过鼠标线显示在对方屏幕上这伟大时刻早点到来,等到这个过程变得司空见惯时,等到能买得起双绞线,光纤,交换机的时候,软件早已僵化,模块间千丝万缕的早期关联使其牵一发而动全身。这大概就是协议演化的过程,RFC817 也提到,程序员很难一开始就设计一个完备的适应未来的协议,任何协议都局限在当前它出现的背景之下。

2025-01-21 11:23:59 11660

原创 Linux TCP 之 RTT 采集与 RTO 计算

RTT最初仅用于RTO的计算而不是用于调速,RTO的计算存在两个问题,如果过估,影响效率,如果激进,则会造成无效重传,但这都不是最大的问题,最大问题是TCPACK只提供给你那么多信息,你能如何利用好它。VJ的rttvar是一个计算容易得多的“伪方差”,同时又能记录数值上下波动,但它同样受到大数定律的影响,换句话说,rttvar的目的不是求一个最终值,而是求一个实时值,取当下的值,以判断当前的网络状态。随着网络带宽增加,窗口增大,大数定律对统计数值的影响增大,这可怎么办?

2025-01-20 11:35:00 11609

原创 TCP 重传演进:TCP RACK Timer 能替代 RTO 吗

VJ 算法不合理的地方在于,SRTT 已经考虑了方差,再单独计算肯定就谨慎保守了,这也导致了 TCP 此后的行为一直谨慎保守,而 iRTT + ReoWIN 才更合理,或许应该为 ReoWIN 单独叫做 ReoWIN_and_Jitter,即 RTO = iRTT + ReoWIN_and_Jitter,一起合入 RACK,然后将经理扔向皮鞋👞。RTO 一直是 TCP 传输过程所要尽量避免的,因为它会将状态带入 Loss 进而 Go-Back-N,这是一个昂贵的操作。浙江温州皮鞋湿,下雨进水不会胖。

2025-01-17 21:42:06 11912

原创 TCP TIME-WAIT 状态为什么要坚持 2MSL

1980 年代的 2MSL 不算什么,彼时多对一 C/S 通信模型尚不流行,连接资源并不昂贵,但进入 HTTP 时代后,情况不一样了,“timewait 太多”,“大量 last_ack 消失不了”,“大量 closing 关不干净” 等变成了最大的恶,因为它们不光阻碍新连接建立,还消耗了大量内存,优雅关闭成了累赘,因此我建议直接用 RST 关连接,或将 MSL 设为 0。关于 MSL 本身,它与什么有关,取值多少?在具体实现中,我们经常希望它为很小的值,30s 嫌大,更别提 1m,2m。

2025-01-17 10:13:43 11721

一个iptables的stateless NAT模块实现

如果你在寻找Linux上配置诸如Cisco设备上的static双向NAT的方法,这个或许就是你想要的; what?你觉得它完不成PAT?是的,它不行。但是想做PAT为何不使用现有的iptables实现呢?它可以自动为你解决元组唯一性问题。不要从概念上分析,事实上,static双向NAT是完全对称的,一对一的 ,也只有在BOX两边的网络在拓扑级别是完全对等的情形下,这种NAT或许才是有用的,Cisco设备经常处在这样的位置,比如一个很大的stub节点的出口位置,比如两个domain的中间位置... 我将名字取为STATIC-2-WAY-NAT,比较长也比较怪,完全不符合UNIX的小写短名传统,我的想法是:这样可以少写很多的帮助信息,因为名字就是自解释的。

2014-12-27

模块化的nf-HiPAC

原版的nf-hipac需要为内核打patch,且只支持较低版本的内核,构建起来相对比较麻烦。 模块化后的nf-hipac可以直接作为内核可加载模块编译,且适配了高版本的Linux内核。为了移植工作简化,去掉了和iptables模块的联动支持!

2014-11-21

配置文件还有一些other

代码和配置iptables配置文件,还有一些别的东西

2010-04-16

关于linux内核以及其他个人体会的文集

本文集是我用将近两年的时间写成的,大多数文章是关于linux内核的,另外还有一些我自己对计算机的理解,还有一些历史,音乐方面的东西。适合于对linux内核思想感兴趣的阅读,文章偏重于对于思想的理解。

2009-09-07

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除