如果你调过 W5500 这类硬协议栈网卡大概率遇到过这样的场景设备上电连服务器一切正常跑了三天、五天或半个月突然连不上了服务器侧早没了这条连接可设备侧还傻乎乎显示着 TCP Established。重启一下设备又能恢复过几天又犯病。更奇怪的是有时候现场去 ping 设备丢包严重、时通时断但网线明明插得好好的。我早期做 STM32 W5500 的采集终端时这个问题整整折磨了一周。后来把 TCP Keep-Alive 的机制彻底啃了一遍又结合 W5500 的寄存器和官方库做了一套断线检测与自动重连方案才算是把长连接真正稳住。这篇文章不绕弯子直接讲清楚 W5500 在服务器长连接场景下为什么会断、Keep-Alive 到底怎么保活、以及一套能直接抄作业的重连代码。1. 先搞清楚问题W5500 为什么会出现服务器断线1.1 典型现象正常工作几天后突然连不上这种故障最直观的表现就是“运行一段时间后连不上服务器”而且非常有迷惑性设备端看 W5500 的状态寄存器Socket 好像还是 Established但服务器应用日志里那条 TCP 连接早就没了。重启设备后能恢复恢复后又能跑几天看起来像随机故障实际上几乎每次都是同一个原因。我用 W5500 做环境数据采集器时现象更具体设备每天正常上报数据到第四天早上开始掉线服务器端无任何记录。现场看设备日志昨天最后一次发送还成功了之后就再没有网络事件。重启后又好第二天再掉。把抓包工具接上去等复现发现设备侧没有任何 TCP FIN 或 RST 包发出链路就像凭空消失一样。这类问题有一个共同点链路不是被某一方主动关闭的而是被“中间设备”悄悄回收了。设备侧完全没感知还以为连接还活着。W5500 作为独立硬件 TCP/IP 协议栈芯片本身不跑业务逻辑也不会因为你业务层“看起来正常”就主动发现异常。要想解决必须让 TCP 层的保活机制和业务层的断线判定同时工作。1.2 根因半开连接与 NAT 静默回收TCP 连接在不再通信后会进入一种“半开”状态两端都保留着 socket 资源但中间经过的路由器、交换机、防火墙或 NAT 网关可能已经在超时后把这条连接表项清掉了。常见的家用路由器、云服务器安全组、运营商级 NAT对空闲 TCP 会话都有超时策略从几十秒到几小时不等。当 NAT 表项被清掉之后设备再发数据出去路由器没有对应映射关系最典型的处理方式就是静默丢弃。设备端 TCP 发送逻辑是“发了就等 ACK”等不到 ACK 就重传重传超时后才报错。但 W5500 的硬件状态机在没有触发数据收发时不会主动去探测链路所以设备就一直停留在 Established直到某次业务发送触发了超时重传才真正意识到链路断了。还有一类情况是服务器端主动关闭了连接但 FIN 包在网络里丢失或没被设备处理设备同样不知道。服务器可能因为心跳超时、运维重启、进程崩溃等原因把连接回收客户端没收到 FIN 或 RST就会继续傻等。说白了TCP 本身并不保证“连接永远活着”它只保证“在双方都愿意维护的前提下数据可靠到达”。没人维护连接就是假的。1.3 为什么硬协议栈不等于免维护很多朋友选 W5500是因为它把 TCP/IP 协议栈做进了芯片硬件里MCU 只要调用几个寄存器命令就能完成 Socket 操作确实省心。但也正因为协议栈在硬件里你没法像 Linux 那样随意改 TCP 参数很多“软件协议栈默认帮你处理”的事情到 W5500 这里就需要你主动配置。比如 Linux 内核的 TCP 栈默认开启 Keep-Alive 探测虽然默认 2 小时才探测一次但至少有个兜底。而 W5500 的 TCP Socket 创建后Keep-Alive 功能默认是关闭的需要你显式去配置 Sn_KALVR 寄存器再打开对应的 KEEP 控制位。如果不配协议栈就真的“什么都不做”一切依赖业务链路是否活跃。另外 W5500 虽然有 8 个硬件 Socket但每个 Socket 都是独立状态机一旦进入半开状态它会一直占着端口和缓冲区资源。如果不做主动清理重连时可能出现“Socket 明明 open 却连接不上”的诡异现象。所以用 W5500 做服务器长连接核心思路就两条一是靠 Keep-Alive 机制让 TCP 层及时发现链路死亡二是靠应用层断线重连机制把 Socket 状态拉回正轨。2. Keep-Alive 机制深入拆解2.1 TCP Keep-Alive 工作原理一个不起眼的探测包TCP Keep-Alive 并不是业务层的心跳包而是 TCP 协议栈自己发送的一种探测包。它做的事情很简单当一条 TCP 连接空闲超过设定时间后协议栈主动向对端发一个字节常见实现是 seq 当前发送序列号 - 1长度 0个别实现会带 1 字节垃圾数据对端如果正常就会回一个 ACK。这样发送方就知道链路还通着。如果对端不回 ACK协议栈会按一定间隔继续发探测包连续发若干次都失败就判定连接已死然后通知上层关闭 Socket。这个机制的好处是不用依赖业务层是否有数据要发空闲连接也能被持续验证。缺点也很明显它只能验证“TCP 路径通不通”没办法验证服务器应用进程是不是还活着、业务逻辑是否正常。所以它不能替代应用层心跳。如果对端已经崩溃但网线还通着Keep-Alive 探测包可能得到对端 TCP 栈的 ACK但应用层根本没在正常处理业务这类“假活”Keep-Alive 也发现不了。反过来如果对端已经断电或网线断开Keep-Alive 就能在较短时间内让本端感知链路失效这正是我们在断线重连中需要的第一道防线。2.2 W5500 硬件 Keep-Alive 是怎么实现的W5500 对 TCP Keep-Alive 的支持非常直接核心就两个寄存器一个叫 Sn_KALVRSocket n Keep Alive Timer Register偏移地址是0x002E n × 0x20单位为 100ms写入 0 表示关闭另一个是 Sn_CRSocket n Command Register里的 KEEP 控制位bit5置 1 表示允许硬件发送 Keep-Alive 包。配置流程说起来很简单Socket 处于 TCP 模式并且连接建立后把 Sn_KALVR 写成你想要的间隔数值再把 Sn_CR 的 bit5 置 1。之后 W5500 硬件就会按照这个间隔持续在链路空闲时发送 Keep-Alive 探测包不需要 MCU 参与也不需要周期性地手动触发。如果对端一直不回 ACKW5500 会根据 RTR重传超时和 RCR重传次数配置进行重试最终触发超时中断并改变 Socket 状态。注意一点Keep-Alive 发送间隔单位是 100ms比如想 5 秒一次就写 50。但这个硬件机制有一个限制它只能保证在“TCP 连接正常建立且处于 Established”时持续探测。如果你把 Socket 配成 TCP Server 模式且链路根本没有建立成功Keep-Alive 也不会生效。这点在联调时要区分清楚。2.3 参数怎么定间隔、RTR、RCR 的配合配置 Keep-Alive 间隔最怕两个极端太短设备频繁发包功耗和网络无效包增加有些低端路由器甚至会因为“探测太频繁”把设备判定为异常太长断线检测滞后可能断了几十分钟甚至几小时才发现。结合我做过的项目5 到 15 秒是比较稳妥的范围。我在环境数据采集终端上用的是 10 秒Sn_KALVR 设 100。原因很简单现场可能经过两级 NAT运营商 NAT 超时通常在 2 到 5 分钟10 秒一次探测能保证每一条中间设备的表项都被持续刷新同时也留足了余量。如果业务需要更快感知断线可以压到 5 秒但不要低于 3 秒否则会产生大量无效探测包。RTR 和 RCR 这两个寄存器也要顺手检查一下。RTR 默认是 0x07D0也就是 2000单位 100us换算过来约 200msRCR 默认是 8也就是重传 8 次。当 Keep-Alive 包发送后没有 ACKW5500 就会按这个节奏重传大约 1.6 秒后累计超时触发 Sn_IR 的 TIMEOUT 中断。这个“1.6 秒内感知”对很多场景是够用的但前提是应用层真的去处理了 TIMEOUT 中断并且在中断里做了 Socket 状态查询和重连准备。提示Sn_KALVR 只是“间隔”真正决定“多久判定失败”的是 RTR、RCR 与 Keep-Alive 间隔的叠加效果。想快速感知断链优先把 RCR 调小比如改成 3 到 5 次而不是把 Keep-Alive 间隔无限调短。3. 实战把 Keep-Alive 和断线重连真正跑起来3.1 应用层怎么判断“连接已经死了”只配置 Keep-Alive 还不够因为 Keep-Alive 只能让 TCP 层发现异常最终“决定要不要重连”的还是应用层的状态机。在裸机或者 RTOS 下我会用一个周期任务每 100ms 或 500ms 做一次 Socket 状态巡检。巡检的核心是三个信号Socket 状态寄存器 Sn_SR、Socket 中断标志 Sn_IR、以及业务层的收包超时。先看 Sn_IR 有没有 TIMEOUT 或 DISCON 标志有就说明硬件层面已经察觉到链路异常。再看 Sn_SR 是不是还停留在 SOCK_ESTABLISHED0x17如果状态已经漂移成 SOCK_CLOSE_WAIT0x1C、SOCK_TIME_WAIT 或者其他值说明连接已经进入关闭流程必须主动清理。这里有一个容易踩的坑W5500 的 Socket 中断标志读到之后不会自动清除必须软件写 1 清标志。很多新手在中断处理里只读了 Sn_IR 判断事件没有清除标志导致同一个中断反复触发看上去像“疯狂掉线”。我一般会在每次巡检后统一清一次 Sn_IR只保留还需要继续处理的中断源。3.2 重连策略设计指数退避和状态清理一旦判定连接已死不要立刻又去连服务器。如果服务器正在重启或者网络还在抖动你疯狂重连只会把自己设备的状态机搞乱还可能因为端口复用冲突导致连不上。更好的做法是指数退避。我的做法是第一重重连间隔 1 秒第二次 2 秒第三次 4 秒依次翻倍最大不超过 60 秒。连续重试 10 次都失败就保持 60 秒间隔继续尝试不设置“放弃”这种选项因为嵌入式设备大多需要无条件保持在线。当然连续失败时可以点亮一个告警 LED方便现场判断。重连前必须先彻底清理旧的 Socket。W5500 的 CLOSE 命令要发出去然后轮询确认 Socket 状态回到 SOCK_CLOSED0x00再重新 OPEN、重新 CONNECT。如果你跳过 CLOSE直接在旧状态上发 CONNECT硬件状态机会因为当前状态不合法导致命令被丢弃表现就是“Ctrl 命令发送了Socket 却没反应”。如果 W5500 用的是非阻塞连接方式CONNECT 命令发出后要去等 CON 中断或者轮询 Sn_SR。我遇到过很多次“连接失败后 Socket 卡在 SYNSENT”的情况当时就是因为在 CONNECT 超时后只做了超时返回没有把 Socket 关掉重建。后来统一改成“任意一次连接失败先 CLOSE再 OPEN再 CONNECT”这个问题才算彻底消失。3.3 核心代码Keep-Alive 配置、状态监测与自动重连下面这套代码基于 W5500 常见的寄存器操作接口不绑定特定厂商库。wizchip_write和wizchip_read是你工程里已有的 SPI 读写函数照着替换即可。// socket 寄存器偏移后面都用 n * 0x20 计算 #define SN_CR(n) (0x0001 ((n) 5)) #define SN_IR(n) (0x0002 ((n) 5)) #define SN_SR(n) (0x0003 ((n) 5)) #define SN_KALVR(n) (0x002E ((n) 5)) #define SOCK_CLOSED 0x00 #define SOCK_INIT 0x13 #define SOCK_LISTEN 0x14 #define SOCK_SYNSENT 0x15 #define SOCK_ESTABLISHED 0x17 #define SOCK_CLOSE_WAIT 0x1C #define SN_CR_KEEP 0x20 #define SN_CR_CLOSE 0x10 #define SN_CR_OPEN 0x01 #define SN_CR_CONNECT 0x04 #define SN_IR_TIMEOUT 0x08 #define SN_IR_DISCON 0x01// 配置 Keep-Aliveinterval_ms 是期望间隔单位毫秒 void w5500_socket_enable_keepalive(uint8_t sn, uint16_t interval_ms) { uint8_t kalv (uint8_t)(interval_ms / 100); // 先关闭 KEEP 控制位避免旧配置残留 uint8_t cr wizchip_read(SN_CR(sn)); cr ~SN_CR_KEEP; wizchip_write(SN_CR(sn), cr); // 写入间隔值单位 100ms wizchip_write(SN_KALVR(sn), kalv); // 开启 KEEP 位硬件开始自动发探测包 cr wizchip_read(SN_CR(sn)); cr | SN_CR_KEEP; wizchip_write(SN_CR(sn), cr); }// 检查 socket 当前是否还“活着” int w5500_socket_is_alive(uint8_t sn) { uint8_t status wizchip_read(SN_SR(sn)); // 1. 状态不是 ESTABLISHED直接认为异常 if (status ! SOCK_ESTABLISHED) { return 0; } // 2. 读取 IR 并清除防止标志堆积 uint8_t ir wizchip_read(SN_IR(sn)); wizchip_write(SN_IR(sn), ir); // 3. 出现超时或断开标志说明链路已经出问题 if ((ir SN_IR_TIMEOUT) || (ir SN_IR_DISCON)) { return 0; } return 1; }// 断线后重建连接采用指数退避 #define RECONNECT_MAX_INTERVAL_MS 60000 #define RECONNECT_MAX_COUNT 10 void w5500_task_reconnect(uint8_t sn, uint8_t *server_ip, uint16_t server_port) { static uint16_t retry_count 0; static uint32_t next_time 0; uint32_t now get_tick_ms(); if (!w5500_socket_is_alive(sn)) { if (now next_time) { return; // 还没到下一次重连时间 } // 计算本次等待间隔1s,2s,4s,...,60s uint32_t wait_ms 1000; if (retry_count RECONNECT_MAX_COUNT) { wait_ms RECONNECT_MAX_INTERVAL_MS; } else { wait_ms 1000 retry_count; if (wait_ms RECONNECT_MAX_INTERVAL_MS) { wait_ms RECONNECT_MAX_INTERVAL_MS; } } // 先彻底关闭再重置 socket避免状态机卡死 wizchip_write(SN_CR(sn), SN_CR_CLOSE); while (wizchip_read(SN_SR(sn)) ! SOCK_CLOSED) { delay_ms(1); } // 重新打开、连接 wizchip_write(SN_CR(sn), SN_CR_OPEN); w5500_set_dest_ip(sn, server_ip); w5500_set_dest_port(sn, server_port); wizchip_write(SN_CR(sn), SN_CR_CONNECT); // 等待状态变为 ESTABLISHED这里只等 3 秒 uint32_t timeout get_tick_ms() 3000; while ((wizchip_read(SN_SR(sn)) ! SOCK_ESTABLISHED) (get_tick_ms() timeout)) { delay_ms(10); } if (wizchip_read(SN_SR(sn)) SOCK_ESTABLISHED) { // 连接成功重新开启 Keep-Alive清空退避计数 retry_count 0; w5500_socket_enable_keepalive(sn, 10000); } else { retry_count; next_time now wait_ms; } } else { retry_count 0; } }这段代码不是我随手写的是在一个 STM32F103 W5500 的项目里实际跑过的版本。任务调度周期建议 50ms 左右每次只做一次状态判断重连等待用next_time控制不阻塞主流程。连接成功开启 Keep-Alive 那一步很容易被忽略很多人先写重连逻辑忘了重新设置 Sn_KALVR结果重连之后又进入“半开状态等死”的循环。3.4 实验验证拔网线、断服务器、切断路由器代码写完后我在办公室搭了一套验证环境W5500 设备作为 TCP Client 连本机服务器服务器开 6080 端口监听。验证分三步走。第一步是拔网线。设备运行半小时后我直接拔掉 W5500 网口端的网线等 Keep-Alive 探测失败满 1.6 秒左右设备日志里打印 TIMEOUTSocket 状态从 Established 切到 CLOSED然后按照 1 秒、2 秒、4 秒的节奏开始重连。网线插回去后第一次 1 秒后的重连就成功了整个过程不到 5 秒业务恢复。第二步是断服务器。保持网线通把服务器进程直接 kill 掉。此时 TCP 的 FIN 会发到设备W5500 的 Socket 状态会切到 CLOSE_WAIT设备通过 Sn_IR 的 DISCON 标志感知到连接断开自动重连。服务器没起来的时候重连失败并开始指数退避服务器恢复后连接在下一个重连窗口恢复。第三步是切断路由器。我把设备接到一个小型家用路由器后面拔掉路由器 WAN 口网线模拟 NAT 表项回收场景。由于此时局域网还通Keep-Alive 包能到路由器但路由器出不去最终在 RTR/RCR 重传超时后触发 TIMEOUT。设备感知到断线并重连WAN 口恢复后链路回到正常。注意实测下来Keep-Alive 的探测包在经过多级 NAT 时中间设备不一定转发但只要 NAT 表项被刷新过链路就能保持。真正致命的反而是“对端已经不会再回 ACK但设备还傻等”的场景。所以 Keep-Alive 间隔一定要小于中间设备 NAT 表项超时建议至少留 50% 余量。4. 常见问题与排查技巧实录4.1 设置了 Keep-Alive 还是掉线问题出在哪如果你按上面步骤配置了 Sn_KALVR 和 Sn_CR 的 KEEP 位但依然掉线通常不是 Keep-Alive 本身没生效而是配置时机不对或者链路断了之后应用层没有及时感知。最常见的是在 TCP 连接建立之前就去配置 Keep-Alive。W5500 硬件只在 Established 状态下发送探测包你在 OPEN 之后、CONNECT 之前写 Sn_KALVR很多固件版本会忽略进入 Established 后也不会补发。所以正确做法是连接成功之后再调用一次 Keep-Alive 配置最好就放在重连成功分支里。第二个问题是我用非阻塞连接时CONNECT 还没成功就去做别的等回来之后状态已经变了。如果你用中断方式处理 Socket一定要在 CON 中断处理里检查连接结果并且重新设置 Keep-Alive。很多驱动库不会帮你做这件事必须自己补。第三个问题是 RTR/RCR 配置太激进。有些项目为了“快速断线检测”把 RTR 改成 50ms、RCR 改成 2结果 TCP 正常传输时只要有轻微网络抖动就会触发超时导致频繁误报掉线。Keep-Alive 探测包如果也走这个节奏很容易把看似正常的链路判死。建议 RTR 不要小于 200msRCR 不要小于 3。4.2 服务器端也要配合NAT 超时、安全组和 TCP 参数问题不只在设备端。云服务器、轻量服务器、自建机房服务器都有自己的网络策略。很多云平台的安全组默认会清理空闲 TCP 会话超时通常在 60 秒到 300 秒之间。你在设备侧发了 Keep-Alive但服务器端如果正好在 NAT/负载均衡后面服务器回给设备的包能出来设备发的探测包也能进去但如果中间某层代理超时被清理链路依然会断。这种情况设备端 Keep-Alive 只能保证设备到“服务器入口”之间的链路活跃没法保证服务器应用进程正常。所以云服务器场景下我会在服务器上也开一层保活配置。Linux 服务器可以用 sysctl 调整sysctl -w net.ipv4.tcp_keepalive_time60 sysctl -w net.ipv4.tcp_keepalive_intvl10 sysctl -w net.ipv4.tcp_keepalive_probes3tcp_keepalive_time 表示连接空闲多少秒后开始发送探测包默认 7200 秒也就是 2 小时对嵌入式设备来说太长了。改成 60 秒基本能保证服务器在 90 秒内感知到异常连接。当然这只对 Linux 服务器上的连接有效如果连接通过云负载均衡还要去控制台看会话保持和空闲超时配置。另外服务器上如果有防火墙别把 ICMP 或者某些自定义端口误封了。我踩过的一个坑是开发环境里服务器防火墙没放行 Keep-Alive 探测包经过的某个端口Wireshark 上能看到设备发出的探测包但服务器侧没有回 ACKW5500 一直重传最终触发 TIMEOUT。排查时不要只盯设备端服务器端tcpdump也要同步抓。4.3 W5500 做 TCP 服务器时的保活思路如果你的 W5500 设备不是主动连服务器而是作为 TCP Server等待后台系统或者手机 App 来连接保活逻辑就要反过来想。W5500 的 Keep-Alive 机制在 Server 模式下同样可以配置一旦客户端连上来建立了 Established 连接Sn_KALVR 和 Sn_CR 的 KEEP 位仍然有效设备会主动向客户端发探测包。这样做的好处是即使客户端因为断网、休眠、进程崩溃而没有发 FIN设备也能在几十秒内发现连接失效。但 Server 模式下最麻烦的不是“连接断了”而是“连接也许还活着但某个客户端占着 Socket 不撒手”。W5500 有 8 个 Socket如果 8 个都被占满新客户端就进不来。所以我通常会在 TCP Server 的巡检任务里维护一个“最后活动时间”业务收到任意一包数据就刷新这个时间。如果超过 30 秒没有任何数据就算 Keep-Alive 逻辑还没判死我也会主动把这条连接关掉给后续客户端腾位置。服务器端主动关闭时W5500 会进入 FIN_WAIT 状态这个状态也需要定时清理。我见过只处理 Established 和 Closed 状态的代码忽略了 TIME_WAIT、CLOSE_WAIT结果 Socket 资源被慢慢耗尽最终表现为“W5500 无法建立新连接重启后又好”。实际上只要在巡检里把非 Established 的状态都归到“需要关闭”一类就能解决。4.4 抓包验证怎么确认 Keep-Alive 真的在发写代码的人不抓包等于闭着眼睛开车。验证 Keep-Alive 是否生效最直接的方法是 Wireshark 抓包。设备连 PCPC 上开一个 TCP Server然后从设备连接 PC在 Wireshark 过滤规则里填tcp.port 你监听的端口链路空闲十几秒后会看到一类特殊报文TCP 包长度 0Seq 是上一次发送的 Seq 减 1Wireshark 直接标记为 “TCP Keep-Alive”。如果 20 秒内一个 Keep-Alive 包都看不到先查 Sn_KALVR 有没有写入成功。常见问题是 SPI 写寄存器时地址偏移算错把 KALVR 写到了别的寄存器里。这时候可以用 WIZnet 官方的寄存器读写工具或者在你的调试串口里把 Sn_KALVR 读出来打印确认值是 50对应 5 秒或者 100对应 10 秒。还有一个小技巧抓包时同时抓设备端和服务器端两个方向。如果设备端抓到了 Keep-Alive但服务器端没抓到说明中间某个网段把包丢了。我之前排查过一个数据上报项目设备侧 Keep-Alive 一直在发服务器侧却频繁收不到最后发现是客户现场的交换机做了基于 MAC 的静态绑定设备换过网口之后 MAC 和端口不匹配导致部分广播包和探测包被丢弃。这类物理层问题光看代码是永远看不出来的。现象可能的根因排查方向设备显示 Established服务器显示连接已断NAT 表项超时 / 对端未收到包设置 Keep-Alive缩短间隔检查抓包Keep-Alive 配置了但 Wireshark 看不到Sn_KALVR 写错地址 / Keep 位没打开读寄存器确认检查 SPI 帧网线断开后设备几十秒才发现RTR/RCR 配置过短或过长调整 RTR/RCR缩短探测重试周期服务器重启后设备一直连接失败旧 Socket 未清理 / 端口被占用重连前执行 CLOSE确认回到 SOCK_CLOSEDping 时通时断但业务不太掉线供电不稳 / 网变虚焊 / 单片机负载过高检查电源纹波、网口电路、SPI 时钟频率5. 一组实测下来的体会前面讲的都是能直接复现的技术点最后再说一个我自己的习惯不管 Keep-Alive 配得多好我都会在业务层再放一条“应用层心跳”。TCP Keep-Alive 只能证明 TCP 链路在设备看来是通的但服务器应用进程是不是正常、数据是不是真的被业务处理了它是管不了的。真正可靠的方案是 TCP Keep-Alive 负责尽早发现链路物理断离应用层心跳负责确认业务逻辑健康两层一起用。我在多个项目里验证过这套组合拳硬件层 Keep-Alive 间隔 10 秒应用层心跳间隔 15 秒服务器连续 3 个心跳没收到就判定设备离线设备连续 3 个心跳的回复没收到就主动断开重连。这样即使遇到“TCP 链路通但业务卡死”的极端情况也能在一分钟内自动恢复。W5500 这种硬协议栈芯片最大的优点是稳定最大的坑也恰恰来自这种“稳定”——它不会主动替你想办法。只要把 Keep-Alive 的寄存器配置、Socket 状态巡检、断线重连的退避策略都补齐W5500 跑几个月不重启是完全做得到的。真到了上线现场建议还是留一个看门狗定时喂同时把掉线原因打日志这样下次再出问题你至少有据可查而不是对着芯片干瞪眼。
W5500长连接掉线？深入解析TCP Keep-Alive与断线重连实战方案
如果你调过 W5500 这类硬协议栈网卡大概率遇到过这样的场景设备上电连服务器一切正常跑了三天、五天或半个月突然连不上了服务器侧早没了这条连接可设备侧还傻乎乎显示着 TCP Established。重启一下设备又能恢复过几天又犯病。更奇怪的是有时候现场去 ping 设备丢包严重、时通时断但网线明明插得好好的。我早期做 STM32 W5500 的采集终端时这个问题整整折磨了一周。后来把 TCP Keep-Alive 的机制彻底啃了一遍又结合 W5500 的寄存器和官方库做了一套断线检测与自动重连方案才算是把长连接真正稳住。这篇文章不绕弯子直接讲清楚 W5500 在服务器长连接场景下为什么会断、Keep-Alive 到底怎么保活、以及一套能直接抄作业的重连代码。1. 先搞清楚问题W5500 为什么会出现服务器断线1.1 典型现象正常工作几天后突然连不上这种故障最直观的表现就是“运行一段时间后连不上服务器”而且非常有迷惑性设备端看 W5500 的状态寄存器Socket 好像还是 Established但服务器应用日志里那条 TCP 连接早就没了。重启设备后能恢复恢复后又能跑几天看起来像随机故障实际上几乎每次都是同一个原因。我用 W5500 做环境数据采集器时现象更具体设备每天正常上报数据到第四天早上开始掉线服务器端无任何记录。现场看设备日志昨天最后一次发送还成功了之后就再没有网络事件。重启后又好第二天再掉。把抓包工具接上去等复现发现设备侧没有任何 TCP FIN 或 RST 包发出链路就像凭空消失一样。这类问题有一个共同点链路不是被某一方主动关闭的而是被“中间设备”悄悄回收了。设备侧完全没感知还以为连接还活着。W5500 作为独立硬件 TCP/IP 协议栈芯片本身不跑业务逻辑也不会因为你业务层“看起来正常”就主动发现异常。要想解决必须让 TCP 层的保活机制和业务层的断线判定同时工作。1.2 根因半开连接与 NAT 静默回收TCP 连接在不再通信后会进入一种“半开”状态两端都保留着 socket 资源但中间经过的路由器、交换机、防火墙或 NAT 网关可能已经在超时后把这条连接表项清掉了。常见的家用路由器、云服务器安全组、运营商级 NAT对空闲 TCP 会话都有超时策略从几十秒到几小时不等。当 NAT 表项被清掉之后设备再发数据出去路由器没有对应映射关系最典型的处理方式就是静默丢弃。设备端 TCP 发送逻辑是“发了就等 ACK”等不到 ACK 就重传重传超时后才报错。但 W5500 的硬件状态机在没有触发数据收发时不会主动去探测链路所以设备就一直停留在 Established直到某次业务发送触发了超时重传才真正意识到链路断了。还有一类情况是服务器端主动关闭了连接但 FIN 包在网络里丢失或没被设备处理设备同样不知道。服务器可能因为心跳超时、运维重启、进程崩溃等原因把连接回收客户端没收到 FIN 或 RST就会继续傻等。说白了TCP 本身并不保证“连接永远活着”它只保证“在双方都愿意维护的前提下数据可靠到达”。没人维护连接就是假的。1.3 为什么硬协议栈不等于免维护很多朋友选 W5500是因为它把 TCP/IP 协议栈做进了芯片硬件里MCU 只要调用几个寄存器命令就能完成 Socket 操作确实省心。但也正因为协议栈在硬件里你没法像 Linux 那样随意改 TCP 参数很多“软件协议栈默认帮你处理”的事情到 W5500 这里就需要你主动配置。比如 Linux 内核的 TCP 栈默认开启 Keep-Alive 探测虽然默认 2 小时才探测一次但至少有个兜底。而 W5500 的 TCP Socket 创建后Keep-Alive 功能默认是关闭的需要你显式去配置 Sn_KALVR 寄存器再打开对应的 KEEP 控制位。如果不配协议栈就真的“什么都不做”一切依赖业务链路是否活跃。另外 W5500 虽然有 8 个硬件 Socket但每个 Socket 都是独立状态机一旦进入半开状态它会一直占着端口和缓冲区资源。如果不做主动清理重连时可能出现“Socket 明明 open 却连接不上”的诡异现象。所以用 W5500 做服务器长连接核心思路就两条一是靠 Keep-Alive 机制让 TCP 层及时发现链路死亡二是靠应用层断线重连机制把 Socket 状态拉回正轨。2. Keep-Alive 机制深入拆解2.1 TCP Keep-Alive 工作原理一个不起眼的探测包TCP Keep-Alive 并不是业务层的心跳包而是 TCP 协议栈自己发送的一种探测包。它做的事情很简单当一条 TCP 连接空闲超过设定时间后协议栈主动向对端发一个字节常见实现是 seq 当前发送序列号 - 1长度 0个别实现会带 1 字节垃圾数据对端如果正常就会回一个 ACK。这样发送方就知道链路还通着。如果对端不回 ACK协议栈会按一定间隔继续发探测包连续发若干次都失败就判定连接已死然后通知上层关闭 Socket。这个机制的好处是不用依赖业务层是否有数据要发空闲连接也能被持续验证。缺点也很明显它只能验证“TCP 路径通不通”没办法验证服务器应用进程是不是还活着、业务逻辑是否正常。所以它不能替代应用层心跳。如果对端已经崩溃但网线还通着Keep-Alive 探测包可能得到对端 TCP 栈的 ACK但应用层根本没在正常处理业务这类“假活”Keep-Alive 也发现不了。反过来如果对端已经断电或网线断开Keep-Alive 就能在较短时间内让本端感知链路失效这正是我们在断线重连中需要的第一道防线。2.2 W5500 硬件 Keep-Alive 是怎么实现的W5500 对 TCP Keep-Alive 的支持非常直接核心就两个寄存器一个叫 Sn_KALVRSocket n Keep Alive Timer Register偏移地址是0x002E n × 0x20单位为 100ms写入 0 表示关闭另一个是 Sn_CRSocket n Command Register里的 KEEP 控制位bit5置 1 表示允许硬件发送 Keep-Alive 包。配置流程说起来很简单Socket 处于 TCP 模式并且连接建立后把 Sn_KALVR 写成你想要的间隔数值再把 Sn_CR 的 bit5 置 1。之后 W5500 硬件就会按照这个间隔持续在链路空闲时发送 Keep-Alive 探测包不需要 MCU 参与也不需要周期性地手动触发。如果对端一直不回 ACKW5500 会根据 RTR重传超时和 RCR重传次数配置进行重试最终触发超时中断并改变 Socket 状态。注意一点Keep-Alive 发送间隔单位是 100ms比如想 5 秒一次就写 50。但这个硬件机制有一个限制它只能保证在“TCP 连接正常建立且处于 Established”时持续探测。如果你把 Socket 配成 TCP Server 模式且链路根本没有建立成功Keep-Alive 也不会生效。这点在联调时要区分清楚。2.3 参数怎么定间隔、RTR、RCR 的配合配置 Keep-Alive 间隔最怕两个极端太短设备频繁发包功耗和网络无效包增加有些低端路由器甚至会因为“探测太频繁”把设备判定为异常太长断线检测滞后可能断了几十分钟甚至几小时才发现。结合我做过的项目5 到 15 秒是比较稳妥的范围。我在环境数据采集终端上用的是 10 秒Sn_KALVR 设 100。原因很简单现场可能经过两级 NAT运营商 NAT 超时通常在 2 到 5 分钟10 秒一次探测能保证每一条中间设备的表项都被持续刷新同时也留足了余量。如果业务需要更快感知断线可以压到 5 秒但不要低于 3 秒否则会产生大量无效探测包。RTR 和 RCR 这两个寄存器也要顺手检查一下。RTR 默认是 0x07D0也就是 2000单位 100us换算过来约 200msRCR 默认是 8也就是重传 8 次。当 Keep-Alive 包发送后没有 ACKW5500 就会按这个节奏重传大约 1.6 秒后累计超时触发 Sn_IR 的 TIMEOUT 中断。这个“1.6 秒内感知”对很多场景是够用的但前提是应用层真的去处理了 TIMEOUT 中断并且在中断里做了 Socket 状态查询和重连准备。提示Sn_KALVR 只是“间隔”真正决定“多久判定失败”的是 RTR、RCR 与 Keep-Alive 间隔的叠加效果。想快速感知断链优先把 RCR 调小比如改成 3 到 5 次而不是把 Keep-Alive 间隔无限调短。3. 实战把 Keep-Alive 和断线重连真正跑起来3.1 应用层怎么判断“连接已经死了”只配置 Keep-Alive 还不够因为 Keep-Alive 只能让 TCP 层发现异常最终“决定要不要重连”的还是应用层的状态机。在裸机或者 RTOS 下我会用一个周期任务每 100ms 或 500ms 做一次 Socket 状态巡检。巡检的核心是三个信号Socket 状态寄存器 Sn_SR、Socket 中断标志 Sn_IR、以及业务层的收包超时。先看 Sn_IR 有没有 TIMEOUT 或 DISCON 标志有就说明硬件层面已经察觉到链路异常。再看 Sn_SR 是不是还停留在 SOCK_ESTABLISHED0x17如果状态已经漂移成 SOCK_CLOSE_WAIT0x1C、SOCK_TIME_WAIT 或者其他值说明连接已经进入关闭流程必须主动清理。这里有一个容易踩的坑W5500 的 Socket 中断标志读到之后不会自动清除必须软件写 1 清标志。很多新手在中断处理里只读了 Sn_IR 判断事件没有清除标志导致同一个中断反复触发看上去像“疯狂掉线”。我一般会在每次巡检后统一清一次 Sn_IR只保留还需要继续处理的中断源。3.2 重连策略设计指数退避和状态清理一旦判定连接已死不要立刻又去连服务器。如果服务器正在重启或者网络还在抖动你疯狂重连只会把自己设备的状态机搞乱还可能因为端口复用冲突导致连不上。更好的做法是指数退避。我的做法是第一重重连间隔 1 秒第二次 2 秒第三次 4 秒依次翻倍最大不超过 60 秒。连续重试 10 次都失败就保持 60 秒间隔继续尝试不设置“放弃”这种选项因为嵌入式设备大多需要无条件保持在线。当然连续失败时可以点亮一个告警 LED方便现场判断。重连前必须先彻底清理旧的 Socket。W5500 的 CLOSE 命令要发出去然后轮询确认 Socket 状态回到 SOCK_CLOSED0x00再重新 OPEN、重新 CONNECT。如果你跳过 CLOSE直接在旧状态上发 CONNECT硬件状态机会因为当前状态不合法导致命令被丢弃表现就是“Ctrl 命令发送了Socket 却没反应”。如果 W5500 用的是非阻塞连接方式CONNECT 命令发出后要去等 CON 中断或者轮询 Sn_SR。我遇到过很多次“连接失败后 Socket 卡在 SYNSENT”的情况当时就是因为在 CONNECT 超时后只做了超时返回没有把 Socket 关掉重建。后来统一改成“任意一次连接失败先 CLOSE再 OPEN再 CONNECT”这个问题才算彻底消失。3.3 核心代码Keep-Alive 配置、状态监测与自动重连下面这套代码基于 W5500 常见的寄存器操作接口不绑定特定厂商库。wizchip_write和wizchip_read是你工程里已有的 SPI 读写函数照着替换即可。// socket 寄存器偏移后面都用 n * 0x20 计算 #define SN_CR(n) (0x0001 ((n) 5)) #define SN_IR(n) (0x0002 ((n) 5)) #define SN_SR(n) (0x0003 ((n) 5)) #define SN_KALVR(n) (0x002E ((n) 5)) #define SOCK_CLOSED 0x00 #define SOCK_INIT 0x13 #define SOCK_LISTEN 0x14 #define SOCK_SYNSENT 0x15 #define SOCK_ESTABLISHED 0x17 #define SOCK_CLOSE_WAIT 0x1C #define SN_CR_KEEP 0x20 #define SN_CR_CLOSE 0x10 #define SN_CR_OPEN 0x01 #define SN_CR_CONNECT 0x04 #define SN_IR_TIMEOUT 0x08 #define SN_IR_DISCON 0x01// 配置 Keep-Aliveinterval_ms 是期望间隔单位毫秒 void w5500_socket_enable_keepalive(uint8_t sn, uint16_t interval_ms) { uint8_t kalv (uint8_t)(interval_ms / 100); // 先关闭 KEEP 控制位避免旧配置残留 uint8_t cr wizchip_read(SN_CR(sn)); cr ~SN_CR_KEEP; wizchip_write(SN_CR(sn), cr); // 写入间隔值单位 100ms wizchip_write(SN_KALVR(sn), kalv); // 开启 KEEP 位硬件开始自动发探测包 cr wizchip_read(SN_CR(sn)); cr | SN_CR_KEEP; wizchip_write(SN_CR(sn), cr); }// 检查 socket 当前是否还“活着” int w5500_socket_is_alive(uint8_t sn) { uint8_t status wizchip_read(SN_SR(sn)); // 1. 状态不是 ESTABLISHED直接认为异常 if (status ! SOCK_ESTABLISHED) { return 0; } // 2. 读取 IR 并清除防止标志堆积 uint8_t ir wizchip_read(SN_IR(sn)); wizchip_write(SN_IR(sn), ir); // 3. 出现超时或断开标志说明链路已经出问题 if ((ir SN_IR_TIMEOUT) || (ir SN_IR_DISCON)) { return 0; } return 1; }// 断线后重建连接采用指数退避 #define RECONNECT_MAX_INTERVAL_MS 60000 #define RECONNECT_MAX_COUNT 10 void w5500_task_reconnect(uint8_t sn, uint8_t *server_ip, uint16_t server_port) { static uint16_t retry_count 0; static uint32_t next_time 0; uint32_t now get_tick_ms(); if (!w5500_socket_is_alive(sn)) { if (now next_time) { return; // 还没到下一次重连时间 } // 计算本次等待间隔1s,2s,4s,...,60s uint32_t wait_ms 1000; if (retry_count RECONNECT_MAX_COUNT) { wait_ms RECONNECT_MAX_INTERVAL_MS; } else { wait_ms 1000 retry_count; if (wait_ms RECONNECT_MAX_INTERVAL_MS) { wait_ms RECONNECT_MAX_INTERVAL_MS; } } // 先彻底关闭再重置 socket避免状态机卡死 wizchip_write(SN_CR(sn), SN_CR_CLOSE); while (wizchip_read(SN_SR(sn)) ! SOCK_CLOSED) { delay_ms(1); } // 重新打开、连接 wizchip_write(SN_CR(sn), SN_CR_OPEN); w5500_set_dest_ip(sn, server_ip); w5500_set_dest_port(sn, server_port); wizchip_write(SN_CR(sn), SN_CR_CONNECT); // 等待状态变为 ESTABLISHED这里只等 3 秒 uint32_t timeout get_tick_ms() 3000; while ((wizchip_read(SN_SR(sn)) ! SOCK_ESTABLISHED) (get_tick_ms() timeout)) { delay_ms(10); } if (wizchip_read(SN_SR(sn)) SOCK_ESTABLISHED) { // 连接成功重新开启 Keep-Alive清空退避计数 retry_count 0; w5500_socket_enable_keepalive(sn, 10000); } else { retry_count; next_time now wait_ms; } } else { retry_count 0; } }这段代码不是我随手写的是在一个 STM32F103 W5500 的项目里实际跑过的版本。任务调度周期建议 50ms 左右每次只做一次状态判断重连等待用next_time控制不阻塞主流程。连接成功开启 Keep-Alive 那一步很容易被忽略很多人先写重连逻辑忘了重新设置 Sn_KALVR结果重连之后又进入“半开状态等死”的循环。3.4 实验验证拔网线、断服务器、切断路由器代码写完后我在办公室搭了一套验证环境W5500 设备作为 TCP Client 连本机服务器服务器开 6080 端口监听。验证分三步走。第一步是拔网线。设备运行半小时后我直接拔掉 W5500 网口端的网线等 Keep-Alive 探测失败满 1.6 秒左右设备日志里打印 TIMEOUTSocket 状态从 Established 切到 CLOSED然后按照 1 秒、2 秒、4 秒的节奏开始重连。网线插回去后第一次 1 秒后的重连就成功了整个过程不到 5 秒业务恢复。第二步是断服务器。保持网线通把服务器进程直接 kill 掉。此时 TCP 的 FIN 会发到设备W5500 的 Socket 状态会切到 CLOSE_WAIT设备通过 Sn_IR 的 DISCON 标志感知到连接断开自动重连。服务器没起来的时候重连失败并开始指数退避服务器恢复后连接在下一个重连窗口恢复。第三步是切断路由器。我把设备接到一个小型家用路由器后面拔掉路由器 WAN 口网线模拟 NAT 表项回收场景。由于此时局域网还通Keep-Alive 包能到路由器但路由器出不去最终在 RTR/RCR 重传超时后触发 TIMEOUT。设备感知到断线并重连WAN 口恢复后链路回到正常。注意实测下来Keep-Alive 的探测包在经过多级 NAT 时中间设备不一定转发但只要 NAT 表项被刷新过链路就能保持。真正致命的反而是“对端已经不会再回 ACK但设备还傻等”的场景。所以 Keep-Alive 间隔一定要小于中间设备 NAT 表项超时建议至少留 50% 余量。4. 常见问题与排查技巧实录4.1 设置了 Keep-Alive 还是掉线问题出在哪如果你按上面步骤配置了 Sn_KALVR 和 Sn_CR 的 KEEP 位但依然掉线通常不是 Keep-Alive 本身没生效而是配置时机不对或者链路断了之后应用层没有及时感知。最常见的是在 TCP 连接建立之前就去配置 Keep-Alive。W5500 硬件只在 Established 状态下发送探测包你在 OPEN 之后、CONNECT 之前写 Sn_KALVR很多固件版本会忽略进入 Established 后也不会补发。所以正确做法是连接成功之后再调用一次 Keep-Alive 配置最好就放在重连成功分支里。第二个问题是我用非阻塞连接时CONNECT 还没成功就去做别的等回来之后状态已经变了。如果你用中断方式处理 Socket一定要在 CON 中断处理里检查连接结果并且重新设置 Keep-Alive。很多驱动库不会帮你做这件事必须自己补。第三个问题是 RTR/RCR 配置太激进。有些项目为了“快速断线检测”把 RTR 改成 50ms、RCR 改成 2结果 TCP 正常传输时只要有轻微网络抖动就会触发超时导致频繁误报掉线。Keep-Alive 探测包如果也走这个节奏很容易把看似正常的链路判死。建议 RTR 不要小于 200msRCR 不要小于 3。4.2 服务器端也要配合NAT 超时、安全组和 TCP 参数问题不只在设备端。云服务器、轻量服务器、自建机房服务器都有自己的网络策略。很多云平台的安全组默认会清理空闲 TCP 会话超时通常在 60 秒到 300 秒之间。你在设备侧发了 Keep-Alive但服务器端如果正好在 NAT/负载均衡后面服务器回给设备的包能出来设备发的探测包也能进去但如果中间某层代理超时被清理链路依然会断。这种情况设备端 Keep-Alive 只能保证设备到“服务器入口”之间的链路活跃没法保证服务器应用进程正常。所以云服务器场景下我会在服务器上也开一层保活配置。Linux 服务器可以用 sysctl 调整sysctl -w net.ipv4.tcp_keepalive_time60 sysctl -w net.ipv4.tcp_keepalive_intvl10 sysctl -w net.ipv4.tcp_keepalive_probes3tcp_keepalive_time 表示连接空闲多少秒后开始发送探测包默认 7200 秒也就是 2 小时对嵌入式设备来说太长了。改成 60 秒基本能保证服务器在 90 秒内感知到异常连接。当然这只对 Linux 服务器上的连接有效如果连接通过云负载均衡还要去控制台看会话保持和空闲超时配置。另外服务器上如果有防火墙别把 ICMP 或者某些自定义端口误封了。我踩过的一个坑是开发环境里服务器防火墙没放行 Keep-Alive 探测包经过的某个端口Wireshark 上能看到设备发出的探测包但服务器侧没有回 ACKW5500 一直重传最终触发 TIMEOUT。排查时不要只盯设备端服务器端tcpdump也要同步抓。4.3 W5500 做 TCP 服务器时的保活思路如果你的 W5500 设备不是主动连服务器而是作为 TCP Server等待后台系统或者手机 App 来连接保活逻辑就要反过来想。W5500 的 Keep-Alive 机制在 Server 模式下同样可以配置一旦客户端连上来建立了 Established 连接Sn_KALVR 和 Sn_CR 的 KEEP 位仍然有效设备会主动向客户端发探测包。这样做的好处是即使客户端因为断网、休眠、进程崩溃而没有发 FIN设备也能在几十秒内发现连接失效。但 Server 模式下最麻烦的不是“连接断了”而是“连接也许还活着但某个客户端占着 Socket 不撒手”。W5500 有 8 个 Socket如果 8 个都被占满新客户端就进不来。所以我通常会在 TCP Server 的巡检任务里维护一个“最后活动时间”业务收到任意一包数据就刷新这个时间。如果超过 30 秒没有任何数据就算 Keep-Alive 逻辑还没判死我也会主动把这条连接关掉给后续客户端腾位置。服务器端主动关闭时W5500 会进入 FIN_WAIT 状态这个状态也需要定时清理。我见过只处理 Established 和 Closed 状态的代码忽略了 TIME_WAIT、CLOSE_WAIT结果 Socket 资源被慢慢耗尽最终表现为“W5500 无法建立新连接重启后又好”。实际上只要在巡检里把非 Established 的状态都归到“需要关闭”一类就能解决。4.4 抓包验证怎么确认 Keep-Alive 真的在发写代码的人不抓包等于闭着眼睛开车。验证 Keep-Alive 是否生效最直接的方法是 Wireshark 抓包。设备连 PCPC 上开一个 TCP Server然后从设备连接 PC在 Wireshark 过滤规则里填tcp.port 你监听的端口链路空闲十几秒后会看到一类特殊报文TCP 包长度 0Seq 是上一次发送的 Seq 减 1Wireshark 直接标记为 “TCP Keep-Alive”。如果 20 秒内一个 Keep-Alive 包都看不到先查 Sn_KALVR 有没有写入成功。常见问题是 SPI 写寄存器时地址偏移算错把 KALVR 写到了别的寄存器里。这时候可以用 WIZnet 官方的寄存器读写工具或者在你的调试串口里把 Sn_KALVR 读出来打印确认值是 50对应 5 秒或者 100对应 10 秒。还有一个小技巧抓包时同时抓设备端和服务器端两个方向。如果设备端抓到了 Keep-Alive但服务器端没抓到说明中间某个网段把包丢了。我之前排查过一个数据上报项目设备侧 Keep-Alive 一直在发服务器侧却频繁收不到最后发现是客户现场的交换机做了基于 MAC 的静态绑定设备换过网口之后 MAC 和端口不匹配导致部分广播包和探测包被丢弃。这类物理层问题光看代码是永远看不出来的。现象可能的根因排查方向设备显示 Established服务器显示连接已断NAT 表项超时 / 对端未收到包设置 Keep-Alive缩短间隔检查抓包Keep-Alive 配置了但 Wireshark 看不到Sn_KALVR 写错地址 / Keep 位没打开读寄存器确认检查 SPI 帧网线断开后设备几十秒才发现RTR/RCR 配置过短或过长调整 RTR/RCR缩短探测重试周期服务器重启后设备一直连接失败旧 Socket 未清理 / 端口被占用重连前执行 CLOSE确认回到 SOCK_CLOSEDping 时通时断但业务不太掉线供电不稳 / 网变虚焊 / 单片机负载过高检查电源纹波、网口电路、SPI 时钟频率5. 一组实测下来的体会前面讲的都是能直接复现的技术点最后再说一个我自己的习惯不管 Keep-Alive 配得多好我都会在业务层再放一条“应用层心跳”。TCP Keep-Alive 只能证明 TCP 链路在设备看来是通的但服务器应用进程是不是正常、数据是不是真的被业务处理了它是管不了的。真正可靠的方案是 TCP Keep-Alive 负责尽早发现链路物理断离应用层心跳负责确认业务逻辑健康两层一起用。我在多个项目里验证过这套组合拳硬件层 Keep-Alive 间隔 10 秒应用层心跳间隔 15 秒服务器连续 3 个心跳没收到就判定设备离线设备连续 3 个心跳的回复没收到就主动断开重连。这样即使遇到“TCP 链路通但业务卡死”的极端情况也能在一分钟内自动恢复。W5500 这种硬协议栈芯片最大的优点是稳定最大的坑也恰恰来自这种“稳定”——它不会主动替你想办法。只要把 Keep-Alive 的寄存器配置、Socket 状态巡检、断线重连的退避策略都补齐W5500 跑几个月不重启是完全做得到的。真到了上线现场建议还是留一个看门狗定时喂同时把掉线原因打日志这样下次再出问题你至少有据可查而不是对着芯片干瞪眼。
