- 博客(1929)
- 资源 (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
39648
26
原创 现代操作系统和 TCP/IP
现实中，时间片并不固定，但这并不重要，因为调度器已经和具体的任务解耦了，同样的创举来自分组交换，时间片统计复用，虽然可以强制规定每个报文固定大小从而占据固定时间片，但现实中报文在最大限制之下可以任意长，根本在于报文和时间解耦，而不再和连接关联，所以，所以最后，TCP 真是一个不合适的传输抽象，它明明是一个连接啊，从这里，你将能推论出 IP 一开始就是 TCP 的一部分，这个故事和现代操作系统是同一个故事。终端接入时，仅分配一个 IP 地址，只在程序需要通信的那一刻，才分配传输层以上资源，这是现在的方式。
2023-01-30 23:15:00
814
原创 TCP 以及网络难题
从南浔到无锡再到苏州湾，绕了一个太湖，路上跟老婆聊起比亚迪，我说这车是好车，败在名字和商标上了，想做民族品牌就要取个民族名字，比如东风，解放，长城，长虹，红旗…其实奔驰，宝马，奔腾都挺好的，但已经作为音译给了德国品牌，否则完全可以用来重命名比亚迪，吸取点教训吧，外国牌子简单音译就好，别把好名字给了别人，比如 Audi 的中文名叫奥迪就挺好，这名字作为中文没有任何意义。日常调侃中我曾经说过，即便你对网络知识一无所知，只要你进了机房，你面对的就是一团乱八七糟的网线，油然而生的欲望就是将它们整理干净。
2023-01-24 03:15:00
1166
2
原创 重新设计 TCP 协议
剥离了 IP 后的 TCP 即 byte-based stream，而负责传输的 IP 则为 packet-base datagram，1986 年后引入的 TCP 拥塞控制基于 byte-based stream 进行修正，注定会带来各种难题以及针对这些难题的各种非正式 trick，典型的问题即，TCP 分不清楚原始报文的 ACK 和重传报文的 ACK，因此会存在伪重传，针对伪重传引入了 Eifel 算法以及复杂的 dsack，undo 等机制，同时 RTT 测量也因此存在歧义。所以，什么是 QUIC？
2023-01-23 02:45:00
1858
2
原创 一个 TCP 双边方案的对话
工人：谁说这一定要是 TCP 的，“TCP 双边”，多一个字它都不是 TCP。经理：妙啊，都快成 QUIC 了，可这已经不是 TCP 了吧。工人：你不是 TCP 双边吗？工人：如果我要区分第一次重传报文和第二次重传报文呢？工人：可你这是 TCP 双边啊，两边互认不就行了吗？经理：对啊，那就开 16 个 bit 吧，足够了。工人：区分原始报文和重传报文，最简单需要怎么做？经理：够了，区分第一个重传报文和原始报文，够了。工人：给你 32bit 的空间，你要怎么用？工人：区分原始报文和重传报文需要时间戳吗？
2023-01-17 20:28:41
1194
1
原创 将仲裁引入 IDC 网络合理吗？
分布式，端到端控制并非网络设计的不变自然律，它恰好迎合了互联网的设计目标，在不需达成这些目标的地方，规则是需要被打破的。但时隙分配的思想却非常好，它在混乱中引入了秩序，有序的时隙可彻底避免冲突和网络拥塞。承诺 sender 一个明确的可无拥塞传输的时间点，到达这个时间点前，sender 可以做点别的，一旦该时间点到来，网络保证一定在固定的极短时延内传输完毕。考虑到复杂度，倒也不一定要严格有序，用 20% 的无序换取保持简单，解决掉 80% 的随机统计复用问题，即引入一种准有序机制，就能解决绝大部分问题。
2023-01-14 13:15:00
1140
原创 TCP 慢启动突发丢包
绿色曲线在后期比红色曲线平缓很多，丢包就减少很多，缓慢的增速虽然更慢探测到最大带宽，但也不算太慢，相反，优点有两个，首先减缓的慢启动过程增加的延迟大概率小于大量丢包重传增加的延迟，其次，减少了丢包重传在全局上提高了带宽利用效能。但这些都很难奏效，和 BBR 很难达到预期的原因一样，这些依托的都是理想模型，而现实并不是。连 RTT 测量都不能算数，需要一个移指平均也不能太算数，何况 HyStart 的测量。这是尾丢的结果，现实中很少部署尾丢，因此很难实际观测到该结果，但这是慢启动的理论伤。
2023-01-07 11:45:00
3653
2
原创 Linux TCP 拥塞正反馈 bad case
但真要打开 sysctl_tcp_thin_linear_timeouts 呢？我觉得这是 Linux kernel TCP 的 BUG！诚然，srtt，rttvar 为 0 无可厚非，采不到就为 0，可 rto 为 0 没有任何现实意义。要么关掉 sysctl_tcp_thin_linear_timeouts，要么用 BBR 算法(BBR 不更新 ssthresh，tcp_stream_is_thin 恒为 false，钻了个空子)。Linux kernel 社区，这可是大好的秀场，方便后面找工作吹逼。
2023-01-01 16:15:00
2391
3
原创 以太网，拥塞控制与 AQM
人们更容易接受 802.3，因为简单廉价，接入新节点代价小，以当时条件，以太网的使用方式比标准允许的更保守，CSMA/CD 也足够。相比分布式控制网络，比如令牌网，TCP/IP over 以太网的 Host 离交换机太远，而光速太慢，发生拥塞是注定的，端到端拥塞控制与网侧 AQM 共同控制拥塞也是必须，这就是秩序的代价。交换机并不神奇，看上面右下角的开关矩阵，数数一共多少根线，如果在共享介质的同轴电缆上这拉这么多线，用继电器相交连接，也可实现开关矩阵，问题是线缆太长，光速太慢，仲裁信号传输太久。
2022-12-31 15:15:00
2571
1
原创 新式 AIMD 拥塞控制
p 约等于 0.0000004，这简直是奢求，对 buffer 要求太高，BDP 越大，buffer overflow 容忍所需 buffer 越大。这解释了 TCP 效率低，更甚者，Reno/CUBIC 等 AIMD 算法族遭遇丢包都会视为拥塞，即使是非拥塞噪声丢包或节点问题丢包也会算在内。既然 RTT 可移指平均，丢包率 p 亦可。既然吞吐公式来自 AIMD 过程，根据公式构造一个拥塞控制算法即合理的，这次将 p 也移指平均。或许移指平均不够精确，但至少是个方向，剩下的就是找个足够好的降噪函数了。
2022-12-31 13:15:00
3260
原创 搜索 和 排序
像晾袜子这种事，可能无法看出间隔夹袜子的好处，因为它仅仅节省了收袜子的工作量，而收袜子只需做一次，但对于打牌和拼积木，意义就很明显，况且无论别人拿牌的时间，还是我闲得发慌，都是可随意浪费的空闲时间，为何不把不经意的搜索和排序工作放在此时呢？下一次的搜索和排序？搬家或外出旅行时，如何在空间有限的行李箱里放尽可能多的东西，我们需要为特定的空间安排特定的物品，并需找到其它特定大小的物品填充其周边剩余空间，总之，为一件物品找一块空间，为一块空间找一件物品，为此，我们需要将裤子卷起来，将鞋子方向相反叠放，诸如此类。
2022-12-25 11:45:00
2609
原创 BBR 加速比收敛图解
抛开 BBR 收敛问题，这个问题适合给小小当几何练习题，也确实可以作一道很简单的平面几何证明题。发现这个话题非常适合抽出来做一个六年级几何题目，就想试试让小小做一做，看看能有几种解法。一文中我曾用算式证明了这个事实，本周换个方法，用几何来证明。这就是 BBR 加速比可收敛到公平的几何证明。浙江温州皮鞋湿，下雨进水不会胖。
2022-12-24 11:15:00
2349
1
原创 Bloom filter-based AQM 和 BBR 公平性
老鼠流与一条 YaBBR 大象流共享带宽，老鼠流拥有更大的加速比，确实可以通过早期的激进发送用一点点 D 挤兑更多 B 从而提高 E，大象流由于检测到 E 的降低，尝试降低 inflight 后找到 “新的山脊”，这让带宽分配趋向公平。并不是都知道这道理，增加 inflight 能挤出吞吐是共识，但却得不到好处(E)却鲜有人理解，换句话说，吞吐并非好处的全部，除了高吞吐，还有低延时，用高延时换来的高吞吐，总效能 E 反而更低。这就是全部，算不上 AQM ，只是 AQM 的前置处理。更加精细的控制效果。
2022-12-24 10:45:00
2365
原创 更合理的 BBR
几乎不可能不产生队列，一旦产生队列，Startup 退出条件基本就是奢望，只要 buffer 不满，吞吐总是能挤兑出来，这非常不利于公平性，而一旦 buffer 溢出，一切又为时已晚。双曲线很容易理解，E = B/D，若 2 流共享带宽，全局最佳效能依然是不排队，E = 1/2B/D + 1/2B/D，若 3 流，每条流的 B 则为 1/3，以此类推，1/4，1/5，即 y = 1/N，为双曲线，同理，每条流达到最佳 E 的 inflt 亦为 1/N 的关系，为双曲线。浙江温州皮鞋湿，下雨进水不会胖。
2022-12-17 11:45:00
2716
5
原创 BBR 与拉弗曲线收敛点
该事实驱使算法降低 inflight，这意味着 BBR 超此方向有个新思路，除了 BDP = maxBW*minRTT 约束外，同时收敛到 E 的最大值。B 和 D 相乘是 BDP，BBR 会主动收敛到 maxB*minD 以保最优，B 和 D 相除即为效能 E = B/D，也是一个有趣的收敛点，且自带负反馈属性，E 比 BDP 有趣。BBR 虚线左边，带宽利用率不足，E 渐大，BBR 虚线右边，排队延时增加，E 渐小。周四的一个分享后，想到一个新思路，使用 E = B/D 做收敛或许可行，但也只是想想。
2022-12-10 12:45:00
2930
原创 源抑制与智能转发
Internet 和 IDC内网往相反方向看就对了，Internet 在胖端瘦网中获益，IDC 则在胖网瘦端中获益，这么看，智能交换机还不够智能，反压算什么，直接疏导啊。懂 Linux 内核的可随意改算法，但大部分人不能，最近，QUIC 将拥塞控制实现在库里，撕开一个大口子，小白都可以改算法，这不是好事。另一方面，在 IDC 内部，各种 PFC，INT 令人眼花缭乱，NPCC(主动拥塞控制)如火如荼，所谓智能交换机也就是 “可将拥塞信息直接反馈到发送端”，这不就是源抑制么？1984年，Nagle，
2022-12-10 12:15:00
2692
原创 网络传输 Tips 小记
虽 pacing 相比 burst 更不易导致统计突发，特别是第一跳更容易由于 burst 而 bufferbloat，所以更该 pacing。但最后一跳正相反。为最大降低接收 overhead，提高聚合效率(如 LRO, Big TCP)，burst 应好过 pacing。【端主机发送需照顾第一跳，不要让它 bufferbloat，所以 pacing】【最后一跳发送需照顾接收端，要利于它批量接收，所以 burst】端主机很容易 pacing，但问题来了，叶交换机如何配置 burst 呢？一般网络传输都
2022-12-04 14:15:00
3916
1
原创 BBR 公平收敛
BBR 的公平收敛来自于两点：详情参见：有趣的TCP BBR ProbeRTT行为点滴但还是复杂了，写个简单的解释。排队论模型，排队时间为： T=1/(μ−λ)T=1/(μ−λ)T=1/(μ−λ) ，T 作为 RTT 的一部分，λ 为 Pacing Rate， μ 为Delivery Rate， μ 一定，作图如下：这是双曲线的一支。ProbeBW 加速比描述为增加单位 inflight 带来 Delivery Rate 的增量。inflight 在排队系统描述为排队时间 T 的线性函数，则加速比
2022-12-04 12:45:00
3814
原创 BBR 数学模型直观展示
看 BBR 的理想图示：但现实中数据包到达并非绝对均匀，考虑统计突发，实际情况如下：后文将 Delivery Rate 设为 B(Bandwidth)，将 RTT 设为 D(Delay)。B/inflt 曲线一定上凸，可想象 1 个 inflt 只有一种到达方式，带来 1 个 B 增益，2 个 inflt 在 2 个时间槽可排列 (0, 2)，(1, 1)，凡带 0 组合，都有浪费处理周期，3 个 inflt 在 3 个时间槽可排列 (3, 0, 0)，(2, 1, 0)，(1, 1, 1)，随
2022-12-03 12:15:00
3812
1
原创 半双工 Wi-Fi 无线局域网
终端进入盲区失联导致数据堆在 AP，HoL 拥塞，连接数据在容忍时间内无法完成传输，从而引发各种超时，重传，某种情况下的误判会加重拥塞。对传输协议调优而言，Wi-Fi 半双工影响很大，根本上还是资源不足，徐经理说，“一旦物理层独立的资源足够多，MAC 其实的功能性就会弱了”，比如有线以太网可随意拉线，因为线多且易得。原因其实很简单，有线以太网本身就独享介质，就是那根线，无线局域网传输介质是空气，本身就是共享的。所有频段被所有功能，所有人共享，管理上一定非常复杂，允许谁用不允许谁用哪个频段，都需要确定。
2022-12-03 01:15:00
3904
原创 UDP-Based 多路径乱序传输
DC 内部，对称拓扑保证 ECMP 等价，切路径后甚至不需重置 RTT，同时没有 NAT Session 问题，直接换端口即可，QUIC 连接迁移的 probing frame，non-probing frame，PATH_CHANGING，PATH_RESPONSE 均可省却，乱序窗口增大，轻松将 QUIC 裁剪成一个轻量 DCN 新协议。地址/端口 与 “连接” 解耦，QUIC 可轻松实现连接迁移，但若仅仅希望利用 ECMP 分散疏导拥塞，QUIC 的连接迁移过重了。浙江温州皮鞋湿，下雨进水不会胖。
2022-11-27 05:45:00
3974
2
原创 Multi-Path Transport 的误区
用力拉棉线时，若纤维不均匀，最弱的那根纤维断裂后，本来由它分担的力将瞬间摊给剩余纤维，这些纤维中依然存在最弱的那根，由于分摊了额外的受力将断裂，如此反复蔓延，直到整根棉线断裂。对于 MP 传输，若违背第 2 条原则，整个带宽池将过载，一旦最弱的路径拥塞崩溃，它承载的流量将会给其它路径输入额外的重传流量，从而加重所有路径的拥塞，拥塞蔓延而引发连锁反应。服务器集群也类似，一台机器挂了，它承载的流量瞬间摊给其它机器，导致其它机器流量增长，从而击垮其中最弱的那台，反复蔓延，直到服务器大面积瘫痪。
2022-11-26 11:45:00
3108
1
原创 网络 buffer 与内存 swap
注意，问题是 “为什么关闭 swap”，而不是 “要不要关闭 swap”，有人不但答非所问，反而贴了一个文章链接而支持打开 swap，此人道不明，似乎是为了反驳而反驳，读了链接的文章，亦不敢苟同。“内存抖动的根源在于内存不够大却还要贪婪使用，要么约束应用程序，要么买更大的内存“ 上面这句话换到网络传输场景再说一遍就是 “延时抖动的根源在于带宽不够大却还要贪婪使用，要么约束发送，要么买更大带宽”，前者，人们普遍知道 swap 不好，要关掉，可对后者，人们却依然倾向于部署大 buffer 而不想约束发送。
2022-11-26 10:45:00
2935
1
原创 TCP 与 CPU 架构发展史
CPU 架构的历史演进大家都知道，加入了超标量，流水线，多核。无论是端资源，还是网络转发资源。诞生于 1970s 的 TCP 协议，在 1981 年作为 TCP/IPv4 被标准化，其实质直到今天都没有发生改变，按序，可靠，其间有过一些涉及效率的修补。TCP over IP 按照 CPU 架构发展史的路线再来一遍，没有空闲资源，最小化等待，就是高尚的，当然，名字可以不叫 TCP。程序视角看起来还是按序执行的，可 CPU 确实乱序执行微指令，TCP 应用看起来还是按照到达的一条流，但网络却可以乱序传输。
2022-11-20 15:45:00
3153
2
原创 单流 TCP 100Gbps+ 难题的直观解释
为实现初始假设，CPU 处理 100Gbps 到达率，需在 100ns 内完成 tcp_v4_rcv 调用(除 CPU 执行冗长的指令，还要加入内存操作，batch 只降低 overhead，但内存时间也相应越久，ZeroCopy 也不例外，稍好，但不完全)，CPU 很难完成该任务，初始假设都难，匡论后续随机过程。若说到达率和服务率相等，在足够久的相同一段时间，垂直线和水平线的数量是相等的，但表示到达的垂直线是实在累加的，而表示处理的水平线中有很多空闲的浪费，所谓逝去时间不可追回。读后 本文接着写点感想。
2022-11-19 12:00:00
3705
1
原创 400Gbps 网络面临的挑战
想到 TCP 诞生的 1970s，网速远小于主机处理速度，它的一切协议逻辑都是合理的，适应彼时硬件的，一路发展到网卡将要逆袭 CPU，CPU 反而成了外设的当今，TCP 反而成了鸡肋，还是有点适者生存的进化理念的，什么样架构的硬件，就需要什么样的软件与之搭伴，否则硬件就是没有竞争力的。400Gbps，40us 链路，BDP 达 2MB，需更大 buffer 平滑统计突发，但更大 buffer 承受更大突发的同时，在大收敛比节点也要承受更大扇入，引入更大延迟，影响公平性。既然单个 CPU 不行，多个总可以。
2022-11-19 07:43:43
3321
原创 100 Gbps 网卡的 TCP 困境
否则 TCP 几乎不可能使用 CPU 跑满 100Gbps 带宽，大概也就 60～80Gbps 吧，同一个 TOR 下，最多 90Gbps。现在 DCN 都在上 100 Gbps 网卡，最近也是不断有这种关于 TCP 100Gbps 的咨询，我的结论是：TCP 很难跑满 100Gbps，除非你的 CPU 内存带宽远超 100Gbps。100Gbps 网络带宽都赶上内存带宽了，这意味着你要完全 pacing rate，才能二者匹配，否则就要套排队论泊松到达公式，当到达率和服务率一样时，等待时间无限长。
2022-11-13 12:06:57
5896
1
原创 BBRv2 Cruise 阶段的 inflight 补偿
除代码所示部分，还有一个细节，只要重新采到更小的 RTT，就可开始将 inflight_lo 拉回 inflight_hi - headroom，并开始递增 bw_lo 到 round_start_bw，RTT 降低意味着排队缓解，此时即便轻微丢包，大概率是非拥塞丢包。若遭遇随机丢包，BBRv2 在 cruise 阶段会持续降速，cycle 内没有任何补偿措施，造成吞吐持续下降，降低了带宽利用率，损害了对自身的公平性。说完第一件事，还有一件事，BBRv2 的 maxbw-filter 的长度。
2022-11-12 11:45:00
5225
原创 Google PLB(Protective Load Balancing) 简评
Host 感知拥塞需要足够的反馈，这需要足够的 round trips，而 DCN 内部的数据传输模式以短 message 为主，因此 PLB 仅针对占比少量的 big Flow 起作用，好消息是，占比少的 big Flow 贡献了占比大的流量，它们正是拥塞控制的实施对象。除非为 Flow 保持状态，当拥塞发生时，交换机可以找出排队最多 5-tuple 属于哪个 Flow，从而改变它的 seed，仅对该 5-tuple 进行 rehash，将它 re-path。浙江温州皮鞋湿，下雨进水不会胖。
2022-11-10 01:45:00
3279
原创 从 BBR 到 BBRv2
这是一个事实上可靠的 BBR/Reno 共存保证。在上述窗口内，BBRv2 执行 cruise，对网络不注入任何干扰，让 Reno/CUBIC 安静 AI，由于 BBR probe up 采用 MI，它只在时间窗口过后，一次性执行 MI，在理论上，BBRv2 和 Reno/CUBIC 具有了同样的 probe 周期，建立了友好共存的基础。策略是个好策略，但在我看来，现实场景中，都是异步流，BDP 个 RTT 的 AIMD 周期属高斯分布的右尾，取其期望均值是高尚的，大约 30～40 个 RTT 很合理。
2022-11-05 17:15:00
3550
2
原创 BBR/CUBIC 共存时的 buffer 挤兑
最近搜集混部公平性数据，实际网络测试，20Gbps，RTT=80us，4 BBR vs. 4 CUBIC，交换机 10MB buffer，远大于 BDP，属深队列，配置尾丢时并没有展示出 CUBIC 压倒性优势，发现是 gain=125% probe 作祟，改经过 25MB buffer，问题消除，CUBIC 力压 BBR，配置 wRED，无论多大的 buffer，CUBIC 均无优势。与之配合，BBR 带宽很小时，加速比很大，带宽占比很大时，加速比变小，其变化曲线与 CUBIC 相一致。
2022-10-29 14:15:00
3505
原创 It‘s Time to Replace TCP in the Datacenter 读后
多核服务器中，Core 负责计算，Mem 负责数据，无论 Core 间通信，还是 Core 和 Mem 通信，很容易理解减少甚至避免大块内存拷贝的意义，仅做计算以及 Load/Store 指令，换做 DC 网络传输，同理，流式大块数据传输即内存拷贝，趋向减少，尽可避免。所谓 DC 传输，将一笔数据传到不远处的对端，这笔数据分割，打包，发送，这是显而易见的做法，没有任何理由需要事先建立一个连接，让这笔数据以流的方式按序流入对端内存，说实话，TCP 才是奇怪的方式。首先，传输不一定必须可靠，应用更懂该怎么做。
2022-10-29 13:15:00
3314
1
原创 Google Swift 与 DC 传输
不拘泥 TCP/UDP，DC 可各种花式传输，依赖交换机的 ECN，INT，QCN，PFC 只是冰山一角，丢包，ECN 打标是常规做法，自研交换机还可以往数据包头里加字段，裁掉 payload，只留报头返回给发送端，或者像运载火箭一样，没用的信息 cut 掉，不一而足。看，这是不是和 Aeolus 的思路差不多，第一笔数据突发，事实上大多数传输也就仅这一笔数据，赢了稳赚，输了回退到重传，用 2 个(或 3 个，总之不会太多) RTT。网络拥塞，默认指转发节点出现了严重的排队现象，甚至队列溢出而丢包。
2022-10-22 17:00:00
3329
原创 cwnd ＜ 1 时的拥塞控制
Linux Kernel TCP 不支持浮点数，TCP cwnd，pacing rate 的计算必须取整，这损失了精度，但 RFC 也是这么规范 cwnd 的，这明显已经不适合 DC 网络这种微秒级网络了，相对粗旷的 cwnd 规范是面向 Internet 的，但现在 DC 显然是另一种性质的网络。事实上，DC buffer 平方反比律，CSMA/CD 统计复用，cwnd < 1 时随机化发送 RTT 时隙，都是一回事，流要异步，不要同步！简单理解，如果经过同一转发节点的流数量大于。
2022-10-22 14:15:00
3192
2
原创 DC 交换机 buffer 的平方反比律
完全没问题，我前面几周写的那些 policy 就可以用了，比如 incast 业务随机退避，此外，即使流同步，大不了就是准备一个 BDP 大小的 buffer，在 DC 内部，RTT 非常小，这个 buffer 充其量也就是 1MB～10MB 级别。这解释了多流收敛代价递增。但且慢，平方反比律成立的前提是所有流异步，cwnd 和 RTT 独立时才适用，对于 Internet，这毫无问题，基本对得上模型，对于 DC 内部，类似 incast 这种流量往往是同步的，怎么办？
2022-10-22 12:45:00
2978
原创 App/QoE-Based Congestion control
各种传输层拥塞控制算法都表现得不尽人意，在我看来不是算法不好，而是要么做的太多，要么做的太少，本质上都是信息不够。不在传输层降低 cwnd 或降低 pacing rate，将拥塞控制事件及相关数据反馈给应用程序，应用程序自行决定降速，分流，服务降级，甚至丢弃一些数据，自然就解除了拥塞，这种做法可维持平稳的 pacing 间隔，保证 QoE。带宽固定，流越多，每流可用带宽越少，体现在每流影响上，如果每流依然坚持传输数据量不变，势必造成延时增加，拥塞维持，如果传输数据量下降，则可压缩时间，解除拥塞。
2022-10-15 13:45:00
4582
原创 Congestion control in DC
有人让我用 traceroute，我说 traceroute 看不到二层设备，只能看到路由器，接着我就被怼，对方告诉我 DC 内没有二层设备，都是三层…AIMD，本来是做 Internet 拥塞控制的，结果却更加适合 DC 网络，对于 Internet 拥塞控制，Rate-Based 正风靡。采用慢启动探测耽搁的时间大于发送时间本身，不如赌一把，如果发生拥塞丢包，下一个 RTT 重传不会耽搁太久，若采用慢启动探测，时间亦无法压缩，如果没发生拥塞，大部分短消息都可在一个或几个 RTT 内完成传输。
2022-10-15 07:15:00
4467
原创 彻底解决 IDC Incast
若同时到达，Incast 丢包重传也会延后完成时间，不如主动延后扇入，减少 buffer 突发占用，减少了丢包也就提供了带宽总利用率，降低了损耗。同样的时间，有丢包就是净损，该净损的端到端体验就是延时增加，不仅 Incast 流量延时增加，所有流量延时都增加。虽缓解了丢包，但延时仍增加，无论重传延时还是大 buffer 排队延时，都伤害了延时敏感业务。于是，即使不知道 RTT 的明确量级，流首包随机延时 5us～10us 甚至 1us～5us 发送，设为 α ，也将能缓解 Incast 大部分问题。
2022-10-01 14:30:00
2234
原创 IDC Incast 的不彻底解决
TCP 不支持下面一种机制，以 pacing rate 为 primary control，以 BDP 以为 cwnd，若 cwnd < 1，则在对应发送时间步长的后端发出该数据包，比如 cwnd = 0.1，即 1 个 RTT 发送 0.1 个数据包，数据包不拆分，就延长时间，即 10 个 RTT 发送 1 个数据包，那么在 10 个 RTT 后，发出 1 个数据包即可。这其中，每去掉一个词，路子就敞亮一些，依次去掉 Linux，kernel，TCP 试试看。浙江温州皮鞋湿，下雨进水不会胖。
2022-10-01 12:15:00
2041
原创 提高 IDC 网络带宽利用率
我本想写一个 Netfilter 模块去 match nf_conntrack 的 account 字段，将一个 TCP 连接的前 n 个包的 ECT 标志 clear 掉，想到上述这段话后，就改成 stap -g 了，抓住 sock 之后，更精细判断丢包率以及别的指标，权衡要不要 clear ECT。IDC 网络拥塞控制要换个思路，不能一味追求端到端算法的精妙，而要充分利用可以利用的一切基础设施提供的信息，比如用额外的流量补充带宽的浪费，又比如 ECN。现实中真的需要这样吗？二者都提高了带宽利用率。
2022-09-25 13:15:00
2686
一个iptables的stateless NAT模块实现
2014-12-27
模块化的nf-HiPAC
2014-11-21
关于linux内核以及其他个人体会的文集
2009-09-07
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人