运维123 - 网络技术
type: channel
link: https://sddts.cn/index.php/category/Network/
items: 中国主机托管生态系统中的恶意软件 C2 基础设施分析
items: Happy Server 零知识同步后端技术分析
items: eSIM 长期漫游服务产品技术分析
items: SSH 隧道深入解析：通过堡垒机进行转发
items: BBR 与 CUBIC 拥塞控制算法深度分析
items: 使用 K 线图分析 BBR 拥塞控制算法
items: Bonding 双活模式：Balance-tlb 与 Balance-alb 技术分析
items: RDMA 技术分析
items: 流媒体拥塞控制与流控技术分析
items: 康威定律与数据中心网络架构思考

中国主机托管生态系统中的恶意软件 C2 基础设施分析
type: item
date: 2026-01-19T14:35:47+00:00
description: 中国主机托管生态系统中的恶意软件 C2 基础设施分析一、概述1. 研究背景A. 问题提出威胁狩猎通常从单个指标开始，如可疑 IP 地址、信标域名或已知恶意软件家族。然而，单独查看这些指标会导致底层基础设施难以被发现。B. 核心发现Hunt.io 在分析中国主机托管环境中的恶意活动时，反复观察到相同的网络和提供商出现在不相关的活动中。商品化恶意软件、网络钓鱼操作和国家相关工具经常在同一基础设施中并存。C. 研究价值本研究揭示了基于指标 hunting 的局限性，展示如何通过主机为中心的方法在国家级尺度上观察恶意基础设施集群和持久性。2. 研究方法A. 数据来源Host Radar 平台聚合了 C2 检测、网络钓鱼识别、开放目录扫描和 IOC 提取的信号，并与主机托管、ASN 和网络所有权上下文进行关联。B. 分析周期2025 年 10 月 5 日至 2026 年 1 月 3 日，共计 90 天。C. 覆盖范围48 个中国基础设施提供商和网络实体。二、核心发现1. 关键数据A. 总体规模C2 服务器：18,000+ 个网络钓鱼站点：2,837 个恶意开放目录：528 个公共 IOC：134 个恶意工件总数：21,629 个B. 分布比例C2 基础设施占约 84%网络钓鱼基础设施占约 13%恶意开放目录和公共 IOC 合计占不到 4%2. 提供商分布A. Top 5 提供商排名提供商C2 服务器数量占比1中国联通9,100约 50%2阿里云3,300约 18%3腾讯3,300约 18%4中国电信620约 3%5京东385约 2%B. 基础设施集中度pie title 中国 C2 服务器分布（Top 5 提供商） "中国联通" : 50 "阿里云" : 18 "腾讯" : 18 "中国电信" : 4 "京东" : 2 "其他" : 8三、恶意基础设施分布1. 按提供商分析A. 中国联通C2 服务器：9,000 个（90 天内）恶意开放目录：30 个IOC：11 个特点：单一提供商占所有中国 C2 基础设施的近一半B. 阿里云C2 服务器：3,300 个网络钓鱼站点：37 个恶意开放目录：0 个IOC：0 个特点：云环境主要用于弹性 C2 操作，而非暴露工件C. 腾讯C2 服务器：3,300 个网络钓鱼站点：2,400 个恶意开放目录：122 个IOC：26 个特点：多样化的恶意足迹，大量滥用社交媒体、游戏和电商平台D. 中国电信C2 服务器：617 个恶意开放目录：42 个特点：国有电信基础设施的定向利用E. 京东C2 服务器：385 个恶意开放目录：0 个IOC：0 个网络钓鱼站点：0 个特点：零售网络相对较少被滥用2. 基础设施类型分布pie title 中国恶意基础设施类型分布 "C2 服务器" : 84 "网络钓鱼" : 13 "开放目录" : 2 "公共 IOC" : 1四、恶意软件家族分析1. Top 10 恶意软件家族排名恶意软件家族C2 IP 数量类型1Mozi9,427IoT 僵尸网络2ARL2,878红队框架3Cobalt Strike1,204商业 C2 框架4Vshell830后门5Mirai703IoT 僵尸网络6Gophish420网络钓鱼框架7NanoCore380RAT8AsyncRAT290RAT9Acunetix180漏洞扫描10XMRig150加密货币挖矿2. 恶意软件类型分布graph TD A[中国恶意软件 C2 基础设施] --> B[IoT 僵尸网络 52%] A --> C[红队/后门框架 28%] A --> D[RAT 远程访问 12%] A --> E[网络钓鱼/扫描 5%] A --> F[加密挖矿 3%] B --> B1[Mozi] B --> B2[Mirai] C --> C1[ARL] C --> C2[Cobalt Strike] C --> C3[Vshell] D --> D1[NanoCore] D --> D2[AsyncRAT] E --> E1[Gophish] E --> E2[Acunetix] F --> F1[XMRig]五、基础设施提供商风险分析1. 最高恶意软件多样性提供商排名提供商恶意软件家族数C2 端点数1腾讯云计算（北京）60~2,0002阿里云计算52~1,9563亚太网络信息中心（APNIC）27数据不足4华为公有云服务20数据不足2. 系统性风险评估graph LR A[高风险提供商] --> B[腾讯云] A --> C[阿里云] A --> D[APNIC] A --> E[华为云] B --> B1[60 恶意软件家族] B --> B2[2000+ C2 端点] B --> B3[重复利用跨活动] C --> C1[52 恶…

Happy Server 零知识同步后端技术分析
type: item
date: 2026-01-19T02:14:58+00:00
description: Happy Server 零知识同步后端技术分析一、技术概述1. 项目简介Happy Server 是一个专为开源 Claude Code 客户端设计的最小化后端服务，提供端到端加密的对话同步功能。A. 核心定位Happy Server 作为安全同步的骨干网络，使多设备能够共享加密对话，同时保持完全隐私。服务器存储加密数据但无法解密，仅作为加密数据的中继存储点。B. 设计哲学零知识架构：服务器无能力查看用户消息内容最小化攻击面：仅包含安全同步必需的功能隐私优先：无分析、无追踪、无数据挖掘2. 核心特性A. 安全特性零知识证明：服务器存储加密数据但无法解密密码学认证：不存储密码，仅使用公钥签名端到端加密：消息在离开发备前已加密B. 功能特性实时同步：基于 WebSocket 的跨设备实时同步多设备支持：手机、平板、电脑无缝会话管理推送通知：任务完成或需要权限时加密推送通知分布式就绪：设计支持水平扩展C. 开源特性完全开源：透明的实现可审计和自托管MIT 许可：自由使用、修改、部署二、技术架构1. 架构设计graph TB subgraph 客户端设备 C1[设备 A 手机] C2[设备 B 电脑] C3[设备 C 平板] end subgraph 本地加密层 E1[密钥生成] E2[端到端加密] E3[签名验证] end subgraph Happy Server S1[WebSocket 同步] S2[加密数据存储] S3[推送通知服务] end C1 -->|本地加密| E1 C2 -->|本地加密| E1 C3 -->|本地加密| E1 E1 --> E2 E2 -->|加密数据流| S1 S1 --> S2 S2 -->|同步| S1 S1 -->|加密推送| S3 S3 -->|加密通知| C1 S3 -->|加密通知| C2 S3 -->|加密通知| C32. 工作流程A. 消息同步流程sequenceDiagram participant D1 as 设备 A participant E as 本地加密层 participant H as Happy Server participant D2 as 设备 B D1->>E: 1. 生成密钥对 D1->>E: 2. 加密消息 D1->>E: 3. 签名验证 E->>H: 4. 上传加密数据 H-->>D1: 5. 确认存储 H->>D2: 6. WebSocket 推送 D2->>E: 7. 下载加密数据 D2->>E: 8. 本地解密 E-->>D2: 9. 显示消息B. 安全模型分析层级安全措施说明客户端本地密钥生成密钥永不离开设备传输层端到端加密服务器仅中继加密数据存储层加密数据存储服务器存储无法解密的数据认证层公钥签名无密码存储风险3. 技术栈分析根据 GitHub 仓库信息：主语言：TypeScript（99.4%）部署方式：Docker 容器化数据库：Prisma ORM实时通信：WebSocket 协议三、安全分析1. 零知识架构A. 核心原理服务器仅存储加密数据块（encrypted blobs），完全没有解密能力。加密在客户端本地完成，只有用户持有密钥。B. 安全优势服务器被入侵无风险：攻击者仅能获取无法解密的加密数据无需信任服务器提供商：即使云服务商也无法访问消息内容符合隐私法规：数据始终处于加密状态C. 密码学认证不存储用户密码使用公钥签名进行身份验证防止密码泄露风险2. 隐私保护A. 无数据收集无分析追踪无行为记录无数据挖掘B. 推送通知加密通知内容同样经过加密，服务器仅能转发但无法查看通知内容。四、部署方案1. 云服务托管A. 官方云服务地址：happy-api.slopus.comB. 安全性说明由于采用端到端加密，使用官方云服务的安全性与自托管完全相同。所有数据在离开发备前已加密，服务器即使想查看也做不到。C. 优势无需维护基础设施自动更新和扩展与自托管相同的安全模型2. 自托管部署A. 开源特性MIT 许可，可自由修改和部署完全透明的实现可审计的代码B. 部署建议使用 Docker 容器化部署配置反向代理（Nginx）启用 HTTPS 加密传输配置防火墙规则五、应用场景1. Claude Code 客户端Happy Server 专为开源 Claude Code 客户端设计，实现：多设备对话同步任务状态共享加密推送通知2. 扩展应用场景基于其架构设计，Happy Server 可应用于：需要高隐私保护的即时通讯多设备协作工具加密笔记同步六、技术影响1. 隐私保护范式Happy Server 展示了一种新的隐私保护范式：通过端到端加密实现零信任架构服务器提供商无法访问用户数据开源透明增加可信度2. 同步架构设计最小化服务器功能客户端承担…

eSIM 长期漫游服务产品技术分析
type: item
date: 2026-01-18T21:45:52+00:00
description: eSIM 长期漫游服务产品技术分析一、概述1. 产品简介本文基于 Banana Travel Sim 的 eSIM 365 天产品，分析嵌入式 SIM 卡技术在长期国际漫游场景中的应用特点、技术实现和使用体验。2. 核心问题传统国际漫游方案存在换卡繁琐、资费昂贵、覆盖不全等问题。eSIM 技术通过数字化配置提供了新的解决思路。二、技术背景1. eSIM 技术原理graph LR A[运营商] -->|下载配置文件| B[eSIM 服务器] B -->|安全认证| C[用户设备] C -->|LPA 协议| D[eSIM 芯片] D -->|存储多配置| E[网络注册]2. 系统组成EID：eSIM 唯一标识符，用于识别设备 eSIM 能力LPA：本地配置助理，管理 eSIM 配置文件Profile：运营商配置文件，包含网络接入参数SM-DP：订阅管理数据发现服务器，负责配置文件下发3. 关键技术要求SIM-lock-free：设备无运营商锁EID 支持：通过 *#06# 查询设备兼容性三、产品规格分析1. 覆盖范围该产品提供两种覆盖方案：52 区域方案：中国大陆、澳门、日本、韩国、台湾、新加坡、马来西亚、泰国、越南、印尼、菲律宾、柬埔寨、老挝、孟加拉、以色列、澳大利亚、新西兰、美国、加拿大、英国及 30+ 个欧洲国家中国区域方案：中国大陆 + 澳门 + 台湾2. 流量分配策略graph TD A[套餐激活] --> B{使用高速流量} B -->|未耗尽| C[5G 高速网络] B -->|已耗尽| D[限速 512kbps] D --> E[无限数据] C --> F{每日 24 小时周期} E --> F F --> G[周期重置]3. 套餐层级套餐类型52 区域方案中国区域方案入门级10GB + 无限10GB + 无限标准级20GB + 无限18GB + 无限进阶级30GB + 无限30GB + 无限高级50GB + 无限50GB + 无限超高级80GB + 无限80GB + 无限旗舰级120GB + 无限120GB + 无限四、技术实现细节1. 激活流程sequenceDiagram participant U as 用户 participant S as 商城系统 participant E as 邮件系统 participant D as 设备 U->>S: 购买 eSIM S->>E: 发送 QR Code E->>U: 24-48 小时内送达 U->>D: 扫描 QR Code D->>D: 下载配置文件 D->>D: 绑定设备 Note over D: 单次扫描 不可转移2. 有效期计算计算基准：激活后 24 小时为一天购买限制：365 天内必须激活逾期处理：自动过期，不可退改3. 兼容性验证验证步骤：检查 SIM-lock 状态：设置 → 查询是否有 SIM 限制查询 EID：拨打 *#06#，确认显示 EID 信息确认网络支持：查阅设备 eSIM 兼容列表五、应用场景分析1. 长期旅行者适用对象：数字游民、长期外派人员优势：一次购买，全年覆盖注意：需提前 2 天购买激活2. 多国商务出行场景：频繁往返不同国家优势：52 区域方案单卡覆盖约束：每次切换网络需重新注册3. 备用网络方案用途：主网络故障时的应急方案优势：与实体 SIM 不冲突限制：需设备支持双卡双待六、问题与挑战1. 技术限制设备兼容性：需支持 eSIM 的设备绑定不可逆：QR Code 扫描后无法更换设备网络质量：部分地区仅支持 4G2. 使用风险激活时限：365 天过期压力退款规则：个人原因退款需收取 HK$20 行政费技术支持：仅 WhatsApp 文字咨询3. 特殊地区要求台湾地区：需要实名注册注册平台：glcm.gloableconnect.com/prepaid/realname七、最佳实践建议1. 购买前检查确认设备 eSIM 兼容性核查目的地网络覆盖评估流量需求选择套餐2. 激活时机出发前 2 天购买，留出配送时间到达目的地后激活，避免浪费有效期先测试网络再切换主 SIM3. 应急预案保存 QR Code 截图备用记录技术支持联系方式准备备用网络方案八、技术总结1. 核心价值eSIM 技术通过数字化配置解决了传统 SIM 卡的物理限制，为长期国际漫游提供了灵活便捷的解决方案。2. 关键权衡便利性 vs. 绑定风险：扫描即绑定，不可转移覆盖广度 vs. 网络质量：52 区域但部分仅 4G长期有效 vs. 激活压力：365 天有效期需规划3. 发展趋势设备兼容性持续提升运营商支持逐步扩大实名监管日趋严格参考资料Banana Travel Sim eSIM 产品页面

SSH 隧道深入解析：通过堡垒机进行转发
type: item
date: 2026-01-18T10:59:10+00:00
description: SSH 隧道深入解析：通过堡垒机进行转发一、概述1. 背景介绍SSH 隧道技术是网络工程师和安全从业者必备的技能之一。在前两部分中，我们介绍了本地端口转发和远程端口转发两种基本的 SSH 隧道方向。本篇文章将深入探讨一种更复杂的场景：通过堡垒机（Bastion Host）进行 SSH 隧道转发。2. 核心概念堡垒机是一种暴露在外部网络中的中间服务器，用于作为访问内部网络的网关。内部系统通常隐藏在堡垒机之后，不直接对外开放访问。这种架构在安全实践中非常常见。3. 应用场景安全地访问受保护的内部网络资源通过跳板机管理多层级网络架构在不暴露内部服务的情况下进行远程运维二、SSH 代理隧道原理1. 工作机制SSH 代理隧道是建立在本地端口转发基础上的扩展技术。其核心思想是：不是将流量直接转发到 SSH 服务器，而是通过一个中间机器（堡垒机）转发到实际目标。2. 架构分析graph LR A[客户端机器] -->|SSH 连接| B[堡垒主机] B -->|网络访问| C[内部机器] A -->|本地端口转发| B B -->|流量转发| C A -.->|最终访问| C3. 关键组件A. 客户端机器用户操作的本地计算机，运行 SSH 命令并建立隧道。B. 堡垒主机暴露在外部网络的中间服务器，作为进入内部网络的网关。C. 内部机器位于受保护网络中的目标服务器，只能通过堡垒机访问。三、实验环境配置1. 网络拓扑典型实验环境包含三台机器：客户端机器：192.168.56.10 - 运行 SSH 命令的本地机器堡垒主机：192.168.56.11 - 暴露在外部的中间服务器内部机器：192.168.57.11 - 需要通过堡垒机访问的目标服务器2. 网络连通性graph TB subgraph 外部网络 Client[客户端 192.168.56.10] Bastion[堡垒主机 192.168.56.11] end subgraph 内部网络 Internal[内部机器 192.168.57.11] end Client -->|可直接访问| Bastion Bastion -->|可访问| Internal Client -.->|无法直接访问| Internal3. 环境要求系统要求所有机器运行 Linux 操作系统SSH 服务已安装并运行网络防火墙规则正确配置权限要求客户端需要有堡垒机的 SSH 访问权限堡垒机需要有内部机器的网络访问权限四、SSH 代理隧道配置1. 基本语法通过堡垒机进行 SSH 隧道转发的命令格式：ssh -L [本地端口]:[内部目标地址]:[内部端口] [堡垒机用户]@[堡垒机地址]参数说明-L：本地端口转发[本地端口]：客户端监听的端口号[内部目标地址]：相对于堡垒机的内部机器地址[内部端口]：内部机器上目标服务的端口号[堡垒机用户]：堡垒机的登录用户名[堡垒机地址]：堡垒机的 IP 地址或域名2. 实战示例假设内部机器 192.168.57.11 上运行着 Web 服务（端口 80），我们要通过堡垒机 192.168.56.11 访问该服务。步骤 1：建立 SSH 隧道ssh -L 8080:192.168.57.11:80 user@192.168.56.11步骤 2：访问内部服务隧道建立后，在客户端浏览器访问：http://localhost:8080流量路径：客户端 localhost:8080 → 堡垒机 → 内部机器:803. 工作流程详解sequenceDiagram participant C as 客户端 participant L as 本地端口 participant B as 堡垒主机 participant I as 内部机器 C->>L: 访问 localhost:8080 L->>B: 通过 SSH 隧道转发 B->>I: 转发到 192.168.57.11:80 I-->>B: 返回响应 B-->>L: 通过隧道返回 L-->>C: 返回给浏览器五、高级配置1. 后台运行隧道使用 -f 参数让 SSH 在后台运行：ssh -f -N -L 8080:192.168.57.11:80 user@192.168.56.11-f：后台运行-N：不执行远程命令，仅建立隧道2. 密钥认证配置 SSH 密钥认证避免重复输入密码：# 生成密钥对 ssh-keygen -t rsa -b 4096 # 复制公钥到堡垒机 ssh-copy-id user@192.168.56.113. 持久化隧道使用 autossh 自动重连断开的隧道：# 安装 autossh sudo apt-get install autossh # 启动持久化隧道 autossh -M 0 -f -N -L 8080:1…

BBR 与 CUBIC 拥塞控制算法深度分析
type: item
date: 2026-01-18T00:30:42+00:00
description: BBR 与 CUBIC 拥塞控制算法深度分析一、概述1. 背景介绍自 2017 年底 BBR（Bottleneck Bandwidth and Round-trip propagation time）发布以来，随着媒体的宣讲，各大站点陆续部署 BBR。很多网友不禁问，BBR 这么好，为什么不替代 CUBIC 成为 Linux 的缺省算法。仅仅因为它尚未标准化，这么好的算法又为什么没被标准化？2. 核心问题本文将从技术原理、系统稳定性、公平性、适用场景等多个维度，深入分析 BBR 为什么没有替代 CUBIC 成为 Linux 内核缺省算法。二、算法对比分析1. 性能度量的误区A. 错误的测试方法包括作者在内的几乎所有人都用过一种错误方法度量 BBR 的"好"：搭建一跳转发的模拟环境，用 tc 配置丢包、时延，用 iperf 对比 BBR 和 CUBIC，得到结论：BBR 的吞吐比 CUBIC 大好多倍，所以 BBR 好。B. 测试的局限性这种测试方法存在严重问题：测试环境过于理想化未考虑真实网络环境的复杂性忽略了统计复用网络的基本特性C. 正确的评价标准根据 Dropbox 的实际部署经验，一个拥塞控制算法在部署之前，至少要自证两件事：不会引发拥塞崩溃网络流量公平收敛2. 算法设计哲学差异A. CUBIC 的设计理念graph LR A[CUBIC 算法] --> B[基于丢包反馈] B --> C[线性系统] C --> D[可叠加性] D --> E[稳定收敛] style A fill:#e1f5ff style E fill:#c8e6c9CUBIC 的核心特点：最小依赖：仅依赖丢包事件丢包不会撒谎：任何行为都无法做到 buffer 溢出而不丢包宁可错杀，但绝不遗漏：对拥塞的反应属反向激励线性系统：具备可叠加性，系统问题可控B. BBR 的设计理念graph LR A[BBR 算法] --> B[主动测量带宽] B --> C[测量 RTT] C --> D[模型估算] D --> E[调整发送速率] A --> F[非线性系统] F --> G[复杂行为] G --> H[不可预测性] style A fill:#fff3e0 style H fill:#ffcdd2BBR 的核心特点：主动探测带宽和 RTT依赖高精度的准确测量非线性系统，行为复杂对测量误差敏感三、深入分析1. 测量精度的陷阱A. 统计律的本质统计复用网络本身不可精确测量。这不仅仅是网络异构性的问题，更深层的原因来自于统计律本身。正如你无法把握某个空气分子的动量，但却能测量一坨空气的温度一样。B. 测量的滞后性统计方法都有滞后性，对反馈响应之前的这段时间可能就是灾难酝酿的时间。而随后的响应并不覆盖灾难，系统可能滑向不稳定状态，包括拥塞崩溃。C. BBR 的依赖性BBR 的正确性依赖高精度的准确的对 bandwidth 和 rtt 的测量，而：高精度取决于实现准确性则依赖网络本身2. 系统稳定性分析A. 线性 vs 非线性graph TB subgraph 线性系统_CUBIC A1[流 1] --> C[共享瓶颈] A2[流 2] --> C A3[流 N] --> C C --> D[稳定收敛] D --> E[公平分配] end subgraph 非线性系统_BBR B1[流 1] --> F[复杂交互] B2[流 2] --> F B3[流 N] --> F F --> G{不确定状态} G --> H[可能发散] G --> I[可能收敛] end style D fill:#c8e6c9 style G fill:#ffcdd2CUBIC 源自 Reno，是线性的，线性可叠加性让系统问题变得和单体问题一样可控。不管是同步流还是异步流，系统行为可预测。BBR 本身是个非线性系统，不能用线性的思维去简单表达。换句话说，这件事本身就凌乱复杂，没有简单到能让人快速画线获得直感的方法。B. 双流相图分析文章中的 BBR 双流相图显示，系统状态空间的边界难以确定。某个状态的可达性取决于你对系统的测量结果，而误估导致的行为不可控。3. 公平性问题A. CUBIC 的公平性与自身共存：公平收敛与异构流量共存：表现可预期收敛速度：可预期B. BBR 的公平性挑战BBR 一个也证明不了：无法自证不会引发拥塞崩溃无法自证网络流量公平收敛在某些场景下可能过度抢占带宽在某些场景下可能被 CUBIC 压制四、缺省算法的选择标准1. 设计原则大道至简，最小依赖，少即是多，这是 CUBIC 作为缺省算法的理由。A. 普适性缺省算法不一定甚至一定不是性能最高的，但一定是普适不挑环境的。B. 公平性缺省算法的公平性一定是可自证的，无论与自身还是与异构流量共存。C. 可预期性缺省…

使用 K 线图分析 BBR 拥塞控制算法
type: item
date: 2026-01-18T00:19:50+00:00
description: 使用 K 线图分析 BBR 拥塞控制算法一、概述1. 问题背景在网络性能分析中，当只有一个吞吐率散点图需要分析链路带宽走势时，传统的分析方法存在局限性。移动平均线会随时间依次平滑掉所有细节，因此它是滞后的。而蜡烛图（即 K 线图）同时保留峰谷起始，更多细节被保留，通过按阶段绘制四点包络线又同时会显示移动平均的趋势。2. 核心思想通过蜡烛图分析 BBR 带宽变化，可以识别多种网络状态：随机波动和随机噪声微突发流量持续拥塞和逐渐拥塞新流侵入和退出探测比例和公平比例3. 技术价值蜡烛图通过实体长度、上影线、下影线长度等特征，能够刻画很多细节并得到很多结论。通过大阳线、大阴线、锤头、十字星、吊颈线等固有模式及其组合分析，可以深入理解 BBR 拥塞控制算法的运行状态。二、蜡烛图基础1. 起源与定义蜡烛图（日本称为「けいせん」，Kei-sen）始于日本，早期用于统计米价走势，如今普遍用于金融领域。只有中国等少数国家叫「K 线图」，其余多称为「蜡烛图」。Kei-sen 发音也包括「线」的发音，疑似源于粤语音读。2. 基本组成一个标准的蜡烛图包含四个关键价格点：开盘价（Open）：周期开始时的价格最高价（High）：周期内的最高价格最低价（Low）：周期内的最低价格收盘价（Close）：周期结束时的价格3. 形态特征实体：收盘价与开盘价之间的部分，反映价格变动幅度上影线：实体上方的细线，代表最高价与实体顶端（开盘价或收盘价）的距离下影线：实体下方的细线，代表最低价与实体底端（开盘价或收盘价）的距离4. 常见模式大阳线：收盘价远高于开盘价，实体较长，表示强势上涨大阴线：收盘价远低于开盘价，实体较长，表示强势下跌锤头：下影线较长，实体较小，表示反转信号十字星：开盘价与收盘价接近，实体很小，表示市场犹豫吊颈线：上影线较长，实体较小，表示可能的反转三、BBR 算法简介1. 核心概念BBR（Bottleneck Bandwidth and Round-trip propagation time）是 Google 推出的一种 TCP 拥塞控制算法。与传统的基于丢包的拥塞控制算法（如 CUBIC）不同，BBR 基于带宽和 RTT（往返时间）进行拥塞控制。2. 工作原理BBR 通过测量网络路径的瓶颈带宽和最小 RTT，动态调整发送速率。其主要状态包括：graph LR A[Startup] -->|探测带宽| B[Drain] B -->|排空队列| C[ProbeBW] C -->|周期探测| D[ProbeRTT] D -->|测量 RTT| C3. 关键参数BtlBw（Bottleneck Bandwidth）：瓶颈带宽RtProp（Round-trip propagation time）：最小往返时间Delivery Rate：实际交付速率Inflight：在途数据量四、BBR 模拟场景分析1. 场景设定以下是一个典型的 BBR 模拟场景：t < 100：单流正常100 < t < 200：随机突发t = 250：新流侵入300 < t < 350：随机突发t = 500：新流侵入600 < t < 650：持续拥塞750 < t < 900：逐渐拥塞t = 1050：带宽加倍1050 < t < 1250：带宽随机波动1300 < t < 1450：突发波动1450 < t < 1550：突发波动2. 带宽变化识别通过蜡烛图分析 BBR 带宽变化：A. 随机波动特征：实体较小，上下影线长度接近，表示带宽在较小范围内波动。B. 微突发特征：下影线较长或上影线较长，实体较小，表示短时间内带宽的突然变化。C. 持续拥塞特征：连续的大阴线，实体较长，表示带宽持续下降。D. 逐渐拥塞特征：实体逐渐变长且呈阴线趋势，表示带宽逐渐恶化。E. 新流侵入特征：突然的大阴线，下影线较长，表示带宽被新流抢占。F. 退出特征：突然的大阳线，上影线较长，表示流退出后带宽释放。3. 分析优势对移动平均而言，不同 alpha 的平滑细节不同，即便和算术平均放一起也看不出任何趋势，几乎无法分析。而蜡烛图能够：保留峰谷起始信息显示阶段内的最大值和最小值同时展示趋势和细节通过形态识别各种网络状态五、Python 实现蜡烛图绘制1. 环境准备A. 安装依赖pip3 install virtualenv virtualenv py3env source py3env/bin/activate pip3 install mplfinanceB. 所需库mplfinance：专门用于金融数据可视化的 Python 库numpy：数值计算库pandas：数据处理库2. 基础示例A. 数据准备import mplfinance as mpf import numpy as np import p…

Bonding 双活模式：Balance-tlb 与 Balance-alb 技术分析
type: item
date: 2026-01-18T00:11:25+00:00
description: Bonding 双活模式：Balance-tlb 与 Balance-alb 技术分析一、概述1. 背景在上一篇文章中讨论了 active-backup 模式，能够在一张网卡出现故障时快速切换，配置简单。但这种方式存在明显缺点——虽然有两张网卡，但同一时间只能使用一张，只有当主网卡挂了才会使用备网卡。2. 核心问题在高可用设计中，双活优于主备，主备意味着浪费。用户希望实现两张网卡都在工作，当其中一张网卡挂了时，退回到单网卡模式。3. 解决方案Linux Bonding 驱动提供了两种双活模式：Balance-tlb（Adaptive transmit load balancing，模式 5）：发送负载均衡Balance-alb（Adaptive load balancing，模式 6）：收发双向负载均衡二、Balance-tlb 模式1. 工作原理A. 发送方向假设两张网卡都要发送数据，需要解决 MAC flapping 问题——如果同一个 MAC 地址一会从端口 1 发出，一会从端口 2 发出，交换机通过收到的包学习 MAC 地址会感到困惑。因此，两个 interface 必须使用不同的 MAC 地址。对于发送流量，可以使用两个 interface 来发送，交换机看起来就像是两个不同的主机。B. 接收方向对于接收流量，只能用一个 interface 来接收。实现方式是：在回应 ARP 请求时，总是使用其中一个 interface 的 MAC 地址来回复。graph LR subgraph 服务器 B0[bond0 IP: 192.168.1.10 主MAC: 1a:50:9c:11:58:a3] E0[eth0 MAC: 1a:50:9c:11:58:a3 主接口: 收+发] E1[eth1 MAC: 9e:fa:f1:b5:0c:28 备接口: 仅发] B0 --> E0 B0 --> E1 end C1[客户端1] -->|目标MAC: 1a:50| SW[交换机] C2[客户端2] -->|目标MAC: 1a:50| SW SW --> E0 SW --> E1 E0 -->|源MAC: 1a:50| SW E1 -->|源MAC: 9e:fa| SW SW --> C1 SW --> C22. 流量特征对于发送流量：使用两个 interface 发送数据通过 hash 机制保证同一个 TCP 流总是走同一个 interface，避免 reorder 问题实际上会根据两张卡的负载动态调整使用哪张卡对于接收流量：由于其他客户端只知道 IP 对应一个网卡的 MAC 地址，入流量总是走到其中一个 interface 上从交换机视角看，有一个主机的 MAC 地址只会发出去包，但从来没有其他人发给这个 MAC3. 适用场景虽然只是发送流量可以使用两张卡，但对于面向客户的服务器来说：进入服务器的流量较少（请求一般比较小）从服务器出去的流量较多（响应一般很大）对于短视频服务器、流媒体、HTTP 服务器等，这种方案可以有效解决性能问题。三、Balance-tlb 故障切换流程1. 角色定义主接口：接收流量的 interface备接口：不接受流量、只发送的 interface2. 故障场景A. 备接口故障接收端不受影响发送端切换到只用主接口发送B. 主接口故障发送端切换到只使用备接口发送接收端流量也要切换到备接口3. 快速切换机制接收端流量的切换需要让发送流量的地方来切换。直观思路是切换 ARP，但 ARP 太慢，在 ARP 更新到发送者之前，流量会因发送到挂掉的 MAC 地址而被丢弃。更好的解决办法是让交换机来切换：发送者的流量发送给交换机，交换机再发送给服务器客户端的目标 MAC 地址不能变，但交换机转发的端口改变这与 active-backup 中讨论的 Gratuitous ARP 类似4. MAC 地址交换机制Balance-tlb 模式需要硬件支持改写 MAC 地址。切换过程需要保持主 MAC 地址总是可用，以不影响 ARP 缓存，实现快速切换：sequenceDiagram participant C as 客户端 participant SW as 交换机 participant E0 as eth0 (主: 1a:50) participant E1 as eth1 (备: 9e:fa) Note over C,E1: 正常状态 C->>SW: 发送至 MAC: 1a:50 SW->>E0: 从端口1转发 E0->>SW: 发送 (源MAC: 1a:50) E1->>SW: 发送 (源MAC: 9e:fa) Note over C,E1: 主接口故障 E0--xE0: 故障 E1->>E1: MAC交换 eth1: 1…

RDMA 技术分析
type: item
date: 2026-01-18T00:07:32+00:00
description: RDMA 技术分析一、概述1. 什么是 RDMARDMA(Remote Direct Memory Access，远程直接内存访问)是一种为了解决网络传输中服务器端数据处理延迟而产生的技术。2. 核心特性A. 传统 TCP/IP 传输数据经过网络堆栈，再经过网卡发送，接收端接收后，按照序列号组装数据。B. DMA 传输可以直接在设备和内存之间传输数据，不需要经过网络堆栈。C. RDMA 传输可以实现跨节点的 DMA 数据传输。3. 技术对比特性TCPDMARDMACPU 占用较高（通常 10-40% 以上）较低（<10%，依赖于实现）极低（通常在 1% 以下）延迟10-100 微秒数微秒（内存传输）亚微秒到单微秒级带宽效率1-10 Gbps（视网络条件而定）最高可达 100 Gbps（与总线速率相关）100-400 Gbps（依赖于 RDMA 网卡型号，如 RoCE、InfiniBand）适用场景通用网络传输本地内存或设备间数据传输高性能网络传输硬件要求无需要 DMA 控制器需要 RDMA 网卡（如 InfiniBand 或 RoCE）二、RDMA 通信过程1. 基本概念RDMA 使用队列的机制进行数据通信，其基本通信单位是 QP（Queue Pairs，队列对）。一个 QP 由一个 SQ（Send Queue，发送队列）和一个 RQ（Receive Queue，接收队列）构成。2. 通信流程graph LR A[HOST] -->|提交 WR| B[工作队列 WQ] B -->|消费 WQE| C[RDMA 硬件] C -->|产生 CQE| D[完成队列 CQ] D -->|消费 WC| A3. 详细步骤HOST 提交工作请求 WR（Work Request，工作请求），将 WR 放到工作队列 WQ(Work Queue，工作队列)RDMA 硬件消费 WQE 中的 WR，进行数据传输RDMA 硬件消费完成后，产生 CQE（Completion Queue Entry，完成队列条目），将 CQE 放入 CQ（Completion Queue，完成队列）队列中，等待 HOST 消费HOST 从 CQ 中消费 WC（Work Completion，工作完成）三、RDMA 技术实现1. InfiniBandA. 背景由 InfiniBand Trade Association（IBTA）在 1999 年提出，旨在为高性能计算（HPC）和大规模数据中心提供高带宽、低延迟的连接，主要由英特尔、NVIDIA、Mellanox（现为英伟达子公司）、IBM 等推动，广泛应用于超级计算机和企业级存储解决方案。B. 应用现状InfiniBand 已成为数据中心和 HPC 的标准之一，支持多种协议（如 RDMA 和 NVMe over Fabrics），并逐渐向 AI 和机器学习领域扩展。C. 技术特性高带宽：可达 400Gbps低延迟：微秒级支持大规模扩展具备先进的流量管理和质量服务（QoS）特性2. iWARPA. 背景由 IETF 的 RDMA Working Group 在 2000 年提出，旨在通过现有的 TCP/IP 网络实现 RDMA，主要由英特尔、Cisco、Broadcom 等公司推动，尤其在云计算和虚拟化环境中应用广泛。B. 应用现状iWARP 在企业网络中得到一定应用，尤其是在传统以太网架构下的 RDMA 需求，逐渐被市场认可，但竞争力相对较弱。C. 技术特性兼容性强：可在现有以太网基础设施上运行支持 TCP/IP 协议，降低了 RDMA 的部署门槛适用于中小型数据中心3. RoCE (RDMA over Converged Ethernet)A. 背景由 IBM 和其他公司在 2008 年提出，旨在将 RDMA 整合到以太网环境中，通过 DCB 技术实现高效的数据传输，主要由 Mellanox（现为英伟达）、Cisco、Intel 等公司推动，逐渐在数据中心和云计算环境中普及。B. 协议版本RoCE v1：以太网链路层协议RoCEv2：构筑于 UDP/IPv4 或 UDP/IPv6 协议之上，能组建更大的网络C. 技术特性相较于 InfiniBand，RoCE 的优势在于可以在现有以太网基础设施上运行，能够降低部分的硬件成本，但也很难达到 InfiniBand 成本的 50% 以下。四、Ascend 下的 RDMA1. 硬件架构Atlas 800 的 RDMA 依赖于 RoCE 网卡。一个 Board 上四个 SF216D-H 网卡，每个 SF216D-H 有两个 200GE 网卡。每个网卡连接一张 NPU 卡，用于组网。华为 Altas 800 集群组网时，通过一个外部交换机将各个 NPU 卡连接起来，组成一个参数面的网…

流媒体拥塞控制与流控技术分析
type: item
date: 2026-01-17T23:56:02+00:00
description: 流媒体拥塞控制与流控技术分析一、概述1. 背景介绍随着网络技术的快速发展，数据中心网络面临着前所未有的挑战。传统的拥塞控制机制基于 AIMD（加法增大、乘法减小）闭环反馈、ECN（显式拥塞通知）、QCN（量化拥塞通知）等技术，但这些机制在数据中心场景下存在局限性。数据中心网络本质上是主板的延伸，而非传统的尽力而为网络。2. 核心问题A. 主机与网络能力失衡高性能网卡吞吐量远超 TOR 交换机处理能力过多资源向端倾斜，导致网络侧成为瓶颈端到端时延中，拥塞排队占比过大B. 传统控制机制的局限带内闭环反馈效率低下丢包是昂贵的手段，而非目的依赖确认反馈的控制方式不直观3. 设计目标消除拥塞排队时延实现微秒级收敛保持网络传输的高吞吐和低时延二、传统拥塞控制机制分析1. 现有技术栈A. AIMD 闭环反馈基于 TCP 的传统机制依靠丢包发现拥塞收敛速度慢（毫秒级）B. ECN 和 QCN用标记代替丢包本质仍是前向带内反馈未突破带内控制的局限C. PFC（基于优先级的流量控制）用网络排队时延换主机时延本末倒置的设计可能导致 Head-of-Line Blocking2. 问题根源graph TD A[传统拥塞控制] --> B[带内闭环反馈] B --> C[依赖确认反馈] C --> D[丢包或标记] D --> E[发送端检测] E --> F[调整发送速率] F --> G[收敛慢 毫秒级]传统机制的瓶颈在于：信息反馈路径长控制决策在端点网络层被动响应三、集中式拥塞控制方案1. 核心思想A. 控制面与数据面分离数据面：分布式路由转发控制面：集中式拥塞调度控制信息通过带外通道传输B. 拥塞疏导原则哪里发生拥塞，哪里负责：发送源抑制信号调度拥塞流量疏导而非丢包2. 架构设计graph TB subgraph 数据面 S1[发送端 1] S2[发送端 2] S3[发送端 3] SW1[交换机 1] SW2[交换机 2 - 拥塞点] R1[接收端 1] R2[接收端 2] end subgraph 控制面 CTRL[集中控制器] end S1 --> SW1 S2 --> SW1 S3 --> SW1 SW1 --> SW2 SW2 --> R1 SW2 --> R2 SW2 -.拥塞检测.-> CTRL CTRL -.源抑制/重路由.-> S1 CTRL -.源抑制/重路由.-> S2 CTRL -.源抑制/重路由.-> S33. 工作原理A. 拥塞检测交换机检测队列 buildup立即通知控制器B. 控制决策控制器拥有全局视图快速决策（微秒级）选择最优疏导方案C. 流量疏导方案 1：重新选路绕过拥塞点方案 2：802.3ad 链路聚合重分配方案 3：发送端源抑制四、时延优化策略1. 慢就是快A. 数据面时延增加人为引入固定时延（如 20us）或拉长线缆提高传播时延B. 控制面快速传播以准光速传播控制信息在出让的时延内完成收敛C. 效果分析端到端时延增加 20us消除毫秒级拥塞排队P99 时延优化sequenceDiagram participant S as 发送端 participant SW as 交换机 participant C as 控制器 participant R as 接收端 S->>SW: 数据包（延迟 20us） SW->>C: 拥塞通知（光速） C->>S: 疏导指令（光速） Note over S,R: 总收敛时间 < 20us2. 快就是慢A. 激进发送的后果造成网络同步拥塞拥塞排队（毫秒级）端到端时延（微秒级）占比巨大B. 业务影响吞吐剧烈波动时延抖动严重业务稳定性下降重连需要更多时间五、技术对比分析1. 传统方案 vs 集中式方案特性传统带内反馈集中式控制控制路径端到端端到控制面到端收敛速度毫秒级微秒级拥塞处理丢包/标记疏导全局视图无有复杂度低（累积）中（集中）2. 协议适用性分析A. TCP/IP设计用于广域互联网工作在毫秒级匹配通用操作系统调度周期不适合数据中心微秒级需求B. 数据中心需求PU（Processing Unit）互联短肥网络场景微秒级时延要求需要专用协议六、实施建议1. 控制面设计A. 实现方式独立控制网络或带外控制通道保证控制信息优先传输B. 复杂度控制不比 PFC 实现更复杂先搭建跑通，后标准化循序渐进优化2. 数据面优化A. 路径多样性准备多条备选路径快速重路由能力链路聚合灵活配置B. 时延管理引入可控时延为控制面收敛留出时间权衡总时延与拥塞消除3. 协议演进A. 短期兼容现有 TCP/IP通过 Gateway 转换B. 长期设计数据中心专用协议参考 PCI/PCIe 总线设计摆脱 TCP/IP 影子七、经验总结1. 设计原则A. 简洁性正确的思路应一气呵成避免过度复杂化复杂累积往往意…

康威定律与数据中心网络架构思考
type: item
date: 2026-01-17T23:53:49+00:00
description: 康威定律与数据中心网络架构思考一、背景概述1. 传统网络架构的困境数据中心网络设计长期遵循着端网分离的原则。从电话网时代开始，甚至追溯到罗马大道时期，负责转发信息的节点与信息的源头目标始终是绝对分离的。然而，在日常生活中的便利性和效率方面，我们并未严格遵循这一原则——尽管很少为邻居转递包裹，但这种自组织的模式在技术领域却鲜有尝试。2. 无线自组织网络的启示无线自组织网络如 Ad-Hoc、Mesh 网络中，每一个通信节点都可以同时作为路由器和交换机。这种架构打破了传统网络中转发节点与终端节点的严格界限，为数据中心网络设计提供了新的思路。二、核心问题分析1. 资源利用率低下的现状在传统的解耦、分离、各司其职的方法论下，网络设备与服务器资源被严格隔离：交换机仅负责数据包转发，其大量内存资源在空闲时处于闲置状态服务器承担所有业务逻辑计算，面临内存压力时无法借用网络设备的空闲资源这种严格的角色划分导致整体资源利用率低下2. PFC 拥塞控制中的 buffer 资源问题以优先级流量控制（PFC）为例，为充分利用资源，拥塞流量在遭遇拥塞时的后备 buffer 应该是动态分配的。关键问题在于：这些 buffer 在没有拥塞时做什么？传统思路：保持闲置创新思路：作为系统内存被应用服务使用三、基于康威定律的网络架构设计1. 康威定律在网络领域的应用康威定律指出：任何组织设计的系统，其结构都将不可避免地受到该组织沟通结构的限制。简单来说，软件系统架构会和开发团队的组织架构相互呼应。将这一定律应用于网络设计：传统网络架构反映了运维团队与开发团队的严格分工打破传统分层、细腰、沙漏模型，基于业务逻辑规划拓扑抛弃以流量规划拓扑的思路，转而以业务（或应用、服务）规划拓扑2. 计算与传输的弹性调度A. 大 buffer 的双重用途当 buffer 仅作为排队缓冲区时：考虑成本因素，使用 SSD、NVMe 作为后备存储当 buffer 可用于业务逻辑计算时：仍然可以使用 DDR 内存实现计算和传输之间的弹性调度B. 统一内存调度模型核心思想是在一片大内存中，由调度算法决策：这块 buffer 用于业务内存还是用于传输 buffer这本质上是一个 yet another malloc 的实现问题。四、拓扑结构的革新1. 摆脱规则拓扑的束缚传统数据中心网络采用预定义的规则拓扑：胖树（Fat-Tree）CLOS 网络Mesh 结构这些先入为主的拓扑结构限制了网络的灵活性和效率。2. 基于业务的动态拓扑新的设计思路：没有独立的交换机、路由器所有服务器都是交换机，都是路由器基于业务逻辑规划拓扑，而非流量模式graph TB subgraph 传统架构 A1[服务器] --> S1[交换机] A2[服务器] --> S1 A3[服务器] --> S1 S1 --> S2[核心交换机] S1 --> S3[核心交换机] end subgraph 新架构 B1[服务器/路由器] <--> B2[服务器/路由器] B2 <--> B3[服务器/路由器] B3 <--> B4[服务器/路由器] B4 <--> B1 end3. 融合架构的优势融合架构在提高资源利用率方面具有显著优势：打破设备角色的严格界限实现资源的动态共享和调度提高整体资源利用效率五、技术挑战与实现路径1. 软件定义的调度算法实现弹性调度的关键在于调度算法：实时监测业务内存需求和网络 buffer 需求动态分配内存资源保证服务质量（QoS）2. 网络协议的适配现有网络协议需要适配新的架构：路由协议需要支持动态拓扑拥塞控制协议需要考虑共享内存的场景需要新的协议来支持节点角色的动态切换3. 管理和运维的变革融合架构对运维提出新的挑战：需要统一的管理平台故障定位和恢复更加复杂需要新的监控和诊断工具六、适用场景分析1. 数据中心场景康威定律指导的网络架构设计特别适用于数据中心：数据中心经理对网络有完全控制权可扩展性不是首要考虑因素性能和资源利用率更重要2. 广域网场景对于广域网，传统架构仍然适用：可扩展性永远是第一位性能需求次于可扩展性分层、解耦、胖端瘦网原则仍然有效七、总结与展望1. 核心观点融合才高尚，尽管在解耦时代显得不合时宜没有交换机，没有路由器，所有服务器都是交换机和路由器基于业务逻辑规划拓扑，而非流量模式2. 实施建议在数据中心环境中尝试融合架构从小规模试点开始，逐步推广重视调度算法的设计和优化3. 未来方向软件定义网络（SDN）技术与融合架构的结合人工智能辅助的资源调度边缘计算场景下的应用参考资料康威定律和数据中心网络 - CSDN博客