Linux 网络协议栈深度解析：从套接字到Netfilter的完整指南

）

指针向后移动（让出 TCP 头的位置给 IP 头），各层通过

/

操作修改指针即可。

二、TCP 协议栈：可靠传输的核心

TCP 是互联网上最广泛使用的传输层协议。Linux 内核中的 TCP 实现经过了二十多年的优化，支持拥塞控制、选择性确认（SACK）、窗口缩放等众多高级特性。

2.1 TCP 三次握手的内部流程

当用户程序调用

时，内核会执行以下操作：

1. 发送 SYN 报文：

   1	tcp_v4_connect()

   →

   1	tcp_transmit_skb()

   → 构造 SYN 包 → 添加到发送队列 → 调用

   1	ip_local_out()

   交给 IP 层

2. 接收 SYN+ACK：网卡中断 → IP 层处理 → TCP 层收到 SYN+ACK → 状态从

   1

   SYN_SENT

   转为

   1	ESTABLISHED

3. 发送 ACK：内核自动发送确认报文，连接建立完成

可以通过

或

查看当前系统中 TCP 连接的状态：

1
2
3
4
5
# 查看 TCP 连接状态

$ ss -tpan | head -20

State       Recv-Q  Send-Q  Local Address:Port   Peer Address:Port

ESTAB       0       0       127.0.0.1:8080       127.0.0.1:43210

TIME-WAIT   0       0       127.0.0.1:8080       127.0.0.1:43211

2.2 拥塞控制算法

Linux 内核支持多种拥塞控制算法，默认为 CUBIC（Linux 2.6.19 以后）：

1
2
3
4
5
6
7
8
9
10
# 查看当前拥塞控制算法

$ sysctl net.ipv4.tcp_congestion_control

net.ipv4.tcp_congestion_control = cubic



# 查看所有可用的拥塞控制算法

$ sysctl net.ipv4.tcp_available_congestion_control

net.ipv4.tcp_available_congestion_control = cubic reno bbr



# 切换到 BBR (Google 开发的基于带宽的拥塞控制算法)

$ sysctl -w net.ipv4.tcp_congestion_control=bbr

BBR（Bottleneck Bandwidth and Round-trip propagation time）是近年来广受关注的拥塞控制算法。与传统的基于丢包的算法不同，BBR 通过测量带宽和 RTT 来估计最优发送速率，在长肥网络（高带宽高延迟）场景下能显著提升吞吐量。

可以通过以下命令开启 BBR：

1
2
3
4
5
6
7
8
9
10
11
12
# 开启 BBR

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf

echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf

sysctl -p



# 验证 BBR 是否生效

$ sysctl net.ipv4.tcp_congestion_control

net.ipv4.tcp_congestion_control = bbr



# 查看 TCP 栈信息确认 BBR 模块已加载

$ lsmod | grep tcp_bbr

tcp_bbr                20480  4

2.3 TCP 接收路径的滑动窗口与内存管理

TCP 接收路径的工作流程大致如下：数据包到达 → 网卡 DMA 到内存 → 内核 IP 层处理 → TCP 层处理 → 数据放入套接字接收缓冲区 → 等待应用通过

读取。

关键的调优参数：

1
2
3
4
5
6
7
# 查看和调整 TCP 读写缓冲区大小

$ sysctl net.ipv4.tcp_rmem

net.ipv4.tcp_rmem = 4096    131072  6291456

# 分别对应: 最小值 默认值 最大值 (单位: 字节)



$ sysctl net.ipv4.tcp_wmem

net.ipv4.tcp_wmem = 4096    16384   4194304

当应用程序读取速度跟不上数据到达速度时，接收缓冲区会逐渐填满，最终触发 TCP 的流量控制机制——内核会发送窗口更新报文（Windows Update），告知对端减小发送窗口，从而形成背压。

理解这一点对于优化高并发服务至关重要：如果发现对端发送窗口经常为 0，说明应用程序处理速度不够，需要优化应用层的 I/O 模型。可以通过

查看每个连接详细的 TCP 信息，包括发送窗口、拥塞窗口、RTT 等指标。

三、IP 层与路由子系统

IP 层是网络协议栈的”交通枢纽”。它负责数据包的路由选择、分片与重组、以及转发决策。Linux 的 IP 层实现涉及路由缓存（早期内核）、路由查找（FIB，Forwarding Information Base）、邻居子系统（ARP/ND）等多个模块。

3.1 路由查找过程

当 TCP 层调用

发送数据包时，IP 层会执行路由查找：

1
2
3
4
5
6
7
8
# 查看当前系统的路由表

$ ip route show

default via 192.168.1.1 dev eth0 proto static

192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100



# 查看路由缓存详细信息

$ ip route get 8.8.8.8

8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.100 uid 0

路由查找的核心数据结构是 FIB（Forwarding Information Base）。Linux 内核使用

来管理路由表，并通过

函数执行最长前缀匹配（Longest Prefix Match）算法。

对于需要本机接收的数据包（目标地址为本机 IP），IP 层会将其上送到传输层。对于需要转发的数据包，内核会调用

函数进行转发处理——这需要在 sysctl 中开启

。

3.2 邻居子系统（ARP 和 NDP）

在以太网环境中，IP 地址需要转换为 MAC 地址才能发送数据帧。Linux 内核使用邻居子系统（Neighbor Subsystem）来管理这个映射关系：

1
2
3
4
5
6
7
# 查看 ARP 表

$ ip neigh show

192.168.1.1 dev eth0 lladdr 00:11:22:33:44:55 REACHABLE

192.168.1.2 dev eth0 lladdr 66:77:88:99:aa:bb STALE



# 手动添加静态 ARP 条目

$ ip neigh add 192.168.1.200 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent

邻居条目的状态机包括

→

→

→

→

→

等状态。理解这些状态对于排查网络连通性问题（如 ARP 表项老化导致丢包）非常有帮助。

3.3 IP 分片与 PMTU 发现

当 IP 数据包的大小超过链路层的 MTU（通常为 1500 字节）时，IP 层需要对数据包进行分片。对于 IPv4，路径上的任何路由器都可能在需要时进行分片；对于 IPv6，只有源主机可以分片。

现代系统通常使用 PMTUD（Path MTU Discovery）来避免分片：

1
2
3
4
5
6
7
8
9
10
# 查看当前系统的 MTU

$ ip link show eth0 | grep mtu

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT



# PMTU 相关设置

$ sysctl net.ipv4.ip_no_pmtu_disc

net.ipv4.ip_no_pmtu_disc = 0  # 0 = 启用 PMTUD（默认）



# 查看内核维护的 PMTU 缓存

$ ip route show cache

PMTU 黑洞是生产环境中一个常见问题——当 ICMP “Fragmentation Needed” 消息被防火墙拦截时，发送端无法得知正确的 MTU 值，导致大包无法到达目的地。解决方案是手动设置 MSS 钳位：

1
2
3
4
5
# iptables 设置 MSS 钳位（解决 PMTU 黑洞）

$ iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu



# 或者在 docker/容器环境中设置

$ iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

四、Netfilter 与 iptables/nftables

Netfilter 是 Linux 内核中的一个数据包过滤框架，它允许在内核网络协议栈的关键位置注册钩子函数，从而实现防火墙、NAT、数据包修改等功能。iptables 和 nftables 都是 Netfilter 框架的用户态配置工具。

4.1 Netfilter 钩子点

Netfilter 在内核网络协议栈中定义了 5 个关键钩子点：

数据包在协议栈各层间穿梭时，每经过一个钩子点就会检查是否有注册的钩子函数需要执行。钩子函数可以返回以下几种裁决：

• 1

  NF_ACCEPT

  ：继续正常流程

• 1

  NF_DROP

  ：丢弃数据包

• 1

  NF_QUEUE

  ：将数据包交给用户态程序处理

• 1

  NF_REPEAT

  ：重新执行当前钩子点

• 1

  NF_STOLEN

  ：钩子函数接管数据包所有权

4.2 nftables 实战配置

nftables 是 iptables 的继任者，它统一了 IPv4 和 IPv6 的处理，语法更清晰，性能也更好：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
# 一个完整的 nftables 防火墙配置示例

#!/usr/sbin/nft -f



flush ruleset



table inet filter {

    chain input {

        type filter hook input priority 0; policy drop;



        # 允许已建立连接的流量

        ct state established,related accept



        # 允许本地环回流量

        iif lo accept



        # 允许 ICMP (ping)

        ip protocol icmp accept



        # 开放 SSH 端口

        tcp dport 22 accept



        # 开放 HTTP/HTTPS

        tcp dport {80, 443} accept



        # 记录并丢弃其他流量

        log prefix "INPUT_DROP: " flags all counter drop

    }



    chain forward {

        type filter hook forward priority 0; policy drop;



        # 允许已建立连接

        ct state established,related accept

    }



    chain output {

        type filter hook output priority 0; policy accept

    }

}



table inet nat {

    chain prerouting {

        type nat hook prerouting priority -100;



        # 端口转发: 将 8080 端口转发到内网 192.168.1.100:80

        tcp dport 8080 dnat to 192.168.1.100:80

    }



    chain postrouting {

        type nat hook postrouting priority 100;



        # MASQUERADE: 让内网机器通过本机上网

        oif eth0 masquerade

    }

}

保存并应用上述配置：

1
2
3
4
5
6
7
8
# 保存配置到文件

$ nft -f /etc/nftables.conf



# 查看当前规则集

$ nft list ruleset



# 添加临时的规则（允许某个特定 IP 访问）

$ nft add rule inet filter input ip saddr 10.0.0.5 tcp dport 22 accept

4.3 conntrack：连接跟踪

连接跟踪（Connection Tracking）是 Netfilter 框架中一个非常重要的子系统。它使得有状态防火墙成为可能——内核会记录每个网络连接的状态（NEW、ESTABLISHED、RELATED、INVALID），从而允许基于连接状态的过滤规则。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 查看连接跟踪表

$ conntrack -L

tcp      6 431995 ESTABLISHED src=192.168.1.100 dst=8.8.8.8 sport=54321 dport=80



# 查看连接跟踪统计

$ conntrack -S

cpu=0   found=128 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 ...



# 连接跟踪表的最大条目数（内存限制）

$ sysctl net.netfilter.nf_conntrack_max

net.netfilter.nf_conntrack_max = 262144



# 如果 conntrack 表满了，新连接会被丢弃，日志中会出现 "nf_conntrack: table full"

# 可以适当增大或者降低超时时间

$ sysctl -w net.netfilter.nf_conntrack_max=1048576

$ sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=86400

高并发服务器上 conntrack 表溢出是常见的性能问题。当 nf_conntrack_max 太小时，新连接无法建立；当太大时又可能占用过多内存。每个连接跟踪条目大约占用 352 字节内存，100 万个连接约消耗 350MB 内存。

五、网络设备与数据包接收路径

数据包的网络之旅始于网络设备。理解网卡驱动、NAPI、中断处理机制对优化网络性能至关重要。

5.1 NAPI 与中断合并

传统方式下，每个数据包到达都会触发一次硬件中断。在高吞吐量场景下，这会导致”中断风暴”，CPU 几乎把所有时间都花在处理中断上。NAPI（New API）解决了这个问题：

1. 第一个数据包到达时触发中断
2. 中断处理程序关闭中断，切换到轮询模式
3. 持续从网卡读取数据包，直到没有更多数据或达到配额
4. 重新启用中断

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 查看网卡的中断合并设置

$ ethtool -c eth0

Coalesce parameters for eth0:

        rx-usecs: 50        # 接收延迟 50 微秒

        tx-usecs: 50

        rx-frames: 64       # 每 64 个帧触发一次中断

        tx-frames: 64



# 调整中断合并（降低延迟但增加 CPU 开销）

$ ethtool -C eth0 rx-usecs 10



# 调整 NAPI 权重（每次轮询最多处理的数据包数）

$ sysctl net.core.netdev_budget

net.core.netdev_budget = 300

5.2 RPS/RFS 与多队列网卡

现代多核服务器上，单 CPU 处理所有网络中断会成为瓶颈。多队列网卡（如 Intel XL710、Mellanox ConnectX 系列）配合 RPS（Receive Packet Steering）和 RFS（Receive Flow Steering）可以将数据包分发到多个 CPU 核心处理：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# 查看网卡的队列数量

$ ethtool -l eth0

Channel parameters for eth0:

Pre-set maximums:

RX:             0

TX:             0

Other:          1

Combined:       8       # 8 个收发队列

Current hardware settings:

RX:             0

TX:             0

Other:          1

Combined:       8



# 配置 RPS（将 eth0 的 RX 队列分发到 CPU 0-3）

# 每个队列的 rps_cpus 是一个 bitmask

echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus



# 配置 RFS 的流表大小

$ sysctl net.core.rps_sock_flow_entries

net.core.rps_sock_flow_entries = 32768



# 每个 RX 队列的流表大小

echo 32768 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt

或

工具可以用来测试网络性能调优前后的对比效果，在有条件的情况下建议做实际的压测验证。

六、性能监控与调优

最后，我们来看一些常用的网络性能监控和调优方法：

6.1 关键性能指标与工具

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# 快速排查网络性能问题的命令集合

# 1. 查看系统网络错误统计

$ nstat -az | grep -i drop

TcpExtListenDrops              1                  0.0

TcpExtTCPBacklogDrop           0                  0.0

TcpExtPAWSActive               0                  0.0



# 2. 查看网卡硬件丢包

$ ethtool -S eth0 | grep -i error

     rx_crc_errors: 0

     rx_frame_errors: 0

     rx_fifo_errors: 0

     tx_fifo_errors: 0



# 3. 查看 socket 缓冲区使用情况

$ ss -t -i | head -10

State   Recv-Q  Send-Q  Local:Port  Peer:Port

ESTAB   0       0       0.0.0.0:80  10.0.0.1:54321

         skmem:(r0,rb131072,t0,tb131072,f2048,w0,o0,bl0,d0)

# 其中 rb = receive buffer, tb = transmit buffer



# 4. tcpdump 抓包分析

$ tcpdump -i eth0 -n 'tcp port 80' -c 100

6.2 常见性能瓶颈与优化方向

以下是生产环境中常见的网络性能问题及其优化方向：

• SYN 队列溢出：

  1	netstat -s | grep -i "SYN"

  查看 SYN dropped。调大

  1	net.ipv4.tcp_max_syn_backlog

  和

  1	net.core.somaxconn

  ，启用

  1	tcp_syncookies

• TIME_WAIT 过多：启用

  1	tcp_tw_reuse

  （4.12 以后内核）或调整

  1	tcp_fin_timeout

  。但注意：

  1	tcp_tw_recycle

  在 4.12 内核中已移除（存在 NAT 问题）

• 发送缓冲区不足：增大

  1

  tcp_wmem

  ，或使用

  1	setsockopt(SO_SNDBUF)

  调整

• 接收缓冲区不足：增大

  1

  tcp_rmem

  ，优化应用层读取速度

• 中断亲和性不均衡：使用

  1	irqbalance

  服务，或手动设置 /proc/irq/ 下的 CPU 亲和性

总结

本文从应用程序调用

开始，沿着数据包在内核网络协议栈中的完整路径，依次剖析了套接字层、TCP 协议栈、IP 层与路由子系统、Netfilter 框架以及网络设备驱动的核心原理。每一层都是经过数十年优化的杰作——套接字层的

通过指针操作避免了数据复制，TCP 拥塞控制算法在不同网络环境下自动调优，Netfilter 钩子框架提供了强大的数据包处理能力，而 NAPI 和 RSS/RPS 确保了多核环境下的高性能。

掌握这些知识不仅有助于排查网络问题，还能帮助你在设计高并发系统时做出更合理的架构决策。例如，理解 conntrack 的内存开销会在设计 Kubernetes 集群时更加谨慎地规划 pod 数量；理解 TCP 缓冲区大小的影响会在优化 Nginx/HAProxy 时有更明确的方向。

建议读者结合文中给出的

参数、

命令和

抓包工具在实际的生产环境中逐步积累经验。纸上得来终觉浅，将这些理论知识转化为排查问题的直觉，才是掌握 Linux 网络协议栈的真谛。