第10章：网络

2026-05-20 读书笔记 3.4k 字 13 分钟阅读
📑 目录
  1. 故事场景：那个凌晨三点的告警
  2. 1. 网络性能的迷雾与破局
  3. 2. 传统网络工具的边界
    1. 2.1 ss / netstat：连接表的快照
    2. 2.2 tcpdump / Wireshark：报文级的显微镜
    3. 2.3 工具能力矩阵
  4. 3. BPF网络工具全景
    1. 3.1 TCP连接分析：tcplife
    2. 3.2 连接建立追踪：tcpconnect / tcpaccept
    3. 3.3 实时流量TOP：tcptop
    4. 3.4 丢包与重传诊断：tcpdrop / tcpretrans
    5. 3.5 SYN Backlog与DNS延迟
    6. 3.6 UDP与ICMP
  5. 4. BPF单行程序：网络分析的快刀
  6. 5. 从TCP/IP协议栈理解BPF观测点
  7. 总结
    1. 本章核心要点

在分布式系统的迷雾中，BPF像一台内核级X光机，让每一帧TCP报文的来去都留下不可磨灭的足迹。

故事场景：那个凌晨三点的告警

凌晨3:17，老张的手机炸了。生产环境电商大促预热，支付网关的P99延迟突然从120ms飙到4.8秒，用户订单支付成功率暴跌至67%。监控大屏上一片血红，Nginx日志只写着"upstream timed out"，却不说为什么超时。

小李被从床上薅起来，顶着鸡窝头打开终端。传统三板斧：ss -s看了一眼连接数，正常；netstat -i看了眼网卡，没丢包；tcpdump -i eth0 port 443一跑，海量的报文喷涌而出，凌晨三点的人眼根本跟不住。Wireshark抓了一分钟，文件已经300MB，下载到本地分析？天都亮了。

老张叹了口气，敲下一行命令：tcplife-bpfcc。终端立刻安静了下来，只输出每一行连接的生命线——哪一秒建立、哪一秒关闭、持续多久、收发多少字节。两分钟后，所有超时连接的本地端口都落在了32000-32500这个区间，而ss显示这个范围正是跟下游库存服务的长连接池。问题瞬间明朗：库存服务的keepalive超时设置是30秒，但连接池复用策略是60秒——半数的TCP连接都在发请求时才发现对方已经悄悄挂了，静默重试三次，每次5秒，正好15秒浪费在等一个死连接上。

小李目瞪口呆："就这么一行命令？"

"一行就够了。"老张关掉终端，"去把连接池的健康检查改成10秒，我要回去睡觉了。"

1. 网络性能的迷雾与破局

在Linux系统中，网络性能问题往往是最难诊断的类别之一。TCP/IP协议栈像一个深埋地下的管道系统——流量进去、出来，中间发生了什么，用户空间几乎无法直接观测。传统的观测手段各有各的盲区：

  • ss和netstat只能看快照（snapshot），连接建立后的一瞬即逝的异常完全捕捉不到
  • tcpdump和Wireshark是报文级的显微镜，数据量巨大且需要离线分析
  • 应用层日志只能看到结果（超时/报错），看不到过程（哪个环节慢了）

更重要的是，生产环境的高流量场景下，tcpdump抓包造成的性能开销本身就可能成为问题。一个10Gbps的网卡，全速跑起来每秒有上千万个报文，tcpdump全量抓取意味着内核要把每个报文复制到用户空间——CPU和I/O的代价不菲。

BPF网络工具的本质优势在于内核级事件驱动：不在数据路径上复制报文，而是挂载到TCP协议栈的关键函数（如tcp_set_state、tcp_sendmsg、tcp_cleanup_rbuf等），只在状态转换时记录结构化的事件。开销极小，信息极准。

# 传统tcpdump：抓取所有报文，后期过滤
tcpdump -i eth0 -w capture.pcap 'tcp port 443'
# 抓1分钟可能产生数百MB文件，需要Wireshark离线分析

# BPF工具：只记录关心的连接事件
tcplife-bpfcc
# 输出：PID COMM LADDR LPORT RADDR RPORT TX_KB RX_KB MS
# 每行一个连接的完整生命周期，毫秒级精度
graph TD
    A[应用层 send/recv] --> B[TCP发送队列/接收队列]
    B --> C[IP层路由与分片]
    C --> D[网卡驱动队列 ring buffer]
    D --> E[物理网络]
    
    style A fill:#f9f,stroke:#333
    style D fill:#bbf,stroke:#333
    
    subgraph "BPF可观测点"
        F1[tcp_set_state
连接状态转换]
        F2[tcp_sendmsg
发送数据]
        F3[tcp_cleanup_rbuf
接收确认]
        F4[tcp_drop
报文丢弃]
        F5[sk_retransmit
重传事件]
    end
    
    B -.->|挂载点| F1
    B -.->|挂载点| F2
    B -.->|挂载点| F3
    C -.->|挂载点| F4
    C -.->|挂载点| F5

2. 传统网络工具的边界

在BPF登场之前，Linux网络诊断有一套成熟的工具链。理解它们的边界，才能明白BPF填补了哪些真空。

2.1 ss / netstat：连接表的快照

ss（socket statistics）是netstat的现代替代品，它直接从内核的TCP哈希表中读取连接状态，速度比netstat快得多。但它的本质仍是快照——就像给繁忙的十字路口拍一张照片，你能看到当下有多少辆车在等红灯，但拍不到那辆闯红灯的车。

# 查看所有ESTABLISHED的TCP连接及其发送/接收队列
ss -tin state established '( dport = :443 or sport = :443 )'
# 输出中的 send-q / recv-q 显示内核队列中积压的字节数

2.2 tcpdump / Wireshark：报文级的显微镜

tcpdump是网络工程师的瑞士军刀，它能捕获每个报文的头部甚至Payload。但问题也在于此——太细了。一次HTTP请求涉及数十到数百个TCP报文，当问题表现为"偶发超时"时，你需要在千万个报文中找到那一个RST或重传。Wireshark的图形化分析固然强大，但生产环境通常没有条件实时抓包并导出到本地。

# 仅抓取SYN和RST报文，减少数据量
tcpdump -i any 'tcp[tcpflags] & (tcp-syn|tcp-rst) != 0' -nn

2.3 工具能力矩阵

graph LR
    subgraph "传统工具"
        T1[ss/netstat
快照型
低开销
无历史]
        T2[tcpdump
报文级
高开销
需离线分析]
        T3[iftop/nethogs
流量统计
聚合型
无连接细节]
    end
    
    subgraph "BPF工具"
        B1[tcplife
生命周期
事件驱动
毫秒精度]
        B2[tcptop
实时TOP
动态排序
零拷贝]
        B3[tcpdrop
丢包追踪
精准归因
内核级]
    end
    
    T1 -.->|填补盲区| B1
    T2 -.->|降低开销| B2
    T3 -.->|精准定位| B3

3. BPF网络工具全景

Brendan Gregg在《BPF之巅》中系统梳理了BPF网络工具的能力矩阵。这些工具大多基于BCC（BPF Compiler Collection）或bpftrace框架，通过预定义的探针（probe）采集内核TCP/IP协议栈的关键事件。

3.1 TCP连接分析：tcplife

tcplife是BPF网络工具中最具代表性的一个。它不追踪每个报文，而是追踪每个连接——从SYN_SENT或SYN_RECV开始，到CLOSED或TIME_WAIT结束，记录完整生命周期。

# 运行tcplife，查看所有TCP连接的完整生命周期
sudo tcplife-bpfcc

# 典型输出：
# PID   COMM       LADDR           LPORT RADDR           RPORT  TX_KB  RX_KB  MS
# 1234  nginx      10.0.0.5        443   192.168.1.100   54321  12     856    2450
# 1234  nginx      10.0.0.5        443   192.168.1.101   54322  0      0      5000

最后一行是个经典的死连接——TX_KB和RX_KB都是0，但持续了5000ms（5秒）。这正是连接池中超时未关闭的僵尸连接的典型特征。

tcplife的核心实现逻辑是挂载到tcp_set_state这个内核函数上。TCP协议栈在每次状态转换时都会调用它，BPF程序记录时间戳，当状态转为CLOSED时计算持续时间并输出。

sequenceDiagram
    participant C as Client
    participant K as Kernel TCP Stack
    participant B as BPF tcplife
    
    C->>K: SYN
    K->>B: state: CLOSED->SYN_SENT [记录t0]
    K->>C: SYN-ACK
    C->>K: ACK
    K->>B: state: SYN_SENT->ESTABLISHED [记录t1]
    Note over B: 连接建立耗时 = t1 - t0
    
    C->>K: 数据传输...
    K->>B: tcp_sendmsg / tcp_cleanup_rbuf [累加TX/RX字节]
    
    C->>K: FIN
    K->>B: state: ESTABLISHED->FIN_WAIT1 [记录]
    K->>C: FIN-ACK
    K->>B: state: FIN_WAIT1->TIME_WAIT [记录t2]
    Note over B: 连接总寿命 = t2 - t0
TX_KB / RX_KB 汇总输出

3.2 连接建立追踪：tcpconnect / tcpaccept

tcpconnect追踪所有主动发起的出站TCP连接（connect()系统调用成功），tcpaccept追踪所有入站连接（accept()返回）。这对安全审计和依赖拓扑发现非常有用——你能准确知道你的服务在跟谁通信。

# 追踪所有出站连接
tcpconnect-bpfcc

# 追踪所有入站连接  
tcpaccept-bpfcc

# 结合使用，绘制服务的网络依赖拓扑

3.3 实时流量TOP：tcptop

tcptop像网络版的top命令，实时刷新，按TX/RX流量排序。它用BPF在内核中聚合每个进程的网络流量，用户空间只需要定期读取聚合结果——零拷贝、低开销。

# 实时查看哪些进程在疯狂收发数据
sudo tcptop-bpfcc

# 输出每秒刷新：
# PID    COMM         LADDR                 RADDR                  RX_KB  TX_KB
# 8821   mongod       10.0.0.10:27017       10.0.0.5:48291         245    12
# 3342   java         10.0.0.5:8080         192.168.3.1:29101       89     456

3.4 丢包与重传诊断：tcpdrop / tcpretrans

TCP丢包和重传是网络问题的核心指标。tcpdrop追踪内核丢弃TCP报文的精确位置和原因（如校验和错误、序列号无效、内存不足等）；tcpretrans追踪所有重传事件，区分超时重传（RTO）和快速重传。

# 追踪TCP报文被内核丢弃的事件
sudo tcpdrop-bpfcc

# 典型输出（带内核调用栈）：
# TIME     PID    IP SADDR:SPORT          DADDR:DPORT          STATE  REASON
# 03:21:45 8821   4  10.0.0.10:27017       10.0.0.5:48291      ESTABL  TCP: checksum failure
#   tcp_v4_rcv+0x123
#   ip_local_deliver+0x89
#   ip_rcv+0x234

# 追踪重传事件
sudo tcpretrans-bpfcc

3.5 SYN Backlog与DNS延迟

tcpsynbl监控SYN backlog的溢出情况——当服务器受到SYN Flood攻击或连接请求突增时，SYN队列满会导致合法的连接请求被丢弃。gethostlatency则追踪getaddrinfo()和gethostbyname()的调用延迟，捕捉DNS解析瓶颈。

# 监控SYN backlog状态
sudo tcpsynbl-bpfcc

# 追踪DNS解析延迟
sudo gethostlatency-bpfcc

3.6 UDP与ICMP

虽然TCP占据了大部分业务流量，但UDP同样重要——DNS（53端口）、QUIC（基于UDP的新版HTTP/3）、各种Telemetry上报都跑在UDP上。BPF工具同样可以追踪UDP的发送和接收事件。

# 追踪UDP连接/发送/接收
sudo udpconnect-bpfcc

4. BPF单行程序：网络分析的快刀

bpftrace的出现让BPF网络分析进入了单行程序时代。不需要写C代码、不需要编译，一行脚本就能完成精准的诊断。

# 统计每个目标端口的连接次数（发现异常连接模式）
bpftrace -e 'kprobe:tcp_set_state /args->state == TCP_ESTABLISHED/ { @[ntohs(args->sk->__sk_common.skc_dport)] = count(); }'

# 追踪大于1秒的TCP连接建立时间
bpftrace -e 'kprobe:tcp_v4_connect { @start[tid] = nsecs; } kretprobe:tcp_v4_connect /@start[tid]/ { @us = hist((nsecs - @start[tid]) / 1000); delete(@start[tid]); }'

# 统计每个进程的发包数量
bpftrace -e 'kprobe:dev_queue_xmit { @[comm] = count(); }'

# 追踪TCP RST报文的发送（快速发现连接异常断开）
bpftrace -e 'kprobe:tcp_send_reset { printf("RST sent: %s:%d -> ", ntop(AF_INET, args->sk->__sk_common.skc_rcv_saddr), args->sk->__sk_common.skc_num); printf("%s:%d\n", ntop(AF_INET, args->sk->__sk_common.skc_daddr), ntohs(args->sk->__sk_common.skc_dport)); }'

这些单行程序的本质是即席查询（Ad-hoc Query）——问题浮现时，30秒内写出一行bpftrace，30秒内得到答案。不再需要重新编译内核模块、不再需要部署复杂的Agent。这是BPF对网络运维最革命性的改变。

graph TD
    A[问题浮现] --> B{需要哪类信息?}
    B -->|连接生命周期| C[tcplife-bpfcc]
    B -->|实时流量排名| D[tcptop-bpfcc]
    B -->|丢包原因| E[tcpdrop-bpfcc]
    B -->|重传分析| F[tcpretrans-bpfcc]
    B -->|即席查询| G[bpftrace单行程序]
    
    C --> H[结构化输出]
    D --> H
    E --> H
    F --> H
    G --> H
    
    H --> I[根因定位]
    I --> J[修复验证]

5. 从TCP/IP协议栈理解BPF观测点

要真正掌握BPF网络工具，需要理解TCP/IP协议栈的分层结构和BPF探针的挂载位置。

graph TB
    subgraph "用户空间"
        APP[应用程序
socket API]
    end
    
    subgraph "内核空间 - BPF观测层"
        SOCK[sockops BPF
socket操作]
        TC[TC BPF
流量控制/分类]
        XDP[XDP BPF
网卡最早拦截点]
    end
    
    subgraph "内核协议栈"
        TCP[TCP层
状态机/拥塞控制]
        IP[IP层
路由/分片]
        DEV[设备层
qdisc/ring buffer]
    end
    
    subgraph "硬件"
        NIC[网卡
NIC offload]
    end
    
    APP --> SOCK
    SOCK --> TCP
    TCP --> IP
    IP --> DEV
    DEV --> NIC
    
    XDP -.->|最早拦截| DEV
    TC -.->|分类/整形| DEV
    SOCK -.->|socket级| TCP

在这个架构中，本书介绍的BCC工具主要挂载在TCP层（如tcp_set_state、tcp_sendmsg等内核函数），而新一代的BPF能力已经延伸到XDP（eXpress Data Path，网卡驱动层）和TC BPF（流量控制层）。XDP可以在报文进入内核协议栈之前就进行处理，延迟极低（ns级别），适合DDoS防护、负载均衡等场景。

总结

mindmap
  root((BPF网络分析))
    传统工具
      ss/netstat快照
      tcpdump报文级
      Wireshark离线分析
    BPF工具
      tcplife连接生命周期
      tcpconnect出站追踪
      tcpaccept入站追踪
      tcptop实时流量TOP
      tcpdrop丢包诊断
      tcpretrans重传分析
      tcpsynbl SYN队列
      gethostlatency DNS延迟
    bpftrace单行
      即席查询
      30秒出结果
      零部署
    核心优势
      事件驱动低开销
      结构化输出
      内核级精度
      生产环境安全

本章核心要点

  1. tcplife是网络诊断的"时光机"——它不追踪每个报文，而是记录每个TCP连接的完整生命周期（建立→传输→关闭），以极低的开销揭示连接池、超时、静默断开等经典问题。

  2. BPF网络工具是快照型工具的互补，不是替代——ss看当前状态，tcplife看历史演变；tcpdump看报文细节，tcptop看聚合趋势。真正的专家懂得组合使用。

  3. 丢包与重传是最硬的网络指标——tcpdrop和tcpretrans直击TCP可靠性机制的核心，任何延迟抖动、吞吐下降的终极原因往往都能追溯到这两个事件。

  4. bpftrace单行程序是网络SRE的"瑞士军刀"——30秒内编写、即时执行、结构化输出，让生产环境网络问题从"抓包分析两小时"进化为"定位根因两分钟"。

  5. BPF观测正在从TCP层向XDP/TC层下沉——本书BCC工具主要基于协议栈探针，而新一代eBPF已经可以在网卡驱动层（XDP）进行ns级处理，这是云原生网络（Cilium、Calico等）的技术底座。

"网络问题最怕的不是复杂，而是不可见。BPF做的，就是让每一帧报文的命运都留下痕迹。"