引言：当传统网络栈遇到性能瓶颈
先看关键判断
如果你正在处理Linux TCP，先别急着照搬网上的参数。在高并发、低延迟的网络场景下，Linux 内核默认的 TCP/IP 协议栈往往成为核心瓶颈。从中断处理、sk_buff 分配，到协议层层解析，每一步都有不小的 CPU 开销。过去，我们只能通过调优参数、使用 DPDK 旁路用户态来突破，但这些方案或灵活性差，或复杂度高。eBPF 与 XDP 技术的成熟，让我们能够在保持内核安全的前提下，以极小的代价直接介入报文处理路径，实现近乎原生硬件的性能。本文将从实战角度，展示如何利用 eBPF 和 XDP 处理 TCP 报文，并搭建一套高性能监控方案。
进阶阅读：此处可内链到“Linux TCP性能优化”指南。
为什么选择 eBPF/XDP 处理 TCP 报文？
传统内核网络栈的瓶颈
常规收包路径：网卡 → 硬中断 → 软中断 → dev_queue_xmit → 协议层处理（IP、TCP）→ socket 接收队列。每一步都涉及锁、内存分配、数据拷贝。在 10G/25G 甚至 100G 网卡下，CPU 很快就会被软中断填满，性能骤降。
eBPF 与 XDP 的架构优势
XDP（eXpress Data Path）在网卡驱动层直接运行 eBPF 程序，数据包甚至尚未构建 sk_buff。它可以在驱动中断处理前完成过滤、转发、丢弃，CPU 开销极低。eBPF 则提供了 TCP 协议栈内部的探针，如 sockops、tcp_connect、tcp_retransmit 等钩子，能零开销采集状态。两者结合，既能做高性能转发，又能做细粒度监控，且无需修改内核代码。
XDP：在网卡驱动层拦截报文——Linux TCP
XDP 程序类型与挂载点
XDP 程序通过 bpf() 系统调用加载到网络设备上，返回动作包括 XDP_DROP（丢弃）、XDP_PASS（放行）、XDP_TX（从原网卡发送回去）、XDP_REDIRECT（重定向到其他网卡或用户态）。通常使用 libbpf 或 cilium/ebpf 库编写。
实战：用 XDP 过滤恶意 TCP SYN 包
假设我们需要丢弃所有源端口为 80 的 TCP SYN 包。以下是一个精简的 C 代码片段（基于 libbpf 框架）：
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/tcp.h>
SEC("xdp_filt")
int xdp_filter(struct xdp_md *ctx) {
void *data_end = (void *)(long)ctx->data_end;
void *data = (void *)(long)ctx->data;
struct ethhdr *eth = data;
if ((void*)eth + sizeof(*eth) > data_end) return XDP_PASS;
if (eth->h_proto != __constant_htons(ETH_P_IP)) return XDP_PASS;
struct iphdr *ip = data + sizeof(*eth);
if ((void*)ip + sizeof(*ip) > data_end) return XDP_PASS;
if (ip->protocol != IPPROTO_TCP) return XDP_PASS;
struct tcphdr *tcp = (void*)ip + (ip->ihl * 4);
if ((void*)tcp + sizeof(*tcp) > data_end) return XDP_PASS;
if (tcp->source == __constant_htons(80) && tcp->syn && !tcp->ack) {
return XDP_DROP;
}
return XDP_PASS;
}
编译后用 ip link set dev eth0 xdp obj xdp_filt.o sec xdp_filt 加载。该程序在网卡驱动层直接丢弃报文，几乎不消耗 CPU，相比 iptables 规则性能提升数十倍。
eBPF 在 TCP 协议栈中的深度观测
eBPF 程序附着到 sockops/tcp 钩子
内核在 TCP 连接建立、发送、重传等关键时刻都会调用特定的 tracepoint 或 kprobe。通过 bpf_prog_attach 将 eBPF 程序绑定到 cgroup/sockops 或 tracepoint/tcp/tcp_rcv_established 等钩子，可以记录双向的延迟和丢包信息。
监控 TCP 连接延迟与重传
以下使用 bpftrace 的一行命令即可实时查看建连延迟分布：
bpftrace -e 'kprobe:tcp_v4_connect { @start[tid] = nsecs; }
kretprobe:tcp_v4_connect /@start[tid]/ { @latency_us[pid] = hist((nsecs - @start[tid]) / 1000); delete(@start[tid]); }'对于重传监控，可以挂载 tracepoint:tcp:tcp_retransmit_skb：
bpftrace -e 'tracepoint:tcp:tcp_retransmit_skb { @retrans[pid, comm] = count(); }'这些探针开销极低，可在生产环境持续运行。
高性能报文处理实战：基于 eBPF 的负载均衡示例
使用 bpf_redirect 实现快速转发
配合 XDP_REDIRECT，我们可以构建一个内核级负载均衡器。假设 eth0 接收流量，eth1 和 eth2 为后端。eBPF 程序根据源 IP 哈希选择后端，并调用 bpf_redirect() 将报文直接发送到另一网卡的驱动队列，无需经过完整协议栈。
int xdp_lb(struct xdp_md *ctx) {
// 解析 hash 并选择后端 ifindex
u32 ifindex = (hash % 2) ? 2 : 3; // 假设 eth1=2, eth2=3
return bpf_redirect(ifindex, 0);
}
该方案延迟在微秒级，吞吐可达线速，且支持动态后端更新。
内核旁路与回注
更复杂的场景下，我们可以将特定报文重定向到用户态 sockets，通过 AF_XDP 套接字实现内核旁路。用户态程序可以直接读写报文，同时依旧保留使用内核协议栈处理常规流量的能力。这种方式兼具性能和灵活性。
延伸阅读：此处可内链到“Linux TCP配置案例”相关文章。
监控与可观测性：用 eBPF 收集 TCP 性能指标
使用 bpftrace 快速诊断
除了前面的一行命令，bpftrace 还支持聚合和条件过滤。例如，诊断 TCP 零窗口问题：
bpftrace -e 'tracepoint:tcp:tcp_probe /skaddr != NULL/ { @window[pid, comm] = lhist(args->rcv_wnd, 0, 65535, 1024); }'持续运行可输出接收窗口大小的直方图，快速判断是否出现零窗口。
整合 Prometheus 导出 eBPF 指标
生产环境需要持久化监控。可以编写一个 Go 服务，利用 cilium/ebpf 库加载 eBPF 程序，将统计的 TCP 重传次数、建连延迟分位数、报文丢弃计数等指标暴露为 Prometheus metric。然后配置 Grafana 仪表盘实时展示，实现从内核到可视化的闭环。
核心步骤：
- 在 eBPF 中使用全局 map 存储计数。
- 用户态程序定期读取 map 并更新 prometheus.CounterVec。
- 注册 HTTP handler，让 Prometheus server 拉取。
想继续深入：此处可内链到“Linux TCP优化清单”文章。
补充参考：此处可内链到“Linux TCP故障排查实例”。
注意事项与生产环境部署建议
验证与回滚
- 内核版本：XDP 要求 Linux 4.8+，sockops 推荐 5.3+。使用较新发行版（如 Ubuntu 22.04、Rocky Linux 9）。
- 驱动支持：并非所有网卡驱动都实现了 XDP 钩子，主流 Intel i40e/ice、Mellanox mlx5、Amazon ena 均支持。
- 安全验证：生产加载前务必在测试环境运行，使用
bpftool prog list检查，并加载 before/after 的计数器确认。 - 回滚方案：使用
ip link set dev eth0 xdp off即可卸载 XDP 程序，不会中断网络，可快速回退。 - 性能压测：使用 pktgen 或 trex 验证，关注 CPU 软中断占比和报文丢失率。
相关阅读：此处可内链到“Linux TCP常见问题”专题。
Linux TCP：结语
验证与回滚
eBPF 和 XDP 重新定义了 Linux 网络报文处理的方式。从 XDP 驱动级过滤到 eBPF 协议栈观测，再到高性能负载均衡与 Prometheus 监控集成，本文提供了一套完整的实战路径。读者可以根据自身业务，选取其中环节落地。未来，随着 eBPF 在容器网络、服务网格中的普及，掌握这项技术将成为网络工程师的必备技能。后续只要定期检查关键指标，Linux TCP就不会变成维护负担。
延伸阅读