2、Linux网络协议栈架构：从Socket到网线
做网络优化，第一件事就是搞清楚数据到底走了哪些路。我见过不少工程师，上来就调参数，结果连数据在哪层丢的都没搞明白。说白了，你得先看懂Linux网络协议栈这张地图。
这一章，我们就从应用层一路往下，走到物理网线。我会结合自己踩过的坑，把每一层的关键点讲清楚。
2.1 整体架构：数据包的奇幻漂流
先看一张总图。你心里要有个全景，后面每层细节才不会乱。
数据从应用发出，经过Socket、传输层、网络层、链路层，最后通过网卡发出去。接收方向反过来。每一层都有自己的缓存、队列和协议逻辑。你想想看，一个包走完这五层，中间要经历多少次拷贝、多少次上下文切换？
核心认知：协议栈优化的本质，就是减少每一层的开销。不是只调一个参数就能解决的。
2.2 Socket层：应用与内核的边界
Socket层是用户态和内核态的分界线。应用调用 send() 或 recv()，实际上是一次系统调用，触发上下文切换。
我个人习惯把Socket层看作一个「文件描述符管理器」。Linux里一切皆文件，Socket也不例外。它背后挂着一套VFS（虚拟文件系统）的操作函数表。
2.2.1 Socket的创建与绑定
看一段简单的代码，你就明白了：
int sock_fd = socket(AF_INET, SOCK_STREAM, 0);
struct sockaddr_in addr;
addr.sin_family = AF_INET;
addr.sin_port = htons(8080);
addr.sin_addr.s_addr = INADDR_ANY;
bind(sock_fd, (struct sockaddr*)&addr, sizeof(addr));
listen(sock_fd, 128);每一步都对应内核里的一个结构体：
| 系统调用 | 内核动作 | 关键数据结构 |
|---|---|---|
socket() | 创建socket对象，分配fd | struct socket, struct sock |
bind() | 绑定本地地址和端口 | struct sockaddr_in |
listen() | 进入监听状态，建立半连接队列 | struct listen_sock |
accept() | 从已完成队列取连接 | struct request_sock |
避坑指南：我曾经遇到一个性能问题，应用层频繁创建和销毁Socket，导致系统调用开销巨大。后来改用连接池，吞吐直接翻倍。记住，系统调用不是免费的。
2.3 传输层：TCP与UDP的博弈
传输层是协议栈里最复杂的一层。TCP要保证可靠，UDP追求速度。你选哪个，决定了后续优化的方向。
2.3.1 TCP的核心机制
TCP为什么慢？因为它做了太多事：
- 三次握手：建立连接要1.5个RTT
- 拥塞控制：慢启动、拥塞避免、快重传、快恢复
- 流量控制：滑动窗口，接收方通知发送方还能发多少
- 确认重传：每个包都要ACK，丢了重传
我记得有一次调优，发现应用吞吐上不去，抓包一看，TCP窗口一直在0和65535之间震荡。说白了，接收方处理不过来，一直在压窗口。这不是网络问题，是应用层消费太慢。
2.3.2 UDP的简单与风险
UDP就简单多了。无连接、无确认、无重传。发出去就不管了。适合实时音视频、DNS查询这类场景。
但UDP也有坑。我曾经在项目中用UDP做自定义协议，结果公网环境下丢包率高达5%。后来不得不自己实现ACK和重传机制，说白了就是造了一个简化版TCP。
| 特性 | TCP | UDP |
|---|---|---|
| 连接 | 面向连接 | 无连接 |
| 可靠性 | 可靠，有ACK和重传 | 不可靠，尽力交付 |
| 顺序 | 保证有序 | 不保证 |
| 开销 | 高（头部20字节+） | 低（头部8字节） |
| 适用场景 | 文件传输、Web、邮件 | 直播、游戏、DNS |
2.4 网络层：路由与过滤
网络层负责把包从源地址送到目的地址。核心是IP协议，加上路由表和Netfilter框架。
2.4.1 IP协议与路由
每个IP包都包含源IP和目的IP。内核通过路由表决定下一跳。你可以用 ip route 查看：
$ ip route
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路由查找是网络层的主要开销之一。内核会缓存最近使用的路由，但路由表很大的时候，查找延迟会上升。
2.4.2 Netfilter与iptables
Netfilter是Linux内核的包过滤框架。iptables、nftables都基于它。每个包经过网络层时，会经过多个hook点：
- PREROUTING：包刚进来，还没做路由决策
- INPUT：包要发给本机
- FORWARD：包要转发到其他机器
- OUTPUT：本机发出的包
- POSTROUTING：包要出去了，最后一道
注意：iptables规则越多，每个包的处理延迟越大。我曾经在一个高并发网关上看过，iptables规则超过200条，吞吐直接掉了30%。能精简就精简，或者用nftables替代。
2.5 数据链路层：与硬件打交道
数据链路层是协议栈的最底层，直接和网卡驱动交互。这里的关键是Ring Buffer和NAPI。
2.5.1 Ring Buffer
网卡收到数据后，通过DMA直接把数据写到内存里的Ring Buffer。然后触发中断通知CPU。Ring Buffer的大小直接影响丢包率。
你可以用 ethtool 查看和调整：
$ ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX: 4096
TX: 4096
Current hardware settings:
RX: 512
TX: 512我建议在流量大的机器上把RX/TX都调到最大。但注意，Ring Buffer太大也会增加延迟，需要权衡。
2.5.2 NAPI与中断合并
传统方式：每个包都触发中断。高PPS下CPU直接被中断打爆。
NAPI（New API）的做法：第一个包来的时候触发中断，然后切换到轮询模式，批量收包。收完再切回中断模式。这大大降低了中断频率。
调优经验：我曾经在40G网卡上做测试，默认中断合并参数下，小包PPS只能到200万。调整 ethtool -C eth0 rx-usecs 50 后，PPS直接冲到800万。中断合并不是越大越好，要根据业务场景调。
2.6 各层性能开销对比
下面这张表是我在实际项目中测出来的典型开销分布。注意，不同硬件和内核版本会有差异，但趋势是一致的。
| 层级 | 主要开销 | 典型延迟占比 | 优化方向 |
|---|---|---|---|
| Socket层 | 系统调用、上下文切换 | 15% - 25% | 减少系统调用、使用epoll |
| 传输层 | TCP协议处理、重传、窗口管理 | 30% - 40% | 调整TCP参数、使用UDP |
| 网络层 | 路由查找、Netfilter规则匹配 | 10% - 15% | 精简iptables、使用路由缓存 |
| 数据链路层 | 中断处理、内存拷贝、DMA | 20% - 30% | NAPI、Ring Buffer调优、大页内存 |
你看，传输层和数据链路层占了大部分开销。所以优化要优先盯这两层。
2.7 本章小结
Linux网络协议栈不是黑盒。从Socket到网线，每一层都有明确的代码路径和数据结构。你理解了每一层的职责和瓶颈，才能精准优化。
嗯，这里要记住一个原则：不要跨层优化。应用层的问题不要到链路层去找，反之亦然。先定位问题在哪一层，再动手。