MCU资源受限场景下uIP实现TCP client与TCP server双角色

简介围绕 uIP 轻量级 TCP/IP 协议栈展开的 TCP 客户端与服务器端完整工程面向具备一定 STM32 基础的嵌入式与物联网开发者对应 ALIENTEK 战舰 STM32 开发板第五十二章 ENC28J60 网络模块实验。内容涵盖 uIP 的内存管理与数据包处理、通过 SPI 接口驱动以太网控制器、中断与定时器配合以及从套接字建立连接、收发数据到断开连接的完整流程可对照代码理解三次握手与四次挥手如何真正落地并附带网页服务、邮件与 DHCP 等应用层例程。压缩包共 223 个文件、约 2.59MB以 81 个头文件与 76 个 C 源文件为主体涵盖协议栈、外设驱动与应用示例另附 pdf、txt 说明文档、png 与 gif 图示、shtml 网页及 makefile 构建脚本目录分层清晰便于按协议栈层次检索。已有 742 人学习适合作为嵌入式网络入门的对照工程边读代码边核对协议细节与硬件配置。1. 在一颗只有几 KB RAM 的 MCU 上同时跑 TCP client 和 TCP server手上有一块资源很紧的采集板网口只有一颗 MACPHY运行内存按 KB 计算。业务要求两件事同时成立板子要主动连上位机把采集数据推上去同时还要开一个端口让现场调试工具能反过来连进来下发参数。用 LwIP 试过一版光是把协议栈编译进去RAM 就被吃掉一大截换成 uIP 之后协议栈连同连接表加缓冲区常常能控制在 24 KB。代价是没有 socket、没有阻塞调用也没有 select所有收发都压在一个 app_call 回调上。uIP 这套 TCP/IP 实现加上一份 TCP client 和一份 TCP server 的应用层代码关键难点是让两条方向相反的连接路径共用同一块 uip_buf。读完你应该能跑通、看懂回调时序并知道改动时该动哪个文件。2. 架构与目录uIP 内核、client 路径、server 路径是怎么切成三层的在开始讲解之前先把工程骨架说清楚。uIP 的设计哲学是「内核只负责协议状态机应用只负责填回调」。内核不知道你是谁也不关心你在做客户端还是服务端它只在合适的时机调用同一个UIP_APPCALL()具体是哪条连接通过全局的uip_conn指针告诉你。这一层抽象一旦理解清楚client 和 server 就不会互相干扰。2.1 目录结构与各文件职责一份可移植的双端工程常见目录长这样uip-tcp-dual/ ├── uip/ # 协议栈内核移植时基本不动 │ ├── uip.c # IP/ICMP/TCP 状态机、输入处理、重传定时 │ ├── uip_arp.c # ARP 表与以太网头封装 │ ├── uip_arch.c # 校验和、32 位加减等与架构相关的实现 │ ├── uipopt.h # 默认配置与核心结构体定义 │ └── uip-conf.h # 工程级配置移植时唯一必须改的头文件 ├── net/ │ ├── tapdev.c # 网卡驱动poll/read/send 三个钩子 │ └── tapdev.h ├── app/ │ ├── app_call.c # 唯一的 uIP 应用回调入口负责分派 │ ├── tcp_server.c # 监听、会话表、命令解析 │ └── tcp_client.c # 主动连接、数据上报、断线重连 ├── timer.c / timer.h # 软件定时器喂 periodic 与 ARP 老化 └── main.c # 主循环编排uip/目录是原封不动拿来的net/是唯一跟硬件绑定的部分app/才是业务。这个分层的好处是换芯片只动net/改协议只动app/。而uip-conf.h是两者之间的合同连接数、缓冲区大小、字节序、回调函数名全在这里对好编译期就定死。我一般会先把app_call.c单独拆出来不把回调写进 client 或 server 的文件里。原因是 uIP 只有一个回调入口回调里必须先做连接归属判断这段分派逻辑只要写错一次client 收的数据就会进 server 的处理函数。2.2 事件驱动模型没有 socket也没有阻塞uIP 没有文件描述符概念。整个协议栈维护一个静态数组uip_conns[UIP_CONNS]每个元素是一个struct uip_conn里面存对端 IP、端口、TCP 状态位、重传计数和appstate指针。应用拿不到句柄只能在这个连接被激活时通过回调里的uip_conn反查自己存进去的状态。回调里能问的问题也就那几个宏宏 / 函数含义典型触发时机uip_connected()连接刚建立三次握手完成uip_newdata()收到新数据uip_appdata指向负载uip_datalen()给长度uip_acked()数据被确认重传计数清零、窗口前移uip_rexmit()需要重传超时未收到 ACKuip_closed()对端关闭收到 FINuip_aborted()/uip_timedout()连接异常或超时RST 或重传耗尽uip_poll()轮询唤醒没有任何事件靠周期驱动uip_poll()这一项很关键。uIP 重传靠周期调用uip_periodic(i)推进很多应用层心跳、超时判断其实都挂在这个「空事件」上。理解这一点才明白为什么不能随便在回调外面调uip_send。2.3 单协议栈双角色client 与 server 如何共享一个 uip_bufuip_buf是全局的收和发共用同一块内存uip_len表示当前长度。这意味着三件事第一任何时刻只能有一个包处于「在途」状态第二MSS 必须按缓冲大小倒算通常取UIP_BUFSIZE - UIP_LLH_LEN - 40第三在一个回调里调了uip_send之后本次周期就不能再发第二个包。client 和 server 共存时连接表是一个池子谁先占谁用。比如UIP_CONF_MAX_CONNECTIONS配 5server 最多并发 3 条、client 常驻 1 条还剩 1 条余量给 TIME_WAIT 兜底。这个数字不是随便定的配小了会在真实环境里出现「server 明明在监听新连接却连不进来」的假死现象后面避坑章会细讲。3. 移植与跑通从 uip-conf.h 到网卡驱动再到 ping 通这一章是能照着抄的部分。顺序不能乱先改配置让它能编过再接驱动让它能收包再排主循环让它能回包最后才验证 TCP。跳过任何一步直接调 TCP出了问题根本没法定位是协议栈还是驱动。3.1 先改 uip-conf.h连接数、缓冲、字节序uip-conf.h是移植时唯一必须动的头文件其余uip/里的东西原样保留#ifndef __UIP_CONF_H__ #define __UIP_CONF_H__ #include stdint.h typedef uint8_t u8_t; typedef uint16_t u16_t; typedef uint32_t u32_t; /* 连接表client 常驻 1 条 server 并发 3 条 1 条留给 TIME_WAIT */ #define UIP_CONF_MAX_CONNECTIONS 5 /* 监听端口一个给调试工具一个预留做后续扩展 */ #define UIP_CONF_MAX_LISTENPORTS 2 /* 单缓冲以太网头 14 IP 头 20 TCP 头 20 载荷 */ #define UIP_CONF_BUFFER_SIZE 400 #define UIP_CONF_BYTE_ORDER UIP_LITTLE_ENDIAN /* 驱动为链路层头预留的字节数与 tapdev 实现保持一致 */ #define UIP_CONF_LLH_LEN 14 #define UIP_CONF_TCP 1 #define UIP_CONF_UDP 0 /* 统一应用回调入口 */ #define UIP_APPCALL app_call /* uIP 1.0 分支才有这项0.9 分支删掉否则编译报未定义 */ #define UIP_CONF_RECEIVE_WINDOW 200 void app_call(void); #endif几个参数的血泪经验UIP_CONF_BUFFER_SIZE别只算载荷uip_buf要能容纳整帧配 400 时实际 MSS 只有 400-14-40346 字节左右如果业务单包超过这个数uIP 会分段对端看到的是两个 TCP 段而不是一个完整消息这是很多人以为「粘包是协议栈 bug」的真实来源。UIP_CONF_LLH_LEN必须和驱动里预留给以太网头的偏移一致配错了表现为 ARP 能通、TCP 握手校验和全错。UIP_CONF_RECEIVE_WINDOW小于 MSS 时对端会按窗口拆包小缓冲下建议配成和载荷相当的值避免窗口为 0 卡死。app_call要在uipopt.h引入uip-conf.h之前有原型否则UIP_APPCALL()展开时会报隐式声明。放在这个头文件末尾是最省事的做法。3.2 网卡收发的三个钩子驱动层只需要暴露三个函数接口定义得越窄越不容易出错/* net/tapdev.h */ #include stdint.h void tapdev_init(void); /* 返回 1 表示收到一帧帧已经落到 uip_buf 的 LLH 偏移之后 */ uint8_t tapdev_poll(void); /* 返回这一帧的总长度含以太网头由调用方赋给 uip_len */ uint16_t tapdev_read(void); /* 把 uip_buf 起始的 uip_len 字节发出去 */ void tapdev_send(void);以常见的 DMA 描述符驱动为例read和send的核心就是一次拷贝但拷贝的方向和偏移必须严格对齐UIP_CONF_LLH_LEN/* net/tapdev.c只给关键片段 */ #include uip.h #include tapdev.h extern uint8_t uip_buf[UIP_BUFSIZE 2]; /* DMA 收包完成标志由中断置位这里只做查询 */ uint8_t tapdev_poll(void) { return rx_desc_own_bit_cleared(); } uint16_t tapdev_read(void) { uint16_t len rx_desc_len(); /* 含 14 字节以太网头 */ if (len UIP_BUFSIZE) len UIP_BUFSIZE; /* 关键数据要落到 uip_buf 起点uIP 认为链层头在最前面 */ memcpy(uip_buf, rx_desc_buf(), len); /* 赶紧把描述符还给 DMA否则下一帧直接丢 */ rx_desc_release(); return len; } void tapdev_send(void) { /* uip_len 由 uIP 填好含以太网头不足 60 字节的帧要补齐 */ uint16_t len uip_len 60 ? 60 : uip_len; memcpy(tx_desc_buf(), uip_buf, len); tx_desc_set_len(len); tx_desc_trigger(); }uip_buf的定义在uip.c里是uip_buf[UIP_BUFSIZE 2]多出的 2 字节是给某些架构做对齐填充用的外部声明时别写成UIP_BUFSIZE否则链接期长度不一致。补 60 字节是因为以太网最小帧长限制不补的话交换机可能直接丢弃现象是「小包全丢、大包正常」非常难查。3.3 主循环编排uip_input、uip_periodic 与 ARP 定时器主循环是 uIP 的心脏所有时序都在这里定/* main.c */ #include uip.h #include uip_arp.h #include tapdev.h #include timer.h static struct timer periodic_timer, arp_timer; int main(void) { clock_init(); tapdev_init(); timer_init(); uip_init(); /* 清空连接表与监听端口必须最先调 */ uip_arp_init(); tcp_server_init(); /* 内部调用 uip_listen(HTONS(8080)) */ tcp_client_start(); /* 内部调用 uip_connect(...) */ timer_set(periodic_timer, CLOCK_SECOND / 100); /* 10ms 一拍 */ timer_set(arp_timer, CLOCK_SECOND * 10); /* 10s 一次老化 */ while (1) { /* 1. 收包优先来一帧处理一帧回包延迟最低 */ if (tapdev_poll()) { uip_len tapdev_read(); if (uip_len 0) { if (BUF-type htons(UIP_ETHTYPE_IP)) { uip_arp_ipin(); /* 顺便学习对端 MAC */ uip_input(); /* 协议栈主入口 */ if (uip_len 0) { /* 非 0 说明有回包要发 */ uip_arp_out(); /* 填以太网头 查 ARP 表 */ tapdev_send(); } } else if (BUF-type htons(UIP_ETHTYPE_ARP)) { uip_arp_arpin(); if (uip_len 0) tapdev_send(); } } } /* 2. 10ms 节拍推进所有连接的重传与超时 */ if (timer_expired(periodic_timer)) { timer_reset(periodic_timer); for (uint8_t i 0; i UIP_CONNS; i) { uip_periodic(i); if (uip_len 0) { uip_arp_out(); tapdev_send(); } } if (timer_expired(arp_timer)) { timer_reset(arp_timer); uip_arp_timer(); /* 老化 ARP 表项 */ } app_timer_poll(); /* 心跳、重连只置标志 */ } } }三点说明。第一uip_input()处理完可能产生回包比如 ACK、echo 数据这时uip_len 0必须补上uip_arp_out()再发否则以太网头里的目的 MAC 是空的抓包能看到帧但对方不回。第二uip_periodic(i)必须遍历全部UIP_CONNS而不是只遍历活跃的uIP 内部自己判断这个槽位是否在用。第三10ms 这个节拍不是随便定的uIP 的重传超时以UIP_RTO为基本单位节拍太慢会导致重传判定的粒度变粗太细则白烧 CPU10ms 在多数 MCU 上是个平衡点。3.4 联调顺序ping → server → client烧进去之后别急着抓 TCP按这个顺序验证每步都有明确的失败含义# 1. 先确认物理层和 ARP 正常 ping 192.168.1.50 -c 4 # 2. 再确认 server 端口在监听在 PC 侧执行 nc -vz 192.168.1.50 8080 # 3. 手动连上去发一包看 echo 是否原样回来 printf hello-uip | nc -q 2 192.168.1.50 8080 | xxd # 4. 最后看 client 有没有主动连到上位机 nc -l -p 9000ping 不通就先别往下走问题在驱动或 ARP。ping 通但第 2 步连不上说明uip_listen没生效或UIP_CONF_MAX_LISTENPORTS配成了 0。第 3 步能连上但收不到回显大概率是uip_send在错误的时机被调用。第 4 步是 client 方向的独立验证它和 server 用的是不同连接槽必须分开测。4. 双端核心实现TCP server 的监听接受与 TCP client 的主动握手协议栈能通只是及格线真正决定这套代码能不能用的是应用层怎么管理连接状态。server 端要解决「多个连接怎么区分」client 端要解决「断了怎么自己爬起来」两个问题都落在回调的那几十行里。4.1 会话表与会话槽server 端怎么管理并发连接uip_conn-appstate是一个void *专门留给应用挂私有数据。server 端最省资源的做法是开一张静态会话表连接建立时分配一个槽关闭时回收/* app/tcp_server.c */ #include uip.h #include string.h #define SESS_MAX 3 #define SESS_FREE 0 #define SESS_EST 1 typedef struct { uint8_t state; uint16_t rport; /* 对端端口仅用于日志区分 */ uint32_t last_tick; /* 最后一次收到数据的时刻做空闲超时 */ uint16_t tx_len; /* 待回发/重传的数据长度 */ uint8_t txbuf[64]; /* 每个会话独立的回发缓冲 */ } session_t; static session_t g_sess[SESS_MAX]; void tcp_server_init(void) { memset(g_sess, 0, sizeof(g_sess)); uip_listen(HTONS(8080)); /* 端口号必须过 HTONS */ } static session_t *session_alloc(void) { for (uint8_t i 0; i SESS_MAX; i) { if (g_sess[i].state SESS_FREE) { g_sess[i].state SESS_EST; return g_sess[i]; } } return NULL; } static void session_free(session_t *s) { if (s) { s-state SESS_FREE; s-tx_len 0; } }会话表的长度和UIP_CONF_MAX_CONNECTIONS是两回事。前者是应用槽位后者是协议栈槽位SESS_MAX必须小于等于连接数减去 client 占用的那一条否则会出现「协议栈还有空位应用分配不到槽」的错位。我在板子上一般把SESS_MAX配成连接数减 2留出余量。4.2 app_call 里的五类事件与 uip_send 的调用时机回调是分派中心先用uip_conn判断归属再进各自的处理函数/* app/app_call.c */ #include uip.h extern struct uip_conn *g_client_conn; void app_call(void) { if (uip_conn g_client_conn) { client_app(); /* TCP client 路径 */ return; } server_app(); /* 其余都是监听派生出来的 server 连接 */ }server 端的回调按事件顺序排列每个分支的职责必须单一static void server_app(void) { session_t *s (session_t *)uip_conn-appstate; /* 事件一新连接建立分配会话槽 */ if (uip_connected()) { s session_alloc(); if (s NULL) { uip_close(); /* 没槽位就立刻关别让对端干等 */ return; } s-rport uip_conn-rport; uip_conn-appstate s; } /* 事件二/四收到数据或需要重传二者互斥一个周期只发一次 */ if (uip_newdata()) { uint16_t n uip_datalen(); if (n sizeof(s-txbuf)) n sizeof(s-txbuf); memcpy(s-txbuf, uip_appdata, n); /* 先落盘缓冲区随时会被覆盖 */ s-tx_len n; s-last_tick get_tick(); uip_send(s-txbuf, s-tx_len); /* echo本周期唯一一次发送 */ } else if (uip_rexmit()) { uip_send(s-txbuf, s-tx_len); /* 重传必须交同一份数据 */ } /* 事件三对端关闭或异常回收槽位 */ if (uip_closed() || uip_aborted() || uip_timedout()) { session_free(s); uip_conn-appstate NULL; } }这里有两个容易写错的点。第一uip_newdata()拿到的uip_appdata是只读且临时的下一个包到了就覆盖所以必须先memcpy到自己的缓冲再处理不能直接把它存成指针。第二uip_rexmit()时必须把同样的数据再交给uip_send一次如果这里发的是「当前最新数据」而不是「上次未确认的那份」对端收到的字节流就乱了表现为文件传输出错但短连接测试正常。uip_acked()在 server 端不一定要处理但如果tx_len需要根据确认情况推进就得在这里清掉已确认长度。4.3 client 端uip_connect 之后该看哪个状态位uip_connect是立即返回的返回非 NULL 只代表「占用了一个连接槽并发出 SYN」不代表连上了。真正的连接结果要在回调里通过uip_connected()或者检查状态位得知/* app/tcp_client.c */ #include uip.h #include timer.h #define CLI_OFFLINE 0 #define CLI_CONNECTING 1 #define CLI_ONLINE 2 struct uip_conn *g_client_conn NULL; uint8_t g_client_state CLI_OFFLINE; static struct timer reconn_timer, heartbeat_timer; static uint8_t heartbeat_pending 0; void tcp_client_start(void) { uip_ipaddr_t ip; uip_ipaddr(ip, 192, 168, 1, 100); /* 上位机地址运行时也可从参数区读 */ g_client_conn uip_connect(ip, HTONS(9000)); if (g_client_conn NULL) { /* 连接表已满先等一轮避免死循环里反复申请 */ g_client_state CLI_OFFLINE; timer_set(reconn_timer, CLOCK_SECOND * 3); return; } g_client_conn-appstate NULL; g_client_state CLI_CONNECTING; timer_set(reconn_timer, CLOCK_SECOND * 10); /* 握手超时看门狗 */ }判断是否真的连上看tcpstateflags的掩码位最稳static uint8_t client_is_established(void) { if (g_client_conn NULL) return 0; return (g_client_conn-tcpstateflags UIP_TS_MASK) UIP_ESTABLISHED; }socket编程里习惯看connect的返回值uIP 里没有这个语义。uip_connect返回非空后连接可能还停在UIP_SYN_SENT此时贸然uip_send数据会被协议栈直接丢弃因为窗口还没协商。这是 client 端最常见的翻车点。4.4 断线重连与心跳用 periodic 的节拍做超时心跳不能在回调外面直接调uip_send因为那个函数作用的是「当前uip_conn」在主循环里调用时指向谁完全不确定。正确做法是置标志等回调被uip_periodic唤醒时再发/* client_appuip_conn 一定等于 g_client_conn可以直接操作 */ static void client_app(void) { if (uip_connected()) { g_client_state CLI_ONLINE; timer_stop(reconn_timer); timer_set(heartbeat_timer, CLOCK_SECOND * 30); uip_send((const void *)HELLO, 5); return; } if (uip_newdata()) { handle_cmd(uip_appdata, uip_datalen()); /* 服务端下发的配置命令 */ } if (uip_newdata() || uip_rexmit()) { /* 有数据要回或者要重传时心跳主动让路一个周期只发一包 */ } else if (heartbeat_pending) { heartbeat_pending 0; uip_send((const void *)PING, 4); } if (uip_closed() || uip_aborted() || uip_timedout()) { g_client_conn NULL; g_client_state CLI_OFFLINE; heartbeat_pending 0; timer_set(reconn_timer, CLOCK_SECOND * 5); uip_conn-appstate NULL; } } /* 主循环里每 10ms 调一次只做定时器判断和置标志 */ void app_timer_poll(void) { if (g_client_state CLI_ONLINE timer_expired(heartbeat_timer)) { timer_set(heartbeat_timer, CLOCK_SECOND * 30); heartbeat_pending 1; } if ((g_client_state CLI_OFFLINE || g_client_state CLI_CONNECTING) timer_expired(reconn_timer)) { timer_set(reconn_timer, CLOCK_SECOND * 5); tcp_client_start(); } }CLI_CONNECTING状态下的reconn_timer是握手看门狗SYN 发出去对方不回uIP 自己也会重传直到超时但那个超时是按 RTO 指数退避算的可能长达几十秒。应用层再加一道 10 秒的超时可以在现场网络不通时更快地把状态切回来让上层逻辑知道「现在断着」。重连时直接调tcp_client_start重新申请槽位是安全的因为上一次的连接已经在uip_closed/uip_timedout分支里置空了。5. 避坑与排查五个把板子跑成黑匣子的现场这些坑有一个共同特征单看代码没问题编译也没警告但一上真实网络就表现为「板子像死了一样」。下面五条按现象、原因、解决来写。5.1 ping 通但 TCP 只发 SYN 不握手现象ping秒回nc -vz连 8080 端口一直超时抓包能看到板子反复发 SYN对方回 SYN-ACK 之后板子没有任何反应。原因uip_periodic没在主循环里跑或者跑了但没遍历全部UIP_CONNS。三次握手的最后一步 ACK 是由uip_periodic驱动的状态机发出的收包路径uip_input只负责处理被动收到的段。只处理收包、不跑周期表现出来就是 SYN 发出去了、SYN-ACK 也收到了但协议栈永远停在UIP_SYN_SENT。解决确认主循环里那个for (i 0; i UIP_CONNS; i) uip_periodic(i);存在且每 10ms 至少执行一次。用调试器在uip_periodic里打断点如果从没命中问题在定时器初始化或节拍配置不在 TCP 层。5.2 连续两次 uip_send 只出去一包现象应用层想「先回 ACK 再推数据」在一个回调里调了两次uip_send抓包只看到第一个包第二个凭空消失。原因uip_buf是单缓冲uip_len只有一个第二次uip_send会直接覆盖第一次的发送请求而不是排队。uIP 没有发送队列这个概念。解决把两次发送合并成一包或者用一个「待发队列 状态标志」在后续的uip_poll周期里逐包发出。合并时注意长度上限是 MSS超了要自己分段并记录偏移。我在应用层一般只保留一个txbuf把所有要发的东西按帧拼进去一个周期发一帧简单可靠。5.3 uip_newdata 里做耗时操作导致数据被覆盖现象小包测试正常连续快速发数据时偶尔丢一段且丢的位置不固定。原因uip_appdata指向的是uip_buf内部回调返回后这块内存随时会被下一个到达的包覆盖。如果在uip_newdata分支里做了 Flash 擦写、串口打印几百字节或者等待外设回调返回时数据已经被新包冲掉。解决uip_newdata里只做memcpy到自己的缓冲长度不超过缓冲大小然后立刻返回。真正的解析、存储放到主循环里按状态机处理。如果业务确实需要长耗时把UIP_CONF_BUFFER_SIZE调大并不能解决问题因为协议栈仍然只有一块缓冲只能靠「收到就抄走」这一个策略。5.4 把 TCP 当消息队列用粘包半包一起翻车现象上位机一次send发 200 字节板子有时候收到 146 字节、有时候收到 54 字节解析函数直接越界。原因TCP 是字节流没有消息边界。uIP 的 MSS 受缓冲区限制大包必然被拆成多段uip_newdata每次只给你一段。指望「一次 newdata 就是一个完整命令」是错的。解决应用层加长度头。常见做法是 4 字节魔数 2 字节长度 载荷接收侧维护一个累积缓冲和已收字节数凑够一帧再解析。缓冲区大小要按「最大帧长 × 1.5」留余量防止半包时越界。长度字段必须做上限校验不能直接信对端。5.5 连接数打满后服务端假死现象设备跑几天后新的调试工具连不上已经连着的连接还在正常收发重启设备立刻恢复。原因UIP_CONF_MAX_CONNECTIONS配得太小或者 client 频繁重连导致TIME_WAIT状态的槽位迟迟不释放。uIP 的TIME_WAIT要等一个定时器周期才会转成UIP_CLOSED期间这个槽位不可用。如果重连间隔设得比这个周期还短槽位会被慢慢吃光。解决连接数按「常驻 client本文还有配套的精品资源点击获取