DPDK on JasperSao的博客

DPDK 用户态 TCP 协议栈（四）：并发与自实现 epoll

Tue, 18 Aug 2026 00:00:00 +0800

本篇只围绕一个问题展开：用户态 TCP 协议栈怎样让一个应用线程并发管理多条 TCP 连接？

前三篇已经反复讲过 DPDK 收发、mbuf、Ethernet/IPv4/TCP 解析、三次握手、SEQ/ACK、TCP 状态机和 POSIX Socket。本篇只在它们影响 epoll 逻辑时简要回顾，不再重新逐层讲包头和握手细节。

一、先给出整篇的核心答案

TCP 并发 epoll 的实现可以浓缩成一个闭环：

1. 每条 TCP 连接拥有独立的 stream/TCB 和用户态 fd
2. 应用通过 epoll_ctl 注册“我关心哪些 fd 的哪些事件”
3. 协议栈处理报文时发现某个 fd 已经可读或可写
4. 协议栈调用 epoll 回调，把该 fd 放入就绪队列
5. 回调唤醒阻塞在 epoll_wait 的应用线程
6. epoll_wait 返回就绪 fd，应用执行 accept/recv/send/close
7. 应用重新进入 epoll_wait，继续管理所有连接

epoll 没有让 TCP 报文并行到达，也没有替协议栈处理握手。它解决的是：

当许多连接都可能产生数据时，应用怎样只处理当前已经就绪的连接，而不是为每条连接创建一个长期阻塞的线程。

理解本篇时始终抓住三种对象：

对象	解决的问题
`ng_tcp_stream`	这是谁的连接，当前 TCP 状态和数据是什么
`epitem`	应用是否关注这个 fd，它现在是否就绪
`eventpoll`	一个 epoll 实例管理的整集、就绪集和等待线程

二、只保留必要的旧知识：数据最终从哪里来到哪里去

完整程序有三个长期运行的执行流：

main/lcore：网卡 RX/TX
 ↕ 全局 in/out ring
pkt_process/lcore：Ethernet/IP/TCP 解析、TCP 输出封包
 ↕ 每连接 rcvbuf/sndbuf
tcp_server_entry/lcore：accept、recv、send、epoll_wait

两层 ring 不要混淆：

全局 ring->in/out 传递 rte_mbuf *，用于网卡线程与协议处理线程之间传包。
每个 ng_tcp_stream 的 rcvbuf/sndbuf 传递 TCP fragment，用于协议栈与应用之间传数据。

一段客户端数据的最短路径是：

网卡 RX
→ 全局 in ring
→ ng_tcp_process()
→ 按四元组找到 stream
→ payload 放入 stream->rcvbuf
→ 触发 EPOLLIN
→ nepoll_wait() 返回 connfd
→ 应用 nrecv(connfd)

应用响应的路径相反：

nsend(connfd)
→ fragment 放入 stream->sndbuf
→ ng_tcp_out() 取出并封装 TCP 报文
→ 全局 out ring
→ 网卡 TX

这些收发与报文构造细节在前几篇已有完整说明。本篇真正关心的是中间这一步：

stream 的状态发生变化
→ 怎样让正在等待的应用知道？

三、支持并发的第一前提：连接必须彼此独立

1. 一条连接对应一个 `ng_tcp_stream`

struct ng_tcp_stream {
 int fd;

 uint32_t sip, dip;
 uint16_t sport, dport;
 uint8_t protocol;

 uint32_t snd_nxt;
 uint32_t rcv_nxt;
 NG_TCP_STATUS status;

 struct rte_ring *sndbuf;
 struct rte_ring *rcvbuf;

 pthread_cond_t cond;
 pthread_mutex_t mutex;
};

它是本代码中的简化 TCB。每个客户端都必须拥有独立的：

地址与端口；
TCP 状态；
SEQ/ACK；
接收和发送缓冲区；
用户态 fd；
阻塞与唤醒状态。

因此，TCP 并发的根基不是 epoll，而是连接级状态隔离。如果两条连接共用序列号或接收缓冲区，换成 epoll 也不能让协议栈正确并发。

2. 报文怎样找到自己的 stream

if (iter->sip == sip && iter->dip == dip &&
 iter->sport == sport && iter->dport == dport) {
 return iter;
}

一般网络流用五元组标识；这里已经确定是 TCP，所以搜索时比较四元组。两个客户端连接同一个服务端地址和端口时，客户端 IP 或源端口不同，因此能找到不同的 stream。

3. 监听 stream 和连接 stream

服务端只有一个监听 stream，但可以有许多已连接 stream：

listenfd / LISTEN stream
 ├── connfd A / ESTABLISHED stream A
 ├── connfd B / ESTABLISHED stream B
 └── connfd C / ESTABLISHED stream C

收到 SYN 时，协议栈保留监听 stream，并创建一个新的连接 stream 处理该客户端：

struct ng_tcp_stream *syn = ng_tcp_stream_create(
 iphdr->src_addr, iphdr->dst_addr,
 tcphdr->src_port, tcphdr->dst_port);

LL_ADD(syn, table->tcb_set);
syn->status = NG_TCP_STATUS_SYN_RCVD;

监听对象负责“还能不能接新连接”，连接对象负责“这个客户端的数据和状态”。epoll 后面会分别监听这两类 fd。

四、一连接一线程为什么能工作，又为什么需要 epoll

1. 一连接一线程

最直观的并发方式是：

主线程：不断 naccept()
连接 A：线程 A 阻塞在 nrecv(A)
连接 B：线程 B 阻塞在 nrecv(B)
连接 C：线程 C 阻塞在 nrecv(C)

它适合验证连接表、stream 隔离和收发缓冲区是否支持多个客户端。问题是大部分连接经常没有数据，线程却仍占用栈空间和调度资源。连接数增长时，线程数也同步增长。

2. epoll 的改变

epoll 模型下，应用线程不阻塞在某一个 nrecv(connfd) 上，而是阻塞在“所有已注册 fd 的就绪集合”上：

应用线程：nepoll_wait(A, B, C, ...)

只有 B 有数据
→ nepoll_wait 只返回 B
→ 应用处理 B
→ 再次等待所有连接

所以两种模型的区别不是 TCP 连接数，而是等待位置：

一连接一线程：每个线程等待一个 fd
epoll：一个线程等待一组 fd

五、为什么不能直接调用 Linux 原生 epoll

代码中的 listenfd、connfd 和 epfd 由自己的位图分配：

static int get_fd_frombitmap(void) {
 for (int fd = DEFAULT_FD_NUM; fd < MAX_FD_COUNT; fd++) {
 if (fd_table 中该位空闲) {
 标记为已用;
 return fd;
 }
 }
 return -1;
}

这些整数只在用户态协议栈内部有意义：

用户态 fd
→ get_hostinfo_fromfd(fd)
→ ng_tcp_stream / localhost / eventpoll

Linux 内核没有创建对应的 socket 对象，也不知道 stream->rcvbuf 是否有数据。因此把这种 connfd 传给内核 epoll_ctl()，内核无法监听它。

既然 Socket API 是用户态自己实现的，事件机制也要自己补齐：

nsocket / nbind / nlisten / naccept / nrecv / nsend
 +
nepoll_create / nepoll_ctl / nepoll_wait

六、理解 epoll 的关键：就绪是一种状态

应用关注的不是“是否来过一个包”，而是“现在执行某个操作会不会阻塞”。

1. 监听 fd 可读

监听 fd 的 EPOLLIN 表示：

至少有一条已完成握手的连接可以被 naccept() 取出

它不是说监听 socket 收到了应用 payload，而是说 accept 现在不会阻塞。

2. 连接 fd 可读

连接 fd 的 EPOLLIN 表示：

nrecv() 现在可以取得 payload，或者取得 EOF/关闭信息

因此，收到 FIN 也可以触发 EPOLLIN。应用随后调用 nrecv() 得到 0，知道对端已关闭。

3. 连接 fd 可写

EPOLLOUT 的一般含义是：发送缓冲区有空间，send 不会因为缓冲区已满而阻塞。它不等于“一个数据包已经从网卡发完”。

本节代码重点实现的是 EPOLLIN 链路；要完整支持 EPOLLOUT，还需要定义 sndbuf 从满变为可用时怎样产生通知。

这一点非常重要：

epoll 事件是 Socket 操作条件的变化，不是对每个网络包做一次简单转发。

七、epoll 的两个集合

一个 epoll 实例内部有两份不同用途的集合。

1. 整集：我关注谁

整集保存所有通过 EPOLL_CTL_ADD 注册的 fd。代码用红黑树组织，以 sockfd 为 key：

整集 = {listenfd, connfd_A, connfd_B, connfd_C, ...}

它回答：

这个 fd 是否被注册？
应用对它关心 EPOLLIN 还是 EPOLLOUT？
ADD/DEL/MOD 应该操作哪个节点？

红黑树提供稳定的 O(log n) 查找、插入和删除，并能随注册数量按节点增长。哈希的平均查找更快，但要额外处理桶容量、冲突和扩容。这里选择红黑树的重点是动态集合与稳定性能，并不是红黑树在所有场景都绝对更快。

2. 就绪集：现在谁能处理

就绪集是链表，只保存当前已经产生事件的节点：

整集：{listenfd, A, B, C, D}
就绪集：{B, D}

nepoll_wait() 无须扫描整棵红黑树，只需从就绪链表取出 B、D。

3. 同一个节点同时属于两份集合

struct epitem {
 RB_ENTRY(epitem) rbn;
 LIST_ENTRY(epitem) rdlink;

 int rdy;
 int sockfd;
 struct epoll_event event;
};

一个 epitem 中同时有红黑树节点和链表节点：

rbn：长期挂在整集，表示注册关系
rdlink：就绪时临时挂在就绪链表
rdy：防止同一节点被重复插入就绪链表

节点进入就绪链表后仍保留在红黑树里。应用消费一次就绪事件，不等于取消对这个 fd 的关注；只有 EPOLL_CTL_DEL 才删除注册关系。

4. `eventpoll` 管理整个 epoll 实例

struct eventpoll {
 int fd;

 ep_rb_tree rbr;
 int rbcnt;

 LIST_HEAD(, epitem) rdlist;
 int rdnum;

 pthread_mutex_t mtx;
 pthread_spinlock_t lock;
 pthread_cond_t cond;
 pthread_mutex_t cdmtx;
};

关系可以画成：

epfd
└── eventpoll
 ├── rbr：全部已注册 epitem
 ├── rdlist：当前就绪 epitem
 └── cond：没有就绪事件时，让 nepoll_wait 睡眠

八、三个外部接口怎样组成应用侧逻辑

1. `nepoll_create()`：创建事件管理器

它做的事情不是创建 TCP 连接，而是创建一个 eventpoll：

分配 epfd
→ 分配 eventpoll
→ 初始化红黑树
→ 初始化就绪链表
→ 初始化锁与条件变量
→ 建立 epfd 到 eventpoll 的映射

应用以后通过 epfd 找到这一整套事件管理状态。

2. `nepoll_ctl()`：维护整集

ADD：树中不存在 → 分配 epitem → 插入红黑树
DEL：树中存在 → 从红黑树移除 → 释放 epitem
MOD：树中存在 → 修改关注的事件

因此，nepoll_ctl() 只是在表达应用的兴趣：

“如果这个 fd 以后出现我关心的状态，请通知我。”

注册本身不会凭空制造事件。

3. `nepoll_wait()`：没有事件就睡，有事件就返回

while (ep->rdnum == 0 && timeout != 0) {
 if (timeout > 0)
 pthread_cond_timedwait(&ep->cond, &ep->cdmtx, ...);
 else if (timeout < 0)
 pthread_cond_wait(&ep->cond, &ep->cdmtx);
}

超时语义：

timeout < 0：一直等待；
timeout == 0：立即检查并返回；
timeout > 0：最多等待指定时长。

醒来后，它从就绪链表取出最多 maxevents 个节点，把其中的 epoll_event 复制给应用：

rdlist 中的 epitem
→ events[0...n-1]
→ 返回 nready

至此，epoll 只告诉应用“哪些 fd 可以处理”。真正的 accept/recv/send 仍由应用自己调用。

九、最关键的内部接口：协议栈怎样触发事件

三个 nepoll_* 接口面向应用；epoll_event_callback() 面向协议栈：

int epoll_event_callback(struct eventpoll *ep,
 int sockid, uint32_t event) {
 struct epitem *epi = RB_FIND(..., sockid);
 if (!epi)
 return -1;

 if (epi->rdy) {
 epi->event.events |= event;
 return 1;
 }

 pthread_spin_lock(&ep->lock);
 epi->rdy = 1;
 LIST_INSERT_HEAD(&ep->rdlist, epi, rdlink);
 ep->rdnum++;
 pthread_spin_unlock(&ep->lock);

 pthread_mutex_lock(&ep->cdmtx);
 pthread_cond_signal(&ep->cond);
 pthread_mutex_unlock(&ep->cdmtx);
}

它完成四步：

按 sockid 查整集
→ 把事件记录到对应 epitem
→ 把 epitem 加入就绪链表
→ signal 唤醒 nepoll_wait

如果节点已经在就绪链表中，就不重复插入，只合并事件位：

epi->event.events |= event;

这避免同一个 fd 连续收到多个通知时，在 rdlist 中出现多个相同节点。

epoll 模块在整体架构中的位置

协议栈 epoll 应用

握手完成 ─┐
收到数据 ─┼→ event_callback → rdlist → cond_signal → nepoll_wait
收到 FIN ─┘ ↓
 accept/recv/close

所以 epoll 不是协议栈之外的独立轮询器。它必须由协议栈在状态真正改变的地方主动通知。

十、用三条时间线彻底串起实现

时间线一：新客户端完成连接

① 客户端发送 SYN
② ng_tcp_process 找到 LISTEN stream
③ 为客户端创建新的 stream，进入 SYN_RCVD
④ 协议栈发送 SYN+ACK
⑤ 收到客户端 ACK，新 stream 进入 ESTABLISHED
⑥ 协议栈触发 listenfd 的 EPOLLIN
⑦ nepoll_wait 返回 listenfd
⑧ 应用调用 naccept(listenfd)
⑨ naccept 取出已建立 stream，为它分配 connfd
⑩ 应用用 EPOLL_CTL_ADD 把 connfd 加入 epoll

对应代码的关键通知：

stream->status = NG_TCP_STATUS_ESTABLISHED;

struct ng_tcp_stream *listener =
 ng_tcp_stream_search(0, 0, 0, stream->dport);

epoll_event_callback(table->ep, listener->fd, EPOLLIN);

为什么通知 listener->fd，而不是新连接的 fd？

因为此时应用还没有执行 naccept()，新 stream 还没有分配给应用使用的 connfd。对应用来说，当前可执行的动作是 accept(listenfd)，所以就绪的是监听 fd。

时间线二：已连接客户端发送 payload

① 报文按四元组找到 established stream
② 协议栈复制 payload，构造 fragment
③ fragment 进入 stream->rcvbuf
④ 协议栈触发 stream->fd 的 EPOLLIN
⑤ callback 找到 connfd 对应的 epitem
⑥ epitem 进入 rdlist，唤醒 nepoll_wait
⑦ 应用得到 connfd
⑧ 应用调用 nrecv(connfd)，从该 stream 的 rcvbuf 取数据

关键顺序必须是：

先让数据真正可读
→ 再发布 EPOLLIN

否则应用被唤醒后可能发现 rcvbuf 仍为空。

时间线三：客户端发送 FIN

① 协议栈收到 FIN
② stream 进入 CLOSE_WAIT
③ rcvbuf 中放入长度为 0 的 fragment，表示 EOF
④ 触发 connfd 的 EPOLLIN
⑤ nepoll_wait 返回 connfd
⑥ nrecv(connfd) 返回 0
⑦ 应用 EPOLL_CTL_DEL，然后 nclose(connfd)

这条时间线解释了为什么“关闭”也能通过可读事件交给应用：读取操作已经不会阻塞，只是结果为 EOF。

十一、epoll 服务器循环现在应该怎样读

int epfd = nepoll_create(1);

ev.events = EPOLLIN;
ev.data.fd = listenfd;
nepoll_ctl(epfd, EPOLL_CTL_ADD, listenfd, &ev);

while (1) {
 int nready = nepoll_wait(epfd, events, 128, 5);

 for (int i = 0; i < nready; i++) {
 if (events[i].data.fd == listenfd) {
 int connfd = naccept(listenfd, ...);

 ev.events = EPOLLIN;
 ev.data.fd = connfd;
 nepoll_ctl(epfd, EPOLL_CTL_ADD, connfd, &ev);
 } else {
 int connfd = events[i].data.fd;
 int n = nrecv(connfd, buff, BUFFER_SIZE, 0);

 if (n > 0) {
 nsend(connfd, buff, n, 0);
 } else {
 nepoll_ctl(epfd, EPOLL_CTL_DEL, connfd, NULL);
 nclose(connfd);
 }
 }
 }
}

不要只把它看成一个 API 调用顺序。这个循环其实在处理两类状态机入口：

listenfd 就绪
→ 连接管理路径
→ accept 新连接并将 connfd 注册进 epoll

connfd 就绪
→ 数据路径或关闭路径
→ recv 数据，或者识别 EOF 后移除连接

多个客户端的并发体现在：所有 connfd 都在同一棵红黑树中，但某一时刻只有真正就绪的连接进入 rdlist。

十二、薄弱但非常重要：LT、ET 与“消费事件”

理解整集和就绪集后，还必须区分两种事件语义。

1. LT：Level Triggered，水平触发

只要可读条件仍然成立，就应该继续报告：

rcvbuf 里还有数据
→ fd 仍然可读
→ 下一次 epoll_wait 仍应返回它

应用可以一次只读一部分，剩余数据会让 fd 继续保持就绪。

2. ET：Edge Triggered，边沿触发

只在状态从“不可读”变为“可读”的边沿通知一次：

rcvbuf：空 → 非空
→ 触发一次 EPOLLIN

如果应用没有把数据一直读到 EAGAIN，而 rcvbuf 始终保持非空，就可能没有新的空→非空边沿，因此也不会再次收到通知。

3. 当前学习代码的核心行为

epoll_event_callback() 把节点加入 rdlist；nepoll_wait() 返回后将其移出并清除 rdy。以后再次发生协议栈回调时，节点才能重新加入。

这更接近“协议栈事件通知队列”的实现骨架。要形成严格的 LT 或 ET，还需要把就绪谓词定义清楚：

监听 fd 可读：accept 队列非空
连接 fd 可读：rcvbuf 非空，或存在 EOF/错误
连接 fd 可写：sndbuf 有可用空间

然后选择策略：

LT：epoll_wait 返回事件后，如果谓词仍为真，应保留或重新加入就绪集。
ET：只有谓词从假变真时才入就绪集，应用必须把资源处理到再次变为假。

这部分是自实现 epoll 最容易遗漏的核心：就绪链表只是结果，真正决定事件语义的是状态谓词和重新入队规则。

十三、线程同步：为什么需要三种同步手段

代码中不同锁保护不同对象：

同步对象	主要保护内容
`ep->mtx`	红黑树的 ADD/DEL/MOD
`ep->lock` 自旋锁	短时间修改 `rdlist`、`rdnum`、`rdy`
`ep->cdmtx + cond`	`nepoll_wait` 睡眠与协议栈唤醒

1. 为什么等待必须检查条件

正确思路不是“收到 signal 就相信一定有事件”，而是：

while (ep->rdnum == 0)
 pthread_cond_wait(...);

条件变量可能虚假唤醒，也可能多个等待者竞争同一批事件。醒来后必须重新检查 rdnum。

同理，nrecv() 等待数据时也使用循环检查 rcvbuf，而不是单次 if。

2. 为什么先入就绪集，再 signal

发布顺序是：

修改受保护状态：epitem 进入 rdlist，rdnum++
→ 再 signal

signal 的作用只是提醒等待线程重新检查条件；真正可信的是受锁保护的 rdlist/rdnum。

3. `DEL` 与回调之间的关系

应用关闭连接时会删除 epitem，协议栈线程则可能正在为同一 fd 触发回调。完整实现必须让红黑树查找、节点删除和就绪链表访问遵守一致的生命周期规则，避免回调继续访问已经释放的节点。

这里不展开代码审查，只需记住：并发数据结构除了“查得快”，还要保证节点从注册、就绪到删除期间始终有效。

十四、单 epoll 与多个 epoll

当前代码在创建时执行：

struct ng_tcp_table *table = tcpInstance();
table->ep = ep;

协议栈触发事件时也直接使用：

epoll_event_callback(table->ep, stream->fd, EPOLLIN);

这意味着当前教学实现默认整个 TCP table 只有一个 epoll。它足以展示完整通知链路，但还不能表达：

同一进程创建多个 epoll 实例；
不同 epoll 注册不同连接；
同一个 fd 同时被多个 epoll 关注。

扩展为多个 epoll 时，不能只保留一个 table->ep。需要建立：

epfd → eventpoll

以及

sockfd → 所有注册了该 sockfd 的 epitem/eventpoll

协议栈产生事件后，要找到所有相关订阅者并分别更新它们的就绪集。这实际上把单指针通知扩展成一对多的观察者关系。

十五、多连接 core dump 在本篇中的位置

多连接时暴露 core dump，说明“单连接路径成立”并不等于“所有连接级资源都已正确隔离”。本节笔记直接涉及的一点是：每条 stream 都会创建自己的 DPDK ring，而 DPDK 命名对象需要可区分的名称。

sprintf(sbufname, "sndbuf%x%d", sip, sport);
stream->sndbuf = rte_ring_create(sbufname, ...);

sprintf(rbufname, "bufname%x%d", sip, sport);
stream->rcvbuf = rte_ring_create(rbufname, ...);

这里用客户端 IP 和源端口区分连接 ring。要记住三层不同的身份：

四/五元组：让协议栈把报文分给正确 stream
DPDK ring 名称：让每条 stream 获得独立缓冲对象
用户态 fd：让应用和 epoll 找到正确 stream

本篇不继续展开具体崩溃排查，因为重点是 epoll 的事件闭环。

十六、把全部实现压缩成一张图

 应用线程
 │
 nepoll_ctl ADD │ 注册兴趣
 ▼
 ┌───────────────┐
 │ eventpoll │
 │ │
 │ 红黑树 rbr │ ← 全部注册 fd
 │ 就绪表 rdlist │ ← 当前就绪 fd
 │ cond │ ← 没事件时睡眠
 └───────┬───────┘
 │ nepoll_wait 返回
 ▼
 accept / recv / send / close
 ▲
 │ 用户态 fd → stream
 ┌───────┴────────┐
 │ ng_tcp_stream │
 │ 状态/SEQ/ACK │
 │ rcvbuf/sndbuf │
 └───────▲────────┘
 │
 ng_tcp_process 按四元组定位
 │
 握手完成 / payload 到达 / FIN 到达
 │
 epoll_event_callback
 │
 加入 rdlist + signal

从这张图可以看到，TCP 并发 epoll 不是单独一个数据结构，而是四套映射协作：

报文四元组 → stream
用户态 fd → stream
epfd → eventpoll
eventpoll 中 sockfd → epitem

缺少任何一层，事件都无法从报文准确传递到应用。

十七、最终应掌握的实现逻辑

多连接首先要求每条连接拥有独立 TCB、状态、序列号和收发缓冲区。
报文通过四元组找到 stream，应用通过用户态 fd 找到同一个 stream。
一连接一线程让每个线程阻塞等一个 fd；epoll 让一个线程等待一组 fd。
用户态 fd 不属于内核，因此必须自实现 epoll，不能直接交给 Linux epoll。
红黑树保存“关注谁”，就绪链表保存“现在谁能处理”。
nepoll_ctl() 建立兴趣关系，epoll_event_callback() 发布事件，nepoll_wait() 消费事件。
握手完成触发监听 fd 的 EPOLLIN，因为此时 accept 不再阻塞。
payload 或 FIN 到达触发连接 fd 的 EPOLLIN，因为此时 recv 能返回数据或 EOF。
必须先改变真实就绪状态，再把事件加入就绪集并唤醒等待线程。
LT/ET 的本质不在链表名字，而在就绪谓词以及事件消费后的重新入队规则。
单 epoll 可以用 tcp_table->ep；多个 epoll 需要 fd 到多个订阅者的映射。
epoll 解决应用调度问题，不替代 TCP 状态机，也不能弥补连接状态未隔离的问题。

十八、反刍题

为什么三次握手完成时触发 listenfd，而不是新连接 fd？
为什么 FIN 可以通过 EPOLLIN 通知？
红黑树和就绪链表各自回答什么问题？
为什么一个 epitem 要同时包含 RB_ENTRY 和 LIST_ENTRY？
nepoll_ctl() 注册了一个 fd 后，为什么它不一定立刻出现在就绪链表？
从 payload 到达到 nepoll_wait() 返回，中间依次发生了什么？
如果 rcvbuf 仍有未读数据，LT 和 ET 下一步分别应该怎样表现？
为什么条件变量的等待必须放在 while 中？
为什么发布事件时要先更新 rdlist/rdnum，再调用 signal？
当前的 tcp_table->ep 为什么只能自然表达单 epoll？
如果一个 connfd 被两个 epoll 实例注册，协议栈该怎样分发一次 EPOLLIN？
epoll 已经实现正确，但不同连接仍共用 rcvbuf，并发为什么仍然会失败？

DPDK 用户态协议栈（三）：从 TCP 握手到可靠传输

Mon, 17 Aug 2026 17:35:00 +0800

系列前文：

DPDK 用户态协议栈设计与实现

DPDK 用户态协议栈（二）：从收包到 UDP Echo 与 TCP 握手

前两篇已经讲过 DPDK 的收发路径、mbuf、Ethernet/IPv4/UDP/TCP Header、UDP Echo 和基础 TCP 握手。本篇直接沿着当前代码的执行顺序复习 TCP，并从代码中的 flags、seq、ack、rx_win、tcp_status 延伸到滑动窗口、延迟确认、重传、慢启动和拥塞控制。

一、先看当前代码的 TCP 主线

当前程序的 TCP 数据路径可以概括为：

rte_eth_rx_burst() 从 RX Queue 取包
 ↓
解析 Ethernet Header
 ↓
解析 IPv4 Header
 ↓
next_proto_id == IPPROTO_TCP
 ↓
解析 TCP Header
 ↓
保存源/目的 MAC、IP、端口
 ↓
读取 flags、seq、ack
 ↓
根据 tcp_status 处理 SYN、ACK、PSH
 ↓
必要时构造 TCP 响应并通过 TX Queue 发出

代码中与 TCP 直接相关的全局信息是：

uint8_t global_flags;
uint32_t global_seqnum;
uint32_t global_acknum;

它们分别保存当前收到的 TCP 报文中的：

global_flags ← TCP 控制位
global_seqnum ← 对方本次发送的 SEQ
global_acknum ← 对方本次携带的 ACK

状态机由下面的枚举描述：

typedef enum __USTACK_TCP_STATUS {
 USTACK_TCP_STATUS_CLOSED = 0,
 USTACK_TCP_STATUS_LISTEN,
 USTACK_TCP_STATUS_SYN_RCVD,
 USTACK_TCP_STATUS_SYN_SENT,
 USTACK_TCP_STATUS_ESTABLISHED,
 USTACK_TCP_STATUS_FIN_WAIT_1,
 USTACK_TCP_STATUS_FIN_WAIT_2,
 USTACK_TCP_STATUS_CLOSING,
 USTACK_TCP_STATUS_TIMEWAIT,
 USTACK_TCP_STATUS_CLOSE_WAIT,
 USTACK_TCP_STATUS_LAST_ACK
} USTACK_TCP_STATUS;

uint8_t tcp_status = USTACK_TCP_STATUS_LISTEN;

当前代码主要走的是服务端路径：

LISTEN
 ↓ 收到 SYN
SYN_RCVD
 ↓ 收到第三次握手 ACK
ESTABLISHED
 ↓
接收 TCP 数据

二、代码怎样识别并取得 TCP 报文

主循环先通过 DPDK 批量收包：

struct rte_mbuf *mbufs[BURST_SIZE] = {0};

uint16_t num_recvd = rte_eth_rx_burst(
 global_portid,
 0,
 mbufs,
 BURST_SIZE
);

num_recvd 表示本次从 RX Queue 中取出的报文数量。程序随后遍历每一个 mbuf：

for (i = 0; i < num_recvd; i++) {
 struct rte_ether_hdr *ethhdr =
 rte_pktmbuf_mtod(
 mbufs[i],
 struct rte_ether_hdr *
 );

先判断它是不是 IPv4：

if (ethhdr->ether_type !=
 rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4)) {
 continue;
}

再取得 IPv4 Header：

struct rte_ipv4_hdr *iphdr =
 rte_pktmbuf_mtod_offset(
 mbufs[i],
 struct rte_ipv4_hdr *,
 sizeof(struct rte_ether_hdr)
 );

最后根据 IPv4 Header 中的协议号进入 TCP 分支：

if (iphdr->next_proto_id == IPPROTO_TCP) {
 struct rte_tcp_hdr *tcphdr =
 (struct rte_tcp_hdr *)(iphdr + 1);
}

在当前实验中，IPv4 Header 按基础 20 字节处理，所以使用 (iphdr + 1) 到达 TCP Header。进一步扩展时，可以根据 IHL 取得真实的 IPv4 Header 长度：

uint16_t ip_hdr_len =
 (iphdr->version_ihl & 0x0f) * 4;

struct rte_tcp_hdr *tcphdr =
 (struct rte_tcp_hdr *)
 ((uint8_t *)iphdr + ip_hdr_len);

这里的层次关系是：

Ethernet Header
IPv4 Header
TCP Header
TCP Payload

三、为什么代码要把地址和端口反过来保存

收到客户端发来的 TCP 包后，服务端回包的方向与收包方向正好相反。

1. MAC 地址交换

rte_memcpy(
 global_smac,
 ethhdr->d_addr.addr_bytes,
 RTE_ETHER_ADDR_LEN
);

rte_memcpy(
 global_dmac,
 ethhdr->s_addr.addr_bytes,
 RTE_ETHER_ADDR_LEN
);

收到包时：

源 MAC = 客户端 MAC
目的 MAC = 服务端 MAC

回包时：

源 MAC = 服务端 MAC
目的 MAC = 客户端 MAC

所以把收到包的目的 MAC 保存为回包源 MAC，把收到包的源 MAC 保存为回包目的 MAC。

2. IP 地址交换

rte_memcpy(&global_sip, &iphdr->dst_addr, sizeof(uint32_t));
rte_memcpy(&global_dip, &iphdr->src_addr, sizeof(uint32_t));

3. TCP 端口交换

rte_memcpy(&global_sport, &tcphdr->dst_port, sizeof(uint16_t));
rte_memcpy(&global_dport, &tcphdr->src_port, sizeof(uint16_t));

最终得到一组回包方向的数据：

global_smac 服务端 MAC
global_dmac 客户端 MAC
global_sip 服务端 IP
global_dip 客户端 IP
global_sport 服务端端口
global_dport 客户端端口

TCP 用下面的四元组区分连接：

源 IP、源端口、目的 IP、目的端口

对于服务端而言，一般写成：

local_ip、local_port、remote_ip、remote_port

四、代码怎样读取 Flags、SEQ 和 ACK

global_flags = tcphdr->tcp_flags;
global_seqnum = ntohl(tcphdr->sent_seq);
global_acknum = ntohl(tcphdr->recv_ack);

1. Flags

tcp_flags 是一个字节，其中每一位代表一个控制标志：

SYN 建立连接并同步初始序列号
ACK ACK 字段有效
PSH 希望接收端尽快把数据交给应用
FIN 本方向没有更多数据需要发送
RST 复位连接
URG Urgent Pointer 有效

一个报文可以同时带多个标志，例如：

SYN | ACK
PSH | ACK
FIN | ACK

所以代码使用按位与判断某一位是否存在：

if (global_flags & RTE_TCP_SYN_FLAG) {
 /* 包含 SYN */
}

2. SEQ 与 ACK 是 32 位字段

global_seqnum = ntohl(tcphdr->sent_seq);
global_acknum = ntohl(tcphdr->recv_ack);

报文使用网络字节序，程序进行加减和比较时使用主机字节序，因此读取时调用 ntohl()。

回包时方向相反：

tcp->sent_seq = htonl(seq);
tcp->recv_ack = htonl(ack);

可以记成：

网络报文 → 主机整数：ntohs / ntohl
主机整数 → 网络报文：htons / htonl

其中：

16 位：端口、Window、部分长度字段
32 位：IPv4 地址、SEQ、ACK

五、结合 `ustack_encode_tcp_pkt()` 看 SYN+ACK 的构造

当前编码函数依次组织 Ethernet、IPv4 和 TCP Header。

1. Ethernet Header

struct rte_ether_hdr *eth =
 (struct rte_ether_hdr *)msg;

rte_memcpy(
 eth->d_addr.addr_bytes,
 global_dmac,
 RTE_ETHER_ADDR_LEN
);

rte_memcpy(
 eth->s_addr.addr_bytes,
 global_smac,
 RTE_ETHER_ADDR_LEN
);

eth->ether_type = htons(RTE_ETHER_TYPE_IPV4);

这一层说明后面的载荷是 IPv4。

2. IPv4 Header

struct rte_ipv4_hdr *ip =
 (struct rte_ipv4_hdr *)(eth + 1);

ip->version_ihl = 0x45;
ip->type_of_service = 0;
ip->total_length = htons(
 total_len - sizeof(struct rte_ether_hdr)
);
ip->packet_id = 0;
ip->fragment_offset = 0;
ip->time_to_live = 64;
ip->next_proto_id = IPPROTO_TCP;
ip->src_addr = global_sip;
ip->dst_addr = global_dip;
ip->hdr_checksum = 0;
ip->hdr_checksum = rte_ipv4_cksum(ip);

total_len 是整个 Ethernet Frame 中由程序填写的长度。IPv4 的 total_length 不包括 Ethernet Header，所以要减去：

sizeof(struct rte_ether_hdr)

3. TCP Header

struct rte_tcp_hdr *tcp =
 (struct rte_tcp_hdr *)(ip + 1);

tcp->src_port = global_sport;
tcp->dst_port = global_dport;

tcp->sent_seq = htonl(12345);
tcp->recv_ack = htonl(global_seqnum + 1);

tcp->data_off = 0x50;

tcp->tcp_flags =
 RTE_TCP_SYN_FLAG |
 RTE_TCP_ACK_FLAG;

tcp->rx_win = htons(TCP_INIT_WINDOWS);

tcp->cksum = 0;
tcp->cksum = rte_ipv4_udptcp_cksum(ip, tcp);

这几行正好对应三次握手第二步：

服务端自己的 SEQ = 12345
确认客户端 SYN 的 ACK = 客户端 SEQ + 1
Flags = SYN | ACK

data_off = 0x50 的高 4 位是 5，表示 TCP Header 长度为：

5 × 4 字节 = 20 字节

本例没有 TCP Options，所以是最基础的 20 字节 TCP Header。

rx_win 是服务端通告给客户端的接收窗口。它是 16 位字段，写入报文时使用 htons()。

六、结合状态机完整理解三次握手

假设：

客户端初始序列号 client_isn = 1234
服务端初始序列号 server_isn = 12345

第一次握手：客户端发送 SYN

客户端 → 服务端

SYN=1
SEQ=1234

代码在 TCP 分支中读取到：

global_flags = RTE_TCP_SYN_FLAG;
global_seqnum = 1234;

随后进入：

if (global_flags & RTE_TCP_SYN_FLAG) {
 if (tcp_status == USTACK_TCP_STATUS_LISTEN) {
 /* 构造 SYN+ACK */
 }
}

第二次握手：服务端回复 SYN+ACK

服务端 → 客户端

SYN=1
ACK=1
SEQ=12345
ACK number=1235

代码中的对应关系：

tcp->sent_seq = htonl(12345);
tcp->recv_ack = htonl(global_seqnum + 1);
tcp->tcp_flags = RTE_TCP_SYN_FLAG | RTE_TCP_ACK_FLAG;

发送后进入：

tcp_status = USTACK_TCP_STATUS_SYN_RCVD;

表示服务端已经发送 SYN+ACK，正在等待客户端确认自己的 SYN。

第三次握手：客户端回复 ACK

客户端 → 服务端

ACK=1
SEQ=1235
ACK number=12346

客户端的 SEQ 变成 1235，是因为它的 SYN 占用了一个序列号。

客户端的 ACK 是 12346，是因为服务端的 SYN 也占用了一个序列号。

代码收到 ACK 后：

if (global_flags & RTE_TCP_ACK_FLAG) {
 if (tcp_status == USTACK_TCP_STATUS_SYN_RCVD) {
 printf("enter established\n");
 tcp_status = USTACK_TCP_STATUS_ESTABLISHED;
 }
}

于是状态变化为：

LISTEN
 ↓ 收到 SYN
SYN_RCVD
 ↓ 收到确认服务端 SYN 的 ACK
ESTABLISHED

在连接数据结构中，可以保存：

iss = 12345 服务端初始发送序列号
irs = 1234 客户端初始发送序列号
snd_una = 12346 服务端最早未确认序号
snd_nxt = 12346 服务端下一个发送序号
rcv_nxt = 1235 服务端下一步期望收到的客户端序号

七、SEQ 的精髓：它是字节序号

TCP 提供的是字节流。SEQ 不是“第几个包”，而是当前 TCP 段中第一个数据字节的编号。

假设服务端当前发送：

SEQ=12345
payload_len=100

那么该段中的 100 个数据字节对应：

12345～12444

下一段新数据从：

SEQ=12445

开始。

如果第二段有 500 字节：

第二段：SEQ=12445，覆盖 12445～12944
第三段：SEQ=12945

所以发送新数据后：

SND.NXT = SND.NXT + payload_len

如果报文还包含 SYN 或 FIN，则它们各自还要消耗一个序列号：

sequence_space_len
 = payload_len
 + (SYN ? 1 : 0)
 + (FIN ? 1 : 0)

ACK 和 PSH 本身不占序列空间。

八、ACK 的精髓：确认连续收到的字节

假设服务端收到客户端的数据：

SEQ=5000
payload_len=1000

数据覆盖：

5000～5999

如果这些字节都按序收到，服务端返回：

ACK=6000

ACK=6000 表示：

6000 以前的连续序列字节已经收到，下一步期望 6000。

因此 ACK 是累计确认。假设发送方连续发送：

[5000, 6000)
[6000, 7000)
[7000, 8000)

接收方可以直接回复：

ACK=8000

一次确认前面三个连续区间。

在代码中，接收端用于生成 ACK 的核心状态可以写成：

conn->rcv_nxt += payload_len;
tcp->recv_ack = htonl(conn->rcv_nxt);

九、一条 TCP 连接为什么有两套 SEQ/ACK

TCP 是全双工协议，两个方向可以同时传输数据：

客户端 ─────客户端数据────→ 服务端
客户端 ←────服务端数据───── 服务端

两个方向分别有自己的序列空间：

客户端发送方向：从 client_isn 开始编号
服务端发送方向：从 server_isn 开始编号

一个 TCP 报文中的两个字段分别表达：

SEQ：我这次发送的数据从哪里开始
ACK：你发送的数据，我连续收到了哪里

使用“北京与广州互相运货”的类比：

北京 → 广州：烤鸭编号是一套序列空间
广州 → 北京：白切鸡编号是另一套序列空间

每辆车都可以同时携带：

SEQ：本车货物的起始编号
ACK：反方向货物已经连续收到的编号
Window：本地仓库还允许对方运来多少货物

所以双方都同时具有发送状态和接收状态。

十、代码怎样定位 TCP Payload

原代码在收到 PSH 后，通过 TCP Header 长度定位数据：

uint8_t hdrlen =
 (tcphdr->data_off >> 4)
 * sizeof(uint32_t);

uint8_t *data =
 (uint8_t *)tcphdr + hdrlen;

data_off 的高 4 位以 4 字节为单位表示 TCP Header 长度：

tcp_hdr_len = (data_off >> 4) × 4

若没有 TCP Options：

data_off 高四位 = 5
TCP Header 长度 = 5 × 4 = 20 字节

TCP payload 长度可以通过 IPv4 总长度计算：

uint16_t ip_total_len = ntohs(iphdr->total_length);
uint16_t ip_hdr_len = (iphdr->version_ihl & 0x0f) * 4;
uint16_t tcp_hdr_len = (tcphdr->data_off >> 4) * 4;

uint16_t payload_len =
 ip_total_len - ip_hdr_len - tcp_hdr_len;

uint8_t *payload =
 (uint8_t *)tcphdr + tcp_hdr_len;

这也解释了 TCP Header 为什么不需要像 UDP Header 那样再放一个长度字段：IPv4 总长度、IPv4 Header 长度和 TCP Header 长度已经能够计算出当前 TCP payload 长度。

PSH 可以理解为“希望接收端尽快把这部分数据交给应用”。处理代码时，是否存在 payload 仍以 payload_len > 0 为准。

十一、从 `rx_win` 理解 TCP 接收窗口

当前构造 TCP Header 时写入：

#define TCP_INIT_WINDOWS 14600

tcp->rx_win = htons(TCP_INIT_WINDOWS);

这个字段是本端向对端通告：

从 ACK 所表示的下一个期望字节开始，
我目前还愿意接收多少字节。

例如服务端回复：

ACK=6000
Window=14600

可以理解为：

6000 以前已经连续收到；
从 6000 开始，当前还能接收 14600 字节。

接收窗口通常与接收缓存关联：

RCV.WND
 = 接收缓存总容量
 - 已收到但应用还没有读取的数据量

如果应用读取很慢，缓存逐渐占满：

RCV.WND 逐渐减小

如果缓存完全占满：

RCV.WND = 0

发送方看到零窗口后，暂停发送新的数据。接收端应用继续读取数据、释放缓存后，再通过 ACK 中的 Window 字段通告新的可用空间。

十二、发送窗口：`SND.UNA` 与 `SND.NXT`

发送端可以把序列空间分成四部分：

已发送已确认 已发送未确认 窗口内尚未发送 当前不能发送
────────────┬────────────────┬──────────────────┬──────────→
 SND.UNA SND.NXT SND.UNA+SND.WND

1. `SND.UNA`

Send Unacknowledged，最早一个尚未被确认的序号。

2. `SND.NXT`

Send Next，下一个新数据应该使用的序号。

3. 在途数据量

flight_size = SND.NXT - SND.UNA

表示已经发送、还没有累计确认的数据量。

4. 收到新 ACK 时窗口滑动

发送端原来是：

SND.UNA=1000
SND.NXT=4000

说明 [1000, 4000) 已发送未确认。

收到：

ACK=3000

之后：

SND.UNA=3000
SND.NXT=4000

[1000, 3000) 已被确认，可以从重传队列和发送缓存中释放；窗口左边界向右移动，这就是“滑动窗口”。

十三、接收窗口与有序交付

接收端维护：

RCV.NXT：下一步期望收到的序号
RCV.WND：从 RCV.NXT 开始还允许接收多少字节

序列空间可以表示为：

已经连续收到 当前接收窗口 窗口之外
───────────────┬─────────────────────────┬────────────→
 RCV.NXT RCV.NXT+RCV.WND

假设依次发送四段：

A：[0, 400)
B：[400, 900)
C：[900, 1600)
D：[1600, 2000)

按序到达

收到 A：

RCV.NXT 从 0 变成 400

收到 B：

RCV.NXT 从 400 变成 900

C 暂时没有到达，D 先到

接收端当前仍缺少从 900 开始的数据，因此：

RCV.NXT 仍为 900
ACK 仍回复 900
D 可以暂存在乱序队列中

当 C 到达后：

C 与已经缓存的 D 连续
RCV.NXT 可以从 900 一次推进到 2000
ACK 回复 2000

对应用程序而言，TCP 仍然按顺序交付：

A → B → C → D

这就是 TCP 利用字节序号、累计 ACK 和乱序缓存实现有序字节流的过程。

十四、延迟确认怎样接入接收逻辑

收到数据后，接收端需要用 ACK 告诉发送端 RCV.NXT。ACK 可以有三种发送方式：

立即发送纯 ACK
延迟一小段时间后发送 ACK
把 ACK 捎带在反方向数据中

延迟确认的主要目标是减少纯 ACK 数量，并等待是否有反方向数据可以一起发送。

可以先用下面的学习模型理解：

收到第一个按序数据段
 → 更新 RCV.NXT
 → 设置 pending_ack
 → 启动 delayed ACK 定时器

定时器到期前又收到一个按序数据段
 → 再次更新 RCV.NXT
 → 立即发送累计 ACK

定时器到期
 → 发送 ACK=RCV.NXT

期间本端正好有数据要发
 → 把 ACK=RCV.NXT 填入数据段
 → 不再额外发送纯 ACK

遇到乱序段时，可以及时回复当前 RCV.NXT，让发送方看到重复 ACK 并发现连续数据中的缺口。

延迟确认属于接收端的 ACK 生成策略；超时重传和快速重传则是发送端恢复丢失数据的策略。

十五、为什么发送过的数据要暂时保存

调用：

rte_eth_tx_burst(
 global_portid,
 0,
 &mbuf,
 1
);

表示把报文提交给 DPDK TX Queue。对于 TCP 来说，提交发送以后还要等待对方 ACK，才能确认该序列范围已经到达。

因此 TCP 需要发送缓存和重传队列：

应用写入数据
 ↓
数据进入发送缓存
 ↓
按 MSS 和窗口切成 TCP 段
 ↓
记录每段的 seq_start、seq_end、发送时间
 ↓
构造 mbuf 并提交 TX
 ↓
等待 ACK
 ↓
收到累计 ACK 后释放已确认的数据

学习版重传项可以记录：

struct tcp_tx_segment {
 uint32_t seq_start;
 uint32_t seq_end;
 uint16_t payload_len;
 uint8_t flags;
 uint64_t first_tx_us;
 uint64_t last_tx_us;
 uint32_t retransmit_count;
};

例如：

重传队列：
[1000, 2000)
[2000, 3000)
[3000, 4000)

收到 ACK=3000 后：

[1000, 2000) 已确认，移除
[2000, 3000) 已确认，移除
[3000, 4000) 继续等待

十六、超时重传：没有收到 ACK 时怎么办

发送一个 TCP 段时，发送端记录发送时间并启动重传定时器。如果在 RTO 到期前没有收到能够确认它的 ACK，就重新发送最早未确认的数据。

发送数据段
 → 保存到重传队列
 → 启动 RTO 定时器
 → 收到新 ACK：推进 SND.UNA，重启或停止定时器
 → RTO 到期：重传最早未确认段

1. RTT

RTT 是数据发出到相应 ACK 返回所经历的往返时间：

send_time ───────────────────── ack_time
 RTT

网络时延会变化，因此不能只用某一次 RTT 作为固定重传时间。

2. SRTT、RTTVAR 与 RTO

TCP 对 RTT 做平滑，并记录波动程度：

SRTT 平滑 RTT
RTTVAR RTT 波动估计
RTO 重传超时时间

核心关系是：

RTO = SRTT + max(G, 4 × RTTVAR)

其中 G 是定时器时钟粒度。

第一次取得 RTT 样本 R 时：

SRTT = R
RTTVAR = R / 2

后续样本继续对两者进行平滑更新，使 RTO 能随网络情况变化。

3. RTO 指数退避

如果重传后仍然没有 ACK：

RTO = RTO × 2

继续超时则继续退避：

1RTO → 2RTO → 4RTO → 8RTO

这样可以避免网络已经拥塞时还以很高频率不断重传。

4. DPDK 主循环中的定时器

定时器处理不能阻塞轮询收包。主循环可以组织为：

while (1) {
 处理 RX burst
 处理到期的 TCP timers
 发送 TX 待发送队列
}

需要处理的 TCP 定时器可以逐步包括：

RTO timer
delayed ACK timer
zero-window persist timer
TIME_WAIT timer

十七、快速重传：通过重复 ACK 更早发现缺口

继续使用下面的序列：

A：[0, 400)
B：[400, 900)
C：[900, 1600) ← 丢失
D：[1600, 2000)
E：[2000, 2400)
F：[2400, 2800)

接收端收到 D、E、F 时，由于 C 仍未到达，连续前缀一直停在 900，于是多次回复：

ACK=900
ACK=900
ACK=900

发送端看到多个重复 ACK，可以在 RTO 之前推断从 900 开始的数据可能丢失。

经典快速重传通常使用：

3 个重复 ACK
 → 重传从 SND.UNA 开始的缺失段

如果握手时协商了 SACK，接收端还能在 TCP Options 中告诉发送端：

[1600, 2800) 已经收到

发送端便能更准确地只补发缺失区间 [900, 1600)。

十八、接收窗口 rwnd 与拥塞窗口 cwnd

发送方决定本轮还能发送多少数据时，要同时考虑两种窗口。

1. rwnd：接收端通告窗口

来源：

tcphdr->rx_win

含义：

对方接收缓存还能容纳多少数据

它解决的是流量控制问题，避免发送速度超过对方应用和接收缓存的处理能力。

2. cwnd：拥塞窗口

cwnd 由发送端本地维护，不直接写在 TCP Header 中。

含义：

根据当前网络状态，允许多少数据处于在途未确认状态

它解决的是拥塞控制问题，避免一次向网络注入过多数据。

3. 两个窗口共同限制发送

send_limit = min(rwnd, cwnd)
flight_size = SND.NXT - SND.UNA
available = send_limit - flight_size

例一：

rwnd = 64 KB
cwnd = 12 KB
flight_size = 8 KB

available = min(64, 12) - 8 = 4 KB

例二：

rwnd = 4 KB
cwnd = 32 KB
flight_size = 3 KB

available = min(4, 32) - 3 = 1 KB

第一个例子受网络拥塞窗口限制，第二个例子受对端接收窗口限制。

十九、慢启动：逐步探测网络容量

连接刚建立时，发送端并不知道路径能容纳多少在途数据，所以用 cwnd 逐步试探。

为了理解增长过程，先假设：

SMSS = 1000 字节
初始 cwnd = 1 × SMSS

第一个 RTT

cwnd=1 MSS
发送 1 个 MSS
收到确认新数据的 ACK
cwnd 增长到约 2 MSS

第二个 RTT

cwnd=2 MSS
发送 2 个 MSS
收到相应 ACK
cwnd 增长到约 4 MSS

第三个 RTT

cwnd=4 MSS
发送 4 个 MSS
cwnd 增长到约 8 MSS

所以慢启动的教学曲线经常写作：

1 → 2 → 4 → 8 → 16

它表示每经过一个 RTT，窗口大致成倍增长。具体实现中，初始窗口可以大于 1 MSS；理解重点是：

慢启动阶段每收到确认新数据的 ACK，cwnd 增加；
一轮 RTT 中 ACK 数量随已发送数据增加，因此整体近似指数增长。

二十、拥塞避免：超过阈值后降低增长速度

TCP 连接还维护：

ssthresh：慢启动阈值

两种阶段的关系是：

cwnd < ssthresh → 慢启动
cwnd > ssthresh → 拥塞避免

慢启动阶段增长较快；进入拥塞避免后，经典算法让 cwnd 每个 RTT 大约增加一个 MSS。

慢启动：近似指数增长
拥塞避免：近似线性增长

用窗口大小表示：

慢启动：1、2、4、8、16
拥塞避免：16、17、18、19、20

实际数值由 ACK、MSS 和算法计算，不一定正好是整数段；这组数字主要用于观察增长形态。

发生 RTO 时

经典学习模型中：

ssthresh = 当前在途数据量的一半，且至少为 2 MSS
cwnd = 1 MSS
重新进入慢启动

发生 3 个重复 ACK 时

说明后续数据仍在到达，发送端执行：

快速重传
调整 ssthresh
进入快速恢复

这几个机制组合起来就是经典 TCP Reno 的核心：

慢启动
拥塞避免
快速重传
快速恢复

二十一、把当前全局状态整理成一条连接的数据结构

目前的全局变量适合单连接实验。为了把已学习的概念放进代码，可以先整理成学习版连接控制块：

struct tcp_connection {
 /* 四元组 */
 uint32_t local_ip;
 uint32_t remote_ip;
 uint16_t local_port;
 uint16_t remote_port;

 USTACK_TCP_STATUS state;

 /* 初始序列号 */
 uint32_t iss;
 uint32_t irs;

 /* 发送方向 */
 uint32_t snd_una;
 uint32_t snd_nxt;
 uint32_t snd_wnd;

 /* 接收方向 */
 uint32_t rcv_nxt;
 uint32_t rcv_wnd;

 /* 重传定时器 */
 uint64_t srtt_us;
 uint64_t rttvar_us;
 uint64_t rto_us;
 uint64_t rto_deadline_us;

 /* 拥塞控制 */
 uint32_t smss;
 uint32_t cwnd;
 uint32_t ssthresh;

 /* 发送缓存、重传队列、接收缓存、乱序队列 */
};

字段与知识点的对应关系：

代码字段	TCP 含义
`state`	当前连接状态
`iss`	本端初始发送序列号
`irs`	对端初始发送序列号
`snd_una`	最早未确认的发送序号
`snd_nxt`	下一个新数据发送序号
`snd_wnd`	对端通告给本端的接收窗口
`rcv_nxt`	本端下一步期望收到的序号
`rcv_wnd`	本端当前可用接收窗口
`srtt_us`	平滑 RTT
`rttvar_us`	RTT 波动估计
`rto_us`	当前重传超时时间
`cwnd`	拥塞窗口
`ssthresh`	慢启动阈值

收到 TCP 报文后，通过四元组找到这条连接：

(local_ip, local_port, remote_ip, remote_port)
 ↓
tcp_connection

每个客户端都有自己的状态、SEQ/ACK、窗口、缓存和定时器。

二十二、ESTABLISHED 状态收到数据时的完整思路

当前代码在看见 PSH 后取得并打印数据：

if (global_flags & RTE_TCP_PSH_FLAG) {
 if (tcp_status == USTACK_TCP_STATUS_ESTABLISHED) {
 uint8_t hdrlen =
 (tcphdr->data_off >> 4)
 * sizeof(uint32_t);

 uint8_t *data =
 (uint8_t *)tcphdr + hdrlen;

 printf("tcp data: %s\n", data);
 }
}

把可靠传输补充进来以后，可以按下面的顺序理解：

收到 ESTABLISHED 状态报文
 ↓
计算 ip_hdr_len、tcp_hdr_len、payload_len
 ↓
读取 SEG.SEQ、SEG.ACK、SEG.WND
 ↓
处理 ACK：推进 snd_una
 ↓
判断 SEG.SEQ 与 rcv_nxt 的关系
 ↓
按序数据写入接收缓存；乱序数据进入乱序队列
 ↓
推进 rcv_nxt
 ↓
根据缓存剩余量更新 rcv_wnd
 ↓
立即 ACK、延迟 ACK，或在反向数据中携带 ACK
 ↓
根据 min(snd_wnd, cwnd) 尝试继续发送

学习版伪代码：

if (conn->state == USTACK_TCP_STATUS_ESTABLISHED) {
 tcp_process_ack(conn, seg_ack, seg_window);

 if (payload_len > 0) {
 if (seg_seq == conn->rcv_nxt) {
 recv_buffer_write(conn, payload, payload_len);
 conn->rcv_nxt += payload_len;

 consume_contiguous_out_of_order_data(conn);
 conn->rcv_wnd = recv_buffer_free_space(conn);

 schedule_or_send_ack(conn);
 } else if (seq_after(seg_seq, conn->rcv_nxt)) {
 queue_out_of_order_data(
 conn,
 seg_seq,
 payload,
 payload_len
 );

 send_ack(conn, conn->rcv_nxt);
 } else {
 send_ack(conn, conn->rcv_nxt);
 }
 }
}

这段伪代码把当前“读取 payload”的路径继续延伸为：

有序接收 + 累计确认 + 乱序缓存 + 接收窗口

二十三、发送数据时的完整思路

当服务端应用有数据需要发送时：

应用数据进入发送缓存
 ↓
读取 snd_wnd 和 cwnd
 ↓
计算当前还能发送多少
 ↓
按 SMSS 切分
 ↓
每段 SEQ = snd_nxt
ACK = rcv_nxt
Window = rcv_wnd
 ↓
保存到重传队列
 ↓
构造 Ethernet + IPv4 + TCP + payload
 ↓
rte_eth_tx_burst()
 ↓
snd_nxt 增加 payload_len
 ↓
启动或维护 RTO 定时器

核心计算：

uint32_t flight_size = conn->snd_nxt - conn->snd_una;
uint32_t send_limit = RTE_MIN(conn->snd_wnd, conn->cwnd);

if (send_limit > flight_size) {
 uint32_t available = send_limit - flight_size;
 uint32_t send_len = RTE_MIN(available, conn->smss);
 /* 构造一个 send_len 字节的数据段 */
}

构造数据段时：

tcp->sent_seq = htonl(conn->snd_nxt);
tcp->recv_ack = htonl(conn->rcv_nxt);
tcp->tcp_flags = RTE_TCP_ACK_FLAG | RTE_TCP_PSH_FLAG;
tcp->rx_win = htons(conn->rcv_wnd);

发送后：

conn->snd_nxt += send_len;

收到累计 ACK 后：

conn->snd_una = seg_ack;

于是发送窗口不断向右滑动。

二十四、用一次完整传输串起所有概念

假设握手结束后：

服务端 snd_una = 12346
服务端 snd_nxt = 12346
服务端 rcv_nxt = 1235
对端通告 snd_wnd = 6000
服务端 cwnd = 3000
SMSS = 1000

1. 计算发送能力

flight_size = 12346 - 12346 = 0
send_limit = min(6000, 3000) = 3000
available = 3000 - 0 = 3000

服务端可以先发送 3 个 1000 字节段：

段 1：SEQ=12346，范围 [12346,13346)
段 2：SEQ=13346，范围 [13346,14346)
段 3：SEQ=14346，范围 [14346,15346)

发送后：

snd_una = 12346
snd_nxt = 15346
flight_size = 3000

2. 对端累计确认

如果三个段都按序收到，对端回复：

ACK=15346

服务端处理后：

snd_una = 15346
snd_nxt = 15346
flight_size = 0

三个段都可以从重传队列中移除。

3. 慢启动增加 cwnd

ACK 确认了新数据，慢启动阶段继续增加 cwnd，下一轮允许更多在途数据，但仍受 snd_wnd 限制。

4. 中间一段丢失

如果第二段丢失，第三段到达，对端连续前缀只能到 13346，因此回复：

ACK=13346

继续收到后续乱序段时仍回复相同 ACK。发送端可以通过重复 ACK 快速重传第二段；如果没有足够的后续 ACK，则由 RTO 定时器最终触发重传。

这一过程把以下概念连在了一起：

SEQ
ACK
滑动窗口
接收窗口
拥塞窗口
慢启动
乱序队列
快速重传
超时重传

二十五、代码与 TCP 知识点对照表

当前代码	对应 TCP 含义	后续实现中保存的位置
`tcphdr->sent_seq`	当前段第一个序列号	`SEG.SEQ`
`tcphdr->recv_ack`	对端累计确认号	`SEG.ACK`
`tcphdr->tcp_flags`	SYN/ACK/PSH/FIN/RST	当前报文状态输入
`tcphdr->rx_win`	报文发送方通告的接收窗口	本端 `snd_wnd`
`tcp->rx_win`	本端向对方通告的接收窗口	本端 `rcv_wnd`
`tcp_status`	当前连接状态	`conn->state`
`global_seqnum + 1`	确认一个 SYN	`conn->rcv_nxt`
`12345`	学习代码中的服务端 ISN	`conn->iss`
`data_off >> 4`	TCP Header 的 32 位字数量	计算 `tcp_hdr_len`
`rte_eth_tx_burst()`	把报文交给 TX Queue	发送路径
`TCP_INIT_WINDOWS`	初始接收窗口示例	`conn->rcv_wnd`
尚未加入	最早未确认序号	`conn->snd_una`
尚未加入	下一个新发送序号	`conn->snd_nxt`
尚未加入	下一个期望接收序号	`conn->rcv_nxt`
尚未加入	重传定时器	`conn->rto_us`
尚未加入	拥塞窗口	`conn->cwnd`
尚未加入	慢启动阈值	`conn->ssthresh`

二十六、整条 TCP 处理路径

flowchart TD
 A["rte_eth_rx_burst 收包"] --> B["解析 Ethernet 和 IPv4"]
 B --> C["定位 TCP Header"]
 C --> D["读取四元组、Flags、SEQ、ACK、Window"]
 D --> E["按四元组查找连接"]
 E --> F{"连接状态"}
 F -->|"LISTEN + SYN"| G["记录客户端 ISN，发送 SYN+ACK"]
 G --> H["进入 SYN_RCVD"]
 F -->|"SYN_RCVD + ACK"| I["确认服务端 SYN"]
 I --> J["进入 ESTABLISHED"]
 F -->|"ESTABLISHED"| K["处理 ACK，推进 SND.UNA"]
 K --> L["释放已确认发送缓存，更新 RTT/RTO/cwnd"]
 F -->|"ESTABLISHED + payload"| M["按 SEQ 处理按序或乱序数据"]
 M --> N["推进 RCV.NXT，更新 RCV.WND"]
 N --> O["发送或延迟 ACK"]
 L --> P["计算 min(rwnd,cwnd)-flight_size"]
 P --> Q["窗口允许时继续发送"]
 Q --> R["数据进入重传队列并提交 TX"]
 S["RTO 定时器"] --> T["超时重传并调整拥塞状态"]
 T --> R

二十七、复习时抓住的主线

第一条：连接状态

LISTEN → SYN_RCVD → ESTABLISHED

状态决定当前收到的 Flags 应该怎样解释。

第二条：字节序列

SEQ 标识本方向发送的数据
ACK 确认反方向连续收到的数据

第三条：发送可靠性

数据发出后保留
ACK 到达后释放
重复 ACK 可触发快速重传
RTO 到期触发超时重传

第四条：有序接收

RCV.NXT 之前已经连续收到
等于 RCV.NXT 的数据可以推进确认号
更大的 SEQ 暂存到乱序队列
缺口补齐后连续交付给应用

第五条：发送数量

rwnd 保护接收端
cwnd 保护网络
实际发送上限取二者较小值

第六条：网络探测

慢启动快速扩大 cwnd
到达 ssthresh 后进入拥塞避免
丢包或超时后降低发送强度

二十八、总结

当前代码用下面几行打开了理解 TCP 的入口：

global_flags = tcphdr->tcp_flags;
global_seqnum = ntohl(tcphdr->sent_seq);
global_acknum = ntohl(tcphdr->recv_ack);

沿着它们继续向下，就是完整的 TCP 传输控制：

Flags 驱动连接状态机
SEQ 给每个方向的数据字节编号
ACK 累计确认已经连续收到的字节
SND.UNA 与 SND.NXT 形成发送滑动窗口
RCV.NXT 与 RCV.WND 管理有序接收和接收缓存
发送缓存保留尚未确认的数据
重复 ACK 与 RTO 负责发现并恢复丢失
rwnd 控制接收端承受能力
cwnd、ssthresh、慢启动和拥塞避免控制网络中的在途数据

因此，从当前代码继续实现 TCP 的核心方向，就是把现在的全局 flags、seq、ack、tcp_status 扩展为每条连接独立的状态、序列空间、窗口、缓存和定时器。

参考规范

DPDK 用户态协议栈（二）：从收包到 UDP Echo 与 TCP 握手

Mon, 17 Aug 2026 00:00:00 +0800

本文承接《dpdk用户态协议栈设计与实现》。本文把重点放在一个新问题上：收到数据以后，怎样在用户态构造一个符合协议的响应包并发送出去？ 为了让代码能够独立读懂，后文会从程序入口开始完整解释执行流程；网络分层等原理知识则只在影响代码理解时说明。

一、本篇要完成什么

上一篇的程序已经可以：

初始化 EAL、mempool 和网口；
通过 rte_eth_rx_burst() 轮询收包；
识别 Ethernet、IPv4、UDP 和 TCP；
打印报文中的地址、端口与数据。

本篇继续完成三件事：

为网口配置 TX Queue，使程序具备发包能力；
实现 UDP Echo：收到 UDP 数据后，构造响应包并原样返回 payload；
实现最小 TCP 服务端：收到 SYN 后回复 SYN+ACK，再接收 ACK 和应用数据。

这里实现的是用于学习协议与验证收发链路的最小原型，不是可投入生产的完整协议栈。

二、用编译期开关隔离增量代码

开发新功能时，可以先用宏把新增代码包起来：

#define ENABLE_SEND 1
#define ENABLE_TCP 1

#if ENABLE_SEND
/* TX Queue、UDP 回包等新增代码 */
#endif

#if ENABLE_TCP
/* TCP 状态机与 TCP 回包代码 */
#endif

这样做的价值不是“上线前把代码删掉”，而是：

新功能出问题时，可快速回退到仅收包版本；
可以分别验证 RX、UDP TX 和 TCP 三部分；
提交 patch 时，新增逻辑的边界更加清楚。

如果功能会长期存在，最终更适合使用构建选项或运行时配置；长期散落大量 #if 会增加维护成本。

三、能收包不等于能发包

仅配置 RX Queue 时，网卡只能供当前程序收包。要发送数据，还需要完成三步：

const uint16_t num_rx_queues = 1;
const uint16_t num_tx_queues = ENABLE_SEND ? 1 : 0;

if (rte_eth_dev_configure(port_id,
 num_rx_queues,
 num_tx_queues,
 &port_conf) < 0) {
 rte_exit(EXIT_FAILURE, "Could not configure port\n");
}

#if ENABLE_SEND
struct rte_eth_txconf txq_conf = dev_info.default_txconf;
txq_conf.offloads = port_conf.txmode.offloads;

if (rte_eth_tx_queue_setup(port_id,
 0,
 512,
 rte_eth_dev_socket_id(port_id),
 &txq_conf) < 0) {
 rte_exit(EXIT_FAILURE, "Could not setup TX queue\n");
}
#endif

if (rte_eth_dev_start(port_id) < 0) {
 rte_exit(EXIT_FAILURE, "Could not start port\n");
}

完整顺序是：

rte_eth_dev_configure
 ↓
rte_eth_rx_queue_setup / rte_eth_tx_queue_setup
 ↓
rte_eth_dev_start
 ↓
rte_eth_rx_burst / rte_eth_tx_burst

`rte_eth_tx_burst()` 的返回值

uint16_t nb_tx = rte_eth_tx_burst(port_id, 0, &tx_mbuf, 1);

if (nb_tx == 0) {
 rte_pktmbuf_free(tx_mbuf);
}

返回值表示实际被 TX Queue 接收的 mbuf 数量：

返回 1：mbuf 的所有权已交给 DPDK/驱动，应用不能立即释放或继续修改；
返回 0：该 mbuf 没有成功入队，仍由应用负责，应重试或释放。

批量发送时，只能释放返回值之后的未发送部分：

uint16_t nb_tx = rte_eth_tx_burst(port_id, 0, tx_pkts, nb_pkts);

for (uint16_t i = nb_tx; i < nb_pkts; i++) {
 rte_pktmbuf_free(tx_pkts[i]);
}

这是 DPDK 发包代码中很重要的内存所有权规则。

四、为什么把收到的 mbuf 直接发出去不是 Echo

最初的尝试是：

rte_eth_tx_burst(port_id, 0, &mbufs[i], 1);

这只是把收到的原始帧再次发出。原包仍然是：

客户端 MAC/IP/Port → 服务端 MAC/IP/Port

而响应包必须是：

服务端 MAC/IP/Port → 客户端 MAC/IP/Port

因此至少要处理：

协议层	响应包需要修改的内容
Ethernet	源 MAC 与目的 MAC 对调
IPv4	源 IP 与目的 IP 对调，重新计算 IPv4 头校验和
UDP	源端口与目的端口对调，重新计算 UDP 校验和
TCP	对调端口，并根据状态设置 Flags、SEQ、ACK 和校验和

以太网 FCS/CRC 通常由网卡在真正发出帧时生成，应用一般不需要在 mbuf 末尾手工追加；但 IPv4、UDP、TCP 的校验和必须由软件计算，或者明确配置硬件 checksum offload。

五、UDP Echo 的数据路径

UDP Echo 的完整过程是：

RX Queue 收到请求
 ↓
检查 Ethernet / IPv4 / UDP 及各层长度
 ↓
保存并对调 MAC、IP、Port
 ↓
从 mempool 分配新的 TX mbuf
 ↓
依次写入 Ethernet、IPv4、UDP Header
 ↓
复制原 UDP payload
 ↓
计算 IPv4 与 UDP checksum
 ↓
rte_eth_tx_burst 发送

为便于学习，草稿使用了全局变量暂存一组通信端点：

uint8_t global_smac[RTE_ETHER_ADDR_LEN];
uint8_t global_dmac[RTE_ETHER_ADDR_LEN];
uint32_t global_sip;
uint32_t global_dip;
uint16_t global_sport;
uint16_t global_dport;

收到请求后，对调方向：

rte_memcpy(global_smac,
 eth->dst_addr.addr_bytes,
 RTE_ETHER_ADDR_LEN);
rte_memcpy(global_dmac,
 eth->src_addr.addr_bytes,
 RTE_ETHER_ADDR_LEN);

global_sip = ip->dst_addr;
global_dip = ip->src_addr;
global_sport = udp->dst_port;
global_dport = udp->src_port;

这些字段本身仍保持网络字节序，写回协议头时不需要再次 hton*()。

不要用全局变量保存真实连接

全局变量只适合单队列、单线程、一次处理一个包的教学程序。多个客户端或多个 lcore 并发时，后一包会覆盖前一包的端点信息。更合理的做法是把地址信息作为函数参数传入，TCP 则使用以四元组为 key 的连接表。

六、构造 UDP 响应包

1. 先算清三种长度

设 UDP payload 长度为 payload_len：

uint16_t udp_len = sizeof(struct rte_udp_hdr) + payload_len;
uint16_t ip_len = sizeof(struct rte_ipv4_hdr) + udp_len;
uint16_t frame_len = sizeof(struct rte_ether_hdr) + ip_len;

三者的含义不同：

udp->dgram_len：UDP Header + UDP payload；
ip->total_length：IPv4 Header + IPv4 payload，不含 Ethernet Header；
mbuf->pkt_len/data_len：本例中的完整 Ethernet 帧长度，不含硬件生成的 FCS。

2. 分配并扩展 mbuf

更稳妥的写法是使用 rte_pktmbuf_append()，而不是只手工改长度字段：

struct rte_mbuf *tx_mbuf = rte_pktmbuf_alloc(mbuf_pool);
if (tx_mbuf == NULL) {
 return -ENOMEM;
}

uint8_t *frame = rte_pktmbuf_append(tx_mbuf, frame_len);
if (frame == NULL) {
 rte_pktmbuf_free(tx_mbuf);
 return -ENOSPC;
}

rte_pktmbuf_append() 会检查尾部空间，并同步更新 data_len 与 pkt_len。

3. 写 Ethernet Header

struct rte_ether_hdr *eth = (struct rte_ether_hdr *)frame;

rte_memcpy(eth->dst_addr.addr_bytes,
 global_dmac,
 RTE_ETHER_ADDR_LEN);
rte_memcpy(eth->src_addr.addr_bytes,
 global_smac,
 RTE_ETHER_ADDR_LEN);
eth->ether_type = rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4);

不同 DPDK 版本中，成员名可能是 d_addr/s_addr 或 dst_addr/src_addr，应以本机头文件为准。

4. 写 IPv4 Header

struct rte_ipv4_hdr *ip = (struct rte_ipv4_hdr *)(eth + 1);

*ip = (struct rte_ipv4_hdr){0};
ip->version_ihl = RTE_IPV4_VHL_DEF;
ip->total_length = rte_cpu_to_be_16(ip_len);
ip->time_to_live = 64;
ip->next_proto_id = IPPROTO_UDP;
ip->src_addr = global_sip;
ip->dst_addr = global_dip;
ip->hdr_checksum = 0;
ip->hdr_checksum = rte_ipv4_cksum(ip);

version_ihl = 0x45 表示 IPv4，且头部长度为 5 × 4 = 20 字节。使用 RTE_IPV4_VHL_DEF 可读性更好。

total_length 是 16 位多字节字段，写入协议头前必须转为网络字节序。

5. 写 UDP Header 和 payload

struct rte_udp_hdr *udp = (struct rte_udp_hdr *)(ip + 1);

udp->src_port = global_sport;
udp->dst_port = global_dport;
udp->dgram_len = rte_cpu_to_be_16(udp_len);
udp->dgram_cksum = 0;

rte_memcpy(udp + 1, payload, payload_len);

udp->dgram_cksum = rte_ipv4_udptcp_cksum(ip, udp);

这里最容易写错的是复制长度。udp_len 包含 8 字节 UDP Header，因此复制 payload 时必须使用：

payload_len = udp_len - sizeof(struct rte_udp_hdr);

不能把整个 udp_len 字节都从 udp + 1 开始复制，否则会越界读取原报文，并可能越界写入新 mbuf。

6. 一个整理后的编码函数

static int encode_udp_echo(uint8_t *frame,
 const uint8_t *payload,
 uint16_t payload_len)
{
 uint16_t udp_len = sizeof(struct rte_udp_hdr) + payload_len;
 uint16_t ip_len = sizeof(struct rte_ipv4_hdr) + udp_len;

 struct rte_ether_hdr *eth = (struct rte_ether_hdr *)frame;
 rte_memcpy(eth->dst_addr.addr_bytes, global_dmac,
 RTE_ETHER_ADDR_LEN);
 rte_memcpy(eth->src_addr.addr_bytes, global_smac,
 RTE_ETHER_ADDR_LEN);
 eth->ether_type = rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4);

 struct rte_ipv4_hdr *ip = (struct rte_ipv4_hdr *)(eth + 1);
 *ip = (struct rte_ipv4_hdr){0};
 ip->version_ihl = RTE_IPV4_VHL_DEF;
 ip->total_length = rte_cpu_to_be_16(ip_len);
 ip->time_to_live = 64;
 ip->next_proto_id = IPPROTO_UDP;
 ip->src_addr = global_sip;
 ip->dst_addr = global_dip;
 ip->hdr_checksum = rte_ipv4_cksum(ip);

 struct rte_udp_hdr *udp = (struct rte_udp_hdr *)(ip + 1);
 udp->src_port = global_sport;
 udp->dst_port = global_dport;
 udp->dgram_len = rte_cpu_to_be_16(udp_len);
 udp->dgram_cksum = 0;

 rte_memcpy(udp + 1, payload, payload_len);
 udp->dgram_cksum = rte_ipv4_udptcp_cksum(ip, udp);

 return 0;
}

七、安全取得 UDP payload

草稿中使用：

printf("udp: %s\n", (char *)(udp + 1));

这只能用于确保 payload 末尾带 \0 的演示数据。网络报文是带长度的二进制数据，不保证是 C 字符串。

在不考虑 IPv4 Options 的最小版本中：

uint16_t udp_len = rte_be_to_cpu_16(udp->dgram_len);
if (udp_len < sizeof(struct rte_udp_hdr)) {
 /* malformed packet */
}

uint16_t payload_len = udp_len - sizeof(struct rte_udp_hdr);
uint8_t *payload = (uint8_t *)(udp + 1);

printf("udp: %.*s\n", (int)payload_len, (char *)payload);

真正处理报文前，还要结合 rte_pktmbuf_pkt_len(mbuf) 检查 Ethernet、IP、UDP 声明的长度是否落在 mbuf 实际数据范围内。需要记住：构造包和解析包都必须以显式长度为边界。

打印 IP 和端口

struct in_addr addr = { .s_addr = ip->src_addr };
printf("sip %s:%u --> ", inet_ntoa(addr),
 rte_be_to_cpu_16(udp->src_port));

addr.s_addr = ip->dst_addr;
printf("dip %s:%u\n", inet_ntoa(addr),
 rte_be_to_cpu_16(udp->dst_port));

inet_ntoa() 使用内部静态缓冲区，不适合并发代码；工程中优先使用 inet_ntop()。

UDP 收到一个数据报就可以立即生成一个独立响应。TCP 则必须维护连接状态，因为一个 TCP 报文的正确响应取决于此前发生过什么。

最小服务端路径为：

客户端 DPDK 服务端
 | -------- SYN, seq=x --------> |
 | <--- SYN+ACK, seq=y, ack=x+1 -|
 | -------- ACK, ack=y+1 ------> |
 | | ESTABLISHED
 | ------ PSH+ACK, data --------> |

草稿定义了完整 TCP 状态枚举：

typedef enum {
 USTACK_TCP_STATUS_CLOSED = 0,
 USTACK_TCP_STATUS_LISTEN,
 USTACK_TCP_STATUS_SYN_RCVD,
 USTACK_TCP_STATUS_SYN_SENT,
 USTACK_TCP_STATUS_ESTABLISHED,
 USTACK_TCP_STATUS_FIN_WAIT_1,
 USTACK_TCP_STATUS_FIN_WAIT_2,
 USTACK_TCP_STATUS_CLOSING,
 USTACK_TCP_STATUS_TIME_WAIT,
 USTACK_TCP_STATUS_CLOSE_WAIT,
 USTACK_TCP_STATUS_LAST_ACK
} ustack_tcp_status_t;

当前代码实际只实现了：

LISTEN → SYN_RCVD → ESTABLISHED

因此准确的描述是“完成服务端三次握手的最小实验”，而不是“已经实现 TCP 协议栈”。重传、乱序、滑动窗口、拥塞控制、RST、FIN 四次挥手、TIME_WAIT、TCP Options 和多连接管理都还没有实现。

九、TCP 的 SEQ 与 ACK 应该怎样理解

收到客户端 SYN：

client.seq = x

服务端回复 SYN+ACK：

server.seq = y
server.ack = x + 1

SYN 虽然不携带应用数据，但会占用一个序列号，所以确认号是 x + 1。FIN 同样占用一个序列号。

对于普通数据段：

下一确认号 = 当前 seq + TCP payload 长度

如果同一段还带 SYN 或 FIN，还应分别再加 1。

草稿中的：

tcp->sent_seq = htonl(12345);
tcp->recv_ack = htonl(global_seqnum + 1);

足以演示 SYN+ACK，但 12345 应被视为教学用的初始序列号。真实实现需要为每条连接保存本端/对端序列号，并校验收到的 ACK 是否真正确认了自己发送的 SYN 或数据。

十、构造最小 SYN+ACK

TCP 响应与 UDP 的 Ethernet、IPv4 部分基本相同；区别在 TCP Header：

struct rte_tcp_hdr *tcp = (struct rte_tcp_hdr *)(ip + 1);
*tcp = (struct rte_tcp_hdr){0};

tcp->src_port = global_sport;
tcp->dst_port = global_dport;
tcp->sent_seq = rte_cpu_to_be_32(server_isn);
tcp->recv_ack = rte_cpu_to_be_32(client_seq + 1);
tcp->data_off = (sizeof(struct rte_tcp_hdr) / 4) << 4;
tcp->tcp_flags = RTE_TCP_SYN_FLAG | RTE_TCP_ACK_FLAG;
tcp->rx_win = rte_cpu_to_be_16(TCP_INIT_WINDOW);
tcp->cksum = 0;
tcp->cksum = rte_ipv4_udptcp_cksum(ip, tcp);

几个容易忽略的点：

data_off 的高 4 位表示 TCP Header 占几个 32 位字；基础头 20 字节，所以值为 5 << 4，即 0x50；
rx_win 是多字节字段，应使用网络字节序；
计算 checksum 前，checksum 字段必须先清零；
struct rte_tcp_hdr 最好整体清零，避免未初始化的 cksum、tcp_urp 等字段混入报文；
IPv4 total_length 必须覆盖 IPv4 Header、TCP Header 和 TCP payload。

为什么 UDP 头有长度，而 TCP 头没有

UDP 自身以数据报为边界，因此 Header 中有 dgram_len：

UDP 长度 = UDP Header + UDP payload

TCP 是字节流协议，段长度可以从 IPv4 总长度推导：

TCP 段长度 = IP total_length - IP Header 长度
TCP payload 长度 = TCP 段长度 - TCP Header 长度

对应代码：

uint16_t ip_hdr_len = (ip->version_ihl & 0x0f) * 4;
uint16_t tcp_hdr_len = (tcp->data_off >> 4) * 4;
uint16_t ip_total_len = rte_be_to_cpu_16(ip->total_length);

uint16_t tcp_payload_len =
 ip_total_len - ip_hdr_len - tcp_hdr_len;

因此，TCP 的确认号并不是“长度字段”，但它会随着已经确认的字节数向前推进，体现了 TCP 字节流的位置。

十一、最小 TCP 状态处理

1. LISTEN 收到 SYN

if ((flags & RTE_TCP_SYN_FLAG) &&
 state == USTACK_TCP_STATUS_LISTEN) {
 client_next_seq = rte_be_to_cpu_32(tcp->sent_seq) + 1;
 send_syn_ack(...);
 state = USTACK_TCP_STATUS_SYN_RCVD;
}

2. SYN_RCVD 收到有效 ACK

不能只检查 ACK 位，还应验证确认号：

if ((flags & RTE_TCP_ACK_FLAG) &&
 state == USTACK_TCP_STATUS_SYN_RCVD &&
 rte_be_to_cpu_32(tcp->recv_ack) == server_isn + 1) {
 state = USTACK_TCP_STATUS_ESTABLISHED;
}

3. ESTABLISHED 收到数据

PSH 只是提示接收端尽快把数据交给应用，不是“存在 payload”的唯一判断条件。更可靠的判断是计算 tcp_payload_len > 0：

uint16_t payload_len = get_tcp_payload_len(ip, tcp);

if (state == USTACK_TCP_STATUS_ESTABLISHED && payload_len > 0) {
 const uint8_t *payload = (const uint8_t *)tcp + tcp_hdr_len;
 printf("tcp data: %.*s\n", (int)payload_len,
 (const char *)payload);

 /* 回复 ACK 时：ack = peer_seq + payload_len */
}

草稿能够打印 TCP 数据，但还没有为数据段回复 ACK，也没有处理 FIN；一些客户端因此会持续重传或无法正常关闭连接。

十二、从草稿中提炼出的典型 Bug

1. IPv4 地址只复制了 2 字节

错误版本：

rte_memcpy(&global_sip, &ip->dst_addr, sizeof(uint16_t));

IPv4 地址是 32 位，应复制 sizeof(uint32_t)，或者直接赋值：

global_sip = ip->dst_addr;
global_dip = ip->src_addr;

2. 把 UDP 总长度当成 payload 长度

错误思路：

rte_memcpy(udp + 1, data, udp_len);

正确关系：

payload_len = udp_len - sizeof(struct rte_udp_hdr);
rte_memcpy(udp + 1, data, payload_len);

3. 分配了新 mbuf，却传错发送指针

错误版本：

rte_eth_tx_burst(port_id, 0, &mbufs, 1);

应发送刚构造的单个 mbuf：

rte_eth_tx_burst(port_id, 0, &mbuf, 1);

&mbufs 是整个 RX 指针数组的地址，语义也不正确。

4. 多字节字段漏做字节序转换

典型字段包括：

ip->total_length = rte_cpu_to_be_16(ip_len);
udp->dgram_len = rte_cpu_to_be_16(udp_len);
tcp->sent_seq = rte_cpu_to_be_32(seq);
tcp->recv_ack = rte_cpu_to_be_32(ack);
tcp->rx_win = rte_cpu_to_be_16(window);

MAC 地址和 payload 是字节数组，不需要转换。

5. 不检查 TX 返回值

TX Queue 满时，rte_eth_tx_burst() 可以少发甚至不发。未成功发送的 mbuf 若不释放，会产生内存泄漏。

6. 只看 Flags，不校验状态与序列号

“收到带 ACK 标志的包”不等于三次握手完成。至少还要确认当前状态是 SYN_RCVD，且 ACK 值为服务端初始序列号加 1。

十三、完整代码逐行讲解

这一节按照程序真正的运行顺序，从头文件开始解释，直到收到、解析、构造并发送一个包。代码前面的数字只是讲解用行号，不是源代码的一部分。

1. 头文件分别提供什么

01 #include <stdio.h>
02 #include <stdint.h>
03 #include <errno.h>
04 #include <arpa/inet.h>
05
06 #include <rte_eal.h>
07 #include <rte_ethdev.h>
08 #include <rte_mbuf.h>
09 #include <rte_ether.h>
10 #include <rte_ip.h>
11 #include <rte_udp.h>
12 #include <rte_tcp.h>

第 1 行：提供 printf()。
第 2 行：提供 uint8_t、uint16_t、uint32_t 等定长整数类型。网络协议字段有固定宽度，因此比普通 int 更合适。
第 3 行：提供 ENOMEM、ENOSPC 等错误码。
第 4 行：提供 inet_ntop()、htons() 等网络地址与字节序函数。
第 6 行：提供 rte_eal_init()、rte_exit() 等 DPDK 运行环境接口。
第 7 行：提供网口、RX/TX Queue 和 rte_eth_rx_burst()、rte_eth_tx_burst()。
第 8 行：提供 mempool、mbuf 分配、释放和数据地址转换接口。
第 9～12 行：分别提供 Ethernet、IPv4、UDP、TCP Header 结构体和协议常量。

#include 的作用是把函数声明、结构体定义和宏定义提供给当前 .c 文件。它不会替代链接步骤；编译时仍要通过 DPDK 的 pkg-config 参数链接对应库。

2. 全局端口、mbuf 数量与 Burst 大小

01 static uint16_t global_portid = 0;
02
03 #define NUM_MBUFS 4096
04 #define BURST_SIZE 128

第 1 行：选择 DPDK 端口 0。它表示 DPDK 枚举得到的端口编号，不一定等于 Linux 中的网卡名称或 PCI 地址。
static：这里表示变量只在当前源文件内可见，减少与其他文件同名变量冲突的机会。
第 3 行：mempool 预备 4096 个 mbuf。RX 和新建的 TX 包都会消耗池中的对象。
第 4 行：一次 rte_eth_rx_burst() 最多取回 128 个 mbuf 指针。

NUM_MBUFS 是整个对象池规模，BURST_SIZE 是一次批量操作的上限，两者不是同一概念。

3. 功能开关与发送端点

01 #define ENABLE_SEND 1
02 #define ENABLE_TCP 1
03 #define TCP_INIT_WINDOW 14600
04
05 #if ENABLE_SEND
06 uint8_t global_smac[RTE_ETHER_ADDR_LEN];
07 uint8_t global_dmac[RTE_ETHER_ADDR_LEN];
08 uint32_t global_sip;
09 uint32_t global_dip;
10 uint16_t global_sport;
11 uint16_t global_dport;
12 #endif

第 1 行：控制是否编译发包代码。关闭后可退回仅收包版本。
第 2 行：控制是否编译 TCP 实验代码，可以只验证 UDP。
第 3 行：定义 SYN+ACK 中通告给客户端的接收窗口大小。
第 5～12 行：只有启用发送功能时才定义响应端点。
第 6～7 行：分别保存响应包的源 MAC 与目的 MAC。
第 8～9 行：IPv4 地址是 32 位，因此类型必须是 uint32_t。
第 10～11 行：TCP/UDP 端口是 16 位。

这些变量保存的地址和端口直接来自收到的协议头，所以仍是网络字节序。只有打印或参与主机侧数值计算时，才需要 rte_be_to_cpu_16()、rte_be_to_cpu_32()。

4. 端口默认配置

01 static const struct rte_eth_conf port_conf_default = {
02 .rxmode = {
03 .max_rx_pkt_len = RTE_ETHER_MAX_LEN
04 }
05 };

第 1 行：定义一个网口配置结构体，并用 const 表示运行中不修改它。
.rxmode = { ... }：这是 C 语言的指定初始化器，只填写 rxmode 成员，其余成员自动初始化为 0。
第 3 行：把最大接收包长设为普通 Ethernet 帧允许的范围。

不同 DPDK 版本的 struct rte_eth_conf 字段可能变化。如果本机版本提示 max_rx_pkt_len 不存在，应检查安装版本的头文件和示例，而不是强行照抄字段名。

5. 查询可用端口和设备默认能力

01 static int ustack_init_port(struct rte_mempool *mbuf_pool)
02 {
03 uint16_t nb_ports = rte_eth_dev_count_avail();
04
05 if (nb_ports == 0) {
06 rte_exit(EXIT_FAILURE,
07 "No supported Ethernet device found\n");
08 }
09
10 if (!rte_eth_dev_is_valid_port(global_portid)) {
11 rte_exit(EXIT_FAILURE, "Invalid port id\n");
12 }
13
14 struct rte_eth_dev_info dev_info;
15 int ret = rte_eth_dev_info_get(global_portid, &dev_info);
16 if (ret != 0) {
17 rte_exit(EXIT_FAILURE,
18 "Cannot get device info: %d\n", ret);
19 }

第 1 行：函数接收 mempool 指针，因为 RX Queue 需要知道从哪个池获取接收缓冲区。
第 3 行：查询当前由 DPDK 管理且可用的 Ethernet 端口数量。
第 5～8 行：一个可用端口都没有时直接退出。常见原因包括网卡没有绑定到合适驱动、权限不足或 EAL 参数错误。
第 10 行：即使系统存在端口，也要确认准备使用的 global_portid 有效。
第 14 行：声明设备信息结构体，用于接收驱动默认配置和网卡能力。
第 15 行：读取 0 号端口的信息。
第 16～18 行：检查 API 返回值；不能在查询失败后继续使用未初始化的 dev_info。

6. 配置 RX Queue 与 TX Queue 的数量

01 const uint16_t num_rx_queues = 1;
02
03 #if ENABLE_SEND
04 const uint16_t num_tx_queues = 1;
05 #else
06 const uint16_t num_tx_queues = 0;
07 #endif
08
09 rte_eth_dev_configure(global_portid,
10 num_rx_queues,
11 num_tx_queues,
12 &port_conf_default);
13
14 #if ENABLE_SEND
15 struct rte_eth_txconf txq_conf = dev_info.default_txconf;
16 txq_conf.offloads = port_conf_default.txmode.offloads;
17
18 if (rte_eth_tx_queue_setup(global_portid,
19 0,
20 512,
21 rte_eth_dev_socket_id(global_portid),
22 &txq_conf) < 0) {
23 rte_exit(EXIT_FAILURE, "Could not setup TX queue\n");
24 }
25 #endif

第 1 行：仍然只配置一个 RX Queue。
第 3～7 行：启用发送时创建一个 TX Queue，否则把 TX Queue 数量设为 0。
第 9～12 行：网口配置阶段必须提前声明 RX/TX Queue 的数量。
第 15 行：从设备能力信息中复制驱动提供的默认 TX 配置，避免凭空构造不兼容的参数。
第 16 行：把端口级 TX offload 配置同步给队列。草稿整理前曾写成 rxmode.offloads，此处应与 TX 配置对应。
第 18 行：开始配置 TX Queue。
第 19 行：队列编号为 0，因为当前只创建一个发送队列。
第 20 行：TX 描述符数量为 512，它描述队列容量，不是单次最多只能发送 512 个包。
第 21 行：让队列内存尽量位于网卡所属的 NUMA Socket。
第 22 行：传入刚才复制并调整的 TX 配置。
第 23 行：配置失败就退出，避免程序进入一个必然无法发送的循环。

7. 配置 RX Queue

01 if (rte_eth_rx_queue_setup(global_portid,
02 0,
03 128,
04 rte_eth_dev_socket_id(global_portid),
05 NULL,
06 mbuf_pool) < 0) {
07 rte_exit(EXIT_FAILURE, "Could not setup RX queue\n");
08 }

第 1 行：为指定网口建立接收队列。
第 2 行：队列编号为 0。
第 3 行：配置 128 个 RX 描述符。描述符用于让网卡和驱动追踪接收缓冲区，不等于只创建 128 个 mbuf。
第 4 行：选择网卡所在 NUMA Socket。
第 5 行：传 NULL 表示使用驱动默认 RX Queue 配置。
第 6 行：把前面创建的 mempool 交给 RX Queue。网卡收到包后，驱动会使用池中的 mbuf 承载数据。
第 7 行：队列创建失败就退出。

8. 启动端口并返回

01 if (rte_eth_dev_start(global_portid) < 0) {
02 rte_exit(EXIT_FAILURE, "Could not start port\n");
03 }
04
05 return 0;
06 }

第 1 行：前面的 configure 和 queue setup 只是准备配置，这里才真正启动设备。
第 2 行：启动失败不能进入收发循环。
第 5 行：返回 0 表示端口初始化成功。
第 6 行：结束 ustack_init_port() 函数。

9. `main()` 的参数与 EAL 初始化

01 int main(int argc, char **argv)
02 {
03 int ret = rte_eal_init(argc, argv);
04 if (ret < 0) {
05 rte_exit(EXIT_FAILURE, "Error with EAL init\n");
06 }

第 1 行：argc 是命令行参数数量，argv 是字符串指针数组。
第 3 行：初始化 DPDK EAL。它会处理 lcore、内存、设备等 DPDK 参数。
返回负数表示初始化失败。
返回非负数表示 EAL 消耗掉的命令行参数数量。如果程序还要解析自己的参数，可以使用 argc -= ret; argv += ret; 跳过 EAL 参数。
第 4～5 行：初始化失败时打印错误并结束进程。

EAL 必须先初始化，后面创建 mempool、查询端口和配置设备才有可用的 DPDK 运行环境。

10. 创建 mbuf pool

07 struct rte_mempool *mbuf_pool =
08 rte_pktmbuf_pool_create("mbuf_pool",
09 NUM_MBUFS,
10 0,
11 0,
12 RTE_MBUF_DEFAULT_BUF_SIZE,
13 rte_socket_id());
14
15 if (mbuf_pool == NULL) {
16 rte_exit(EXIT_FAILURE,
17 "Could not create mbuf pool\n");
18 }

第 7 行：声明 mempool 指针，用来保存创建结果。
第 8 行：池名称用于 DPDK 内部查找和调试，同一进程中应保持唯一。
第 9 行：池中创建 NUM_MBUFS 个 mbuf 对象。
第 10 行：per-lcore cache 大小设为 0，逻辑简单，但性能实验中通常会选择合适缓存值。
第 11 行：每个 mbuf 不添加额外的应用私有区。
第 12 行：每个 mbuf 的数据缓冲区使用 DPDK 默认大小。
第 13 行：在当前执行 lcore 所在 NUMA Socket 分配池内存。
第 15～18 行：创建失败时不能继续配置 RX Queue。

11. 初始化网口并进入无限循环

19 ustack_init_port(mbuf_pool);
20
21 while (1) {
22 struct rte_mbuf *mbufs[BURST_SIZE] = {0};

第 19 行：把刚创建的 mempool 交给端口初始化函数，并建立 RX/TX Queue。
第 21 行：DPDK 常使用轮询模式，所以程序持续运行，不断检查 RX Queue。
第 22 行：在栈上创建一个数组，用来保存本次批量取回的 mbuf 指针。数组中不是报文数据本身，而是指向 mbuf 的指针。
= {0} 会把所有数组元素初始化为空指针；虽然接下来有效元素会被 API 覆盖，但初始化有利于调试。

12. 从 RX Queue 批量取包

23 uint16_t num_recvd =
24 rte_eth_rx_burst(global_portid,
25 0,
26 mbufs,
27 BURST_SIZE);
28
29 for (uint16_t i = 0; i < num_recvd; i++) {
30 struct rte_mbuf *rx_mbuf = mbufs[i];
31 uint32_t frame_len = rte_pktmbuf_pkt_len(rx_mbuf);

第 23～27 行：从 0 号端口、0 号 RX Queue 最多取 BURST_SIZE 个包。
返回 0 表示当前没有包，不是错误；while 会立即进入下一轮轮询。
返回值不会大于传入的 BURST_SIZE，所以原草稿中的 num_recvd > BURST_SIZE 棬查没有实际意义。
第 29 行：只遍历 API 确认有效的前 num_recvd 个元素。
第 30 行：为当前包取一个更易读的局部变量名。
第 31 行：读取整个包的实际字节数，后面定位 Header 前必须先检查长度。

13. 检查并定位 Ethernet Header

32 if (frame_len < sizeof(struct rte_ether_hdr)) {
33 rte_pktmbuf_free(rx_mbuf);
34 continue;
35 }
36
37 struct rte_ether_hdr *ethhdr =
38 rte_pktmbuf_mtod(rx_mbuf,
39 struct rte_ether_hdr *);
40
41 if (ethhdr->ether_type !=
42 rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4)) {
43 rte_pktmbuf_free(rx_mbuf);
44 continue;
45 }

第 32 行：报文连一个 Ethernet Header 都放不下时，不能继续强制转换并读取字段。
第 33 行：当前 mbuf 没有交给 TX，应用仍拥有它，因此需要释放。
第 34 行：跳过当前包，继续处理 Burst 中的下一个包。
第 37～39 行：rte_pktmbuf_mtod() 取得 mbuf 数据起始地址，并转换为 Ethernet Header 指针。
第 41～42 行：EtherType 等于 IPv4 才进入本实验的 IPv4 处理路径。
第 43～44 行：非 IPv4 包当前不处理，但仍必须释放 mbuf。

rte_pktmbuf_mtod() 只是做地址取得与类型转换，不会自动校验数据是否足够长，所以第 32 行不能省略。

14. 检查并定位 IPv4 Header

46 uint32_t min_ipv4_frame =
47 sizeof(struct rte_ether_hdr) +
48 sizeof(struct rte_ipv4_hdr);
49
50 if (frame_len < min_ipv4_frame) {
51 rte_pktmbuf_free(rx_mbuf);
52 continue;
53 }
54
55 struct rte_ipv4_hdr *iphdr =
56 rte_pktmbuf_mtod_offset(
57 rx_mbuf,
58 struct rte_ipv4_hdr *,
59 sizeof(struct rte_ether_hdr));
60
61 uint16_t ip_hdr_len =
62 (iphdr->version_ihl & 0x0f) * 4;
63
64 if (ip_hdr_len < sizeof(struct rte_ipv4_hdr) ||
65 frame_len < sizeof(struct rte_ether_hdr) +
66 ip_hdr_len) {
67 rte_pktmbuf_free(rx_mbuf);
68 continue;
69 }

第 46～48 行：计算 Ethernet Header 加最小 IPv4 Header 需要多少字节。
第 50～53 行：实际帧比这个值短时直接丢弃。
第 55～59 行：从 mbuf 数据起点偏移一个 Ethernet Header，取得 IPv4 Header 地址。
第 61～62 行：IPv4 IHL 位于 version_ihl 的低 4 位，单位是 4 字节。
第 64 行：IHL 小于 20 字节不合法。
第 65～66 行：实际帧必须能容纳 IHL 声明的完整 IPv4 Header。
第 67～68 行：格式不合法就释放并跳过。

当前示例默认 Header 位于 mbuf 的第一个连续数据段。若接收的是 multi-segment mbuf，直接取指针前还要确保所需字节连续，或使用 rte_pktmbuf_read()。

15. 根据 IHL 定位 UDP 或 TCP Header

70 uint8_t *l4 = (uint8_t *)iphdr + ip_hdr_len;
71
72 if (iphdr->next_proto_id == IPPROTO_UDP) {
73 if (frame_len <
74 sizeof(struct rte_ether_hdr) + ip_hdr_len +
75 sizeof(struct rte_udp_hdr)) {
76 rte_pktmbuf_free(rx_mbuf);
77 continue;
78 }
79
80 struct rte_udp_hdr *udphdr =
81 (struct rte_udp_hdr *)l4;
82 /* 进入 UDP Echo 处理 */
83
84 } else if (iphdr->next_proto_id == IPPROTO_TCP) {
85 if (frame_len <
86 sizeof(struct rte_ether_hdr) + ip_hdr_len +
87 sizeof(struct rte_tcp_hdr)) {
88 rte_pktmbuf_free(rx_mbuf);
89 continue;
90 }
91
92 struct rte_tcp_hdr *tcphdr =
93 (struct rte_tcp_hdr *)l4;
94 /* 进入 TCP 状态处理 */
95 }

第 70 行：不能总用 iphdr + 1 找四层 Header，因为 IPv4 可能带 Options；这里使用前面算出的真实 IHL。
第 72 行：next_proto_id 表示 IPv4 payload 使用哪种上层协议。
第 73～78 行：读取 UDP Header 之前，确认帧中至少有 8 字节 UDP Header。
第 80～81 行：把四层起点解释为 UDP Header。
第 84 行：如果不是 UDP，再检查是否为 TCP。
第 85～90 行：TCP 基础 Header 至少 20 字节，读取前同样检查实际长度。
第 92～93 行：把四层起点解释为 TCP Header。

到这里，程序才安全地取得 UDP 或 TCP Header。下面开始解释各协议的响应构造。

16. 收到 UDP 包后保存响应方向

01 if (iphdr->next_proto_id == IPPROTO_UDP) {
02 struct rte_udp_hdr *udphdr =
03 (struct rte_udp_hdr *)((uint8_t *)iphdr + ip_hdr_len);
04
05 rte_memcpy(global_smac,
06 ethhdr->dst_addr.addr_bytes,
07 RTE_ETHER_ADDR_LEN);
08 rte_memcpy(global_dmac,
09 ethhdr->src_addr.addr_bytes,
10 RTE_ETHER_ADDR_LEN);
11
12 global_sip = iphdr->dst_addr;
13 global_dip = iphdr->src_addr;
14 global_sport = udphdr->dst_port;
15 global_dport = udphdr->src_port;

第 1 行：只进入 UDP 分支。
第 2～3 行：把 IPv4 Header 起点加上刚计算出的 ip_hdr_len，定位 UDP Header；这样 IPv4 带 Options 时也不会找错位置。
第 5～7 行：请求包的目的 MAC 是本机 MAC，它应成为响应包的源 MAC。
第 8～10 行：请求包的源 MAC 是客户端 MAC，它应成为响应包的目的 MAC。
第 12～13 行：用直接赋值对调 IPv4 地址，避免误写复制长度。
第 14～15 行：对调 UDP 端口，使响应发回请求客户端。

这里的“对调”不是在原协议头中原地交换，而是先保存响应方向，稍后写入一个新的 TX mbuf。

17. 计算收到的 UDP 数据长度

16 uint16_t udp_len =
17 rte_be_to_cpu_16(udphdr->dgram_len);
18
19 if (udp_len < sizeof(struct rte_udp_hdr)) {
20 rte_pktmbuf_free(mbufs[i]);
21 continue;
22 }
23
24 uint16_t payload_len =
25 udp_len - sizeof(struct rte_udp_hdr);
26
27 uint8_t *payload = (uint8_t *)(udphdr + 1);
28 uint16_t ip_len =
29 sizeof(struct rte_ipv4_hdr) + udp_len;
30 uint16_t frame_len =
31 sizeof(struct rte_ether_hdr) + ip_len;

第 16～17 行：从 UDP Header 读取总长度，并转换为主机字节序，方便做减法和比较。
第 19 行：合法 UDP 长度至少为 8 字节，即一个 UDP Header。
第 20 行：这个示例假定当前分支负责释放收到的 mbuf。若外层统一释放，此处不能再次释放。
第 24～25 行：UDP payload 长度等于 UDP 总长度减去 UDP Header。
第 27 行：udphdr + 1 跨过一个完整的 UDP Header，指向 payload 起始位置。
第 28～29 行：IPv4 总长度由 IPv4 Header 和整个 UDP 数据报组成。
第 30～31 行：完整帧长度再加上 Ethernet Header。

在使用 UDP Header 声明的长度前，还必须确认它没有超过 IPv4 total_length 和 RX mbuf 的实际数据范围。前面的 Header 存在性检查只能证明 UDP Header 本身可读，不能证明对方声明的整个 payload 都真实存在。

18. 为响应包分配 TX mbuf

32 struct rte_mbuf *tx_mbuf =
33 rte_pktmbuf_alloc(mbuf_pool);
34
35 if (tx_mbuf == NULL) {
36 printf("rte_pktmbuf_alloc failed\n");
37 continue;
38 }
39
40 uint8_t *frame =
41 rte_pktmbuf_append(tx_mbuf, frame_len);
42
43 if (frame == NULL) {
44 rte_pktmbuf_free(tx_mbuf);
45 continue;
46 }

第 32～33 行：从创建好的 mempool 中取一个 mbuf，用于保存响应包。
第 35 行：mempool 耗尽时分配会失败，不能继续解引用空指针。
第 40～41 行：在 mbuf 尾部追加 frame_len 字节，并取得可写的数据地址。
第 41 行：rte_pktmbuf_append() 同时更新 data_len 和 pkt_len，比手工写两个长度字段更安全。
第 43～45 行：如果 mbuf 的可用尾部空间不足，释放刚分配的 mbuf。

这里选择“新建 TX mbuf”，优点是 RX 包保持不变，逻辑直观。后续追求性能时，也可以在满足可写、连续性和所有权条件的前提下原地改写 RX mbuf 再发送。

19. 逐层写入 UDP 响应包

47 struct rte_ether_hdr *eth =
48 (struct rte_ether_hdr *)frame;
49
50 rte_memcpy(eth->dst_addr.addr_bytes,
51 global_dmac,
52 RTE_ETHER_ADDR_LEN);
53 rte_memcpy(eth->src_addr.addr_bytes,
54 global_smac,
55 RTE_ETHER_ADDR_LEN);
56 eth->ether_type =
57 rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4);

第 47～48 行：把帧首地址解释成 Ethernet Header。
第 50～52 行：写目的 MAC，即原请求的源 MAC。
第 53～55 行：写源 MAC，即原请求的目的 MAC。
第 56～57 行：声明 Ethernet payload 是 IPv4。EtherType 是 16 位字段，要使用网络字节序。

接着写 IPv4 Header：

58 struct rte_ipv4_hdr *ip =
59 (struct rte_ipv4_hdr *)(eth + 1);
60 *ip = (struct rte_ipv4_hdr){0};
61
62 ip->version_ihl = RTE_IPV4_VHL_DEF;
63 ip->total_length = rte_cpu_to_be_16(ip_len);
64 ip->time_to_live = 64;
65 ip->next_proto_id = IPPROTO_UDP;
66 ip->src_addr = global_sip;
67 ip->dst_addr = global_dip;
68 ip->hdr_checksum = 0;
69 ip->hdr_checksum = rte_ipv4_cksum(ip);

第 58～59 行：eth + 1 跨过 Ethernet Header，得到 IPv4 Header 地址。
第 60 行：先把整个 Header 清零，避免未初始化字段影响报文和 checksum。
第 62 行：写入 IPv4 与 20 字节基础头长度。
第 63 行：IPv4 总长度不包含 Ethernet Header。
第 64 行：TTL 设置为 64。
第 65 行：声明上层协议为 UDP。
第 66～67 行：写入已经对调好的源/目的 IPv4 地址。
第 68 行：计算 IPv4 Header checksum 前先把 checksum 字段清零。
第 69 行：计算并写入新的 IPv4 Header checksum。

最后写 UDP Header 和 payload：

70 struct rte_udp_hdr *udp =
71 (struct rte_udp_hdr *)(ip + 1);
72
73 udp->src_port = global_sport;
74 udp->dst_port = global_dport;
75 udp->dgram_len = rte_cpu_to_be_16(udp_len);
76 udp->dgram_cksum = 0;
77
78 rte_memcpy(udp + 1, payload, payload_len);
79 udp->dgram_cksum =
80 rte_ipv4_udptcp_cksum(ip, udp);

第 70～71 行：基础 IPv4 Header 后紧跟 UDP Header。
第 73～74 行：写入对调后的端口；它们已经是网络字节序。
第 75 行：UDP 长度包括 UDP Header 和 UDP payload。
第 76 行：计算 UDP checksum 前先清零。
第 78 行：只复制 payload_len，不能复制包含 UDP Header 的 udp_len。
第 79～80 行：使用 IPv4 伪首部、UDP Header 和 payload 计算 UDP checksum。

20. 发送 UDP 响应并处理所有权

81 uint16_t nb_tx =
82 rte_eth_tx_burst(global_portid,
83 0,
84 &tx_mbuf,
85 1);
86
87 if (nb_tx == 0) {
88 rte_pktmbuf_free(tx_mbuf);
89 }
90 }

第 81～85 行：请求 0 号 TX Queue 发送一个 mbuf。
第 84 行：参数必须是 &tx_mbuf，即“mbuf 指针数组的首地址”。只有一个包时，单个指针的地址可以充当长度为 1 的数组。
第 85 行：本次希望发送 1 个包。
第 87 行：若返回 0，说明驱动没有接管这个 mbuf。
第 88 行：发送失败时所有权仍属于应用，所以由应用释放。
若返回 1，不能在这里释放；后续由驱动在发送完成后回收。

外层还必须释放没有转交给 TX 的 RX mbuf。若选择原地改写 RX mbuf 并成功发送，则该 RX mbuf 的所有权已经交给 TX，不能再按接收包释放一次。

21. TCP 状态与每条连接需要保存的数据

草稿中使用一个全局状态：

01 uint8_t tcp_status = USTACK_TCP_STATUS_LISTEN;
02 uint32_t global_seqnum;
03 uint32_t global_acknum;
04 uint32_t server_isn = 12345;

第 1 行：服务端从监听状态开始。
第 2 行：保存收到报文的 SEQ，转换为主机字节序后便于加减。
第 3 行：保存收到报文的 ACK。
第 4 行：教学代码使用固定初始序列号；真实实现应生成合适的 ISN。

这些字段实际上都属于一条 TCP 连接。支持多个客户端时，应把它们放入连接控制块：

struct tcp_control_block {
 uint32_t local_ip;
 uint32_t remote_ip;
 uint16_t local_port;
 uint16_t remote_port;
 uint32_t snd_nxt;
 uint32_t rcv_nxt;
 ustack_tcp_status_t state;
};

前四项构成连接四元组，收到 TCP 包后用四元组查找对应状态，而不是共享一个全局 tcp_status。

22. 收到 TCP 包并读取关键字段

01 } else if (iphdr->next_proto_id == IPPROTO_TCP) {
02 struct rte_tcp_hdr *tcphdr =
03 (struct rte_tcp_hdr *)(iphdr + 1);
04
05 global_sip = iphdr->dst_addr;
06 global_dip = iphdr->src_addr;
07 global_sport = tcphdr->dst_port;
08 global_dport = tcphdr->src_port;
09
10 uint8_t flags = tcphdr->tcp_flags;
11 uint32_t peer_seq =
12 rte_be_to_cpu_32(tcphdr->sent_seq);
13 uint32_t peer_ack =
14 rte_be_to_cpu_32(tcphdr->recv_ack);

第 1 行：进入 TCP 分支。
第 2～3 行：教学版本仍假设 IPv4 Header 固定为 20 字节。
第 5～8 行：对调 IP 和端口，准备构造服务端响应。
第 10 行：TCP Flags 只有一个字节，不需要字节序转换。
第 11～12 行：SEQ 是 32 位字段，转换为主机字节序后保存。
第 13～14 行：ACK 同样转换为主机字节序。

TCP 响应同样需要保存 MAC 方向：

rte_memcpy(global_smac,
 ethhdr->dst_addr.addr_bytes,
 RTE_ETHER_ADDR_LEN);
rte_memcpy(global_dmac,
 ethhdr->src_addr.addr_bytes,
 RTE_ETHER_ADDR_LEN);

第一段把收到包的目的 MAC 保存为响应源 MAC；第二段把收到包的源 MAC 保存为响应目的 MAC。

23. LISTEN 状态收到 SYN

15 if ((flags & RTE_TCP_SYN_FLAG) != 0 &&
16 tcp_status == USTACK_TCP_STATUS_LISTEN) {
17
18 uint32_t ack_to_peer = peer_seq + 1;
19 send_syn_ack(server_isn, ack_to_peer);
20 tcp_status = USTACK_TCP_STATUS_SYN_RCVD;
21 }

第 15 行：使用按位与检查 SYN 标志是否存在，因为一个 TCP 包可以同时带多个 Flags。
第 16 行：只有监听状态才把这个 SYN 当作新连接请求。
第 18 行：SYN 占用一个序列号，因此响应 ACK 为客户端 SEQ+1。
第 19 行：构造并发送 SYN | ACK 报文。
第 20 行：发送后进入 SYN_RCVD，等待三次握手的最后一个 ACK。

学习版还应继续改进：如果 SYN+ACK 实际没有成功进入 TX Queue，不能直接认为它已经发送；收到重复 SYN 时也应考虑重发 SYN+ACK。

24. 逐行构造 SYN+ACK

Ethernet 和 IPv4 Header 的写法与 UDP 响应相同，只需把 IP 上层协议及总长度改为 TCP：

01 uint16_t tcp_len = sizeof(struct rte_tcp_hdr);
02 uint16_t ip_len = sizeof(struct rte_ipv4_hdr) + tcp_len;
03 uint16_t frame_len = sizeof(struct rte_ether_hdr) + ip_len;
04
05 ip->total_length = rte_cpu_to_be_16(ip_len);
06 ip->next_proto_id = IPPROTO_TCP;
07 ip->hdr_checksum = 0;
08 ip->hdr_checksum = rte_ipv4_cksum(ip);
09
10 struct rte_tcp_hdr *tcp =
11 (struct rte_tcp_hdr *)(ip + 1);
12 *tcp = (struct rte_tcp_hdr){0};
13
14 tcp->src_port = global_sport;
15 tcp->dst_port = global_dport;
16 tcp->sent_seq = rte_cpu_to_be_32(server_isn);
17 tcp->recv_ack = rte_cpu_to_be_32(peer_seq + 1);
18 tcp->data_off =
19 (sizeof(struct rte_tcp_hdr) / sizeof(uint32_t)) << 4;
20 tcp->tcp_flags = RTE_TCP_SYN_FLAG | RTE_TCP_ACK_FLAG;
21 tcp->rx_win = rte_cpu_to_be_16(TCP_INIT_WINDOW);
22 tcp->cksum = 0;
23 tcp->cksum = rte_ipv4_udptcp_cksum(ip, tcp);

第 1 行：SYN+ACK 不带 payload，本例 TCP 段只有基础 TCP Header。
第 2～3 行：依次得到 IPv4 总长度与完整帧长度，用于 Header 和 mbuf。
第 5 行：IPv4 总长度包含 IPv4 Header 与 TCP Header，不含 Ethernet Header。
第 6 行：把 IPv4 上层协议改为 TCP。
第 7～8 行：写完影响 IPv4 Header 的字段后重新计算 Header checksum。
第 10～11 行：TCP Header 紧跟在基础 IPv4 Header 后面。
第 12 行：清零整个 TCP Header，避免窗口、紧急指针等字段含有随机值。
第 14～15 行：写入对调后的端口。
第 16 行：服务端第一次发送 SYN，SEQ 等于本端 ISN。
第 17 行：确认客户端的 SYN，所以 ACK 等于客户端 SEQ+1。
第 18～19 行：TCP Header 长度以 32 位字为单位，并放在 data_off 的高 4 位。
第 20 行：同时置位 SYN 与 ACK。
第 21 行：窗口是 16 位字段，要转换为网络字节序。
第 22～23 行：清零后计算覆盖 IPv4 伪首部和 TCP 段的 checksum。

完成 Header 后，仍要像 UDP 一样分配/扩展 mbuf、调用 rte_eth_tx_burst() 并处理未发送的 mbuf。

25. 验证三次握手最后一个 ACK

01 if ((flags & RTE_TCP_ACK_FLAG) != 0 &&
02 tcp_status == USTACK_TCP_STATUS_SYN_RCVD &&
03 peer_ack == server_isn + 1) {
04
05 tcp_status = USTACK_TCP_STATUS_ESTABLISHED;
06 printf("enter established\n");
07 }

第 1 行：检查 ACK 标志存在。
第 2 行：只有已经发送 SYN+ACK 的连接才能通过这个分支建立。
第 3 行：客户端必须确认服务端的 SYN；因为 SYN 占一个序列号，所以期望值是 server_isn + 1。
第 5 行：状态迁移到 ESTABLISHED。
第 6 行：打印日志，方便结合抓包确认状态变化时机。

草稿最初只检查“有 ACK 标志且当前是 SYN_RCVD”，没有验证 ACK 数值。补上第 3 行后，三次握手判断才更完整。

26. 计算 TCP payload，而不是只检查 PSH

01 uint16_t ip_hdr_len =
02 (iphdr->version_ihl & 0x0f) * 4;
03 uint16_t tcp_hdr_len =
04 (tcphdr->data_off >> 4) * 4;
05 uint16_t ip_total_len =
06 rte_be_to_cpu_16(iphdr->total_length);
07
08 if (ip_total_len < ip_hdr_len + tcp_hdr_len) {
09 continue;
10 }
11
12 uint16_t payload_len =
13 ip_total_len - ip_hdr_len - tcp_hdr_len;
14 uint8_t *payload =
15 (uint8_t *)tcphdr + tcp_hdr_len;
16
17 if (tcp_status == USTACK_TCP_STATUS_ESTABLISHED &&
18 payload_len > 0) {
19 printf("tcp data: %.*s\n",
20 (int)payload_len,
21 (char *)payload);
22 }

第 1～2 行：从 IHL 低 4 位得到 IPv4 Header 的 32 位字数量，再乘 4 得到字节数。
第 3～4 行：从 data_off 高 4 位得到 TCP Header 的字节数，因此 TCP Options 也会被正确跳过。
第 5～6 行：读取 IPv4 Header 声明的整个 IP 包长度。
第 8～10 行：总长度不能比两个 Header 相加还小，否则减法会发生无符号下溢。
第 12～13 行：用 IP 总长度减去两个 Header，得到 TCP payload 长度。
第 14～15 行：根据真实 TCP Header 长度定位 payload，而不是固定写 tcphdr + 1。
第 17 行：只有已建立连接才把数据交给应用层。
第 18 行：以实际 payload 长度判断是否有数据，不依赖 PSH 标志。
第 19～21 行：使用带长度的格式打印，避免把网络数据误当作以 \0 结尾的字符串。

收到数据后还应该回复 ACK：

ack_to_peer = peer_seq + payload_len;

如果该段带 SYN 或 FIN，还应为每个标志额外加 1。当前草稿尚未实现数据 ACK，因此还只是握手与数据解析原型。

27. RX mbuf 的最终释放位置

接收循环应为每个包建立唯一、清楚的释放路径。使用新 TX mbuf 构造响应时，可以在本轮处理结束后释放 RX mbuf：

for (uint16_t i = 0; i < num_recvd; i++) {
 bool rx_forwarded_to_tx = false;

 /* 解析并处理 mbufs[i] */

 if (!rx_forwarded_to_tx) {
 rte_pktmbuf_free(mbufs[i]);
 }
}

当前 UDP/TCP 示例新建了 tx_mbuf，所以原 mbufs[i] 没有转交给 TX，应由接收循环释放。草稿中缺少这一步，会导致 RX mbuf 持续泄漏，最终耗尽 mempool。

如果以后改为原地改写并发送 RX mbuf，则发送成功后应把 rx_forwarded_to_tx 设为 true，防止重复释放。

十四、怎样验证实现是否正确

建议按层验证，不要一上来同时调 UDP 和 TCP。

阶段一：只验证 TX Queue

网口成功配置一个 TX Queue；
rte_eth_tx_burst() 返回 1；
抓包能看到 DPDK 网卡发出的帧。

阶段二：验证 UDP Echo

请求和响应的 MAC、IP、Port 方向相反；
Echo payload 与请求完全一致；
IPv4 total_length、UDP dgram_len 正确；
Wireshark 未报告 IPv4/UDP checksum 错误；
连续发送大量数据时，mempool 可用数量没有持续下降。

若开启了 TX checksum offload，抓包点可能位于网卡真正计算 checksum 之前，抓包工具会显示“校验和错误”；需要结合 offload 配置和抓包位置判断，不能只看这一条提示。

阶段三：验证 TCP 握手

SYN 到达时，状态为 LISTEN；
SYN+ACK 的 ACK 等于客户端 SEQ+1；
客户端最终 ACK 等于服务端 SEQ+1；
只有 ACK 校验通过后才进入 ESTABLISHED；
发送 payload 后，能正确计算 TCP Header 长度和 payload 长度。

常用观察点：

源/目的 MAC
源/目的 IP
源/目的端口
EtherType / IP Protocol
IP total_length
UDP length 或 TCP data offset
TCP flags / seq / ack
checksum
rte_eth_tx_burst 返回值

十五、把实验抽象成 pktgen 发包工具

完成 UDP/TCP 编码后，可以把“回包程序”进一步抽象为一个简单的发包工具。命令行可以设计为：

./ustack-pktgen \
 --udp \
 --src-ip 192.168.1.10 \
 --dst-ip 192.168.1.20 \
 --src-port 10000 \
 --dst-port 20000 \
 --dst-mac 00:11:22:33:44:55 \
 --count 1000 \
 --payload "hello dpdk"

TCP 模式可改用 --tcp，并增加：

--flags syn|ack|psh|fin|rst
--seq N
--ack N
--window N

程序结构可以拆成：

参数解析
 ├── 公共参数：源/目的 MAC、IP、数量、长度
 ├── UDP 参数：源/目的端口、payload
 └── TCP 参数：flags、seq、ack、window
 ↓
统一 packet description
 ↓
encode_ether + encode_ipv4
 ↓
encode_udp 或 encode_tcp
 ↓
burst send + 统计

这个小工具的价值在于：

为协议栈、网关、防火墙等项目构造可重复的测试流量；
精确控制五元组、TCP Flags、SEQ/ACK 等字段；
练习 DPDK 多包批量构造和发送；
后续可增加速率限制、不同包长、随机地址、时延与丢包统计。

在简历中应写清“实现了哪些能力”和“测得什么结果”，不要泛写成“实现 TCP/IP 协议栈”。例如：

基于 DPDK 实现用户态 UDP Echo 与最小 TCP 服务端握手原型，完成 Ethernet/IPv4/UDP/TCP 报文构造、校验和计算、TCP 状态迁移及 mbuf 批量收发；进一步抽象可配置五元组与报文数量的流量生成工具，用于协议功能测试。

若有实测结果，可以继续补充包长、队列数、CPU 核数、吞吐量和丢包率。

十六、本篇回顾清单

读完代码后，应能不看资料回答这些问题：

为什么配置了 RX Queue 仍不能发送数据？
为什么把收到的 mbuf 原样送进 TX Queue 不构成 Echo？
UDP Echo 需要交换哪三层的哪些字段？
Ethernet FCS 与 IPv4/UDP/TCP checksum 分别由谁处理？
ip->total_length、udp->dgram_len、mbuf->pkt_len 各自包含什么？
为什么 payload 复制长度不能直接使用 UDP dgram_len？
rte_eth_tx_burst() 返回 0 时，mbuf 应由谁释放？
SYN 和 FIN 为什么会各占用一个序列号？
为什么 TCP Header 没有类似 UDP 的长度字段？
为什么仅凭 PSH 标志不能判断 TCP 包一定携带数据？
为什么一个全局 tcp_status 无法支持多个 TCP 连接？
当前原型距离完整 TCP 协议栈还缺哪些关键能力？

十七、总结

本篇真正跨过的一步，是从“解析别人构造好的报文”走向“自己构造一个能被对端接受的报文”。

UDP Echo 说明了发包的基本方法：

分配 mbuf → 填各层 Header → 复制 payload
→ 写网络字节序 → 计算 checksum → 交给 TX Queue

TCP 实验则进一步说明：协议栈不只是报文格式的集合，还必须维护状态和时序。能生成 SYN+ACK 只是起点；要成为完整 TCP 实现，还需要可靠传输、序列号校验、超时重传、窗口管理、连接表和连接关闭等机制。

从工程实践看，本次代码最值得记住的不是某个固定 API，而是四条原则：

每一层的长度边界必须算清楚；
所有多字节协议字段都要明确主机/网络字节序；
checksum 计算前先清零，并明确由软件还是硬件负责；
任何 mbuf 都必须有清晰的所有权和释放路径。

DPDK 用户态协议栈设计与实现

Sat, 15 Aug 2026 00:00:00 +0800

学习目标：理解网卡、网卡驱动、TCP/IP 协议栈、POSIX Socket API 与应用程序之间的关系；搭建 DPDK 环境；使用 DPDK 收取以太网帧；逐步解析 Ethernet、IPv4、UDP、TCP；最终理解用户态协议栈需要补齐哪些能力。

一、先建立完整的网络数据路径

可以把网络程序拆成五个逻辑模块：

1. 网卡 NIC
 ↕
2. 网卡驱动 Driver
 ↕
3. TCP/IP 协议栈
 ↕
4. POSIX Socket API：socket / bind / listen / accept / recv / send
 ↕
5. Application：Redis / Nginx / 自己编写的服务器

接收数据时，数据总体从左向右、从上向下流动；发送数据时方向相反。

不过，必须区分下面两条不同的数据路径。

1. Linux 内核协议栈路径

物理网络
 → 网卡
 → Linux 内核网卡驱动
 → sk_buff
 → 内核 Ethernet/IP/TCP/UDP 协议栈
 → Socket 接收缓冲区
 → recv()/read()
 → 应用程序

应用程序使用的是 Linux 已经实现好的协议栈。Redis、Nginx 默认走的就是这条路径。

2. DPDK 用户态路径

物理网络
 → 网卡
 → VFIO/UIO + DPDK PMD 用户态驱动
 → RX Descriptor Ring
 → rte_mbuf
 → 自己实现或引入的用户态协议栈
 → 自己实现的 Socket/POSIX 兼容层
 → 应用程序

网卡绑定给 DPDK 使用的驱动后，该端口的普通数据收发路径通常绕过 Linux 内核网卡驱动和内核 TCP/IP 协议栈。DPDK 负责高速收发原始数据包，但 DPDK 本身不是 TCP/IP 协议栈。

重要纠错：不能把 DPDK 主路径理解成“网卡 → DPDK → 内核驱动 → 内核 TCP/IP”。正常的 DPDK 用户态收包路径绕过内核协议栈。只有主动使用 KNI、TAP、virtio-user 等机制时，才会把选定的数据包重新送入内核。

二、网卡是什么

1. 网卡的基本职责

网卡（NIC，Network Interface Card）连接计算机和网络介质，主要完成：

接收和发送物理信号；
完成物理层编码、解码、时钟恢复等工作；
识别和生成以太网帧；
校验帧的 FCS；
按配置进行 MAC 地址过滤、VLAN 处理；
通过 DMA 在网卡和主机内存之间搬运数据；
一些网卡还能完成 checksum、TSO、LRO、RSS 等硬件卸载。

“网卡把模拟信号通过 AD/DA 转换为 0 和 1”可以帮助入门理解，但并不完全准确。现代以太网 PHY 会进行复杂的线路编码、调制、均衡和信号恢复，不能简单等同于普通 ADC/DAC。

2. 网卡属于哪一层

网卡不是完全独立于分层模型之外。通常可以这样理解：

PHY 部分主要工作在物理层；
MAC 部分主要工作在数据链路层；
checksum、TSO、RSS 等卸载能力会辅助更高层处理。

因此，说网卡“主要横跨物理层和数据链路层”更准确。

3. DMA：网卡如何把数据交给内存

网卡不会要求 CPU 一个字节一个字节地读取数据。典型过程如下：

驱动在内存中准备一组 RX 描述符和数据缓冲区；
驱动把这些内存地址告诉网卡；
网卡收到数据后，通过 DMA 直接把数据写入内存缓冲区；
网卡更新 RX 描述符，标记该数据包已经完成；
CPU 再处理描述符所指向的数据。

这里的 RX 描述符通常按环形结构组织，所以常称为 RX Ring 或 Descriptor Ring。

三、网卡驱动做什么

网卡驱动是操作系统或 DPDK 与具体网卡硬件之间的适配层。它通常负责：

根据 PCI Vendor ID / Device ID 识别硬件；
初始化网卡寄存器；
配置 MAC、MTU、收发队列和硬件卸载；
分配 RX/TX Descriptor Ring；
建立 DMA 映射；
启停网卡；
处理链路状态和错误；
在中断模式或轮询模式下回收、提交数据包。

Linux 内核中有统一的网络设备框架，e1000、ixgbe、i40e、mlx5、vmxnet3 等具体驱动在这个框架下实现。DPDK 则提供 PMD（Poll Mode Driver），让用户态程序通过轮询直接与网卡队列交互。

1. 中断模式与轮询模式

传统内核路径通常结合中断和 NAPI 轮询：

流量较低时，网卡通过中断通知 CPU；
流量较高时，NAPI 暂时关闭频繁中断，改用批量轮询；
这样可以避免“中断风暴”。

DPDK 的典型方式是 Poll Mode：

rte_eth_rx_burst(port_id, queue_id, mbufs, BURST_SIZE);

线程不断轮询指定的端口和队列，避免中断、调度和上下文切换开销。代价是即使没有数据，轮询线程也可能持续占用一个 CPU 核。

2. 多队列网卡

多队列网卡拥有多个 RX/TX 队列。其价值在于：

不同队列可以由不同 CPU 核或线程独立处理；
减少多个核心竞争同一个队列锁；
利用 RSS 把不同网络流分散到多个 RX 队列；
提升并行处理能力和总体吞吐量。

常见绑定关系是：

RX Queue 0 → lcore 1
RX Queue 1 → lcore 2
RX Queue 2 → lcore 3
RX Queue 3 → lcore 4

RSS 通常根据源/目的 IP、源/目的端口、协议号计算哈希，将同一个流稳定地送到同一队列，避免同一 TCP 流的数据包在多个核心间乱序处理。

重要纠错：多队列能显著提高并行性，但“不是多队列网卡就一定无法绑定 DPDK”并不准确。单队列设备也可能被支持，只是扩展能力差。能否绑定和运行取决于设备、PMD、IOMMU、VFIO/UIO 以及虚拟化环境等条件。

3. 虚拟机中的 vmxnet3

VMware 中可以在 .vmx 文件中指定：

ethernet0.virtualDev = "vmxnet3"
ethernet0.wakeOnPcktRcv = "TRUE"

vmxnet3 是 VMware 的半虚拟化高性能网卡，通常比模拟的 e1000 拥有更好的性能和多队列能力。修改配置前应关闭虚拟机，并确认实际使用的 ethernet0、ethernet1 与目标 MAC 地址相匹配。

四、sk_buff、rte_mbuf 与 Ring

1. Linux 的 sk_buff

Linux 内核用 struct sk_buff 描述网络包。它不是简单地把所有协议头复制一遍，而是保存：

数据缓冲区的位置；
当前数据起点和末尾；
MAC、网络层和传输层头的位置；
数据包长度；
所属设备；
checksum、VLAN、路由等元数据；
链表等组织信息。

协议层之间传递的通常是 sk_buff 指针。各层通过移动或记录头部位置来解析数据，而不是每经过一层就复制整个包。

2. 海量 sk_buff 如何组织

“每包一个 sk_buff，海量包如何组织”不能只用一种数据结构回答。不同阶段使用不同结构：

网卡收发描述符：环形队列 Ring；
NAPI 待处理对象：调度列表；
Socket 接收队列：链表/队列形式的 skb queue；
TCP 乱序数据：红黑树等结构；
TCP 重传数据：按发送顺序管理的队列/树；
内存对象分配：slab/slub 缓存。

所以，常用答案是“以 Ring 和各种队列为主，根据查找、排序、重传等需求再使用树结构”。

3. DPDK 的 rte_mbuf

rte_mbuf 与 sk_buff 的定位相似：都用来描述一个数据包及其元数据。DPDK 通常从预先创建的 mempool 中分配 mbuf，以减少频繁动态分配的开销。

mempool
 ├── rte_mbuf + data buffer
 ├── rte_mbuf + data buffer
 ├── rte_mbuf + data buffer
 └── ...

网卡通过 DMA 把数据写入 mbuf 对应的数据缓冲区。rte_eth_rx_burst() 返回的是已经装有数据的 mbuf 指针数组，因此 CPU 不需要再把整个数据包从内核复制到用户态。

这通常称为零拷贝或少拷贝设计，但严格来说仍然可能发生 DMA、缓存行传输、跨 NUMA 访问以及应用层复制，不能把“零拷贝”理解成整个系统完全没有任何数据移动。

五、协议栈是什么

协议栈是一组按层协作的协议实现。接收一个 UDP/IPv4 以太网帧时，可依次解析：

Ethernet Header
 → IPv4 Header
 → UDP Header
 → Application Payload

接收 TCP 时则是：

Ethernet Header
 → IPv4 Header
 → TCP Header
 → TCP Segment Payload

解析协议头只是用户态协议栈的第一步。一个真正可用的协议栈还需要实现 ARP、路由、校验和、分片重组、TCP 状态机、重传、拥塞控制、Socket 缓冲区等功能。

六、以太网帧解析

不考虑 VLAN 标签时，Ethernet II 头部固定为 14 字节：

0 5 6 11 12 13
+----------------+----------------+--------+
| 目的 MAC 6字节 | 源 MAC 6字节 | 类型 2 |
+----------------+----------------+--------+

常见 EtherType：

0x0800：IPv4；
0x0806：ARP；
0x86DD：IPv6；
0x8100：802.1Q VLAN。

DPDK 中对应：

struct rte_ether_hdr *ethhdr =
 rte_pktmbuf_mtod(mbufs[i], struct rte_ether_hdr *);

rte_pktmbuf_mtod() 的作用是把 mbuf 中的数据起始地址转换成指定类型的指针。它并没有复制以太网头，只是在同一段内存上按 struct rte_ether_hdr 的布局解释字节。

判断是否为 IPv4：

if (ethhdr->ether_type != rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4)) {
 continue;
}

网络协议字段通常采用大端字节序，所以要进行主机字节序与网络字节序转换。

VLAN 注意事项

代码直接把以太网头后的数据当作 IPv4，只适用于没有 VLAN 标签的帧。若 EtherType 为 0x8100，还要解析 4 字节 VLAN Header，然后才能找到真正的上层 EtherType。

七、IPv4 解析

IPv4 基础头部最少 20 字节，结构包括：

+---------+---------+-------------------+
|Version | IHL | DSCP/ECN | Length |
+---------+---------+-------------------+
| Identification | Flags/Fragment Offset|
+---------------------------------------+
| TTL | Protocol | Header Checksum |
+---------------------------------------+
| Source IPv4 Address |
+---------------------------------------+
| Destination IPv4 Address |
+---------------------------------------+
| Options（可选，IHL > 5 时存在） |
+---------------------------------------+

关键字段：

Version：IPv4 时为 4；
IHL：头部长度，以 4 字节为单位；最小值为 5，即 20 字节；
Total Length：整个 IPv4 数据报长度；
Fragment Offset / Flags：分片相关；
TTL：每经过一个路由器通常减 1；
Protocol：上层协议，UDP=17，TCP=6，ICMP=1；
Header Checksum：只校验 IPv4 头；
Source/Destination Address：源和目的 IPv4 地址。

原代码通过固定的 14 字节 Ethernet Header 偏移找到 IPv4 头：

struct rte_ipv4_hdr *iphdr = rte_pktmbuf_mtod_offset(
 mbufs[i], struct rte_ipv4_hdr *, sizeof(struct rte_ether_hdr));

判断 UDP：

if (iphdr->next_proto_id == IPPROTO_UDP) {

IPv4 解析必须检查的内容

健壮的实现至少应检查：

mbuf 中是否有完整的 Ethernet 和 IPv4 基础头；
IPv4 Version 是否为 4；
IHL 是否至少为 5；
包长度是否覆盖 IHL * 4；
Total Length 是否合理；
IPv4 Header Checksum 是否正确，或确认硬件已校验；
是否为分片；
再根据 Protocol 分发给 ICMP、UDP 或 TCP。

原代码使用 (iphdr + 1) 寻找 UDP 头，相当于默认 IPv4 头固定为 20 字节。若 IPv4 带 Options，IHL 会大于 5，UDP 头的真实起点应为 IP Header 起点 + IHL * 4。

八、UDP 解析

UDP 头固定为 8 字节：

+-------------------+-------------------+
| Source Port | Destination Port |
+-------------------+-------------------+
| UDP Length | UDP Checksum |
+-------------------+-------------------+
| Payload ... |
+---------------------------------------+

关键字段：

Source Port：源端口；
Destination Port：目的端口；
Length：UDP 头加 Payload 的总长度，最小为 8；
Checksum：覆盖伪首部、UDP 头和 UDP 数据。

原代码：

struct rte_udp_hdr *udphdr = (struct rte_udp_hdr *)(iphdr + 1);
printf("udp:%s\n ", (char *)(udphdr + 1));

第一行把 IPv4 基础头后的地址解释为 UDP Header；第二行把 UDP Header 后的数据解释为 C 字符串并打印。

为什么 `%s` 只适合当前演示

网络 Payload 不保证以 \0 结尾，而 %s 会持续读取，直到遇到 \0。因此实际代码必须：

根据 UDP Length 计算 Payload 长度；
确认长度没有超过 mbuf/IPv4 数据长度；
使用带长度的输出方式，例如 %.*s；
对二进制协议应使用十六进制打印，而不是字符串打印。

当前 Packet Sender 发送的是短 ASCII 文本，并且内存后面恰好出现零字节，所以演示中可能正常输出，但这不是安全的通用处理方法。

九、TCP 解析

TCP 头最少为 20 字节，可带 Options，最长可达 60 字节。

+-------------------+-------------------+
| Source Port | Destination Port |
+---------------------------------------+
| Sequence Number |
+---------------------------------------+
| Acknowledgment Number |
+------+----------+---------------------+
|Offset| Flags | Window |
+-----------------+---------------------+
| Checksum | Urgent Pointer |
+---------------------------------------+
| Options（可选） |
+---------------------------------------+
| Payload ... |
+---------------------------------------+

关键字段：

Sequence Number：本段第一个字节的序号；
Acknowledgment Number：期望收到的下一个序号；
Data Offset：TCP Header 长度，以 4 字节为单位；
Flags：SYN、ACK、FIN、RST、PSH、URG 等；
Window：接收窗口，参与流量控制；
Checksum：覆盖 IPv4/IPv6 伪首部、TCP 头和 TCP 数据。

只把 TCP Header 拆出来还不能叫“实现 TCP”。至少还需要：

四元组查找连接：源 IP、源端口、目的 IP、目的端口；
TCP 状态机；
三次握手和四次挥手；
序列号和 ACK；
乱序重组；
超时重传；
RTT/RTO 估计；
滑动窗口和流量控制；
拥塞控制；
TIME_WAIT 等定时器管理。

TCP 状态机简图

服务器：CLOSED → LISTEN → SYN_RECEIVED → ESTABLISHED
客户端：CLOSED → SYN_SENT → ESTABLISHED

主动关闭的一方：ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED
被动关闭的一方：ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED

十、POSIX Socket API 与用户态协议栈

POSIX API 是应用程序看到的接口：

socket()：创建 Socket；
bind()：绑定本地 IP 和端口；
listen()：把 TCP Socket 设为监听状态；
accept()：取出一个已经建立的 TCP 连接；
connect()：主动发起 TCP 连接；
recv()/read()：读取接收数据；
send()/write()：发送数据；
close()：关闭 Socket。

1. 内核中的关系

在 Linux 内核协议栈中，文件描述符 fd 会关联到内核 Socket 对象。TCP 连接还对应一个传输控制块，可广义称为 TCB，其中保存：

四元组；
TCP 状态；
序列号；
收发窗口；
重传队列；
接收队列；
定时器等。

recv(fd, ...) 不是简单地“直接读取 TCB 某个位置”，而是通过 fd 找到 Socket，再从该 Socket 的接收缓冲区读取已经按序整理好的字节。如果没有数据，调用可能阻塞，或者在非阻塞模式下返回 EAGAIN。

2. 用户态协议栈怎样提供 POSIX API

如果应用完全绕过内核协议栈，Linux 原生 recv() 不会自动读取 DPDK mbuf。需要增加适配层，常见方法包括：

修改应用，让它调用用户态协议栈自己的 API；
使用库替换或 LD_PRELOAD 截获 Socket 调用；
提供兼容 POSIX 的用户态 Socket 库；
通过事件通知机制实现类似 epoll 的接口。

用户态需要自己维护：

fd/table
 → socket object
 → UDP endpoint 或 TCP TCB
 → receive queue / send queue

对于 UDP，recvfrom() 通常从对应端口的报文队列取出一个 Datagram；对于 TCP，recv() 从已经重排并确认连续的字节流中读取数据。

十一、DPDK 是什么，以及为什么快

DPDK（Data Plane Development Kit）是一组用于高速数据包处理的库、驱动和工具。它的核心思想包括：

用户态 PMD 轮询网卡；
批量收发 Burst；
预分配 mempool/mbuf；
Hugepage；
CPU 亲和性和独占核心；
NUMA 感知；
无锁 Ring；
硬件多队列与 RSS；
Prefetch 和缓存友好布局；
减少中断、系统调用、上下文切换和数据复制。

DPDK 优化的核心指标

DPDK 不只是“处理大包、提高吞吐量”。更准确地说，它常用于提高：

每秒处理的数据包数 PPS，尤其是大量小包；
总吞吐量；
延迟的可预测性和尾延迟；
多核心扩展能力。

是否能提升 Redis/Nginx 性能，取决于瓶颈：

如果瓶颈在业务逻辑、锁、存储或单线程执行，只有 DPDK 不会神奇地提高 QPS；
如果瓶颈在内核网络路径、软中断、系统调用或数据复制，用户态网络方案可能改善 QPS 或延迟；
把现有 Redis/Nginx 接到 DPDK 上需要完整协议栈和兼容层，并非简单绑定网卡即可。

常见使用场景

防火墙、ACL、DPI；
路由器、交换机、网关；
负载均衡器；
5G/电信数据面；
虚拟交换机；
流媒体或报文转发；
流量采集与监控；
高性能存储网络的数据面。

数据备份和 RDMA 可能使用类似的大页、DMA、零拷贝、用户态驱动思想，但 DPDK 与 RDMA 是不同的技术体系，不能简单说“底层一定用 DPDK，应用层用 RDMA”。

可研究的用户态协议栈/数据面项目包括 mTCP、lwIP、F-Stack、VPP、Seastar networking、基于 BSD 协议栈移植的实现等。项目是否仍活跃、DPDK 版本是否兼容，需要按实际版本确认。

十二、VFIO、UIO、PCI、KNI 与 NUMA

1. PCI 地址

网卡通常是 PCIe 设备。可以使用：

lspci
lspci -nn
lspci -k

PCI 地址形如：

0000:1a:00.0

含义是：

domain:bus:device.function

2. VFIO 与 UIO

它们帮助用户态程序访问 PCI 设备资源：

UIO：较简单的通用用户态 I/O 框架；
VFIO：通常配合 IOMMU，隔离性和安全性更好，现代环境一般优先使用；
DPDK PMD：真正理解并操作具体网卡寄存器和队列的用户态驱动。

不能简单理解为 VFIO/UIO“截获 PCI 地址”；更准确地说，它们把设备资源安全地映射或暴露给用户态驱动，并管理中断、DMA/IOMMU 等能力。

3. KNI

KNI 曾用于在 DPDK 应用与 Linux 内核网络栈之间交换数据包。例如，把控制面流量送回内核处理。但它不是 DPDK 收包必须经过的组件，而且在较新的 DPDK 方案中通常会考虑 TAP、virtio-user 等替代路径。

4. NUMA

NUMA 是 Non-Uniform Memory Access，即非一致内存访问。多路 CPU 服务器中，每个 CPU Socket 通常拥有本地内存：

CPU Socket 0 ↔ Local Memory 0
CPU Socket 1 ↔ Local Memory 1

CPU 访问本地内存比跨 Socket 访问远端内存更快。因此应尽量做到：

网卡所在 NUMA Node；
轮询该网卡的 CPU 核；
mbuf mempool 所在内存；

三者位于同一个 NUMA Node。

代码中的 rte_eth_dev_socket_id() 用于查询设备所在 NUMA Socket，rte_socket_id() 返回当前 lcore 所在 Socket。二者不一定总是相同。

十三、Hugepage 大页

普通页通常为 4 KiB。Hugepage 常见规格为：

2 MiB；
1 GiB。

DPDK 使用大页主要是为了：

减少页表项数量；
降低 TLB Miss；
便于大块、稳定、可用于 DMA 的内存管理；
减少运行时内存分配的不确定性。

1. 示例 GRUB 配置

GRUB_CMDLINE_LINUX_DEFAULT="default_hugepagesz=2M hugepagesz=2M hugepages=1024"

这表示默认大页为 2 MiB，共预留 1024 页，即约 2 GiB 内存。虚拟机内存有限时，需要根据虚拟机总内存调整，不能机械照抄。

通常修改后还需要更新 GRUB 并重启，例如 Ubuntu/Debian：

sudo update-grub
sudo reboot

重启后验证：

grep -i huge /proc/meminfo

具体命令因发行版和 DPDK 版本而异。现代 DPDK 可能自动处理 hugetlbfs，也可以手动挂载。1 GiB 大页还依赖 CPU 支持，并通常需要在启动参数中预留。

2. Hugepage 不直接提升网卡物理转换速度

Hugepage 优化的是主机内存管理、TLB 和 DMA 缓冲区访问，并不会让网卡的光电信号转换本身更快。它提升的是数据包在 CPU/内存数据面中的处理效率和稳定性。

十四、VMware 三种网络模式

1. Bridged（桥接）

虚拟机像局域网中的独立主机：

物理局域网
 ├── Windows/macOS 宿主机：172.26.185.5
 └── 虚拟机：172.26.185.250

虚拟机通常与宿主机处于同一二层网络，可从局域网 DHCP 获取地址，或配置同网段静态地址。桥接绑定到某个宿主机物理接口时，该接口断开可能影响虚拟机网络。

“复制物理网络连接状态”之类的选项，通常让虚拟网卡随宿主机物理接口的连接/断开状态变化，适合笔记本在 Wi-Fi、有线网络之间切换的场景。不同 VMware 产品中的名称和细节会略有不同。

2. NAT

VMware 在宿主机上创建虚拟子网，虚拟机通过宿主机做 NAT 访问外网：

虚拟机 → VMware 虚拟网关/NAT → 宿主机 → 外网

外部设备通常不能直接主动访问虚拟机，除非做端口映射或额外配置。

3. Host-only（仅主机）

虚拟机主要与宿主机及同一 Host-only 网络中的虚拟机通信，默认不能直接访问外网。它适合隔离实验环境。

“Host-only 一定可以 ping 通公网”是不对的；默认情况下它不能上网，除非宿主机另行开启路由/NAT。

十五、macOS Packet Sender 测试链路

已知 DPDK 端口信息：

MAC：00:0c:29:aa:5b:f0
PCI：0000:1a:00.0
PMD：net_vmxnet3
Link：up

宿主机：

IP：172.26.185.5
Mask：255.255.0.0
Interface：en0

ustack 测试地址：

172.26.185.250

1. 为什么需要静态 ARP

应用把 UDP 发往 172.26.185.250:8888 时，操作系统需要构造以太网帧。因为目标 IP 在同一子网，macOS 必须知道目标 IP 对应的 MAC 地址。

正常情况是：

macOS 广播 ARP Request：谁是 172.26.185.250？
ustack 单播 ARP Reply：172.26.185.250 是 00:0c:29:aa:5b:f0

当前 ustack 没有实现 ARP Reply，所以手工建立：

sudo arp -s 172.26.185.250 00:0c:29:aa:5b:f0
sudo arp -s 172.26.185.250 00:0c:29:aa:5b:f0 ifscope en0

验证：

arp -n 172.26.185.250

2. Packet Sender 配置

Address：172.26.185.250
Port：8888
Protocol：UDP
ASCII：hello dpdk

完整路径：

Packet Sender
 → macOS UDP/IP 处理
 → 静态 ARP 表查到目标 MAC
 → macOS en0
 → VMware Fusion 桥接
 → vmxnet3 虚拟网卡
 → DPDK port 0 / RX queue 0
 → rte_eth_rx_burst()
 → Ethernet / IPv4 / UDP 解析
 → 打印 hello dpdk

看到：

udp:hello dpdk

说明至少以下环节已经连通：

macOS 到 Fusion 桥接网络；
目标 MAC 投递；
vmxnet3 链路；
DPDK 端口初始化；
RX Queue 0 收包；
当前测试报文的 Ethernet/IPv4/UDP 基础解析。

但它还不能单独证明 checksum、分片、VLAN、IP Options、异常长度处理等已经正确实现。

十六、DPDK 环境搭建思路

老版本 DPDK 常使用 dpdk-setup.sh、RTE_SDK 和 RTE_TARGET。典型含义是：

export RTE_SDK=/home/.../dpdk
export RTE_TARGET=...

RTE_SDK：DPDK 源码/SDK 根目录；
RTE_TARGET：旧版构建系统生成的目标目录名称。

native 一般表示按当前机器架构优化；linuxapp 是旧版目标名称的一部分；具体选项需要以所使用的旧版 DPDK 文档和脚本为准。

现代 DPDK 已主要使用 Meson + Ninja 构建，不再依赖旧式 make config、RTE_TARGET 流程：

meson setup build
ninja -C build

因此必须先确认教程使用的 DPDK 版本。不要把老教程里的菜单选项直接套到新版本。

通用搭建检查表

确认 CPU 架构、Linux 发行版和 DPDK 版本；
确认 vmxnet3/物理网卡被当前 DPDK PMD 支持；
配置 Hugepage；
若使用 VFIO，确认 IOMMU/VFIO 条件；
查看 PCI 地址和当前驱动；
将实验网卡绑定到合适驱动；
保留管理网卡，避免把 SSH 所依赖的唯一网卡绑定走；
用 testpmd 检查端口、队列、Link 和收包计数；
再运行自己的程序。

安全提示：绑定网卡前一定确认 PCI 地址。将正在承载 SSH 或默认路由的网卡绑定给 DPDK，会立即让普通 Linux 网络连接中断。

十七、原始代码（保持不变）

下面代码完全按原内容保留，没有修改：

#include<stdio.h>
#include<rte_eal.h>
#include<rte_ethdev.h>
#include<arpa/inet.h>

int global_portid=0;//网卡绑定id从0开始 发数据和收数据知道id就好
#define NUM_MBUFS 4096
#define BURST_SIZE 128
static const struct rte_eth_conf port_conf_default={
 .rxmode={.max_rx_pkt_len=RTE_ETHER_MAX_LEN}
};
static int ustack_init_port(struct rte_mempool *mbuf_pool){

 uint16_t nb_sys_ports=rte_eth_dev_count_avail();
 if(nb_sys_ports==0){
 rte_exit(EXIT_FAILURE,"No Supported eth found/n");
 } 
 //struct rte_eth_dev_info dev_info;
 //rte_eth_dev_info_get(global_portid，&dev_info);
 //绑定的网卡
 //现在有八个 队列 弄1 2 4 8 
 const int num_rx_queues =1;
 const int num_tx_queues =0;
 rte_eth_dev_configure(global_portid,num_rx_queues,num_tx_queues,&port_conf_default);
 
 if(rte_eth_rx_queue_setup(global_portid,0,128,rte_eth_dev_socket_id(global_portid),NULL,mbuf_pool)<0){
 //在0号网卡的0号队列开辟了RX队列 准备了128个mbuffer
 rte_exit(EXIT_FAILURE," Could not setup RX queue/n"); 
 }

 if (rte_eth_dev_start(global_portid)<0){//启动
 rte_exit(EXIT_FAILURE,"Could not start"); 
 }
 return 0;
}

int main(int argc,char *argv[]){

 if(rte_eal_init(argc,argv)<0){//初始化 检查网卡信息 配置 是否绑定
 rte_exit(EXIT_FAILURE,"Error with EAL init\n");
 }
 struct rte_mempool *mbuf_pool= rte_pktmbuf_pool_create("mbuf pool",NUM_MBUFS,0,0,RTE_MBUF_DEFAULT_BUF_SIZE,rte_socket_id());
 //接收数据放在mbuff
 //mbuffer分配在内存上的 rte_socket_id 就是当前使用哪块内存卡槽ID分配的
 if(mbuf_pool==NULL){
 rte_exit(EXIT_FAILURE,"Could not create mbuf pool\n");
 }

 ustack_init_port(mbuf_pool);

 //接收数据
 while(1){
 struct rte_mbuf *mbufs[BURST_SIZE]={0};
 uint16_t num_recvd= rte_eth_rx_burst(global_portid,0,mbufs,BURST_SIZE);
 if (num_recvd>BURST_SIZE){
 rte_exit(EXIT_FAILURE,"Error receiving from eth\n");
 }

 int i=0;
 for(i=0;i<num_recvd;i++){
 struct rte_ether_hdr *ethhdr=rte_pktmbuf_mtod(mbufs[i],struct rte_ether_hdr *);
 if(ethhdr->ether_type != rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4)){
 continue;
 }
 struct rte_ipv4_hdr *iphdr =rte_pktmbuf_mtod_offset(mbufs[i],struct rte_ipv4_hdr *,sizeof(struct rte_ether_hdr));
 if (iphdr->next_proto_id==IPPROTO_UDP){//两个以上都转
 struct rte_udp_hdr *udphdr =(struct rte_udp_hdr *)(iphdr+1);
 printf("udp:%s\n ",(char*)(udphdr+1));
 }
 }

 }
 printf("Hello dpdk\n");


}

十八、代码逐行对照理解

1. 头文件

#include<stdio.h>

引入标准输入输出声明，本程序用它调用 printf()。

#include<rte_eal.h>

引入 DPDK EAL 接口。EAL 是 Environment Abstraction Layer，负责 Hugepage、lcore、内存、PCI 设备等基础环境初始化，也声明了 rte_eal_init()、rte_exit() 等接口。

#include<rte_ethdev.h>

引入以太网设备抽象接口，包括端口配置、RX Queue 设置、设备启动和 Burst 收包。

#include<arpa/inet.h>

提供网络字节序、IP 地址转换等常用声明。当前代码中没有直接调用 htons()、ntohs() 等函数，但 IPPROTO_UDP 等定义可能通过相关系统头可见。实际项目通常还会显式包含 DPDK Ethernet/IP/UDP 头文件，具体取决于 DPDK 版本的包含关系。

2. 全局端口与常量

int global_portid=0;

选择 DPDK 逻辑端口 0。这里的 port id 是 DPDK 枚举后的端口编号，不等于 PCI 地址，也不一定等于 Linux 的 eth0。

#define NUM_MBUFS 4096

准备在 mempool 中创建 4096 个 mbuf。它们不仅供 128 个 RX 描述符使用，还要留给收包后尚未释放、缓存以及其他内部需求。

#define BURST_SIZE 128

每次调用 rte_eth_rx_burst()，最多希望取回 128 个包。实际返回值可以是 0 到 128。

3. 默认端口配置

static const struct rte_eth_conf port_conf_default={
 .rxmode={.max_rx_pkt_len=RTE_ETHER_MAX_LEN}
};

创建端口配置结构，把最大接收包长设为标准以太网最大长度对应的 DPDK 常量。

注意：DPDK 的结构体字段会随版本变化。某些新版本中 max_rx_pkt_len 的位置或用法已变化。如果发生编译错误，应首先对照当前版本 API，而不是认为网络原理有问题。

4. 端口初始化函数

static int ustack_init_port(struct rte_mempool *mbuf_pool){

定义只在本源文件使用的函数，参数是已经创建好的 mbuf 内存池。

uint16_t nb_sys_ports=rte_eth_dev_count_avail();

查询当前 EAL 环境中可用的 DPDK Ethernet 设备数量。nb 是 number 的常用缩写。它不是固定表示“绑定网口数量”，更准确地说是当前可用的 ethdev 数量。

if(nb_sys_ports==0){
 rte_exit(EXIT_FAILURE,"No Supported eth found/n");
}

如果没有设备，打印错误并退出。字符串中的 /n 是普通字符，不是换行符；真正的换行符写法是 \n。本笔记遵守要求，不修改原代码，只指出区别。

//struct rte_eth_dev_info dev_info;
//rte_eth_dev_info_get(global_portid，&dev_info);

这两行被注释，不会执行。设计意图是读取端口能力，比如最大队列数、RSS、offload 能力。第二行参数之间使用了中文逗号 ，，若取消注释需要注意它不能作为 C 语言逗号使用。

const int num_rx_queues =1;
const int num_tx_queues =0;

配置 1 个接收队列、0 个发送队列。此程序只收不发，所以 TX Queue 设为 0。若以后要回复 ARP、UDP 或 TCP，就必须配置 TX Queue。

rte_eth_dev_configure(global_portid,num_rx_queues,num_tx_queues,&port_conf_default);

配置端口的 RX/TX 队列数量和总体参数。函数有返回值，当前代码没有检查；健壮程序应检查是否小于 0。

if(rte_eth_rx_queue_setup(global_portid,0,128,
 rte_eth_dev_socket_id(global_portid),NULL,mbuf_pool)<0){

配置 RX Queue：

global_portid：端口 0；
0：RX Queue 0；
128：描述符数量；
rte_eth_dev_socket_id(...)：在网卡所在 NUMA Socket 分配队列资源；
NULL：使用默认 RX Queue 配置；
mbuf_pool：网卡收到的数据放入这个池提供的 mbuf。

注释“准备了 128 个 mbuffer”是便于理解的近似说法。准确说是请求建立 128 个 RX descriptors；描述符与 mbuf 的补充、占用和回收由 PMD 管理，mempool 总大小仍为 4096。

rte_exit(EXIT_FAILURE," Could not setup RX queue/n");

配置失败就退出。同样，/n 不会产生换行。

if (rte_eth_dev_start(global_portid)<0){
 rte_exit(EXIT_FAILURE,"Could not start");
}

启动端口。配置端口和队列只是准备工作，start 后网卡才进入正式收发状态。

return 0;

表示初始化成功。

5. main 与 EAL 初始化

int main(int argc,char *argv[]){

程序入口。DPDK 会先解析命令行中的 EAL 参数，应用自己的参数通常放在 -- 后面并根据 rte_eal_init() 的返回值调整。

if(rte_eal_init(argc,argv)<0){
 rte_exit(EXIT_FAILURE,"Error with EAL init\n");
}

初始化 DPDK 运行环境，涉及：

解析 EAL 参数；
发现 CPU lcore；
初始化 Hugepage 内存；
初始化内存管理；
探测并初始化设备和总线；
建立主从 lcore 等运行环境。

它不等于“自动保证所有网卡已经正确绑定”。绑定通常要在运行程序之前完成，EAL 负责发现当前可使用的设备。

6. 创建 mbuf pool

struct rte_mempool *mbuf_pool=
 rte_pktmbuf_pool_create("mbuf pool",NUM_MBUFS,0,0,
 RTE_MBUF_DEFAULT_BUF_SIZE,rte_socket_id());

参数逐个理解：

"mbuf pool"：内存池名称；
NUM_MBUFS：4096 个 mbuf；
第一个 0：每个 lcore 的 cache 数量为 0；
第二个 0：每个对象额外私有区域大小为 0；
RTE_MBUF_DEFAULT_BUF_SIZE：每个 mbuf 默认数据缓冲区大小；
rte_socket_id()：在当前运行核心所在 NUMA Socket 分配。

这里 rte_socket_id() 指 NUMA 节点编号，不是物理“内存卡槽 ID”。服务器硬件的 DIMM 插槽和 NUMA Node 不是同一个概念。

if(mbuf_pool==NULL){
 rte_exit(EXIT_FAILURE,"Could not create mbuf pool\n");
}

创建失败立即退出。可能原因包括 Hugepage 不足、名称冲突、socket 内存不够或参数不合法。

ustack_init_port(mbuf_pool);

用刚创建的内存池配置并启动端口。

7. 轮询收包

while(1){

进入无限循环。这是 PMD 轮询模型的核心，线程会持续询问 RX Queue 是否有包。

struct rte_mbuf *mbufs[BURST_SIZE]={0};

创建一个长度为 128 的指针数组。数组保存 rte_mbuf *，并不在栈上创建 128 个完整 mbuf。

uint16_t num_recvd=
 rte_eth_rx_burst(global_portid,0,mbufs,BURST_SIZE);

从端口 0、队列 0 最多取 128 个已经收到的包：

返回 0：当前没有包；
返回 1～128：实际取到的包数；
mbuf 指针写入 mbufs[0 ... num_recvd-1]。

rte_eth_rx_burst() 通常通过检查 RX descriptors 批量完成工作，不是每次都触发系统调用。

if (num_recvd>BURST_SIZE){
 rte_exit(EXIT_FAILURE,"Error receiving from eth\n");
}

按 API 契约，返回值不会大于传入的 BURST_SIZE，所以这个判断正常情况下不会成立。它也不能检测一般收包错误，因为该 API 的返回值语义主要是“本次收到多少包”。

8. 遍历每一个包

int i=0;
for(i=0;i<num_recvd;i++){

依次处理本轮收到的所有 mbuf。

struct rte_ether_hdr *ethhdr=
 rte_pktmbuf_mtod(mbufs[i],struct rte_ether_hdr *);

取得包数据起点，把它解释成 Ethernet Header。

if(ethhdr->ether_type != rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4)){
 continue;
}

如果 EtherType 不是 IPv4，就跳过后续解析。ARP、IPv6、VLAN 等都会走 continue。

这里有一个重要的生命周期问题：跳过不等于释放。当前程序没有调用 rte_pktmbuf_free(mbufs[i])，因此收到的 mbuf 不会归还 mempool。运行一段时间后，RX Queue 可能因为拿不到空闲 mbuf 而停止继续收包。

struct rte_ipv4_hdr *iphdr =rte_pktmbuf_mtod_offset(
 mbufs[i],struct rte_ipv4_hdr *,sizeof(struct rte_ether_hdr));

从数据起点向后移动一个 Ethernet Header 的长度，即 14 字节，再把地址解释成 IPv4 Header。

当前代码在解引用前没有检查包的实际长度；遇到截断帧或异常帧时可能越界读取。

if (iphdr->next_proto_id==IPPROTO_UDP){

检查 IPv4 Protocol 字段是否等于 UDP 的协议号 17。

struct rte_udp_hdr *udphdr =(struct rte_udp_hdr *)(iphdr+1);

iphdr + 1 会跳过一个 struct rte_ipv4_hdr，也就是按 20 字节基础 IPv4 头定位 UDP Header。它没有考虑 IHL 大于 5的 IPv4 Options。

printf("udp:%s\n ",(char*)(udphdr+1));

udphdr + 1 跳过 8 字节 UDP Header，将后续 Payload 当作字符串打印。它没有依据 UDP Length 限制读取长度，也没有保证 Payload 以 \0 结尾，因此只适合受控的入门测试。

9. 循环之后的代码

printf("Hello dpdk\n");

由于前面是无限循环，并且没有 break，正常情况下这一行不可达。

十九、今天内容的核心总结

网卡把网络介质上的信号变成帧，并通过 DMA 把数据放入主机内存；它主要涉及物理层和数据链路层。
驱动负责初始化网卡、配置队列和 DMA，并让软件能够操作具体硬件。
Linux 使用 sk_buff 描述数据包；DPDK 使用 rte_mbuf，两者都不只是数据本身，还包含元数据。
多队列让多个 CPU 核并行处理流量，RSS 负责把流分配到不同队列；多队列很重要，但不是所有 DPDK 绑定的绝对前提。
DPDK 用用户态轮询、Burst、Hugepage、mempool、多队列和 NUMA 优化高速包处理。
网卡绑定给 DPDK 后，常规数据路径绕过内核 TCP/IP；因此要么引入现有用户态协议栈，要么自己实现。
Ethernet 普通头为 14 字节，IPv4 最少 20 字节，UDP 固定 8 字节，TCP 最少 20 字节。
“能找到协议头并打印 Payload”只是解析器原型，不等于完整协议栈。
完整 UDP 还需要 ARP、IP、校验和、端口分发、队列和 API；完整 TCP 还需要状态机、序列号、重传、窗口、定时器等。
POSIX recv() 读取的是 Socket 接收缓冲区；用户态协议栈必须自己建立 fd、Socket、TCB 和收发队列之间的关系。
当前测试通过静态 ARP 绕过了尚未实现的 ARP Reply，成功证明了 macOS、Fusion 桥接、vmxnet3、DPDK RX 和基础 UDP 解析链路已打通。
下一步最重要的不是立即写 TCP，而是先补齐 mbuf 释放、长度校验、ARP Reply、TX 和 UDP Echo。

二十、版本说明与官方参考

你的学习材料明显包含旧版 DPDK 构建流程，因此本笔记保留了 dpdk-setup.sh、RTE_SDK、RTE_TARGET 的历史解释，同时把现代版本单独说明。实际执行命令时，必须先运行 dpdk-testpmd -v、查看源码目录中的 release 信息或构建文件，确认本机 DPDK 版本。

DPDK Linux Getting Started Guide：现代 Linux 环境、编译、驱动和运行入口；
DPDK Poll Mode Driver：PMD 绕过传统内核网络栈、直接轮询 RX/TX Descriptor 的官方说明；
DPDK Linux Drivers：VFIO、UIO、设备绑定和安全性说明；
DPDK VMXNET3 PMD：vmxnet3 收发环、多队列/RSS、功能与限制；
DPDK Hugepage Tool：查看、预留和挂载大页；
DPDK 22.11 KNI 文档：KNI 的用途、弃用状态及 virtio-user 替代说明。

DPDK on JasperSao的博客

DPDK 用户态 TCP 协议栈（四）：并发与自实现 epoll

一、先给出整篇的核心答案

二、只保留必要的旧知识：数据最终从哪里来到哪里去

三、支持并发的第一前提：连接必须彼此独立

1. 一条连接对应一个 ng_tcp_stream

2. 报文怎样找到自己的 stream

3. 监听 stream 和连接 stream

四、一连接一线程为什么能工作，又为什么需要 epoll

1. 一连接一线程

2. epoll 的改变

五、为什么不能直接调用 Linux 原生 epoll

六、理解 epoll 的关键：就绪是一种状态

1. 监听 fd 可读

2. 连接 fd 可读

3. 连接 fd 可写

七、epoll 的两个集合

1. 整集：我关注谁

2. 就绪集：现在谁能处理

3. 同一个节点同时属于两份集合

4. eventpoll 管理整个 epoll 实例

八、三个外部接口怎样组成应用侧逻辑

1. nepoll_create()：创建事件管理器

2. nepoll_ctl()：维护整集

3. nepoll_wait()：没有事件就睡，有事件就返回

九、最关键的内部接口：协议栈怎样触发事件

epoll 模块在整体架构中的位置

十、用三条时间线彻底串起实现

时间线一：新客户端完成连接

时间线二：已连接客户端发送 payload

时间线三：客户端发送 FIN

十一、epoll 服务器循环现在应该怎样读

十二、薄弱但非常重要：LT、ET 与“消费事件”

1. LT：Level Triggered，水平触发

2. ET：Edge Triggered，边沿触发

3. 当前学习代码的核心行为

十三、线程同步：为什么需要三种同步手段

1. 为什么等待必须检查条件

2. 为什么先入就绪集，再 signal

3. DEL 与回调之间的关系

十四、单 epoll 与多个 epoll

十五、多连接 core dump 在本篇中的位置

十六、把全部实现压缩成一张图

十七、最终应掌握的实现逻辑

十八、反刍题

DPDK 用户态协议栈（三）：从 TCP 握手到可靠传输

一、先看当前代码的 TCP 主线

二、代码怎样识别并取得 TCP 报文

三、为什么代码要把地址和端口反过来保存

1. MAC 地址交换

2. IP 地址交换

3. TCP 端口交换

四、代码怎样读取 Flags、SEQ 和 ACK

1. Flags

2. SEQ 与 ACK 是 32 位字段

五、结合 ustack_encode_tcp_pkt() 看 SYN+ACK 的构造

1. Ethernet Header

2. IPv4 Header

3. TCP Header

六、结合状态机完整理解三次握手

第一次握手：客户端发送 SYN

第二次握手：服务端回复 SYN+ACK

第三次握手：客户端回复 ACK

七、SEQ 的精髓：它是字节序号

八、ACK 的精髓：确认连续收到的字节

九、一条 TCP 连接为什么有两套 SEQ/ACK

十、代码怎样定位 TCP Payload

十一、从 rx_win 理解 TCP 接收窗口

十二、发送窗口：SND.UNA 与 SND.NXT

1. SND.UNA

2. SND.NXT

3. 在途数据量

4. 收到新 ACK 时窗口滑动

十三、接收窗口与有序交付

按序到达

C 暂时没有到达，D 先到

十四、延迟确认怎样接入接收逻辑

十五、为什么发送过的数据要暂时保存

十六、超时重传：没有收到 ACK 时怎么办

1. RTT

1. 一条连接对应一个 `ng_tcp_stream`

4. `eventpoll` 管理整个 epoll 实例

1. `nepoll_create()`：创建事件管理器

2. `nepoll_ctl()`：维护整集

3. `nepoll_wait()`：没有事件就睡，有事件就返回

3. `DEL` 与回调之间的关系

五、结合 `ustack_encode_tcp_pkt()` 看 SYN+ACK 的构造

十一、从 `rx_win` 理解 TCP 接收窗口

十二、发送窗口：`SND.UNA` 与 `SND.NXT`

1. `SND.UNA`

2. `SND.NXT`

`rte_eth_tx_burst()` 的返回值