2026-06-11

今日主题

• 阿里云四层SLB回程机制
• 阿里云洛神网络虚拟化
• Git Config 配置
• 云网络基础概念
• 云网络硬件架构

新增认知

阿里云四层SLB回程机制

• DNAT 不等于断链：阿里云 CLB 四层在入方向可以只改目的地址，
  把 ClientIP:CPort -> VIP:VPort 转成 ClientIP:CPort -> RSIP:RSPort，
  因此后端能直接看到真实客户端 IP。TCP 仍能成立的前提是回方向必须再经过 CLB/LVS，
  由它把响应包源地址从 RSIP:RSPort 反向改回 VIP:VPort。

• 回程依赖负载均衡：RS 发出的响应包虽然内核视角是 RSIP:RSPort -> ClientIP:CPort，
  但阿里云官方架构说明后端响应会通过内网返回给负载均衡，并遵循“流量从哪里进来，就从哪里出去”。这意味着回包路径由 CLB/VPC 内网转发体系承接，
  而不是 ECS 直接公网回客户端。

• 不是 DR TUN：典型 LVS-DR 或 LVS-TUN 下，RS 通常仍会看到目标地址为 VIP，或需要本机绑定 VIP/隧道解封装；
  而阿里云故障图和旧 FAQ 表明到达 ECS 前已经变成 DIP:DPORT。关键前提是后端看到的是 RSIP 而不是 VIP，
  所以更接近定制 LVS NAT/DNAT + 回程反向 NAT。

• 四元组会折叠：两个不同 VIP 如果转发到同一 RS 的同一后端端口，并且客户端源 IP 与源端口相同，
  入方向 DNAT 后都会变成同一个 TCP 标识：CIP:CPORT -> DIP:DPORT。后端协议栈无法区分原始 VIP，
  TIME_WAIT 或握手状态就可能互相干扰。

阿里云洛神网络虚拟化

• "vSwitch"一词两义：阿里云控制台的 vSwitch 是子网（等同 AWS Subnet，一个 CIDR 段），
  宿主机上的 vSwitch 是虚拟交换机软件（VTEP、ARP proxy、VXLAN 封装都由它完成）。两者共享一个名字但分属完全不同的抽象层级——
  控制台里你创建的是逻辑子网，底层软件才是真正转发数据包的虚拟交换机。

• NFV 的物理共享、逻辑隔离：NFV 网元（SLB、NAT 等）跑在通用 ECS 资源池上，物理层面多个租户的实例共享同一台宿主机，
  但逻辑层面每个实例是独立的——各自绑定到对应 VPC 的 VNI 下。VTEP 是宿主机级别的，不是每个租户一个 VTEP，
  租户隔离靠 VXLAN 头里的 VNI 区分。

• 分布式网关通过 ARP proxy + 虚拟 MAC 实现：VPC 子网网关（阿里云固定 .253）不是真实物理设备，ECS 发出 ARP 请求时，
  本机 vSwitch 在本地用虚拟 MAC（如 ee:ff:ff:ff:ff:ff）代理响应。VM 以为自己在跟一台真实网关通信，
  实际上每个包都在本地 vSwitch 走完路由后直接 VXLAN 封装发到目标宿主机，完全绕过集中网关。

• 快慢路径分离是 vSwitch 的性能核心：vSwitch 内部有两条路径——快路径是数据面查 cache 直接转发（稳态，高性能），
  慢路径是控制面参与学习建表（冷启动，有开销）。首次通信因为自学习协议需要查询目标 VM 位置表，会走慢路径产生额外延迟；一旦位置写入 cache，
  后续所有包走快路径，不再经过控制面。

• AWS Subnet vs 阿里云 vSwitch 的设计哲学差异：AWS Subnet 更贴近物理网络思维——
  有 public/private 身份、子网级 NACL、网关在 .1，像传统机房 VLAN 规划。阿里云刻意剥离这些概念，
  vSwitch 只管 CIDR 划分，公网靠 EIP/NAT 网关、安全策略只做实例级安全组，更"原子化"。两边无优劣，是对云网络抽象的不同取舍。

• veth pair 是 VM 接入虚拟网络的关键机制：veth 成对出现，
  guest 端放进 VM 的 network namespace（VM 只看到 eth0），host 端插在宿主机 bridge 上连接 VXLAN 隧道设备。
  VM 完全不知道 VXLAN 层的存在，只看到一张普通网卡，封装/解封装在 host 端透明完成。

• 控制面按需下发而非全量推送配置：一个子网的 VM 分布在多台宿主机上，每台宿主机的 vSwitch 只需要知道本机 VM 信息 + 按需学习目标位置。
  这是自学习协议 + 位置表缓存策略——控制面不会把全量子网配置推到每台宿主机，只在 VM 创建/迁移时按需同步，避免每次变更导致全集群广播更新的开销。

Git Config 配置

• includeIf 位置决定覆盖优先级：git config 采用"后值覆盖前值"规则，includeIf 内联处理——
  被包含文件的配置在 includeIf 语句所在位置生效。因此如果全局段（如 [core] hooksPath）写在 includeIf 之后，
  它的值会覆盖被包含文件中同名键的值。正确做法是将 includeIf 放在 ~/.gitconfig 末尾，确保被包含配置拥有最终覆盖权。
  此前误以为 includeIf 天然具有高优先级，实际验证发现顺序才是决定因素。

云网络基础概念

• 网元是网络功能最小单元：网元（Network Element）是网络管理中可监视和管理的最小逻辑单元。在云网络中，
  VPC、SLB、NAT、PrivateLink 等产品每个都是一个网元，本质是软件定义的虚拟网络功能。波塞冬平台管理的"网关、网元、交换机"中，
  网元特指运行虚拟网络功能的设备节点。

• AVS = Apsara vSwitch（飞天虚拟交换机）：AVS 是部署在每台物理服务器上的软件网元，
  负责将该宿主机上的 ECS/裸金属接入 VPC 虚拟网络。所有 VM 的进出报文先经过 AVS，由它完成 VXLAN 封装、安全组、路由表查表等。
  洛神架构的核心就是 AVS（主机侧）+ 各种网关网元（网络侧）两大类。

• PIP = Private IP（私网IP）：在 VPC 网络配置中，vSwitch 需要知道每个 VM 的 PIP 和所属 VPC ID，
  才能正确进行 VXLAN 封裝和二层转发。PIP 是云网络 Overlay 通信的基础标识。

云网络硬件架构

• x86 vs Tofino 网关的本质区别：x86 vGateway 跑在通用 CPU 上做软件转发，灵活但性能受 CPU 限制；
  Tofino vGateway 用可编程交换 ASIC 做硬件线速转发（Tbps 级），延迟极低但受芯片流水线资源约束。
  两者是同一逻辑功能（vGateway）的两种硬件载体，云网络通常混用——大象流走 Tofino 快车道，控制面/异常路径走 x86。

• Tofino 是交换机芯片而非 PCIe 卡：Tofino 是一颗独立的交换 ASIC，焊接在交换机主板上，整机前面板有 32~64 个高速以太网口。
  它与 x86 服务器是两台独立设备，通过网线连接。PCIe 插卡形态的可编程网络设备是 SmartNIC/DPU（如 NVIDIA BlueField），
  性能与端口密度与 Tofino 交换机不在一个量级。

• Tofino 可通过 P4 语言编程：P4 是领域专用语言，描述报文如何解析、匹配、执行动作，编译后刷入 Tofino 芯片。与普通固定功能交换机不同，
  Tofino 允许自定义数据面行为——如定制网关、自定义隧道封装、新网络协议，均硬件线速运行。P4 编译器 → 配置文件 → 加载到 Tofino 流水线。

• vGateway 是逻辑功能，Tofino/x86 是硬件载体：同一个网关功能（转发、路由、封装/解封装）既可以部署在 x86 服务器上，
  也可以部署在 Tofino 交换机上，两者跑的是同一套逻辑。波塞冬控制器需要同时兼容这两种异构设备，把同一份配置分别翻译下发——
  这就是论文中"异构设备配置下发"挑战的来源。