企业官网建设流程全解析

简介：面向嵌入式开发者和物联网工程师的uIP协议栈学习资料包，旨在帮助资源受限设备开发者快速掌握轻量级TCP/IP协议栈的核心原理与实战应用。压缩包共127个文件，以C源码（29个.c、34个.h）和PDF文档为主，辅以PNG/GIF示意图、makefile构建脚本及示例工程，总计4.8MB，结构紧凑便于系统研读。内容覆盖uIP架构、TCP连接管理、事件驱动编程、内存缓冲策略等关键知识点，并包含httpd、dhcpc、telnetd、webclient等典型应用模块，可直接对照源码理解协议实现细节。资料还配有教程文档和调试建议，可帮助读者厘清uIP与lwIP等协议栈的差异，进而具备在嵌入式项目中移植和定制uIP的能力。该资料已有171人学习下载，是一份适合从入门到进阶的实用参考。

1. 是时候重新认识 uIP 了

坦白讲，在 LwIP 满天飞、各种带 OS 的协议栈都成了标配的今天，uIP 这个名字听起来像上古遗物。但恰恰是这份“上古”，让它成了资源受限设备上的常青树。它的整套实现目标，就是把完整 TCP/IP 协议栈塞进 1 KB 左右的 RAM，没错，是 KB，不是 MB。很多工程师第一次打开 uIP 源码时，被那几百行的uip.c震惊——一个 TCP 连接的全部状态机、重传、分片逻辑居然能在这么小的空间里跑起来。这个标题挂着“学习资料”的 .rar 压缩包，大概率就是当年学生或者工程师收集的源码、文档和移植笔记，但比资料更值钱的，是你拿到协议栈后如何把它用对地方。这件事，值得弄明白。

uIP 适用的场景非常具体：8 位或低端 32 位 MCU、几十 KB Flash、几 KB RAM、没有完整操作系统，却需要稳定收发 TCP/UDP 数据。它不追求吞吐量，不追求高并发，追求的是“在极端资源约束下把连接跑通”。本文要做的，就是把 uIP 的设计核心、移植步骤、会话编排和内存陷阱一层层拆给你看。你如果看完能照着把协议栈拽到自己的板子上，那这个思路就算立住了。

2. 把 uIP 的根基一根根拆开：事件驱动与 1 KB 内存窗口

如果只记住 uIP 的一个设计原则，那就是事件驱动 + 单缓冲区。它没有线程，没有阻塞，甚至没有真正的 socket 抽象，所有网络行为最终都汇到一个函数调用上：uip_process()。理解这个函数怎么被驱动起来，比背源码更管用。

2.1 为什么 uIP 不做成 LwIP 那样的线程模型

LwIP 可以在承接较高吞吐的同时提供多线程、内存池、零拷贝等机制，但它的代价是千行级复杂度。uIP 的目标从一开始就不是“性能”，而是“最小可行性”。常见嵌入式平台的 RAM 紧张到以百字节为单位计数，任何调度器、缓冲区队列、动态内存分配都会撑爆预算。uIP 的思路是：网络中所有的事件，无论是数据到达、定时器超时还是应用层主动发包，都被映射成对协议栈单次函数调用。协议栈处理完这些事件后返回，应用层再决定下一步。

这个模型带来的直接好处是确定性极高。我在无 RTOS 的裸机循环里用它，主循环只维护一个uip_periodic()定时调用和一个网卡中断标志位，就能稳定维持多个 TCP 连接。因为处理器没有切换开销，整个栈的 CPU 占用可以压缩到几十微秒级别，这对低主频 MCU 至关重要。

2.2 uip_buf 与数据进出的唯一通道

uIP 的内部细节很多，但对使用者来说，最需要死磕的就是uip_buf这个全局缓冲区。协议栈接收网卡的数据、构造发给网卡的数据，全部复用这块内存。默认大小是 400 字节，其中包含链路层、IP 头、TCP 头以及应用数据。这就意味着应用层能直接使用的载荷空间只有几百字节。很多第一次接触 uIP 的工程师会犯一个错：试图往uip_appdata指向的区域写入超过 MTU 的数据，结果直接把协议头覆盖了。

要理解内存窗口，先要看几个关键全局变量：

• uip_buf：整个协议栈收发共用的原始缓冲区；
• uip_appdata：指向应用层数据起始位置的指针，在回调中读写数据都要从这里取；
• uip_len：当前缓冲区里有效数据的长度；
• uip_slen：应用层主动构造的需要发送的数据长度。

数据流向是这样的：网卡驱动把数据搬运进uip_buf，设置好uip_len，然后调用uip_input()。协议栈解析头部后，把uip_appdata指向载荷位置，再触发应用回调。应用回调里通过uip_newdata()判断是否有新数据，从uip_appdata读取，然后清掉uip_len，最后返回。如果需要回复，就往uip_appdata写入数据，设置uip_slen，协议栈会在收尾阶段自动封包。

if (uip_newdata()) { uint16_t len = uip_datalen(); memcpy(my_buffer, uip_appdata, len); // 处理完业务数据马上清长度 uip_len = 0; uip_slen = 0; }

这段代码的逻辑说明：第一行判断当前连接是否收到了新数据，这是 uIP 回调里最常用的入口条件；uip_datalen()返回实际载荷字节数，复制后立刻把uip_len和uip_slen清空，避免协议栈误以为我们还要发送数据。参数上的注意点是，uip_datalen()的值永远不会大于UIP_BUFSIZE减去协议头长度，所以接收缓冲区按 512 字节做静态数组就已经足够。

2.3 uip_periodic 与定时器驱动的可靠传输

TCP 的可靠性依赖确认与重传，uIP 没有为每个连接分配定时器资源，而是把所有重传、ACK 延时统一拆成一个节拍函数。这个函数就是uip_periodic()。在裸机环境，我一般用硬件定时器产生 100 Hz 的中断，然后把标志位置位，主循环中调用它：

if (timer_flag) { timer_flag = 0; for (conn = 0; conn < UIP_CONNS; conn++) { uip_periodic(conn); if (uip_len > 0) { uip_arp_out(); tapdev_send(); } } }

这里有两个细节容易踩坑：第一，uip_periodic()的入参是连接编号，范围是 0 到UIP_CONNS-1，执行完成后需要检查uip_len，因为协议栈可能需要发送 ACK 或重传数据；第二，uip_arp_out()必须在发送前调用，它负责把 IP 地址解析成 MAC 地址，如果 ARP 表项不存在，它会丢包并发出 ARP 请求。很多人调试“能 ping 通但 TCP 连不上”时，往往问题就出在没有在发送路径里走 ARP 封装。

定时器频率也不是越高越好。UIP_PERIODIC默认对应 200 ms 周期，但这个链路时钟跟 TCP 的重传超时直接挂钩，如果调得太快，容易造成不必要的重传；调得太慢，丢包后的恢复时间会被拉长。常见配置是 100 Hz 的系统 tick 对应CLOCK_SECOND，然后基于它计算重传超时。这部分的数值关系，在下面的移植章节里具体展开。

2.4 冲突域与并发限制：这不是 bug，是设计

uIP 默认只支持有限的并发 TCP 连接数，比如UIP_CONNS设为 10，意味着最多同时存在 10 个 TCP 连接。每个连接的状态保存在一个结构体数组中，每个结构体存放对端 IP、端口、seq、ack、重传计时器等。这样设计避免了动态内存分配，但也带来了隐性的限制：如果你的应用需要同时维持几十个传感器连接，uIP 给你的选择只有调大这个数组，或者接受连接被拒绝。

对我个人而言，uIP 适合终端节点，不适合做网关。网关设备即便是低端的，也建议用 LwIP 或裸机加协议栈的混合方案。做整机架构时，把“哪些连接常驻、哪些连接短连”规划清楚，比猛调并发参数更有效。uIP 的短连接处理成本非常低，连接关闭后槽位立即释放，非常适合 HTTP 请求和 MQTT 这类间歇性通信。

3. 把协议栈请进工程：移植清单与最小配置

拿到 .rar 里的学习资源，第一件事不是打开代码埋头看，而是先看有没有uip-conf.h和对应平台的网卡驱动范例。整个移植过程其实就三步：配置裁剪、对接时钟、填好网卡驱动的四个函数。这三步都做完，协议栈就能跑起来。

3.1 最小工程里必须现身的源文件

纯 uIP 核心（不包含应用层协议）只要这几个文件就能编译：

如果你想把 DHCP 也纳入，还需加入dhcpc.c和对应回调。但从我见过的大多数项目看，uIP 节点更适合静态 IP，原因很简单：DHCP 客户端会追加不少逻辑和内存开销，在几十个节点的内网环境里，静态地址能省去大量调试时间。移植初期，先把静态 IP 跑通，再谈 DHCP。

3.2 时钟对接：一个函数与一个宏的全部含义

uIP 内部所有超时计算依赖一个毫秒级时间戳。clock-arch.c里需要实现clock_time_t clock_time(void)，它返回从任意起点开始的毫秒计数。在 STM32 上，这个函数可能就是直接读 SysTick：

static volatile uint32_t tick_count; void SysTick_Handler(void) { tick_count++; } clock_time_t clock_time(void) { return tick_count; // 每 tick 为 1 ms }

参数说明：clock_time_t的类型在uip-conf.h中定义，一般是unsigned long，所以 32 位平台下大约 49 天才溢出一次，对嵌入式设备来说这个周期完全够用。切记，如果平台的中断频率不是 1 kHz，而是 10 kHz，就必须在clock_time()里做换算，否则 uIP 的 RTO（重传超时）计算会偏快十倍，导致网络经常无端重传。检查方法很简单：开启调试打印，观察连续发送的数据包序号是否频繁出现 seq 回退。

3.3 网卡驱动的四个出口

uIP 不自带任何硬件访问代码，它期待底层驱动提供四个出口：初始化、发送、读取、中断交给主循环轮询。具体函数在不同移植版本里名称不同，但风格一致。以常见的伪驱动为例：

// 初始化网卡，并将自己的 MAC 地址写入寄存器 uint8_t tapdev_init(uint8_t *mac_addr) { enc28j60_init(mac_addr); return 0; } // 发送，从 uip_buf 取 uip_len 字节 void tapdev_send(void) { enc28j60_packet_send(uip_buf, uip_len); } // 主循环调用，返回是否收到新包 uint8_t tapdev_poll(void) { int len = enc28j60_packet_receive(uip_buf); if (len > 0) { uip_len = len; return 1; } return 0; }

这里必须解释一个隐藏很深的约定：tapdev_poll()把数据填进uip_buf并设置uip_len后，直接交给上层处理；但上层处理后可能会把uip_len清空，所以网卡驱动绝不能在tapdev_poll()返回前自己释放缓冲区。许多刚上手的人把 DMA 接收和 uIP 的缓冲区重叠，结果 DMA 后写覆盖了 uIP 正在处理的数据，引发随机的校验和错误。

发送路径的另一个易错点是uip_arp_out()和网卡驱动的顺序。正确流程永远是先uip_arp_out()，再tapdev_send()。因为uip_arp_out()会把数据包的目的 IP 替换成对应的 MAC，并重新计算 ARP 头。如果驱动先发送，ARP 逻辑就无法生效，目标设备收到的数据包的目的 MAC 是错的，直接丢弃。

3.4 uip-conf.h 里的关键旋钮

配置文件是移植过程中需要反复打磨的地方。下面几个参数决定了内存占用，也决定了并发能力：

配置的核心策略是“按需加码”。比如只做远程配置管理，那么 4 个连接、1 个监听端口足矣；如果要同时支持 Modbus TCP、HTTP 配置页和固件升级，至少需要 6 个连接、2 个监听端口。UIP_CONF_BUFFER_SIZE与UIP_CONF_TCP_MSS联动，MSS 默认为BUFFER_SIZE - 40，如果缓冲区 600 字节，MSS 就约 560 字节，应用中一次写入的数据不要超过这个值。

改动这些宏之后，工程占用的 RAM 大概可以通过公式粗算：UIP_CONNS * 30 + UIP_CONF_BUFFER_SIZE + ARP 表项 * 12，按这个公式核对芯片剩余 RAM，可以避免烧录后莫名死机。

4. 跑通第一个 uIP 会话：TCP 回显与数据收发实战

配置和移植都做完之后，该让代码说话了。这一章用一个最简单的 TCP 回显服务器作为载体，完整走一遍应用回调的编排。之后在这个基础上加上真实业务，比如温湿度采集上报、Modbus 网关转发。这条路走通了，几乎所有基于 uIP 的项目都只是换皮。

4.1 回调函数是状态机，不是线性逻辑

uIP 应用层回调的典型结构长这样：

void app_call(void) { if (uip_connected()) { connected_handle(); return; } if (uip_aborted() || uip_timedout()) { error_handle(); return; } if (uip_newdata() && uip_datalen() > 0) { process_sensor_data(uip_appdata, uip_datalen()); uip_slen = 0; return; } if (uip_acked()) { ack_handle(); } if (uip_poll()) { poll_handle(); } }

这段代码的结构说明：每次协议栈在处理完一个事件后，都会调用这个回调，但事件类型不同，回调会走不同分支，这就是“状态机”的含义。要点在于每个分支处理完业务后，必须通过uip_slen或uip_len告知协议栈后续动作。比如uip_newdata()分支返回前，把uip_slen设为要回复的字节数，协议栈就会自动捎带 ACK 并发送响应数据。如果你什么都没设，它就只回 ACK，不回数据。

uip_poll()是一个容易被误解的分支。它表示协议栈主动询问应用层“有没有数据要发”，触发频率取决于连接状态。在建立连接后，这个分支会被反复调用，所以把定期上报业务的发送逻辑放在这里，比用定时器更优雅。但需要注意：在uip_poll()分支里调用uip_send()，必须在同一个回调周期内完成数据准备，否则下一次uip_poll()来的时候，前面的数据就被丢掉了。

4.2 一个能跑的 Echo 服务完整代码

假设你已经完成了网卡驱动和时钟适配，下面是完整的应用回调实现，能实现从 PC 上用任意 TCP 客户端发数据、原样返回的功能：

void sensor_app(void) { static uint8_t echo_buf[UIP_CONF_BUFFER_SIZE - UIP_TCPIP_HLEN]; if (uip_connected()) { // 连接建立，立刻准备发送欢迎信息 memcpy(uip_appdata, "uIP ready\n", 10); uip_send(uip_appdata, 10); return; } if (uip_newdata()) { uint16_t len = uip_datalen(); memcpy(echo_buf, uip_appdata, len); memcpy(uip_appdata, echo_buf, len); uip_send(uip_appdata, len); return; } if (uip_acked()) { // 上一条发送被对端确认，可以记录下来用于统计 tx_ack_count++; } if (uip_poll()) { // 轮询分支，空转即可，不主动发包 return; } }

代码逻辑说明：连接建立时，向对端发送 10 字节欢迎信息，这里直接操作uip_appdata，然后调用uip_send()。收到新数据时，先把载荷搬到自己的静态缓冲区，再复制回uip_appdata原位置，最后调用uip_send()。因为uip_appdata就是指向上层载荷的位置，所以直接把数据填回去再发送，是最省内存的做法。而uip_acked()分支用来确认对端收到了数据，这个信息对 TCP 流量控制有参考价值。

有一个细节值得注意：echo_buf的大小为什么用UIP_CONF_BUFFER_SIZE - UIP_TCPIP_HLEN？因为uip_datalen()返回的值最大就是载荷区长度，也就是缓冲区减去 IP 头和 TCP 头的 40 字节。不用这个宏而直接用 512 之类的数值，会留下潜在的越界风险。当你启用了链路层（比如 Ethernet），实际头部会变成 54 字节，但 uIP 内部对uip_appdata的偏移量已经处理好了，应用层不必关心。

4.3 从 PC 到板子的连通性测试与抓包验证

代码写完，烧录调试，进到验证阶段。我通常在开发机上进行两个测试：先是 ICMP 连通性，再是 TCP 业务验证。

1. 静态 IP 配置在192.168.1.100，PC 配192.168.1.10，直连网线或通过交换机相连。
2. 先 ping 一下192.168.1.100。能通，说明 ARP 和 IP 层基本正常。
3. 使用 Python 脚本进行 TCP 测试，发送并接收确认：

import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(3) s.connect(("192.168.1.100", 80)) s.send(b"hello uip") data = s.recv(200) print("recv:", data) s.close()

这个测试的价值在于：能一次验证 TCP 三次握手、数据承载、ACK 和关闭流程。如果脚本卡死在connect()，优先检查板子回调里的uip_connected()是否把uip_slen意外设置为非零值；如果在recv()时超时，则需要用抓包工具确认板子是否内核态回复了 ACK 但应用层未回数据。

抓包是调试 uIP 最有效的动作。看到三次握手成功但数据包不响应，基本都是回调状态机逻辑问题；看到 PC 发出 SYN 但板子完全没反应，优先查网卡驱动接收路径；看到乱序和校验和错误，优先查缓冲区是否被复用。熟练之后，这套排查顺序能帮你把定位时间压缩到 10 分钟以内。

5. 构建一个基于 uIP 的温湿度采集节点：会话编排与内存边界

回显服务只能证明网络通，不足以证明产品可用。这一章把 TCP 回显改造成一个像样的数据采集节点：周期上报传感器数据、被动响应查询命令、支持远程配置连接参数。你会看到 uIP 应用层设计的真实全貌：它是一种协作式多任务，而不是单纯的 socket 编程。

5.1 设备端架构：采集循环如何与协议栈共存

裸机平台上，主循环通常长这样：

while (1) { if (tapdev_poll()) { uip_input(); if (uip_len > 0) { uip_arp_out(); tapdev_send(); } } if (periodic_flag) { periodic_flag = 0; for (i = 0; i < UIP_CONNS; i++) { uip_periodic(i); if (uip_len > 0) { uip_arp_out(); tapdev_send(); } } } if (sensor_tick >= 1000) { sensor_tick = 0; collect_and_report(); } }

这种结构的核心优势是完全没有锁和竞争。所有网络处理都在主循环的同一个上下文里完成，传感器采集函数collect_and_report()不能阻塞，也不允许在里面调用长延时。如果传感器是 I2C 接口且需要等待转换完成，建议用状态机把“发起转换”和“读取结果”拆开，分别放到两次循环里执行，否则一个阻塞函数足以把 TCP 重传全部延误。

uip_input()和uip_periodic()都只处理一个事件。主循环里先处理网卡事件，后处理定时事件，这个顺序本身不重要，但保持一致对调试有帮助。我习惯先处理接收，再处理定时，因为定时事件通常需要回复数据，而接收事件可能只是 ACK，及时排空输入队列可以降低丢包概率。

5.2 周期上报业务：可以使用 uip_poll() 的窗口

假设传感器每分钟上报一次温湿度，这里用uip_poll()分支做发送窗口：

static uint32_t last_report_sec = 0; void report_sensor_if_ready(void) { if (now_sec - last_report_sec < 60) { return; } last_report_sec = now_sec; int len = snprintf((char *)uip_appdata, UIP_CONF_BUFFER_SIZE - UIP_TCPIP_HLEN, "TH:%d.%d,%d.%d\n", temp_int, temp_dec, humi_int, humi_dec); uip_send(uip_appdata, len); }

这里的巧妙之处在于：uip_poll()分支会被周期性地调用，相当于协议栈为应用层提供了“自动发送节拍”。应用层只需要在满足条件时填充数据，不用自己维护独立的 TCP 发送定时器。需要注意snprintf的缓冲区上限，必须严格使用载荷区大小，同时预留末尾的空字符空间。有些编译器对snprintf的可重入特性有要求，裸机环境下建议检查其线程安全属性，尽量避免动态内存分配版本。

需要特别提醒的是数据帧长度。假使UIP_CONF_BUFFER_SIZE仍为 400，则载荷上限是 360 字节，一条 TH 报文只有二十几个字节，远未触碰上限。但如果业务扩展到同时上报多路数据，就得考虑自定义二进制格式，而不是继续堆 ASCII 文本。典型的做法是预定义一个结构体，通过memcpy填充后发送，这样载荷利用率最高。

5.3 被动命令处理：用最小代码实现可配置的 Modbus 风格交互

很多设备不止上报数据，还要响应查询、修改参数。这里常见做法是把载荷的第一个字节当作功能码，后续是参数体：

if (uip_newdata()) { uint8_t *req = (uint8_t *)uip_appdata; uint16_t len = uip_datalen(); if (len < 2) { uip_slen = 0; return; } if (req[0] == 0x01) { // 查询设备状态 uint8_t rsp[4]; rsp[0] = 0x81; rsp[1] = ok_flag; rsp[2] = (uint8_t)(fw_version >> 8); rsp[3] = (uint8_t)(fw_version & 0xFF); memcpy(uip_appdata, rsp, 4); uip_send(uip_appdata, 4); } else if (req[0] == 0x02) { // 设置上报周期 set_report_interval(req[1]); uip_appdata[0] = 0x82; uip_appdata[1] = 0x00; uip_send(uip_appdata, 2); } }

这个状态的演进过程很清楚：从最简单的原样回显，进化成有格式的协议解析。同样是操作uip_appdata，现在做的事是：解析请求 -> 更新状态 -> 回填响应 -> 调用uip_send()。代码没有引入动态内存，没有多线程锁，所有状态都是全局变量或静态变量。

这章里要盯住内存边界。uip_appdata是共享的，上一帧数据在回调返回后可能被新数据覆盖，因此只要你想保存数据，就必须立刻复制到自己的缓冲区。另外，如果将来要支持多条并发 TCP 连接都操作同一个全局参数，需要规划一个合理的“锁”策略。但因为整个协议栈是单线程的，你只需在回调内部小心处理状态，通常一个全局状态机就够了。

5.4 常见移植误用之比较：堵塞式延时与共享缓冲区的冲突

写 uIP 应用最容易出现的两个误用，值得单独拿出来说。

第一个是在回调分支内调用阻塞延时。有人喜欢用HAL_Delay(10)等待传感器稳定，这在带 RTOS 的环境里尚可容忍，在裸机 uIP 里却会直接摧毁 TCP 定时器。因为所有 TCP 超时重传都依赖主循环及时调用uip_periodic()，你在回调阻塞的 10 ms 里，协议栈无法处理任何事件，连续几个这种延时就可以造成重传超时。解决办法是把这种等待拆成状态机步骤，放到主循环其他函数里轮询状态。

第二个是多个回调共享同一个uip_appdata却没有立即复制。举个例子，连接 A 收到数据，你把指针保存在一个全局变量里；连接 B 立刻发来新数据，这个全局指针指向的内容就变了。我在调试一个多连接版本时就踩过这个坑，收到传感器 A 的上报，来不及拷贝，连接 B 的 ACK 数据就把缓冲区覆盖了。最终修正方案很笨但有效：在进入任何回调函数的第一时间，把uip_appdata中的数据搬到自己的静态缓存区，后续所有逻辑都依赖这个缓存区。

6. 在资源受限下的最后一步：验证链路质量与排查隐藏陷阱

uIP 能跑通不代表能跑稳。一个嵌入式设备的网络性能，要压着边界测过才算数。这一章不写大道理，直接给出我常用的验证方法和几个容易被忽视的低级坑。你把这些动作做一遍，剩下的事基本就是业务迭代。

检查 RAM 占用有个快速办法：编译后查看 map 文件里uip_buf、连接表、ARP 表等符号的地址差。只要这些区间都在芯片 RAM 范围内且没有越界，协议栈的内存安全就有基础保障。更严格的手段是启用编译器的栈保护，然后在主循环里故意制造最大载荷收发，观察是否触发硬 fault。

验证链路质量时，我一般在一台 PC 上跑一个几十行的 Python 脚本，持续向设备发送递增序列号，同时判断回包是否乱序或丢包：

import socket, time s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(("192.168.1.100", 80)) s.settimeout(1) ok = 0 for i in range(2000): s.send(b"A" * 100) data = s.recv(200) if data == b"A" * 100: ok += 1 print("pass rate:", ok / 2000) s.close()

大量连续小包能暴露 uIP 缓冲区切换时的潜在竞争条件。两千个包全过且耗时正常，说明状态机稳定；如果出现卡住或断连，可在设备端打印uip_aborted()、uip_timedout()触发的回调次数，直接对应到核心状态机的异常路径。

除了功能验证，还要看长期稳定性。把设备运行一整夜，期间每隔一分钟上报一次数据，同时监控内存是否增长。uIP 的静态内存分配决定了内存越界发生时不会慢慢腐化，而是直接在某次发送时崩溃或挂起，因此整夜测试比短时灌包更能说明问题。

最后说一个几乎所有移植者都会忽略的技巧：在发送链路层帧时，手动检查 Ethernet 帧的最小长度是 60 字节。很多网卡驱动对小于 60 字节的帧会做填充，但有些直连的交换芯片不会。如果你发现自己发的 ICMP 请求偶尔被吞，优先检查发送函数是否把小于 60 字节的帧做了 padding。uIP 的很多移植示例没处理这个细节，这也是不同平台表现不一致的最大来源之一。

本文还有配套的精品资源，点击获取