【网络工程】网络技术展望：SmartNIC、CXL 与内核旁路的未来

# 传统网卡（NIC）只做两件事：
# 1. 把网络帧从线缆搬到主机内存（DMA）
# 2. 把主机内存中的帧发送到线缆

# 所有协议处理都由主机 CPU 完成：
# - TCP/IP 协议栈
# - 虚拟交换机（OVS）
# - 防火墙规则（iptables/nftables）
# - 加密/解密（TLS/IPSec）
# - 负载均衡

# 在 100GbE 时代，这些处理消耗了多少 CPU？
# 粗略估算：
# - 100Gbps 线速 ≈ 148 Mpps（最小包）
# - 每个包的内核处理 ≈ 1000-3000 ns
# - 需要 ~10 个 CPU 核心 仅用于基本网络处理
# - 加上 OVS + iptables + TLS，可能需要 20+ 核心

# SmartNIC 的核心价值：
# 把这些网络处理从主机 CPU 卸载到网卡上的专用硬件
# 主机 CPU 只处理应用逻辑

# NVIDIA BlueField-3 DPU 规格
# - 16 个 ARM Cortex-A78 核心
# - 400GbE 网络接口
# - 硬件加速器：
#   - 加密引擎（IPSec/TLS）
#   - 正则表达式引擎（DPI）
#   - 压缩/解压引擎
#   - OVS 卸载引擎

# BlueField DPU 的典型部署模式：
#
# ┌─────────────────────┐
# │     主机 CPU         │  ← 只运行应用
# │  ┌───────────────┐  │
# │  │  App  │  App  │  │
# │  └───────┴───────┘  │
# │         │ PCIe       │
# │  ┌──────┴──────────┐│
# │  │   BlueField DPU  ││  ← 运行所有基础设施
# │  │  ┌────────────┐ ││
# │  │  │ OVS 卸载   │ ││
# │  │  │ IPSec 加速 │ ││
# │  │  │ 存储虚拟化 │ ││
# │  │  │ 网络安全   │ ││
# │  │  └────────────┘ ││
# │  │   ARM Linux     ││
# │  └────────────────┘│
# │         │ 400GbE    │
# └─────────┼──────────┘
#           │
#       网络交换机

# DPU 的意义：
# 1. 性能——硬件加速的网络/存储处理
# 2. 隔离——基础设施与租户完全隔离
# 3. 安全——租户无法绕过安全策略
# 4. 可编程——运行标准 Linux 和容器

# 常见的 SmartNIC 卸载场景：

# 1. OVS 卸载（Open vSwitch Offload）
# 虚拟交换机的流表匹配和转发卸载到网卡
ovs-vsctl set Open_vSwitch . other_config:hw-offload=true
ovs-vsctl set Open_vSwitch . other_config:tc-policy=skip_hw
# 效果：OVS 吞吐从 ~40Gbps 提升到线速 100Gbps+
# CPU 消耗从多核降到接近零

# 2. IPSec 加速
# 加密/解密由网卡硬件完成
# 配置 strongSwan 使用硬件加速
# ipsec.conf:
# conn tunnel
#   ...
#   hw_offload = yes
# 效果：IPSec 吞吐从 ~20Gbps 提升到 100Gbps+

# 3. TLS 卸载（kTLS + NIC offload）
# Linux 5.x 支持 kTLS，部分 NIC 支持硬件 TLS
sysctl -w net.ipv4.tcp_tls_offload=1
# 应用使用 kTLS API，内核将加解密卸载到网卡

# 4. VXLAN/Geneve 封装卸载
# 隧道封装/解封装由网卡完成
ethtool -k eth0 | grep offload
# tx-udp_tnl-segmentation: on
# tx-udp_tnl-csum-segmentation: on

# AWS Nitro 架构的启示：
# Nitro 不只是 SmartNIC——它是一个完整的卸载架构

# 传统虚拟化：
# 主机 CPU 同时处理：虚拟机管理 + 虚拟网络 + 虚拟存储 + 安全
# → 大量 CPU 被"税"掉，客户可用资源少

# Nitro 架构：
# Nitro Card（DPU）处理：虚拟网络 + EBS 存储 + 安全监控
# 主机 CPU 几乎 100% 给客户虚拟机
# → 这就是为什么 AWS 能提供"裸金属性能"的虚拟机

# 工程影响：
# - 网卡不再是"哑管道"，而是基础设施的核心
# - 云厂商的核心竞争力之一是自研 DPU
# - 未来每台服务器可能都有 DPU

# CXL 的三种协议：

# CXL.io  — 基于 PCIe，设备发现和管理（等价于 PCIe）
# CXL.cache — 设备访问主机内存（保持缓存一致性）
# CXL.mem  — 主机访问设备内存（内存扩展）

# CXL 设备类型：
# Type 1: 加速器（只用 CXL.io + CXL.cache）
#          例：SmartNIC、GPU
# Type 2: 带内存的加速器（三种协议都用）
#          例：带 HBM 的 GPU、FPGA
# Type 3: 内存扩展设备（CXL.io + CXL.mem）
#          例：CXL 内存模块

# CXL 对网络工程的影响：
# 1. SmartNIC 可以直接访问主机内存——零拷贝
# 2. 多台服务器可以共享 CXL 内存池
# 3. 内存扩展降低了大内存应用对网络缓存的依赖

# 影响 1：内存池化——减少网络流量

# 传统架构：
# 服务器 A 需要数据 → 通过网络从服务器 B 读取 → 数据在网络上传输
# 延迟：10-100 μs（取决于网络拓扑）

# CXL 内存池架构：
# 服务器 A 需要数据 → 通过 CXL 从共享内存池读取 → 数据不经过网络
# 延迟：200-500 ns（CXL 延迟）

# 这意味着：
# - 部分原本需要网络传输的数据访问变成了内存访问
# - 分布式缓存（Redis/Memcached）的部分场景可以被 CXL 内存池替代
# - 数据库的远程页面读取可能不再需要网络

# 影响 2：CXL 交换机——内存网络
#
# ┌──────┐  ┌──────┐  ┌──────┐
# │ CPU 1│  │ CPU 2│  │ CPU 3│
# └──┬───┘  └──┬───┘  └──┬───┘
#    │ CXL     │ CXL     │ CXL
# ┌──┴─────────┴─────────┴──┐
# │       CXL Switch         │
# └──┬─────────┬─────────┬──┘
#    │         │         │
# ┌──┴───┐ ┌──┴───┐ ┌──┴───┐
# │Mem 1 │ │Mem 2 │ │Mem 3 │
# └──────┘ └──────┘ └──────┘
# 任何 CPU 可以访问任何内存模块

# RDMA 和 CXL 都实现了"远程内存访问"，但层次不同：

# RDMA（Remote Direct Memory Access）
# - 工作在网络层（以太网/InfiniBand）
# - 延迟：1-5 μs
# - 带宽：100-400 Gbps
# - 距离：机架到数据中心级
# - 需要特殊网卡（RDMA NIC）

# CXL
# - 工作在 PCIe 物理层
# - 延迟：200-500 ns
# - 带宽：PCIe 5.0 = 128 GB/s per x16
# - 距离：机箱到机架级（CXL 3.0 支持交换）
# - 需要 CXL 控制器

# 互补关系：
# - CXL 用于近距离、超低延迟的内存共享
# - RDMA 用于远距离、跨机架的数据传输
# - 未来可能融合：CXL over Fabric

# 对工程师的影响：
# - 分布式系统的"远程"和"本地"的边界在模糊
# - 某些原本需要网络协议的场景可以用内存语义替代
# - 系统架构需要重新考虑数据放置策略

// io_uring 网络操作——零系统调用的 TCP 服务器

#include <liburing.h>
#include <netinet/in.h>
#include <string.h>

#define QUEUE_DEPTH 256
#define BUF_SIZE 4096

enum event_type {
    EVENT_ACCEPT,
    EVENT_READ,
    EVENT_WRITE,
};

struct conn_info {
    int fd;
    enum event_type type;
    char buf[BUF_SIZE];
};

int main() {
    struct io_uring ring;
    io_uring_queue_init(QUEUE_DEPTH, &ring, 0);

    // 创建监听 socket
    int listen_fd = socket(AF_INET, SOCK_STREAM, 0);
    struct sockaddr_in addr = {
        .sin_family = AF_INET,
        .sin_port = htons(8080),
        .sin_addr.s_addr = INADDR_ANY,
    };
    bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr));
    listen(listen_fd, 128);

    // 提交第一个 accept
    struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
    struct conn_info *info = malloc(sizeof(*info));
    info->fd = listen_fd;
    info->type = EVENT_ACCEPT;
    io_uring_prep_accept(sqe, listen_fd, NULL, NULL, 0);
    io_uring_sqe_set_data(sqe, info);
    io_uring_submit(&ring);

    // 事件循环——可以做到 零系统调用
    while (1) {
        struct io_uring_cqe *cqe;
        io_uring_wait_cqe(&ring, &cqe);

        struct conn_info *conn = io_uring_cqe_get_data(cqe);
        int result = cqe->res;

        switch (conn->type) {
        case EVENT_ACCEPT: {
            // 新连接
            int client_fd = result;
            // 提交 read
            struct conn_info *read_info = malloc(sizeof(*read_info));
            read_info->fd = client_fd;
            read_info->type = EVENT_READ;
            sqe = io_uring_get_sqe(&ring);
            io_uring_prep_recv(sqe, client_fd, read_info->buf,
                              BUF_SIZE, 0);
            io_uring_sqe_set_data(sqe, read_info);
            // 继续 accept
            sqe = io_uring_get_sqe(&ring);
            io_uring_prep_accept(sqe, listen_fd, NULL, NULL, 0);
            io_uring_sqe_set_data(sqe, conn);
            break;
        }
        case EVENT_READ: {
            if (result <= 0) {
                close(conn->fd);
                free(conn);
                break;
            }
            // 提交 write（echo）
            conn->type = EVENT_WRITE;
            sqe = io_uring_get_sqe(&ring);
            io_uring_prep_send(sqe, conn->fd, conn->buf,
                              result, 0);
            io_uring_sqe_set_data(sqe, conn);
            break;
        }
        case EVENT_WRITE: {
            // 继续 read
            conn->type = EVENT_READ;
            sqe = io_uring_get_sqe(&ring);
            io_uring_prep_recv(sqe, conn->fd, conn->buf,
                              BUF_SIZE, 0);
            io_uring_sqe_set_data(sqe, conn);
            break;
        }
        }
        io_uring_cqe_seen(&ring, cqe);
        io_uring_submit(&ring);
    }
}

# io_uring 相比 epoll 的网络性能优势：

# 1. 零系统调用
# epoll: epoll_wait() → recv() → send() = 3 次系统调用/请求
# io_uring: 批量提交，可以做到 0 次系统调用
# 通过 IORING_SETUP_SQPOLL，内核线程轮询 SQ
# 应用只需写共享内存，无需 syscall

# 2. 固定缓冲区（Registered Buffers）
io_uring_register_buffers(&ring, buffers, nr_buffers);
# 预注册缓冲区，避免每次 I/O 的页表查找

# 3. 固定文件描述符
io_uring_register_files(&ring, fds, nr_fds);
# 预注册 fd，避免每次 I/O 的 fd 查找

# 4. 多射操作（Multishot）
# 一次提交，多次完成——适合 accept 和 recv
io_uring_prep_multishot_accept(sqe, listen_fd, NULL, NULL, 0);
# 提交一次 accept，每次有新连接都会产生 CQE
# 无需重复提交

# 5. 零拷贝发送
io_uring_prep_send_zc(sqe, fd, buf, len, 0, 0);
# 使用 MSG_ZEROCOPY 语义，避免数据拷贝

# 6. 提供的缓冲区（Provided Buffers）
# 内核从预注册的缓冲区池中自动选择缓冲区
# 适合大量短连接场景——不需要为每个连接预分配缓冲区

# io_uring 的局限性：

# 1. 内核版本要求
# 基础网络支持：5.5+
# multishot accept：5.19+
# send_zc：6.0+
# 完整特性集：6.1+
# 生产推荐：6.1+

# 2. 安全考量
# io_uring 在容器中默认被禁用（安全限制）
# Docker: --security-opt seccomp=unconfined
# 或自定义 seccomp profile 允许 io_uring syscall

# 3. 编程复杂度
# 比 epoll 更复杂——异步编程模型
# 错误处理更难——CQE 中的错误码需要仔细处理
# 内存管理更复杂——缓冲区生命周期

# 4. 调试困难
# 异步操作的调试比同步更难
# strace 不太适用（SQPOLL 模式）
# 需要 io_uring 专用的调试工具

# io_uring 正在成为 Linux 的统一异步 I/O 框架

# 当前支持的网络操作：
# - socket / bind / listen / connect
# - accept (multishot)
# - recv / send (零拷贝)
# - recvmsg / sendmsg
# - read / write (on sockets)
# - poll (multishot)
# - close / shutdown

# 正在开发/规划的特性：
# 1. io_uring 网络代理——在内核中完成简单的代理转发
# 2. 更好的 TLS 集成——kTLS + io_uring
# 3. QUIC 支持——用户态 QUIC 的 io_uring 后端
# 4. 网络调度——io_uring 的 SQ 优先级

# 生态系统：
# - Rust: tokio-uring（实验性）
# - Go: 讨论中
# - Java: 讨论中（Project Loom 团队关注）
# - C++: liburing 包装

# Kernel Bypass 技术的发展历程：

# 第一代：专用硬件（2000s）
# - InfiniBand RDMA
# - 专用网络，不走 TCP/IP
# - 高性能计算（HPC）领域

# 第二代：用户态驱动（2010s）
# - DPDK（Intel，2010）
# - 用户态轮询模式驱动（PMD）
# - 绕过内核协议栈
# - NFV/防火墙/负载均衡

# 第三代：内核协作（2015s）
# - XDP/eBPF（2016）
# - AF_XDP（2018）
# - 在内核最早的路径上处理包
# - 保持内核可见性

# 第四代：统一框架（2020s）
# - io_uring + 零拷贝
# - CXL + SmartNIC
# - 内核与用户态的协作而非对抗

# 技术选型决策树：

# Q1: 你的流量需要 TCP/IP 协议栈吗？
#   YES → Q2
#   NO  → DPDK（自己实现协议栈或用 F-Stack）

# Q2: 你需要修改每个包的处理逻辑吗？
#   YES → Q3
#   NO  → 标准 Linux 内核栈 + io_uring

# Q3: 你需要线速处理（>40Gbps）吗？
#   YES → SmartNIC/DPU 卸载 或 XDP
#   NO  → eBPF/TC

# Q4: 你在容器/K8s 环境吗？
#   YES → Cilium（eBPF）
#   NO  → 看具体场景

# Q5: 你需要极低延迟（<10μs）吗？
#   YES → RDMA 或 DPDK
#   NO  → XDP/AF_XDP

# 这些技术不是互相替代，而是在融合：

# 融合 1: XDP + io_uring
# XDP 在最早的路径上过滤/预处理包
# io_uring 在用户态高效处理应用逻辑
# 组合：XDP 丢弃攻击流量 + io_uring 处理合法流量

# 融合 2: SmartNIC + eBPF
# SmartNIC 卸载固定功能（OVS/IPSec/VXLAN）
# eBPF 在主机端处理动态策略
# 组合：SmartNIC 做基础转发 + eBPF 做精细控制

# 融合 3: CXL + RDMA
# CXL 用于机架内超低延迟内存访问
# RDMA 用于跨机架高带宽数据传输
# 组合：近端用 CXL + 远端用 RDMA

# 融合 4: DPDK + io_uring
# DPDK 处理数据面（包处理）
# io_uring 处理控制面（配置/日志/管理）
# 组合：DPDK 做快路径 + io_uring 做慢路径

# 传统网络监控的局限：
# - 基于采样（sFlow/NetFlow）——可能错过异常
# - 基于日志（访问日志）——滞后，不含内核信息
# - 基于探针（SNMP）——粒度粗，频率低

# eBPF 可观测性的优势：
# - 内核级别的全量数据
# - 纳秒级精度
# - 零采样丢失
# - 动态加载，无需重启

# 工具生态：
# 1. Cilium Hubble——K8s 网络可观测性
#    - 每个包的流向追踪
#    - DNS 请求日志
#    - HTTP/gRPC 层指标

# 2. Pixie——自动化应用可观测性
#    - 零配置的请求追踪
#    - 自动协议检测（HTTP/MySQL/gRPC）
#    - 火焰图和延迟直方图

# 3. Tetragon——安全可观测性
#    - 进程级别的网络连接追踪
#    - 系统调用审计
#    - 安全策略执行

# 网络数字孪生（Network Digital Twin）——用软件模拟整个网络

# 概念：
# 1. 采集真实网络的拓扑、配置和流量数据
# 2. 在软件中构建精确的网络模型
# 3. 在模型上测试变更（before 在真实网络上执行）
# 4. 预测网络行为（故障影响、容量规划）

# 工具：
# - Batfish：网络配置分析和模拟
# - Forward Networks：企业级网络数字孪生
# - GNS3/EVE-NG：网络拓扑模拟

# Batfish 示例——分析配置变更的影响
# 上传网络配置
batfish_client upload_configurations \
    --container network1 \
    --testrig current_config \
    --path ./configs/

# 查询路由表
batfish_client query \
    --question routes \
    --parameters '{"nodes": "core-router-1"}'

# 测试 ACL 变更的影响
batfish_client query \
    --question "searchFilters" \
    --parameters '{
        "action": "deny",
        "headers": {"srcIps": "10.0.0.0/8"}
    }'

# QUIC 不只是 HTTP/3 的传输层——它正在成为通用传输协议

# 1. WebTransport over QUIC
# 浏览器中的低延迟双向通信
# 替代 WebSocket，支持不可靠数据报

# 2. MASQUE（Multiplexed Application Substrate over QUIC Encryption）
# 在 QUIC 上构建代理协议
# 替代传统 VPN 和 HTTP CONNECT

# 3. QUIC Multipath
# 同时使用多条路径（WiFi + 4G）
# RFC 9443，正在标准化

# 4. QUIC over Satellite
# 卫星网络的高延迟场景
# QUIC 的 0-RTT 和连接迁移特别有价值

# 5. DNS over QUIC (DoQ)
# RFC 9250，减少 DNS 查询延迟
# 比 DoH 更轻量

# 1. Ultra Ethernet
# Ultra Ethernet Consortium（UEC）——2023 年成立
# 目标：为 AI/ML 工作负载优化以太网
# 特点：
# - 多路径传输
# - 自适应路由
# - 拥塞控制优化（适合 all-to-all 流量模式）
# - 无序交付支持

# 2. CXL over Fabric
# 将 CXL 扩展到机架级别
# 通过以太网/光纤承载 CXL 协议
# 实现远距离内存共享

# 3. NVMe over Fabrics
# 存储网络正在从专用协议（FC/iSCSI）迁移到以太网
# RDMA + NVMe = 高性能远程存储
# TCP + NVMe = 部署简单的远程存储

# AI/ML 对网络的新需求：
# - All-to-all 通信模式（不是传统的 client-server）
# - 极低延迟（梯度同步不能等）
# - 极高带宽（模型参数传输）
# - 无阻塞网络（任何拥塞都会拖慢整个训练）

# 1. 掌握 eBPF/XDP
# 这是当前最有价值的网络新技能
# 无论你做云原生、性能优化还是安全
# 推荐路径：bpftrace → bcc → libbpf → Cilium

# 2. 关注 io_uring
# 如果你开发高性能网络服务
# io_uring 将成为 Linux 网络 I/O 的未来
# 推荐：先理解原理，等生态成熟后采用

# 3. 了解 SmartNIC/DPU
# 如果你在云基础设施领域
# DPU 是云厂商的核心竞争力
# 推荐：了解 NVIDIA DOCA SDK 或 AMD Pensando

# 1. CXL 生态
# 当 CXL 3.0 设备普及后
# 分布式系统的架构可能需要重新思考
# 某些"远程"访问变成"本地"内存访问

# 2. AI 网络
# AI/ML 工作负载对网络有全新的需求
# 集合通信（AllReduce/AllGather）
# 需要专门的网络拓扑和协议

# 3. 可编程网络
# P4 + eBPF + SmartNIC 的融合
# 网络工程师需要编程能力
# "配置网络"到"编程网络"的转变

# 趋势 1：硬件卸载——从 CPU 到专用硬件
# 网络处理不再是"CPU 的事"
# SmartNIC/DPU 承担基础设施网络处理
# CPU 专注于应用逻辑

# 趋势 2：可编程性——从配置到编程
# 网络设备不再是"黑盒"
# P4 让交换机可编程
# eBPF 让内核网络栈可编程
# 网络工程师需要编程能力

# 趋势 3：融合——内核与用户态的协作
# 不再是"绕过内核 vs 走内核"的二选一
# XDP + io_uring + SmartNIC 协作
# 每层做最适合的事情

# 趋势 4：内存级互联——打破服务器边界
# CXL 让内存跨服务器共享
# 某些网络通信变成内存访问
# 分布式系统的边界在模糊

# 趋势 5：AI 驱动——新的流量模式
# AI/ML 训练需要全新的网络设计
# 集合通信替代 RPC 模式
# 网络拓扑和协议都需要适配