简介：这份资源面向嵌入式网络开发学习者与STM32进阶开发者，提供一套以STM32F750为硬件平台、将单片机配置为TCP服务器并支持多个PC客户端并发连接的完整Demo工程，可用于理解资源受限环境下的并发网络服务设计。压缩包共820个文件，约60.36MB，以217个h头文件与204个c源文件为核心，配合109个o目标文件、109个d依赖文件及104个crf交叉引用文件，另含少量html、txt、asm、s、exe与uvprojx工程文件，覆盖lwIP协议栈、UCOSIII实时操作系统、以太网驱动及HAL库等模块。资源重点展示服务器初始化、监听接受连接、事件驱动并发处理、数据收发与错误关闭等关键流程，并给出UCOSIII任务调度与lwIP多连接管理的具体实现，便于读者对照源码梳理工程结构与排错思路。目前已有5560人学习下载，适合希望深入掌握嵌入式TCP服务器并发模型的开发者参考。
1. 一块 STM32 当 TCP 服务器，PC 多客户端同时连它到底靠不靠谱
前阵子帮一个做工业网关的朋友看代码，他拿一块 STM32F407 跑 LwIP，想让产线上的三台 PC 同时连上来读数据，结果第二台一连上，第一台就掉线。他以为是网口硬件问题，换了两块板子都一样。这其实是嵌入式 TCP 服务器最典型的翻车点——不是硬件不行，是 socket 管理没做对。STM32 单片机作 TCP 服务器、实现 PC 多客户端连接，本质是在资源受限的 MCU 上跑一个精简协议栈，用有限的 socket 描述符同时维护多条连接。它解决的是「设备侧主动提供网络服务、上位机免装驱动直接 socket 通信」这个需求，适合做数据采集、远程控制、参数配置这类场景。这份 Demo 就是把这套流程跑通的最小可复现工程，新手能照着搭，熟手能看清并发上限和内存边界在哪。
2. 选型与协议栈：为什么是 LwIP 而不是自己撸 TCP
2.1 裸机跑 TCP 的三种路线对比
在 STM32 上做 TCP 服务器，绕不开协议栈选型。常见做法有三条路：一是用芯片厂商配套的以太网外设加 LwIP 协议栈，二是用带硬件 TCP/IP 加速的独立网口芯片（比如常见的 SPI 转以太网方案），三是自己写精简 TCP 状态机。第三条基本是血泪经验劝退——TCP 的三次握手、超时重传、滑动窗口、拥塞控制，任何一块写不严谨，多客户端一压就崩，调试成本远超收益。
LwIP 是目前 STM32 生态里最成熟的开源协议栈，支持 raw API、netconn API、socket API 三种编程接口。raw API 是回调式、零拷贝、内存占用最小，但写起来反人类；socket API 最接近 PC 端编程习惯，但每层封装都要吃 RAM。这个 Demo 走的是 socket API 路线，原因是多客户端场景下代码可读性和可维护性优先，而且 STM32F4/F7/H7 系列的 RAM 足够撑起几个并发 socket。
| 路线 | RAM 占用 | 并发能力 | 开发难度 | 适用场景 |
|---|---|---|---|---|
| LwIP raw API | 最低 | 强 | 高 | 资源极紧、连接数固定 |
| LwIP socket API | 中等 | 中 | 低 | 多客户端、快速开发 |
| 硬件协议栈芯片 | 低（MCU 侧） | 受芯片限制 | 低 | 无以太网外设的 MCU |
2.2 LwIP 内存配置：并发数的真正天花板
很多人以为并发数取决于 CPU 主频，其实在 LwIP 里，能同时维持几条连接，几乎完全由内存池决定。打开lwipopts.h，下面这几个宏是必须调的：
// lwipopts.h 关键配置，决定并发上限 #define MEM_SIZE (16 * 1024) // LwIP 堆大小，socket API 依赖它 #define MEMP_NUM_TCP_PCB (8) // 同时存在的 TCP 控制块数量 #define MEMP_NUM_TCP_PCB_LISTEN (2) // 监听用 PCB 数量 #define MEMP_NUM_NETCONN (10) // netconn/socket 描述符上限 #define TCP_SND_BUF (2 * 1460) // 单连接发送缓冲，约 2 个 MSS #define TCP_WND (2 * 1460) // 单连接接收窗口 #define PBUF_POOL_SIZE (16) // pbuf 池，收包全靠它逻辑说明：MEMP_NUM_NETCONN直接决定socket()能成功创建多少个描述符，它必须大于等于「监听 socket + 客户端连接数」。MEMP_NUM_TCP_PCB是底层 TCP 控制块，通常要比 netconn 数再留一点余量。PBUF_POOL_SIZE太小的话，多客户端同时发数据会丢包，表现为连接还在但数据收不全。
参数怎么改：假设你要稳定支持 4 个 PC 客户端，MEMP_NUM_NETCONN至少设 6（1 个监听 + 4 个连接 + 1 个余量），MEMP_NUM_TCP_PCB设 8，PBUF_POOL_SIZE建议 16 起步。改完这些宏，MEM_SIZE也要跟着涨，否则堆分配会失败。判断是否够用的方法：在accept返回后打印剩余堆，跑满客户端看余量。
提示：LwIP 的 socket API 在 accept 时会为每个连接分配 netconn 结构，如果
MEMP_NUM_NETCONN设小了，第 N 个客户端连上来时 accept 直接返回错误，现象就是「连不上」而不是「掉线」，别和硬件问题搞混。
3. 多客户端并发的实现：从单连接循环到 select 轮询
3.1 单线程 select 模型为什么适合 MCU
PC 端写多客户端服务器，第一反应是开线程，一个连接一个线程。但 STM32 裸机没有操作系统线程，就算上了 FreeRTOS，给每个 socket 开任务也是奢侈——每个任务栈至少 512 字节起，4 个连接就是 2KB RAM 没了。所以 MCU 上的标准做法是单线程 +select多路复用：用一个循环同时监听监听 socket 和所有已连接 socket，谁有数据就处理谁。
这个模型的好处是逻辑线性、无锁、无上下文切换开销。代价是任何一次处理不能阻塞太久，否则其他连接的数据会积压。所以发送大块数据时要分片，接收要设非阻塞。
3.2 完整的多客户端服务器主循环
下面这段是 Demo 的核心骨架，可直接抄：
// tcp_server.c 多客户端 select 主循环 #include "lwip/sockets.h" #define MAX_CLIENTS 4 #define BUF_SIZE 512 static int client_fds[MAX_CLIENTS]; // 保存所有已连接客户端 void tcp_server_task(void *arg) { int listen_fd, max_fd, activity, i, n; struct sockaddr_in addr, cli_addr; socklen_t cli_len = sizeof(cli_addr); fd_set readfds; char rx_buf[BUF_SIZE]; // 初始化客户端数组 for (i = 0; i < MAX_CLIENTS; i++) client_fds[i] = -1; listen_fd = socket(AF_INET, SOCK_STREAM, 0); addr.sin_family = AF_INET; addr.sin_addr.s_addr = INADDR_ANY; // 监听本机所有网卡地址 addr.sin_port = htons(8080); // 服务端口 bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)); listen(listen_fd, MAX_CLIENTS); // backlog 设为最大客户端数 while (1) { FD_ZERO(&readfds); FD_SET(listen_fd, &readfds); max_fd = listen_fd; for (i = 0; i < MAX_CLIENTS; i++) { if (client_fds[i] > 0) { FD_SET(client_fds[i], &readfds); if (client_fds[i] > max_fd) max_fd = client_fds[i]; } } // 超时 100ms，避免死等导致其他任务饿死 struct timeval tv = {0, 100000}; activity = select(max_fd + 1, &readfds, NULL, NULL, &tv); if (activity <= 0) continue; // 有新客户端接入 if (FD_ISSET(listen_fd, &readfds)) { int new_fd = accept(listen_fd, (struct sockaddr *)&cli_addr, &cli_len); if (new_fd >= 0) { for (i = 0; i < MAX_CLIENTS; i++) { if (client_fds[i] == -1) { client_fds[i] = new_fd; break; } } if (i == MAX_CLIENTS) closesocket(new_fd); // 满了就拒 } } // 处理已连接客户端的数据 for (i = 0; i < MAX_CLIENTS; i++) { int fd = client_fds[i]; if (fd > 0 && FD_ISSET(fd, &readfds)) { n = recv(fd, rx_buf, BUF_SIZE, 0); if (n <= 0) { // 对端关闭或出错 closesocket(fd); client_fds[i] = -1; } else { send(fd, rx_buf, n, 0); // 回显，实际项目换成业务处理 } } } } }逻辑说明：select每次循环重建 fd 集合，把监听 fd 和所有活跃客户端 fd 都塞进去，然后阻塞等待（带 100ms 超时）。有事件时先判断是不是新连接，是就 accept 并存入数组；再遍历客户端判断谁有数据可读。recv返回 0 或负数表示对端断开，必须及时closesocket并清空槽位，否则数组会被占满，新客户端永远进不来。
参数说明：backlog设为MAX_CLIENTS，表示内核允许的等待队列长度；tv超时不能设 0（变成纯轮询吃 CPU），也不能设太大（响应迟钝），100ms 是常见折中。BUF_SIZE别超过PBUF_POOL单块大小太多，否则一次 recv 要拼多个 pbuf。
3.3 客户端槽位管理与连接回收
上面代码里client_fds数组就是连接管理的核心。几个容易忽略的点：一是 accept 后如果数组满了，必须closesocket掉新连接，不能不管，否则 LwIP 的 netconn 会被耗尽；二是recv出错后要立即回收槽位，不能等下一轮；三是如果客户端异常断电（没有正常四次挥手），recv可能长时间不返回错误，这时要靠 TCP keepalive 或者应用层心跳来清理。
LwIP 里开启 keepalive 的方式：
// 对每个已连接 socket 开启 keepalive int keepalive = 1; int keepidle = 5; // 5 秒无数据开始探测 int keepintvl = 2; // 探测间隔 2 秒 int keepcnt = 3; // 3 次无响应则断开 setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &keepalive, sizeof(keepalive)); setsockopt(fd, IPPROTO_TCP, TCP_KEEPIDLE, &keepidle, sizeof(keepidle)); setsockopt(fd, IPPROTO_TCP, TCP_KEEPINTVL, &keepintvl, sizeof(keepintvl)); setsockopt(fd, IPPROTO_TCP, TCP_KEEPCNT, &keepcnt, sizeof(keepcnt));逻辑说明：keepalive 让协议栈在连接空闲时自动发探测包，对端无响应就判定断开并触发recv返回错误，从而回收槽位。参数上keepidle别设太短，否则正常空闲的客户端会被误杀；工业场景一般 5~10 秒起步。
4. 避坑与排查：多客户端连不上的五个真实原因
4.1 现象：第二个客户端连上，第一个就掉
原因：最常见的是MEMP_NUM_NETCONN设成了 1 或 2，只够一个监听加一个连接。第二个连接 accept 时底层分配 netconn 失败，协议栈可能复用或顶掉旧连接。 解决：把MEMP_NUM_NETCONN调到「1 + 最大客户端数 + 余量」，同时确认MEMP_NUM_TCP_PCB不小于它。
4.2 现象：连接建立成功，但收不到数据
原因：PBUF_POOL_SIZE太小，或者TCP_WND设得比 pbuf 能承载的还大，导致接收窗口虚高但实际没内存收包，数据被静默丢弃。 解决：PBUF_POOL_SIZE至少 16，TCP_WND不要超过PBUF_POOL_SIZE * 单块大小的量级。用netif的统计计数看是否有 drop。
4.3 现象：跑一段时间后新客户端连不上，重启才好
原因：客户端异常断开时没有触发recv错误，槽位一直占着，数组满了。 解决：开启 TCP keepalive，或者应用层约定心跳包，超时未收到就主动closesocket。别指望对端一定正常挥手。
4.4 现象：select 返回后处理某个 fd 卡死，其他客户端无响应
原因：send在缓冲区满时会阻塞，如果对端一直不收，整个循环卡在这一条连接上。 解决：把 socket 设为非阻塞，或者send前用select判断可写。MCU 上更稳的做法是发送也走状态机，分片发。
4.5 现象：PC 能 ping 通板子，但 TCP 连不上
原因：bind时地址写成了具体 IP 而不是INADDR_ANY，或者端口被别的服务占了；也可能是防火墙拦了。 解决：先用INADDR_ANY排除地址问题，再用 PC 端telnet 板子IP 端口测端口通不通。注意 LwIP 的bind对地址字节序敏感，htons别漏。
5. 进阶技巧：把并发上限和稳定性再压一压
想让这套 Demo 从「能跑」变成「能上产线」，有几个具体技巧值得试。第一，把 socket API 换成 netconn API，能省下每个连接约几百字节的封装开销，代价是代码要改成回调或阻塞式，可读性下降。第二，发送路径改成「应用层环形缓冲 + 状态机分片发送」，避免send阻塞主循环，这是多客户端下最影响实时性的点。第三，给每个客户端记录最后活跃时间，主循环里定期扫描，超时的主动踢掉，比单纯依赖 keepalive 更可控。
验证并发上限的方法很直接：PC 端用脚本同时开 N 个连接，每个连接每秒发一包，跑十分钟，看板子端有没有掉线、丢包、内存耗尽。下面这个 Python 脚本可以当压测工具：
# stress_test.py 多客户端并发压测 import socket, threading, time HOST, PORT = "192.168.1.100", 8080 # 换成板子实际 IP CLIENTS = 4 def worker(idx): s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((HOST, PORT)) for i in range(600): # 每秒一包，跑 10 分钟 s.sendall(f"client{idx} seq{i}\n".encode()) data = s.recv(128) if not data: print(f"client{idx} disconnected at {i}") break time.sleep(1) s.close() threads = [threading.Thread(target=worker, args=(i,)) for i in range(CLIENTS)] for t in threads: t.start() for t in threads: t.join()逻辑说明：每个线程模拟一个 PC 客户端，持续发送并等待回显，一旦recv返回空就说明被断开。跑的时候同时观察板子端串口打印的剩余堆和连接数，就能定位是内存先耗尽还是逻辑先出错。参数上CLIENTS从 2 开始逐步加，找到稳定上限，别一上来就压 10 个。
我自己的习惯是：每次改完lwipopts.h的内存宏，都先用这个脚本从 2 客户端压到目标值，确认不掉线再进业务逻辑。从那以后我每次调 LwIP 并发参数，都强制先跑一遍连接压测再写业务代码，省得后面业务和协议栈问题混在一起查。希望帮到你。
本文还有配套的精品资源，点击获取
