第四章：用户态协议栈：设计一个简单的TCP栈。自己动手，丰衣足食。
说实话，很多做网络优化的朋友，一听到「协议栈」三个字就头大。觉得那是Linux内核里几千行C代码的庞然大物，碰都不敢碰。
但我告诉你，在低延迟场景下，内核协议栈恰恰是最大的瓶颈之一。你想想看，每次收发数据都要经过系统调用、软中断、内存拷贝……这一套流程下来，几十微秒就没了。对于高频交易、游戏服务器这些场景，这简直是灾难。
所以，自己动手撸一个用户态TCP栈，不是炫技，是刚需。说白了，就是把网络协议的处理逻辑从内核搬到你自己的进程里，绕过那些不必要的开销。
4.1 为什么要在用户态搞TCP？
我在做量化交易系统的时候，遇到过这么个事：两台机器通过万兆网卡直连，用内核TCP跑，延迟死活压不到10微秒以下。后来换成用户态栈，直接降到了2-3微秒。差距就这么大。
用户态TCP栈的核心优势就三点：
- 零系统调用：收发包都在用户态完成，不用切内核态。
- 零拷贝：数据直接从网卡到应用缓冲区，不走内核内存。
- 完全控制：TCP的参数、重传策略、拥塞控制，你说了算。
当然，代价也很明显——你得自己处理TCP的复杂状态机。嗯，这里要注意，TCP可不是闹着玩的。
4.2 最简单的TCP栈长什么样？
一个最小可用的用户态TCP栈，至少需要搞定这几块：
- 网卡收发包：用DPDK或者AF_XDP直接从网卡拿数据。
- TCP状态机：管理连接的生命周期（SYN、ESTABLISHED、FIN等）。
- 发送与重传：维护发送缓冲区，超时没收到ACK就重传。
- 接收与重组：处理乱序包，拼成完整的应用数据流。
我个人习惯，先从最简单的「回显服务器」开始练手。就是客户端发什么，服务器原样返回。这样TCP状态机只需要处理ESTABLISHED状态，省掉连接建立和关闭的麻烦。
核心思路：用户态TCP栈 = 网卡驱动 + TCP协议处理 + 应用接口。这三层之间用无锁队列通信，避免锁竞争。
4.3 动手：实现一个迷你TCP栈
下面我给出一个极度简化的示例。它只处理ESTABLISHED状态下的数据收发，但骨架是完整的。
// 伪代码：用户态TCP栈核心结构
struct tcp_socket {
uint32_t snd_nxt; // 下一个要发送的序号
uint32_t rcv_nxt; // 下一个期望接收的序号
uint16_t local_port;
uint16_t remote_port;
uint32_t local_ip;
uint32_t remote_ip;
// 发送缓冲区（环形队列）
struct ring_buffer *send_buf;
// 接收缓冲区
struct ring_buffer *recv_buf;
// 状态
enum tcp_state state;
};
// 发送一个TCP段
int tcp_send(struct tcp_socket *sk, const char *data, int len) {
// 1. 构造TCP头部
struct tcp_hdr *hdr = alloc_packet();
hdr->src_port = sk->local_port;
hdr->dst_port = sk->remote_port;
hdr->seq = htonl(sk->snd_nxt);
hdr->ack_seq = htonl(sk->rcv_nxt);
hdr->flags = TCP_ACK;
hdr->window = htons(65535);
// 2. 拷贝数据
memcpy(hdr + 1, data, len);
// 3. 计算校验和（伪头部+TCP头+数据）
hdr->checksum = tcp_checksum(sk->local_ip, sk->remote_ip,
hdr, len + sizeof(*hdr));
// 4. 通过网卡发送
nic_send_packet(hdr, len + sizeof(*hdr));
// 5. 更新序号
sk->snd_nxt += len;
// 6. 加入重传队列（这里简化了）
add_to_retransmit_queue(sk, hdr, len);
return len;
}
// 接收一个TCP段（从网卡回调）
void tcp_receive(struct tcp_socket *sk, struct packet *pkt) {
struct tcp_hdr *hdr = (struct tcp_hdr *)pkt->data;
int payload_len = pkt->len - sizeof(*hdr);
char *payload = pkt->data + sizeof(*hdr);
// 1. 检查序号是否匹配
if (ntohl(hdr->seq) != sk->rcv_nxt) {
// 乱序包，这里简化处理：直接丢弃
// 实际应该缓存起来
return;
}
// 2. 拷贝数据到接收缓冲区
ring_buffer_write(sk->recv_buf, payload, payload_len);
// 3. 更新期望序号
sk->rcv_nxt += payload_len;
// 4. 发送ACK
send_ack(sk);
}避坑指南：我曾经在计算TCP校验和时，忘了包含伪头部（pseudo header）。结果抓包一看，所有包都被网卡丢弃了。排查了整整一天。记住，TCP校验和的计算范围是：伪头部 + TCP头部 + 数据。伪头部包含源IP、目的IP、协议号、TCP长度。
4.4 状态机：TCP的灵魂
上面那个例子跳过了状态机，但实际项目中你躲不开。TCP有11个状态，最核心的迁移路径是这样的：
| 当前状态 | 事件 | 下一状态 | 动作 |
|---|---|---|---|
| CLOSED | 应用调用listen() | LISTEN | 等待SYN |
| LISTEN | 收到SYN | SYN_RCVD | 发送SYN+ACK |
| SYN_RCVD | 收到ACK | ESTABLISHED | 连接建立 |
| ESTABLISHED | 收到FIN | CLOSE_WAIT | 发送ACK，等待应用关闭 |
| CLOSE_WAIT | 应用调用close() | LAST_ACK | 发送FIN |
| LAST_ACK | 收到ACK | CLOSED | 连接关闭 |
我建议你实现状态机时，用一张二维表来驱动。行是当前状态，列是事件，交叉点就是下一状态和回调函数。这样代码清晰，也容易扩展。
4.5 性能调优：从能用到好用
一个能跑的TCP栈和能上生产的TCP栈，差距在哪？我总结了几点：
- 重传定时器：不要用固定的超时时间。用RTT估算动态调整。我习惯用Karn算法，简单有效。
- 滑动窗口：接收窗口要动态通告，避免发送方把接收缓冲区撑爆。
- Nagle算法：低延迟场景下，建议关闭。否则小包会被延迟合并，增加延迟。
- 内存池：频繁分配释放小包会导致碎片。用预分配的slab分配器，性能提升明显。
警告：用户态TCP栈最大的坑是「丢包恢复」。内核有完整的超时重传和快速重传机制，你自己实现时很容易漏掉边界情况。比如：收到三个重复ACK才触发快速重传，这个阈值不能随便改。我曾经为了追求激进，把阈值改成1，结果网络抖动时疯狂重传，把带宽吃光了。
4.6 什么时候该用，什么时候不该用？
用户态TCP栈不是银弹。我个人的经验是：
- 该用：延迟敏感、吞吐量要求高、网络环境可控（比如数据中心内部）。
- 不该用：公网环境、需要兼容各种网卡、开发周期紧、团队没有网络协议专家。
说白了，你是在用开发复杂度换性能。如果你的应用延迟要求是毫秒级，内核TCP完全够用。只有到了微秒级，才值得你动手。
嗯，这一章就到这里。下一章我会带你深入DPDK，看看怎么从网卡直接撸数据包。那才是用户态协议栈的真正起点。