2.2 连接状态机追踪实现

// 定义连接元数据结构体
struct conn_id {
    __u32 saddr;     // 源 IP
    __u32 daddr;     // 目的 IP
    __u16 sport;     // 源端口
    __u16 dport;     // 目的端口
    __u32 pid;       // 进程 ID
    __u64 ts;        // 起始时间戳
};

struct conn_info {
    __u64 t_connect;        // SYN 发送时间
    __u64 t_established;    // 连接建立时间
    __u64 t_first_byte;     // 接收到第一个字节数据的时间
    __u64 t_close;          // 连接关闭时间
    __u64 bytes_sent;       // 发送字节数
    __u64 bytes_recv;       // 接收字节数
    __u32 retransmit_cnt;   // 重传次数
    __u8  state;            // 当前连接状态
};

// BPF_HASH 存储活跃连接
BPF_HASH(active_conns, struct conn_id, struct conn_info);

// 追踪 connect() 系统调用入口
SEC("kprobe/tcp_v4_connect")
int trace_connect(struct pt_regs *ctx) {
    struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);
    
    struct conn_id id = {};
    id.saddr = BPF_CORE_READ(sk, __sk_common.skc_rcv_saddr);
    id.daddr = BPF_CORE_READ(sk, __sk_common.skc_daddr);
    id.sport = BPF_CORE_READ(sk, __sk_common.skc_num);
    id.dport = bpf_ntohs(BPF_CORE_READ(sk, __sk_common.skc_dport));
    id.pid = bpf_get_current_pid_tgid() >> 32;
    id.ts = bpf_ktime_get_ns();
    
    struct conn_info info = {};
    info.t_connect = id.ts;
    info.state = TCP_SYN_SENT;
    
    active_conns.update(&id, &info);
    return 0;
}

// 追踪状态变为 ESTABLISHED 
SEC("tracepoint/sock/inet_sock_set_state")
int trace_set_state(struct trace_event_raw_inet_sock_set_state *ctx) {
    if (ctx->newstate == TCP_ESTABLISHED) {
        // 查找匹配的连接并记录 established 时间
        // ... 省略键匹配逻辑
    }
    
    if (ctx->newstate == TCP_CLOSE) {
        // 连接关闭：计算总生命周期，输出到 Perf Buffer
        struct conn_meta event = {};
        event.duration_ns = ctx->activeconn->t_close - ctx->activeconn->t_connect;
        event.latency_ns  = ctx->activeconn->t_established - ctx->activeconn->t_connect;
        event.bytes_total = ctx->activeconn->bytes_sent + ctx->activeconn->bytes_recv;
        events.perf_submit(ctx, &event, sizeof(event));
        
        // 删除哈希条目释放内存
        active_conns.delete(&key);
    }
    return 0;
}

2.3 用户态数据消费

eBPF 程序收集到的数据需要传递到用户态进行聚合和存储。常用的数据传输机制是 Perf Buffer（高性能）和 Ring Buffer（Linux 5.8+，更高效）。

// 用户态：使用 libbpf 消费 Perf Buffer
#include <bpf/libbpf.h>

struct perf_buffer *pb = perf_buffer__new(
    bpf_map__fd(obj->maps.events),  // Perf Buffer FD
    256,                           // 每个 CPU 的 buffer 大小（页）
    handle_event,                  // 回调函数
    NULL, NULL, NULL
);

// 轮询数据
while (1) {
    perf_buffer__poll(pb, 100);  // 100ms 超时
}

// 回调函数：处理每个连接关闭事件
static void handle_event(void *ctx, int cpu, void *data, __u32 size) {
    struct conn_meta *e = data;
    
    // 计算关键指标
    double connect_ms = e->latency_ns / 1e6;       // 连接延迟（毫秒）
    double duration_ms = e->duration_ns / 1e6;     // 连接持续时间
    double throughput = e->bytes_total / (duration_ms / 1000.0); // 字节/秒
    
    // 写入 Prometheus Metrics 或 InfluxDB
    metrics.record(connect_ms, duration_ms, throughput);
}

三、网络延迟热力图：可视化 TCP 性能瓶颈

3.1 eBPF 采集的延迟维度

网络延迟并非单一指标，通过 eBPF 可以同时采集四个层次的延迟数据：

• 连接建立延迟（TCP Handshake）：从 SYN 发出到收到 SYN-ACK 的 RTT
• 首字节延迟（Time To First Byte）：从连接建立到收到第一个数据字节
• 请求/响应延迟（RTT）：应用层请求发出到收到完整响应
• 队列延迟（Queuing Delay）：数据包在内核 Socket Buffer 中的等待时间

3.2 延迟直方图实现

eBPF 提供专门的 BPF_MAP_TYPE_HIST 和直方图助手函数，可以直接生成对数分布的延迟直方图：

// 定义延迟直方图（自动按 2 的幂次分桶）
BPF_HISTOGRAM(conn_latency, __u64);
BPF_HISTOGRAM(rtt_histogram, __u64);

// 计算并记录连接延迟（单位：微秒）
SEC("tracepoint/sock/inet_sock_set_state")
int trace_established(struct trace_event_raw_inet_sock_set_state *ctx) {
    // ... 查找连接记录
    
    __u64 latency_us = (t_established - t_connect) / 1000;
    conn_latency.atomic_increment(bpf_log2l(latency_us));
    
    return 0;
}

// RTT 估算：利用 TCP 的 RTT 采样
SEC("kprobe/tcp_ack_update_rtt")
int trace_rtt(struct pt_regs *ctx) {
    struct sock *sk = PT_REGS_PARM1(ctx);
    __u32 rtt = PT_REGS_PARM4(ctx); // RTT 采样值（微秒）
    
    rtt_histogram.atomic_increment(bpf_log2l(rtt));
    return 0;
}

3.3 可视化输出

通过将 eBPF 直方图数据导出到 Prometheus，我们可以使用 Grafana 构建炫酷的延迟热力图：

# Prometheus 格式的直方图查询
# TCP 连接延迟分布（P50/P95/P99）
histogram_quantile(0.50, sum(rate(ybb_tcp_connect_latency_bucket[5m])) by (le))
histogram_quantile(0.95, sum(rate(ybb_tcp_connect_latency_bucket[5m])) by (le))
histogram_quantile(0.99, sum(rate(ybb_tcp_connect_latency_bucket[5m])) by (le))

# 按目的服务分组的 RTT 热力图
sum by (destination, le) (rate(ybb_tcp_rtt_bucket{service!="unknown"}[5m]))

四、容器网络中的 eBPF 实践

4.1 容器网络的可见性挑战

在 Kubernetes 集群中，Pod 之间的网络通信经过复杂的虚拟网络设备（veth pair、bridge、overlay tunnel 等），传统的 iptables + kube-proxy 方案导致：

• 东西向流量经过大量 NAT 转换，源 IP 丢失
• iptables 规则成千上万，匹配开销巨大
• 传统监控工具无法区分容器边界

4.2 Cilium 的 eBPF 方案

Cilium 是 Kubernetes 生态中最成熟的 eBPF 网络方案，它完全替代 kube-proxy，通过 eBPF 实现：

• Sockmap/Sockops：在内核 Socket 层直接转发数据包，跳过整个协议栈
• Identity-based 安全模型：为每个 Pod 分配安全身份标签，取代 IP 规则
• Hubble：基于 eBPF 的网络可观测性平台，提供实时服务依赖图和 DNS 监控

4.3 cgroup 级别的流量统计

利用 cgroup 挂载点，eBPF 可以关联网络流量与具体容器：

// 在 socket 层关联 cgroup ID
SEC("cgroup_skb/egress")
int count_egress(struct __sk_buff *skb) {
    // 获取当前 socket所属的 cgroup ID
    __u64 cgroup_id = bpf_get_current_cgroup_id();
    
    // 按 cgroup 统计出口流量
    struct traffic_key key = {
        .cgroup_id = cgroup_id,
        .direction = EGRESS
    };
    
    __u64 *bytes = bpf_map_lookup_elem(&cgroup_traffic, &key);
    if (bytes)
        __sync_fetch_and_add(bytes, skb->len);
    
    return 1; // 允许通过
}

五、DNS 查询行为分析

5.1 eBPF 追踪 DNS 请求

DNS 故障是微服务架构中最常见但最难定位的问题之一。通过 kprobe 挂载 udp_sendmsg 和 tcp_sendmsg，可以捕获每次 DNS 查询的域名、响应时间和服务端。

// 追踪 DNS 查询（UDP 53端口）
SEC("kprobe/udp_sendmsg")
int trace_dns_query(struct pt_regs *ctx) {
    struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);
    struct msghdr *msg = (struct msghdr *)PT_REGS_PARM2(ctx);
    
    // 过滤 DNS 端口（UDP 53 或 TCP 53）
    __u16 dport = bpf_ntohs(BPF_CORE_READ(sk, __sk_common.skc_dport));
    if (dport != 53)
        return 0;
    
    // 读取 DNS 查询内容中的域名
    // DNS 查询名在 msg->msg_iter 中
    char name[256] = {};
    struct iov_iter *iter = &msg->msg_iter;
    
    // 简化：直接访问第一个 iov
    struct iovec iov;
    bpf_probe_read_kernel(&iov, sizeof(iov), iter->iov);
    
    // 从 DNS 报文中提取查询域名（跳过12字节header）
    char *dns_data = iov.iov_base;
    extract_dns_name(dns_data + 12, name, sizeof(name));
    
    // 记录查询事件
    struct dns_event event = {};
    event.ts = bpf_ktime_get_ns();
    event.pid = bpf_get_current_pid_tgid() >> 32;
    bpf_probe_read_kernel_str(event.query, sizeof(event.query), name);
    
    // 存储查询时间戳，用于后续计算 DNS 延迟
    __u32 txn_id = extract_dns_txn_id(dns_data);
    bpf_map_update_elem(&dns_requests, &txn_id, &event.ts, BPF_ANY);
    
    events.perf_submit(ctx, &event, sizeof(event));
    return 0;
}

5.2 DNS 延迟与失败分析

通过匹配 DNS 请求和响应（通过 Transaction ID），可以计算每次 DNS 查询的耗时，并统计失败率：

// 追踪 DNS 响应（udp_recvmsg）
SEC("kretprobe/udp_recvmsg")
int trace_dns_response(struct pt_regs *ctx) {
    struct msghdr *msg = (struct msghdr *)PT_REGS_PARM1(ctx);
    long ret = PT_REGS_RC(ctx);
    
    if (ret < 0) return 0; // 接收失败
    
    // 读取响应中的 Transaction ID
    // ... 提取事务 ID 并与请求匹配
    
    __u64 *req_ts = bpf_map_lookup_elem(&dns_requests, &txn_id);
    if (!req_ts) return 0;
    
    __u64 latency_ns = bpf_ktime_get_ns() - *req_ts;
    
    struct dns_latency_event event = {};
    event.latency_ns = latency_ns;
    event.rcode = extract_dns_rcode(response_data); // 0=NOERROR, 2=SERVFAIL, 3=NXDOMAIN
    
    dns_events.perf_submit(ctx, &event, sizeof(event));
    dns_requests.delete(&txn_id);  // 清理记录
    
    return 0;
}

六、流量图谱构建：关联服务依赖关系

6.1 原理概述

流量图谱的构建依赖于对网络五元组（源IP、目的IP、协议、源端口、目的端口）信息的聚合。结合 Kubernetes 的 Service 注册信息或 DNS 查询日志，可以将 IP 地址映射为服务名称，最终形成一张实时更新的服务调用关系图。

6.2 数据流设计

完整的流量图谱数据流如下：

1. eBPF 采集：在每个节点部署 eBPF Agent，捕获 TCP accept/connect 事件，提取五元组 + 进程信息
2. 关联解析：用户态程序将 IP 映射到 Kubernetes Service/Pod/DNS 域名
3. 时序存储：将结构化数据写入 InfluxDB 或 ClickHouse（按时间窗口聚合）
4. 图计算：在图数据库（Neo4j）中维护服务依赖矩阵
5. 可视化：通过 Grafana 或 Hubble UI 展示实时流量拓扑

6.3 关键聚合算法

在大量数据流场景下，需要考虑高效的聚合策略，避免内存爆炸：

// eBPF 使用 LRU 哈希表自动淘汰过期连接
BPF_HASH(flow_stats, struct flow_key, struct flow_info, 65536);
//                              ↑ 最大条目数

// LRU 策略：当表满时自动淘汰最久未使用的条目
// 也可以使用 BPF_MAP_TYPE_LRU_HASH 显式声明
BPF_LRU_HASH(active_flows, struct flow_key, __u64, 100000);

七、生产环境部署与最佳实践

7.1 性能开销控制

eBPF 虽然高效，但在万兆网卡满负载场景下仍需注意：

• 采样率控制：通过随机抽样（如 1/1000）降低高频事件的 CPU 消耗
• 早期过滤：在 BPF 程序最前端做 IP 端口过滤，避免无意义的解析开销
• 批量提交：使用 Perf Buffer 的批量消费模式，减少用户态/内核态上下文切换
• CPU 隔离：将 BPF JIT 编译和消费逻辑绑定到特定 CPU 核心

7.2 安全边界

eBPF 程序运行在内核态，需要特别注意安全性：

• Verifier 验证：所有 eBPF 程序必须通过内核验证，禁止无限循环和越界访问
• Capability 控制：加载 eBPF 程序需要 CAP_BPF 或 CAP_SYS_ADMIN 权限
• BTF 支持：使用 BTF（BPF Type Format）实现跨内核版本可移植的 CO-RE（Compile Once, Run Everywhere）

7.3 调试技巧

eBPF 程序调试和传统内核模块不同，常用工具链：

• bpftool：查看/管理 eBPF 程序和 Map（bpftool prog show、bpftool map dump）
• bpftrace：单行脚本快速验证探针点（如 bpftrace -e 'tracepoint:tcp:tcp_probe { printf("cwnd %d\n", args->snd_cwnd); }'）
• perf record：结合 eBPF 进行性能分析

八、总结与展望

eBPF 网络可观测性已经从实验室走向大规模生产。微软的 Retina、Isovalent 的 Hubble、Cilium 等项目证明了 eBPF 在容器网络场景下的独特价值。相比传统抓包方案，eBPF 的优势在于：

• 零侵扰：无需修改应用代码或重启服务
• 纳秒级精度：内核级时间戳，无上下文切换误差
• 可编程过滤：在数据采集点直接过滤/聚合，减少无效数据传输
• 全栈关联：从网卡驱动到应用层 Socket，覆盖完整网络路径

未来，随着 eBPF 在 Windows 系统（eBPF on Windows）和智能网卡（SmartNIC/DPU）上的落地，网络可观测性能力将进一步下沉到硬件层，实现从云端到边缘的全覆盖。