【网络工程】eBPF 可编程网络：从包过滤到流量工程

# XDP 有三种执行模式：

# 1. Native XDP（原生模式）
# eBPF 程序在网卡驱动中执行
# 性能最高——包不经过内核网络栈
# 需要网卡驱动支持
# 支持的网卡：Intel (ixgbe, i40e, ice), Mellanox (mlx5), etc.

# 2. Offloaded XDP（硬件卸载）
# eBPF 程序在网卡硬件（SmartNIC）上执行
# 性能最高——CPU 零开销
# 支持的网卡：Netronome nfp

# 3. Generic XDP（通用模式）
# eBPF 程序在内核网络栈中执行
# 性能最低——但所有网卡都支持
# 适合开发和测试

# 检查网卡是否支持 Native XDP
ethtool -i eth0 | grep driver
# ixgbe, i40e, mlx5_core 等支持 Native XDP

# 加载 XDP 程序
ip link set dev eth0 xdp obj xdp_prog.o sec xdp

# 查看已加载的 XDP 程序
ip link show dev eth0
# eth0: ... xdp/id:42 ...

# 卸载 XDP 程序
ip link set dev eth0 xdp off

// XDP 程序返回值决定包的命运

// XDP_DROP   — 丢弃包（DDoS 防御）
// XDP_PASS   — 正常处理（交给内核网络栈）
// XDP_TX     — 从同一网卡发回（反射）
// XDP_REDIRECT — 重定向到其他网卡或 AF_XDP
// XDP_ABORTED — 错误（触发 trace 点）

// 简单的 XDP 防火墙示例
SEC("xdp")
int xdp_firewall(struct xdp_md *ctx) {
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;
    
    // 解析以太网头
    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end)
        return XDP_PASS;
    
    // 只处理 IP 包
    if (eth->h_proto != htons(ETH_P_IP))
        return XDP_PASS;
    
    // 解析 IP 头
    struct iphdr *ip = (void *)(eth + 1);
    if ((void *)(ip + 1) > data_end)
        return XDP_PASS;
    
    // 查找黑名单 Map
    __u32 src_ip = ip->saddr;
    if (bpf_map_lookup_elem(&blacklist, &src_ip))
        return XDP_DROP;
    
    return XDP_PASS;
}

# XDP 的包处理能力（单核）：

# 操作            | 性能 (Mpps)  | 说明
# XDP_DROP        | ~24 Mpps     | 最快——驱动层直接丢弃
# XDP_TX          | ~12 Mpps     | 从同一网卡反射
# XDP_REDIRECT    | ~10 Mpps     | 重定向到其他设备
# XDP_PASS        | ~5 Mpps      | 交给内核处理
# iptables DROP   | ~3 Mpps      | 作为对比

# 测试工具
# 使用 xdp-bench（bpf-examples 仓库）
xdp-bench drop -d eth0          # 测试 XDP_DROP
xdp-bench redirect -d eth0 -r eth1  # 测试 XDP_REDIRECT

# TC（Traffic Control）是另一个重要的 eBPF 网络钩子
# 比 XDP 晚执行，但可以访问更多上下文信息

# TC vs XDP：
# XDP：在驱动层，只能看到原始帧，不能修改 skb 元数据
# TC：在内核网络栈，可以访问 skb 所有字段

# 加载 TC eBPF 程序
tc qdisc add dev eth0 clsact
tc filter add dev eth0 ingress bpf da obj tc_prog.o sec tc
tc filter add dev eth0 egress bpf da obj tc_prog.o sec tc_egress

# 查看已加载的程序
tc filter show dev eth0 ingress
tc filter show dev eth0 egress

// TC 程序可以做更复杂的包处理

SEC("tc")
int tc_process(struct __sk_buff *skb) {
    void *data = (void *)(long)skb->data;
    void *data_end = (void *)(long)skb->data_end;
    
    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end)
        return TC_ACT_OK;
    
    if (eth->h_proto != htons(ETH_P_IP))
        return TC_ACT_OK;
    
    struct iphdr *ip = (void *)(eth + 1);
    if ((void *)(ip + 1) > data_end)
        return TC_ACT_OK;
    
    // TC 可以修改包内容
    // 例如：修改 DSCP 标记
    __u8 new_tos = 0xb8;  // EF (DSCP 46)
    bpf_skb_store_bytes(skb,
        offsetof(struct iphdr, tos) + sizeof(struct ethhdr),
        &new_tos, sizeof(new_tos), 0);
    
    // TC 动作：
    // TC_ACT_OK      — 正常处理
    // TC_ACT_SHOT    — 丢弃
    // TC_ACT_REDIRECT — 重定向
    // TC_ACT_PIPE    — 继续下一个 filter
    
    return TC_ACT_OK;
}

// 定义一个 IP 黑名单 Map
struct {
    __uint(type, BPF_MAP_TYPE_LPM_TRIE);
    __uint(max_entries, 100000);
    __uint(key_size, 8);     // 4 bytes prefix_len + 4 bytes IP
    __uint(value_size, 4);   // action
    __uint(map_flags, BPF_F_NO_PREALLOC);
} ip_blacklist SEC(".maps");

// 在用户态更新 Map
// bpftool map update name ip_blacklist \
//     key 32 0 0 0 10 0 1 100 \     # /32 + 10.0.1.100
//     value 1 0 0 0                  # action=1 (drop)

# bpftool 管理 Map

# 列出所有 Map
bpftool map list

# 查看 Map 内容
bpftool map dump name ip_blacklist

# 添加条目
bpftool map update name ip_blacklist \
    key hex 20 00 00 00 0a 00 01 64 \
    value hex 01 00 00 00

# 删除条目
bpftool map delete name ip_blacklist \
    key hex 20 00 00 00 0a 00 01 64

# 查看 Map 统计
bpftool map show name ip_blacklist

# Cilium 安装
helm install cilium cilium/cilium --version 1.15 \
    --namespace kube-system \
    --set kubeProxyReplacement=true \
    --set k8sServiceHost=<API_SERVER_IP> \
    --set k8sServicePort=6443

# 验证 eBPF 数据平面
cilium status
# KubeProxyReplacement: True

# 查看 eBPF 程序
cilium bpf endpoint list

# 查看 CT 表
cilium bpf ct list global

# 查看 NAT 表
cilium bpf nat list

# Katran 是 Facebook 开源的基于 XDP 的 L4 负载均衡器
# 处理能力：单核 10Mpps+

# 架构：
# 1. XDP 程序在网卡驱动层处理包
# 2. 使用一致性哈希选择后端
# 3. 通过 IP-in-IP 封装转发到后端
# 4. 后端通过 DSR 直接回复客户端

# 优势：
# - 不需要专用硬件
# - 性能接近硬件 LB
# - 可以在任意服务器上运行

# 与传统 LVS/IPVS 对比：
# LVS：内核 Netfilter 层，~3 Mpps
# Katran：XDP 层，~10 Mpps（3x 提升）

# Cilium 也提供基于 XDP 的 L4 负载均衡

# 启用 XDP L4LB
helm upgrade cilium cilium/cilium \
    --set loadBalancer.mode=dsr \
    --set loadBalancer.acceleration=native \
    --set devices=eth0

# DSR 模式——Direct Server Return
# 请求：客户端 → LB (XDP) → 后端
# 响应：后端 → 客户端（绕过 LB）
# 优势：LB 只处理入站流量，吞吐量翻倍

# Cilium Hubble——基于 eBPF 的网络可观测性

# 启用 Hubble
helm upgrade cilium cilium/cilium \
    --set hubble.enabled=true \
    --set hubble.relay.enabled=true \
    --set hubble.ui.enabled=true

# 观察实时流量
hubble observe --namespace default

# 按类型过滤
hubble observe --type drop          # 丢包
hubble observe --type l7 --protocol http  # HTTP 流量
hubble observe --verdict DROPPED    # 被策略拒绝的流量

# 导出 Prometheus 指标
# hubble_flows_processed_total
# hubble_drop_total{reason="POLICY_DENIED"}
# hubble_http_requests_total{method="GET",protocol="HTTP/1.1"}

# bpftrace 可以在网络路径的任意位置插入探针

# 追踪 TCP 重传
bpftrace -e 'kprobe:tcp_retransmit_skb {
    $sk = (struct sock *)arg0;
    $inet = (struct inet_sock *)$sk;
    printf("retrans: %s:%d -> %s:%d\n",
        ntop($inet->inet_saddr), $inet->inet_sport,
        ntop($inet->inet_daddr), $inet->inet_dport);
}'

# 追踪 TCP 连接建立延迟
bpftrace -e 'kprobe:tcp_v4_connect {
    @start[tid] = nsecs;
}
kretprobe:tcp_v4_connect /@start[tid]/ {
    printf("connect latency: %d us\n", (nsecs - @start[tid]) / 1000);
    delete(@start[tid]);
}'

# 追踪 XDP 丢包
bpftrace -e 'tracepoint:xdp:xdp_bulk_tx {
    @drops[args->action] = count();
}'

# 追踪 socket 缓冲区使用
bpftrace -e 'kprobe:tcp_sendmsg {
    $sk = (struct sock *)arg0;
    printf("sk_wmem_queued: %d, sk_sndbuf: %d\n",
        $sk->sk_wmem_queued, $sk->sk_sndbuf);
}'

# Cilium 的 eBPF Network Policy 比 iptables 实现更高效

# Kubernetes NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - port: 80
          protocol: TCP

# iptables 实现：每个 Pod 添加多条 iptables 规则
# 1000 个 Pod × 10 条规则 = 10000 条 iptables 规则

# eBPF 实现：每个 Pod 的策略存储在 Map 中
# 查找复杂度 O(1)，不受 Pod 数量影响

# Cilium 支持 L7 级别的网络策略
# 可以基于 HTTP 路径、方法、头部做策略控制

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-policy
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "80"
              protocol: TCP
          rules:
            http:
              - method: GET
                path: "/api/v1/.*"
              - method: POST
                path: "/api/v1/orders"

# eBPF 在 Socket 层拦截并解析 HTTP 请求
# 匹配策略后决定允许或拒绝

// sockops 在 TCP 连接事件时执行
// 可以修改 TCP 参数、实现连接级策略

SEC("sockops")
int bpf_sockops(struct bpf_sock_ops *skops) {
    switch (skops->op) {
        case BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB:
            // 主动连接建立成功
            // 设置 TCP_NODELAY
            bpf_sock_ops_cb_flags_set(skops,
                BPF_SOCK_OPS_STATE_CB_FLAG);
            break;
            
        case BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB:
            // 被动连接建立成功
            break;
            
        case BPF_SOCK_OPS_RTO_CB:
            // RTO 超时
            break;
            
        case BPF_SOCK_OPS_RETRANS_CB:
            // 重传事件
            break;
    }
    return 1;
}

// 用途：
// 1. 自动设置 TCP 参数（避免应用层修改）
// 2. 记录连接事件（可观测性）
// 3. 实现 Socket-level 策略

# sk_msg + sockmap 可以实现 Pod 间通信的加速
# 当两个 Pod 在同一节点时，绕过整个 TCP/IP 栈

# 传统路径（同节点 Pod 通信）：
# Pod A → TCP → IP → veth → bridge → veth → IP → TCP → Pod B
# 经过完整的内核网络栈两次

# sockmap 加速路径：
# Pod A → TCP → sk_msg eBPF → sockmap 重定向 → TCP → Pod B
# 直接在 Socket 层重定向，绕过网络栈

# Cilium 的实现：
# 启用 Socket-level 加速
helm upgrade cilium cilium/cilium \
    --set socketLB.enabled=true

# 效果：
# 同节点 Pod-to-Pod 延迟降低 ~50%
# 同节点 Pod-to-Pod 吞吐量提升 ~30%

# eBPF 程序的性能优化要点：

# 1. 减少 Map 查找次数
# 坏：多次查找不同 Map
# 好：合并到一个 Map，一次查找

# 2. 使用 per-CPU Map
# 避免 CPU 间的缓存竞争
# BPF_MAP_TYPE_PERCPU_HASH 替代 BPF_MAP_TYPE_HASH

# 3. 内联辅助函数
# __always_inline 确保编译器内联

# 4. 避免过多的边界检查
# 验证器要求每次指针访问前检查边界
# 尽量减少指针操作次数

# 5. 使用批量操作
# bpf_map_lookup_batch 替代多次 bpf_map_lookup_elem

# 6. 合理设置 Map 大小
# 过大的 Map 浪费内存
# 过小的 Map 导致哈希冲突

# 1. 启用 JIT 编译
sysctl -w net.core.bpf_jit_enable=1
# JIT 将 eBPF 字节码编译为原生机器码
# 性能提升 ~2-5 倍

# 2. 增大 eBPF 栈大小（如果需要）
# 默认 512 字节，通常够用

# 3. 合理分配 CPU
# XDP 程序绑定到特定 CPU
# 避免 CPU 迁移开销

# 4. 使用 BTF（BPF Type Format）
# 编译时包含类型信息
# 使程序可以跨内核版本运行（CO-RE）

# 5. 监控 eBPF 程序开销
bpftool prog profile id 42 duration 5
# 输出每秒运行次数、平均执行时间等

# 性能基准参考（XDP，单核）：
# 简单丢包：24 Mpps
# Map 查找后丢包：18 Mpps
# 修改包头后转发：10 Mpps
# L4 负载均衡：8 Mpps

# 场景：Web 服务遭受 SYN Flood 攻击
# 传统方案：iptables 限速 → CPU 开销大
# eBPF 方案：XDP 层直接丢弃

# XDP SYN 防护程序逻辑：
# 1. 解析 TCP SYN 包
# 2. 检查源 IP 的 SYN 速率
# 3. 超过阈值 → XDP_DROP
# 4. 正常 → XDP_PASS

# 效果对比：
# 方案              处理能力      CPU 开销
# iptables rate     ~3 Mpps      100%
# XDP drop          ~24 Mpps     30%

# 实现：使用 per-CPU Map 记录每个源 IP 的 SYN 计数
# LRU Map 自动淘汰旧条目，避免内存膨胀

# 场景：Istio Service Mesh 的 sidecar 代理导致延迟增加
# 原因：每次 Pod 间通信经过两个 Envoy sidecar

# Pod A → Envoy (sidecar) → TCP → Pod B's Envoy (sidecar) → Pod B
# 额外延迟：~1-3ms

# 解决方案：使用 Cilium 替代 Istio 的数据平面
# 1. eBPF 在内核层做 L4/L7 策略
# 2. 同节点通信通过 sockmap 加速
# 3. 无需 sidecar 代理

# 效果：
# 指标              Istio (sidecar)  Cilium (eBPF)
# P50 延迟          +0.5ms           +0.05ms
# P99 延迟          +3ms             +0.2ms
# 内存开销/Pod      ~50MB (Envoy)    ~0 (内核态)
# CPU 开销          10-15%           2-3%

# 场景：需要了解 Kubernetes 集群中所有网络流量的来龙去脉
# 传统方案：每个节点部署 tcpdump → 海量数据，难以分析
# eBPF 方案：Hubble 在内核层采集流量元数据

# Hubble 可以回答的问题：
# 1. 哪些 Pod 正在通信？
hubble observe --namespace production

# 2. 哪些连接被 Network Policy 拒绝？
hubble observe --verdict DROPPED

# 3. HTTP 请求的延迟分布是什么？
hubble observe --type l7 --protocol http \
    -o json | jq '.flow.l7.latency_ns'

# 4. DNS 查询是否有异常？
hubble observe --type l7 --protocol dns

# 5. 哪些 Pod 产生了最多的流量？
hubble observe -o json | jq '.flow.source.labels' | sort | uniq -c | sort -rn

# 零侵入——不需要修改应用代码
# 低开销——eBPF 在内核态采集，开销 < 1% CPU

# eBPF 网络程序的开发工具

# 1. libbpf（C 库）
# 最底层的库，直接操作 BPF 系统调用
# 适合：高性能、精细控制

# 2. cilium/ebpf（Go 库）
# Go 生态的 eBPF 库
# 适合：Go 应用集成

# 3. Aya（Rust 库）
# Rust 生态的 eBPF 库
# 适合：Rust 应用、类型安全

# 4. bpftool
# 内核自带的 eBPF 管理工具
bpftool prog list         # 列出加载的程序
bpftool map list          # 列出 Map
bpftool net list          # 列出网络 eBPF 程序
bpftool prog show id 42   # 查看程序详情

# 5. bpftrace
# 高级追踪语言，类似 awk
# 适合：快速诊断和调试

# 6. 验证器（Verifier）
# 内核在加载 eBPF 程序时会进行安全验证
# 确保：无死循环、内存安全、有界执行
# 验证失败时会给出详细错误信息

# 7. CO-RE（Compile Once, Run Everywhere）
# 使用 BTF 信息，eBPF 程序可以跨内核版本运行
# 不再需要为每个内核版本重新编译

# 检查当前内核的 eBPF 支持
bpftool feature probe kernel

# 检查 BTF 支持
ls /sys/kernel/btf/vmlinux
# 存在则支持 CO-RE