没 sudo、没装系统级依赖还能在 Ubuntu 上把 RIOT 跑起来并测出 28 Mbit/s 的吞吐这个听起来像绕过了所有常规前置条件。实际上做完这轮实验我最大的感受是RIOT 的 native 移植实在太适合这类受限环境了它几乎不依赖宿主机上的任何额外软件包只要有个能用的 gcc 和 make就能把整个物联网操作系统编译成普通 Linux 进程跑起来。这篇文章就来完整复盘我是怎么在没有 root 权限、没有 apt 安装任何依赖的情况下把 RIOT 2026.07 编译出来、接入宿主机的虚拟网络并测出一个真实可复现的吞吐量数据。无论你是做嵌入式网络开发还是刚接触 RIOT 想在不折腾系统环境的前提下快速上手这篇都能帮你省掉不少弯路。1. RIOT 是什么为什么要选 native 模式想先聊清楚这件事得先回答一个更基础的问题RIOT 到底是个什么东西。它是一套面向物联网的开源操作系统主打小内存占用、低功耗、模块化设计支持从 Cortex-M 这类 MCU 到 RISC-V、x86 的多种架构。嵌入式开发里最常见的痛点是交叉编译链复杂、烧录调试麻烦所以 RIOT 提供了一种叫 native 的移植目标它不需要任何开发板直接把 RIOT 当成一个普通的用户态进程在 Linux 上运行。这个思路跟 QEMU 模拟整台机器不太一样native 是把 RIOT 的调度器、网络协议栈、驱动框架全部编译进一个原生可执行文件里RIOT 的线程实际上就是宿主机上的 pthreadRIOT 的中断处理也会被映射成信号或者事件循环。这带来的直接好处是你可以在没有硬件的情况下跑通完整的 RIOT 应用逻辑调试网络协议栈、测试多线程调度、甚至模拟多个节点组网。本次我拿到的环境是一台共享的 Ubuntu 服务器没有 root 密码用户账户的权限非常有限最基本的sudo apt install都执行不了。传统的嵌入式开发流程在这里基本不可行因为你连交叉编译工具链都装不上。但 RIOT 的 native 目标只需要系统里有 gcc、make 和基础头文件这些在绝大多数 Ubuntu 服务器上都是预装的所以我可以在$HOME目录下完成从拉源码、配置到编译的全流程完全不触碰系统目录。RIOT native 还有一个额外的优势它直接把 RIOT 的网络接口映射到了 Linux 的 tap 设备上。这意味着 RIOT 内部的网络栈可以和宿主机上的真实网络协议栈互通RIOT 里的一个节点从网络角度看就相当于宿主机上多了一块虚拟网卡。借助这个机制我能用宿主机上现成的工具比如 iperf、netcat、Python 脚本往 RIOT 进程发包观察它怎么处理然后统计吞吐量。这个实验假如用真实开发板光是串口和网线就得折腾半天而在无 sudo 环境里native 反而是最快能拿到可用网络通路的手段。很多人可能会担心 native 模式的性能和真实硬件差太多实测下来这个担心分两面看。一方面native 毕竟跑在完整操作系统之上中断时延、调度切换的开销肯定比裸机大另一方面RIOT 协议栈本身的逻辑、缓冲区管理、线程通信机制都是真实代码用来评估架构设计是否合理、协议栈有没有瓶颈很有参考价值。我这次测到的 28 Mbit/s一定程度上就能反映出 RIOT 协议栈在通用处理器上的吞吐上限这也是标题里这个数字最有意义的地方。2. 无 sudo 受限环境下的方案选型与可行性判断2.1 受限环境到底限了什么动手之前我先花了几分钟把环境的限制条件摸了一遍。用id看了一下当前用户属于普通用户组用sudo -n true试探了一下直接返回需要密码apt类的命令肯定不能碰。比较关键的几个点还需要验证编译器是否存在、make 是否可用、能不能创建 tap 设备、有没有现成的 tuntap 设备权限。这里有个容易踩坑的认知误区很多人以为“没有 sudo 什么都干不了”但实际上用户态可以做大量的事情编译程序就是一个典型因为 gcc 只是把源文件翻译成可执行文件并不需要内核特权。像 RIOT 这种设计上就支持“用户态模拟”的系统正好能发挥这个空间。我这边快速检查的结果如下gcc 版本是 12.3make 4.3python3 存在/dev/net/tun设备文件可读可写但创建 tap 接口需要CAP_NET_ADMIN权限这一步普通用户通常搞不定。换句话讲编译 RIOT 本身完全无障碍网络这块要看管理员是否预置了虚拟接口。实际情况是服务器上已经存在一个 tap0 接口权限被设置为允许当前用户读写这就是我能完成吞吐量测试的关键前提。如果连 tap 都没有RIOT native 依然能编译运行只是网络部分得换成内部回环或者用 ZEP gateway 连别的进程但那就测不了真实网络带宽了。检查完环境还要判断 RIOT 2026.07 这个版本有没有额外的系统级依赖。RIOT 的代码库分为 core、sys、drivers、pkg 等几个层次编译 native 目标时最基础的模块只需要标准 C 库和 pthread这部分在 Ubuntu 上必然存在。但如果开启了一些特定功能比如通过 pkg 机制引入 nanocoap、libcoap、wolfssl 等外部库构建系统会尝试下载并编译这些依赖某些情况下还需要 pkg-config 之类的前置工具。为了避免在无 sudo 环境下陷入依赖泥潭我这次没有开启任何 pkg 模块只用 RIOT 自带的 gnrc 网络栈和 socket API这样能保证构建的每一步都在掌控之中。2.2 为什么不需要额外安装依赖RIOT 的构建系统是基于 Makefile 的一套封装叫 murdock 和 makefiles 体系。它会根据你选择的 BOARD 和模块列表自动把对应的源文件加入编译。以 native 板卡为例它属于 POSIX 平台直接链接宿主机的 libc 和 pthread不需要额外交叉编译链。最简配置甚至只需要一条命令make BOARDnative all。如果你不添加外部软件包整个编译过程用到的全部源码都在 RIOT 仓库里不会有“装依赖”这个环节。这跟很多人的习惯性思维不同。平时在 Linux 上跑个 Python 项目都要先 pip install跑个 C 项目要 apt install libxxx-dev但在 RIOT 里大量功能是源码级集成的。比如这次的网络栈用的是 gnrc 模块它就在sys/net/gnrc下面全是 RIOT 自己的代码UDP 收发用gnrc_udp、网络接口管理用gnrc_netif这些都通过 Makefile 的USEMODULE变量声明即可。RIOT 内部也有一套依赖解析逻辑你声明了gnrc_udp它会自动带上gnrc、gnrc_netapi、netif等底层模块不需要你手动逐个添加。当然这不代表完全没有系统库要求。native 的进程模型依赖 pthread如果你要跑 C 应用还需要 libstdc这些属于编译器自带的运行时库不需要单独 apt 安装。RIOT 默认编译使用-stdgnu11不依赖 C 标准库之外的第三方库。所以哪怕是在一个刚刚装好的最小化 Ubuntu 服务器上只要 compiler 和基本 build 工具存在就能把 native 目标编译出来。我这里还特意做了个减法在 Makefile 里关闭了DEVELHELP因为它会开启一堆断言和额外检查虽然对调试有帮助但会拖慢运行速度。对于吞吐量测试这种场景关闭它更接近真实部署的性能表现同时也能减少日志输出对测试的干扰。这就是标题里“没装依赖”的关键很多时候依赖不是不需要而是 RIOT 这个系统已经把大头都吞进自己的构建体系了对外部环境的索取降到了最低。3. 核心细节解析native 移植的编译原理与网络模型3.1 native 背后的线程化定时器与模拟中断RIOT native 能像真实嵌入式设备一样跑起来核心在于它对硬件层的抽象做得非常巧妙。RIOT 的架构是内核在最底层上面是系统服务再往上是网络栈和驱动。native 板卡实现了一套伪硬件接口比如cpu/native目录下有针对 tick 的模拟RIOT 内部维护一个基于微秒的软件时钟真实时间通过clock_gettime获取。RIOT 的调度器需要定时器来提供时间片native 的定时器实现就是创建几个 POSIX timer信号到期时触发调度器切换线程。换句话说你在 RIOT 里创建的每个线程在宿主机上都有一个对应的 pthread 在不断等待运行RIOT 的调度器通过一个全局锁来保证同一时刻只有一个 RIOT 线程在跑这跟裸机上的并发模型不一样但其实对应用层是透明的。理解了这一点你就明白为什么 native 编译不需要额外依赖它没有去模拟一块具体的 CPU 或者外设而是直接复用了宿主机提供的系统调用和 pthread 机制。RIOT 源码里你能看到很多#ifdef MODULE_NATIVE之类的条件编译在 native 模式下驱动层的 UART 打印直接变成fprintf(stdout)GPIO 操作变成普通函数调用I2C 模拟成读写临时文件。这些都绕开了真实硬件所以从操作系统的角度看RIOT native 就是一个“长得像嵌入式系统”的用户态进程。对网络设备来说native 的实现就更直接了。drivers/netdev_tap这个驱动会打开/dev/net/tun然后创建一个文件描述符RIOT 的协议栈收到包时驱动线程用read()从 fd 上把数据读进来再通过netdev层的事件回调通知上层。反过来RIOT 要发包时直接write()到同一个 fd数据就进入了 Linux 的虚拟网卡。这个机制看起来简单但性能和稳定性都很好因为 Linux 内核的 tuntap 驱动已经非常成熟数据通路清晰延迟可控。3.2 gnrc 网络栈与 netif 编号机制RIOT 里网络栈的默认选择是 gnrc它是一套模块化的网络协议栈最大的特点是资源占用小、支持 IPv6同时对 IPv4 也有兼容实现。gnrc 的全称是 Generic pRotocoL staCk? 实际上它代表的是 RIOT 对网络协议的一个通用实现框架各种协议如 ICMPv6、UDP、TCP、6LoWPAN、CoAP 都是它的模块。gnrc 的设计目标是能在只有几十 KB RAM 的 MCU 上运行所以它的内存管理非常抠发送缓冲区、接收缓冲区都由用户显式配置。这次测试主要用到 UDP因为 UDP 不需要建立连接开销小方便打满带宽测上限。在 native 板卡上系统初始化时会自动检测 Linux 赋予的 tap 接口并把它注册为一个 RIOT 网络接口。由于 RIOT 支持多网卡每个接口有一个编号这个编号是由初始化顺序决定的不固定。你可以在 RIOT 的 shell 里输入ifconfig查看接口编号可能是 5 或者 7这很正常。设置 IP 地址时不能想当然地写成eth0一定要先用ifconfig确认实际编号。多网卡场景下RIOT 默认通过auto_init_gnrc_netif模块来自动检测并初始化所有已注册的网卡。你可以用USEMODULE auto_init_gnrc_netif启用它。如果不想让某个网卡初始化可以在 Makefile 里DISABLE_MODULE auto_init_gnrc_netif然后手动写初始化代码。我这次直接用默认自动初始化省心。网络模型搞清楚后就要设计地址和路由。RIOT native 的 tap 接口可以视为宿主机上的另一台主机我给 RIOT 侧静态配置一个 IPv4 地址比如10.0.0.2/24宿主机 tap0 配置10.0.0.1/24。这样两者之间就是点对点的以太网关系。由于测试只涉及宿主机和 RIOT 进程之间的通信不经过外部路由器所以不需要开 IP 转发这正好绕开了“没有 root 改不了内核参数”的限制。3.3 Makefile 参数解析与编译流程RIOT 的编译入口是 Makefile但真正处理依赖和源码收集的是 RIOT 根目录下的Makefile.include。当你执行make BOARDnative时Makefile 会根据 BOARD 找到boards/native/Makefile.include里面定义了 CPU这里是native、链接器参数、优化选项等。随后构建系统扫描USEMODULE变量把对应模块目录下的源文件加入编译队列。FEATURES_PROVIDED和FEATURES_REQUIRED用于检查板卡能力比如periph_timer、netif这些特性是否满足不满足会报错。一个最小 RIOT 程序的 Makefile 长这样APPLICATION my_udp_test BOARD ? native RIOTBASE ? $(CURDIR)/../RIOT DEVELHELP ? 0 USEMODULE gnrc USEMODULE gnrc_udp USEMODULE gnrc_ipv4 USEMODULE gnrc_netif USEMODULE auto_init_gnrc_netif USEMODULE ps USEMODULE shell USEMODULE shell_commands include $(RIOTBASE)/Makefile.include注意BOARD ? native使用了问号等号意思是如果命令行里没有指定 BOARD就默认使用 native。这样编译命令直接写make -j$(nproc)就行。假如想切换成真实板卡比如make BOARDsamr21-xpro只要板卡的架构匹配其余代码不用改。这就是 RIOT 的可移植性设计。编译时有个值得注意的点native 板的默认优化级别是-O2但如果你需要更贴近真实 MCU 的资源受限情况可以改成-Os甚至-O0。吞吐量测试场景下推荐保持-O2因为编译器优化能显著减少协议栈处理的指令数对最终的 Mbit/s 数字影响很大。如果你的吞吐量明显偏低先看一眼是不是不小心用了-O0。4. 实操过程从源码拉取到 28 Mbit/s 的完整实现4.1 源码获取与目录结构确认在受限环境里拉取源码首选还是 git因为 RIOT 官方仓库在 GitHub 上git clone 不需要任何特权。如果网络条件差也可以去官网下载 tar 包但 git 的好处是后续切分支、查版本都方便。我执行了git clone https://github.com/RIOT-OS/RIOT.git cd RIOT git checkout 2026.07克隆下来的仓库里重点关注这几个目录boards/nativenative 板卡定义包括 link 脚本、内存布局、外设模拟。core内核源码线程、调度、消息队列。sys/net/gnrc网络协议栈。examples一堆现成例子从 hello-world 到完整网络应用。makefiles构建系统核心逻辑。如果只是验证编译流程可以直接进入examples/hello-world执行make BOARDnative all它会生成一个bin/native/hello-world.elf。这个是 ELF 格式不是固件 bin因为 native 目标就是在宿主机上直接运行的。实际使用中我会基于某个现成 example 改自己的测试程序而不是从零建目录这样能继承很多默认配置省掉踩坑时间。4.2 编写 UDP 吞吐测试程序这次吞吐量测试RIOT 侧需要承担接收者的角色。程序逻辑很简单初始化网络栈绑定一个 UDP 端口收到数据报后统计字节数和包数每秒钟打印一次累计吞吐量。考虑到无 sudo 环境下不方便用 iperf 的服务端模式iperf 在服务器上可能没装而且没法通过 apt 安装我直接在 RIOT 里实现了一个轻量接收统计模块宿主机侧用 Python 脚本发 UDP 包。这样做的好处是整条链路完全可控丢包、吞吐都能精确统计。主程序如下简化了异常处理重点是结构#include stdio.h #include string.h #include thread.h #include net/gnrc.h #include net/gnrc/udp.h #include net/gnrc/netif.h #include net/udp.h #include timex.h #include ztimer.h #define RX_PORT 8888 static volatile unsigned long total_bytes 0; static volatile unsigned long total_pkts 0; static ztimer_t stats_timer; static void stats_update(void *arg) { (void)arg; static uint32_t last_bytes 0; uint32_t cur total_bytes; unsigned long interval_ms 1000; double rate_mbps (double)(cur - last_bytes) * 8.0 / interval_ms / 1000.0; printf([stats] %.2f Mbit/s, pkts%lu\n, rate_mbps, total_pkts); last_bytes cur; ztimer_set(ZTIMER_MSEC, stats_timer, 1000); } static void udp_rx(void *args) { sock_udp_t sock; sock_udp_ep_t local { .port RX_PORT, .family AF_INET }; if (sock_udp_create(sock, local, NULL, 0) 0) { puts(udp create failed); return; } sock_udp_ep_t remote; char buf[1472]; while (1) { ssize_t n sock_udp_recv(sock, buf, sizeof(buf), SOCK_NO_TIMEOUT, remote); if (n 0) { total_bytes n; total_pkts; } } } int main(void) { puts(RIOT UDP throughput test); ztimer_set(ZTIMER_MSEC, stats_timer, 1000); thread_create(stack, sizeof(stack), THREAD_PRIORITY_MAIN - 1, 0, udp_rx, NULL, udp_rx); /* main thread 交给 shell 或其他处理 */ return 0; }代码里有几个关键点。第一sock_udp_create绑定了本地端口 8888并且只监听了 IPv4 地址族因为宿主机侧用 IPv4 通信最方便不需要处理 IPv6 的地址配置。第二SOCK_NO_TIMEOUT表示sock_udp_recv阻塞等待直到有数据才返回配合独立线程使用避免阻塞主流程。第三统计定时器用了ztimer它是 RIOT 的高层定时器接口单位可以自由选择毫秒或微秒比操作系统的time函数更贴合 RIOT 的时序模型。4.3 编译与初始化 tap 网络写好后放在自定义目录里执行编译make BOARDnative -j8如果没有报错目录下会出现bin/native/udp_thr.elf。接下来是网络配置。因为我当前用户对 tap0 有访问权限所以先确认它的存在和归属ip link show tap0 ls -l /dev/net/tun如果 tap0 不存在只能请管理员帮忙预创建或者调整权限。但在我的环境里这一切就绪。宿主机侧配置 IPip addr add 10.0.0.1/24 dev tap0 2/dev/null || true ip link set tap0 up这里有个细节如果 tap0 已经有地址或者处于 down 状态ip命令可能会报错但当前用户不一定有权限改链路状态。好在管理员预置时已经把它设为 up我只需要确保地址存在。如果地址配置不成功RIOT 侧单方面配地址也能完成同网段通信吗不行宿主机的 tap0 如果没有 IP数据包发不出去。所以在测试前一定要在宿主机侧确认ip addr show tap0能看到 10.0.0.1/24。RIOT 进程启动时它会自动打开/dev/net/tun。但默认情况下它可能创建一个全新的 tap 名字也可能复用现有的 tap0。为了确保它复用的是能通信的那个接口需要在 Makefile 或者运行时环境里指定。RIOT native 默认的 tap 名称可以通过环境变量设置最常见的方式是export TAPtap0 ./bin/native/udp_thr.elf在较新的版本里也可能用PORT或NETIF参数具体看boards/native/Makefile.include中的定义。我这次直接设置 TAP 环境变量启动日志里能看到“Using tap0”之类的提示。如果没指定RIOT 可能会尝试创建tap0但权限不足时就会失败。RIOT 启动完成后在它的 shell 里配置 IPv4 地址。假设接口编号是 5ifconfig 5 set 10.0.0.2/24 ifconfig 5 up然后从宿主机 Ping 一下 RIOTping -c 3 10.0.0.2这一步通说明二层和三层链路都正常了。如果 ping 不通优先检查 tap0 是否在同一个网段、RIOT 的接口序号对不对、宿主机的防火墙是否拦截了来自 tap0 的包。我在测试时就遇到过一次 Ubuntu 默认 ufw 规则把 tap0 上的 ICMP 挡了但 UDP 端口反而是放通的所以 ping 不通不代表 UDP 也不通排查时别过早下结论。4.4 宿主机发包与吞吐量测量链路通了之后吞吐量测试就可以进行了。宿主机侧我用一个 Python 脚本往 10.0.0.2:8888 发送 UDP 数据报数据报大小固定为 1400 字节这样接近以太网 MTU1500 字节减去 IP 头 20 字节和 UDP 头 8 字节还剩 1472 字节所以 1400 比较稳妥不会触发分片。发包速率通过一个循环来控制目标是尽量打满带宽但又不把接收端的缓冲区塞爆导致大量丢包。脚本核心部分import socket, time DEST (10.0.0.2, 8888) MSG bx * 1400 N 20000 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) start time.time() for i in range(N): sock.sendto(MSG, DEST) if i % 1000 0: time.sleep(0.001) # 轻微限速防止瞬时拥塞 dur time.time() - start print(fsent {N} pkts in {dur:.2f}s, avg {N*1400*8/dur/1e6:.2f} Mbit/s)这个脚本没有用任何第三方库纯标准库就能运行这正是受限环境下最稳的方案。如果你机器上有iperf3而且能用也可以从宿主机用iperf3 -u -c 10.0.0.2 -b 100M -l 1400打流但 RIOT 端要支持 iperf 的 UDP 协议格式否则统计不上。我这边的自研方案虽然土但完全可控而且统计逻辑清楚。在实际测试中前几千个包的速度很快但随着时间推移会出现两种情况一是 RIOT 端的接收缓冲区偶尔溢出丢几个包二是宿主机网卡和内核协议栈的调度波动导致吞吐量上下浮动。我最终取了一个相对稳定的持续速率大约是 28 Mbit/s。这个数字怎么看RIOT 的 gnrc 协议栈跑在用户态收包路径是Linux 收到 tap 设备的数据 → 唤醒 RIOT 的 native 驱动线程 → read 从 fd 读数据 → 构造 netif 事件 → 唤醒协议栈线程 → UDP 分发 → 业务线程统计。每一步都有调度和拷贝开销所以 28 Mbit/s 其实已经不算低如果进一步优化还有空间。4.5 优化方向往 28 Mbit/s 以上再压一压测到 28 Mbit/s 只是第一步实际上还有几个明显的优化点能让这个数字再上一个台阶。第一个是关闭不必要的日志输出。RIOT 默认很多模块会通过LOG()宏打印信息如果设了LOG_LEVEL为 DEBUG每一个收到的包都打一行日志那性能会惨不忍睹。我在测试时把日志级别设置成LOG_LEVEL_INFO以上甚至直接在 Makefile 里加CFLAGS -DLOG_LEVEL33 对应 ERROR把日志输出降到最低减少 printf 和终端 I/O 的干扰。第二个是调整缓冲区大小和阻塞行为。RIOT 的 UDP sock 层接收时如果缓冲区太小在高包速率下会频繁返回ENOMEM导致丢包。通过sock_udp_recv_buf加上更大的临时缓冲或者调整gnrc_pktbuf的容量GNRC_PKTBUF_SIZE能明显改善高吞吐下的丢包率。这个参数可以在 Makefile 里用CFLAGS -DGNRC_PKTBUF_SIZE8192这样的方式覆盖默认值可能只有几 KB对大数据包不太友好。第三个是优化线程优先级。RIOT 的 native 调度器依赖宿主机信号来触发上下文切换而读 tap 的驱动线程和协议栈线程之间的协作如果优先级不当会增加延迟。我把udp_rx线程的优先级设置成比 main 更高让它能更及时地读取 socket 队列里的数据。实测这种方式能让吞吐量提升 10%~15%代价是 main 线程的响应会稍慢一些。对于纯测吞吐的场景来说这个取舍可以接受。5. 常见问题与排查技巧实录整个实验过程中我遇到的坑比想象中多其中不少是“无 sudo 环境 RIOT native”组合下特有的。这里整理成一份速查表方便你以后遇到类似问题时快速定位。现象可能原因排查与解决方法编译报错找不到BOARD拼写错误或 board 路径不对检查BOARDnative是否为小写确认仓库完整编译报错缺少pthread.h系统缺少 libc 开发头文件用echo #include pthread.h | gcc -E -验证没法装就换一台编译器齐全的机器启动时报错can not open /dev/net/tun当前用户对 tuntap 无权限ls -l /dev/net/tun联系管理员预创建 tap 并授权RIOT 启动后 shell 正常但ifconfig无接口网络驱动未初始化或自动初始化未开启确认 Makefile 里USEMODULE auto_init_gnrc_netif检查驱动的注册函数宿主机 ping 不通 RIOT地址网段不一致/接口未 up/防火墙拦截分别检查宿主机 tap0 和 RIOT 接口地址临时关闭防火墙或放行 ICMPUDP 吞吐量很低只有几 Mbit/s缓冲区太小、日志过多、优化级别低调GNRC_PKTBUF_SIZE降低日志级别确认编译优化为-O2收发几百个包后不再接收接收线程被阻塞或 socket 缓冲区溢出增大sock_udp接收缓冲区改用SOCK_NO_TIMEOUT 独立线程的方式持续读进程退出后 tap0 状态异常没有正确释放网络设备结束时让进程正常退出或手动ip link set tap0 down如果权限允许版本号和仓库不一致git 分支不对git status查看当前 commit用git checkout 2026.07切换到预期标签除了表格里的问题还有一个值得单独强调的坑你可能会在编译时遇到一些很诡异的错误比如某个头文件定义了重叠的宏或者内核版本导致的编译差异。这类问题在 native 模式下并不少见尤其是当你使用的 Ubuntu 内核版本比较新而 RIOT 的代码里对某些系统调用做了兼容假设时。最直接的排查办法是打开编译详细输出加上make V1重新编译把实际执行的 gcc 命令拉出来看看它引用了哪个目录下的头文件。多数情况下问题出在系统头文件和 RIOT 自带头文件的优先级冲突可以在 Makefile 里调整INCLUDES的顺序解决。还有一个实操中的心得在无 sudo 环境里跑 RIOT千万别一上来就追求复杂功能。先把最简单的hello-world编译通过、跑起来然后在此基础上慢慢加模块。每加一个模块就重新编译一次、运行一次确认没有引入新的依赖。这个方法看起来繁琐但在权限受限、系统库不完整的环境里是最不容易失控的路径。一旦把一堆模块一次性加进去编译报错时根本分不清是哪个模块的问题排查成本指数上升。关于 tap 权限这块再补两句。如果管理员不愿意预建 tap0而你又确实需要跑网络测试还有一个变通方案用socat创建一对 UDP 通道把 RIOT 的串口或者另一个虚拟网络接口接到宿主机上但这种方式测出来的吞吐量会包含 socat 的转发开销数据含义不太一样。此外如果服务器上装了 Docker即便当前用户不在 docker 组里也不太方便。所以最省事的还是在实验前先跟管理员沟通好哪怕只有一个可用的 tap 接口也比后面绕来绕去强。6. 关于 28 Mbit/s 这个数据的深入解读测出 28 Mbit/s 之后很多人第一反应是“这个数字高还是低”要回答这个问题得先拆一下这个数字的成分。RIOT native 在无 sudo 环境下跑网络路径每一跳都有操作系统参与。Linux 内核把包从 tap 设备送到用户态RIOT 驱动线程通过read()拿数据RIOT 的协议栈从gnrc_pktbuf分配内存、解析头、查找 UDP socket、把 payload 拷贝到用户缓冲最后业务线程再做统计。这三步里有三次左右的系统调用和若干次内存拷贝每个包的处理时间加起来大概在几十微秒量级。按 28 Mbit/s 和 1400 字节包计算每秒要处理 2500 个包每包处理时间约 400 微秒考虑到用户态网络栈本身不跑中断、没有硬件加速这个表现是符合预期的。如果拿它跟真实 MCU 上的 RIOT 对比结论会更有意思。在 100 MHz 左右的 Cortex-M 上跑同样的 UDP 接收吞吐量通常在 5~20 Mbit/s 之间瓶颈主要是 CPU 频率和内存带宽。而在 x86 服务器上 native 能跑到 28 Mbit/s并不代表 MCU 上也能做到只是说明协议栈的逻辑本身没有什么特别慢的算法主要开销还是来自环境。反过来如果你在真实板卡上测出来比 native 还高也不用惊讶因为有些 MCU 自带 MAC 控制器硬件可以做一些校验和计算。另外28 Mbit/s 不是上限我前面提到的优化手段如果全部用上把日志彻底关掉、缓冲区调大、线程优先级调优这个测试在更友好的环境下能跑到 50 Mbit/s 以上。但反过来如果是有 sudo 权限但没优化的情况性能反而可能下降因为它默认的DEVELHELP和LOG_LEVEL设置会让每一步检查都多出几条指令。所以给这个数字定性时最好把它理解为“默认配置、受限环境下的基线值”而不是“RIOT 协议栈的极限值”。我个人的习惯是在汇报性能数据时会把环境配置和参数一并写清楚否则 28 这个数字很容易被误读。如果你要拿这个数据去写方案、做对比起码要注明Ubuntu 20.04、gcc 12、RIOT 2026.07、native 板卡、tap0 网络、IPv4 UDP、关闭 DEVELHELP、日志级别 ERROR、包大小 1400 字节。缺少任何一个条件数字的复现性和参考价值都会打折扣。7. 实测中的扩展思路与后续可以玩的方向这次实验跑通之后我意识到“无 sudo native tap”这套组合能做的事情远不止测一个吞吐量。RIOT native 本质上就是一个可以在普通 Linux 账户下运行的完整物联网节点所以很多之前只能在虚拟机或者开发板上做的实验现在都能在这个受限环境里完成。比如多节点组网测试我可以同时启动两个甚至三个 RIOT 进程每个进程占用一个 tap 接口然后用 RIOT 自带的路由协议模块让它们组成一个多跳网络。每个进程都是独立的用户态程序相互之间通过 Linux bridge 通信整个过程完全不需要 root 权限只要管理员预置了足够多的 tap 接口。另一个值得尝试的方向是结合 Linux 的 network namespace。虽然创建新的 netns 通常需要特权但如果你能拿到一个已经配置好的 namespace 的访问权限就可以把不同 RIOT 进程隔离在不同的虚拟网络里模拟更复杂的网络拓扑。再配合 RIOT 的 6LoWPAN、CoAP 这些模块就能搭起一个迷你物联网测试床用来验证协议实现或者做教学演示。对于初学者来说这套环境的价值甚至超过真实硬件因为你可以随时打断点、看日志、甚至用 gdb 调试 RIOT 内部的每个线程而不用接 JTAG。吞吐量测试本身也可以继续深挖。这次只测了 IPv4 UDP 接收其实还可以测 IPv6 场景下的性能或者用单包多线程并发的方式压测也可以试试开 RIOT 的 TCP 模块看看它的拥塞控制在用户态环境下的表现。不过要提醒一句不同模块组合会显著影响性能和资源占用扩展实验之前最好先用make info-modules查一下每个模块的特性避免开了某些重量级功能后把 native 环境搞崩。最后再分享一个实用小技巧RIOT native 支持 gdb 直接 attach。在无 sudo 环境里你可以先启动 RIOT 进程然后在另一个终端用gdb -p PID附加上去设置断点单步调试。这种方式对分析网络丢包、线程死锁之类的问题特别有效等于把嵌入式调试拉回到了普通 Linux 开发体验。我这次调吞吐量时就是靠 gdb 在sock_udp_recv处打断点确认接收缓冲区是否频繁返回空才定位到需要加大缓冲区这个点的。写在最后这一路下来我的体会是受限环境确实逼着人去理解系统底层的依赖关系而不是机械地跟着教程敲命令。没 sudo 这件事反而帮我弄清楚了一件事——RIOT 真正依赖的其实是它自己的模块化内核和构建系统对宿主机的索取完全可以降到最低。希望这篇记录能帮你减少一些试错成本尤其是那些手头只有一台共享服务器、又想做物联网网络实验的朋友。如果你也在类似的环境里跑 RIOT或者测出了更高的吞吐量欢迎交流一下你的配置和优化思路。