TCP/IP 协议栈与 MQTT、HTTP、Socket
Wi-Fi 连接成功，只代表设备接入了 AP，不代表业务已经在线。
完整联网链路是：
Wi-Fi 接入-> DHCP 获取 IP-> DNS 解析域名-> TCP / UDP 传输-> TLS 加密-> MQTT / HTTP / WebSocket 业务协议模组产品写 Embedded TCP/IP Stack 的意思是：
模组内部已经处理 IP、TCP、UDP、DNS 等网络协议；主控 MCU 可以通过 UART / SPI 命令使用这些能力。所以面试时不要只说“设备联网成功”，而要拆成：
Wi-Fi connected：已经关联 AP。IP ready：已经通过 DHCP 或静态配置拿到 IP。DNS ready：域名可以解析。transport connected：TCP / UDP 通道可用。secure connected：TLS 握手完成。business online：MQTT / HTTP / WebSocket 业务协议真正在线。这也是 Wi-Fi 模组软件开发的重点：把每一层状态、错误码、超时和恢复动作分清楚。
TCP/IP 协议栈放在哪里
Section titled “TCP/IP 协议栈放在哪里”有两种常见模式。
模式一：模组内部 TCP/IP。
主控 MCU ↓ AT / 私有协议Wi-Fi 模组 - Wi-Fi - IP - TCP / UDP - TLS / MQTT / HTTP优点：
主控简单RAM 压力小接入快缺点：
状态隐藏在模组里调试依赖 AT 响应和错误码UART 吞吐可能成为瓶颈模式二：主机侧 TCP/IP。
Linux / RTOS Host - Wi-Fi Driver - TCP/IP Stack - MQTT / HTTP ↓ SDIO / SPI / USBWi-Fi 连接模组适合复杂主机，例如 Linux 网关、摄像头、HMI。
对 Wi-Fi 模组产品来说，面试官常问的不是“你会不会实现 TCP/IP 协议栈”，而是：
你是否知道协议栈在模组还是主机？你是否知道主控通过什么命令或驱动访问网络能力？你是否能把 Wi-Fi、IP、TCP/TLS、业务协议的状态拆开？你是否能处理断线、超时、重连、离线缓存和日志诊断？DHCP 负责自动分配网络参数：
IP 地址子网掩码网关DNS租约常见问题：
Wi-Fi connected 但没有 IP。DHCP 超时。AP 地址池满。静态 IP 配置错误。排查时要区分：
Wi-Fi 层已连接IP 层未就绪如果 DHCP 失败，不应该马上判断“Wi-Fi 模组坏了”。更合理的恢复顺序是：
重新发起 DHCP检查 AP 地址池检查静态 IP 配置必要时断开并重新关联 AP最后才考虑重启模组DNS 负责把域名解析成 IP。
例如：
mqtt.example.com -> 1.2.3.4常见问题：
能 ping IP，不能访问域名。DNS 服务器不可达。设备时间错误导致 TLS 后续失败。模组 AT 命令里常见：
域名解析命令建立 TCP / SSL 连接命令查询连接状态命令如果 DNS 失败，也不应该直接重启 Wi-Fi。可以先做：
重试 DNS切换备用域名短期缓存上一次解析结果检查网关和 DNS 配置记录失败域名和错误码TCP 和 UDP
Section titled “TCP 和 UDP”TCP 特点：
面向连接可靠传输三次握手重传滑动窗口适合 MQTT / HTTP / WebSocketUDP 特点：
无连接开销小不保证可靠适合低延迟或自定义可靠性的场景IoT 设备最常见：
MQTT over TCP / TLSHTTP over TCP / TLSTCP 相关面试追问通常有：
TCP connect timeout 怎么处理？服务器主动 close 怎么处理？send 返回失败是否代表 Wi-Fi 断开？为什么 TCP 已连接，业务还是可能不在线？回答思路是：
TCP 失败优先重建 socket。不要立刻重启 Wi-Fi。连续失败再逐层向下恢复。发送失败要结合错误码、重试次数、RSSI、重连日志判断。UDP 虽然开销小，但设备侧通常要自己补：
序号ACK重传去重超时否则丢包后业务层不知道数据是否真的到达。
TLS 解决：
加密身份认证数据完整性嵌入式模组里 TLS 常见风险：
证书太大RAM 不足系统时间错误CA 证书过期SNI / 域名校验问题握手耗时长低功耗唤醒后重连慢面试表达：
TLS 不是只打开一个选项。嵌入式设备要关注证书存储、时间同步、内存占用、握手耗时和错误码。
MQTT 很适合 IoT，因为它有：
publish / subscribetopickeepaliveQoSretainlast will常见 topic：
device/{device_id}/telemetrydevice/{device_id}/statusdevice/{device_id}/commanddevice/{device_id}/event设备侧要处理：
connectsubscribe command topicpublish telemetrykeepalive timeoutreconnectoffline cacheMQTT 的核心不是“能 publish”，而是要把在线状态处理完整：
网络已连接MQTT connect 成功订阅 command topic 成功keepalive 正常收到服务器 ack异常断开后能恢复订阅常见异常：
MQTT 鉴权失败keepalive timeout服务器踢下线topic 配置错误QoS ack 超时离线期间 telemetry 堆积恢复策略：
keepalive timeout：优先重建 MQTT / TCP。鉴权失败：不要无限重试，进入配置错误状态。publish 失败：关键数据进入离线缓存。订阅失败：重连后重新 subscribe。长期失败：指数退避，避免频繁打服务器。面试表达：
MQTT 很适合 IoT，但设备不能只实现 publish。更关键的是 keepalive、订阅恢复、离线缓存、QoS ack、鉴权错误处理和重连退避。
HTTP 适合：
设备注册配置拉取固件升级一次性数据上传诊断文件上传不适合高频低延迟双向控制，除非产品本身很简单。
HTTP 常见异常：
DNS 失败TCP connect timeoutTLS 握手失败HTTP 401 / 403 鉴权失败HTTP 5xx 服务端异常上传大文件中途断开设备侧要区分：
401 / 403：通常是 token、证书、权限问题。5xx：通常是服务器问题，应该退避重试。timeout：可能是网络弱、DNS、TCP 或服务器慢。HTTP 更适合“请求-响应”业务，不适合一直在线的实时控制。
WebSocket
Section titled “WebSocket”WebSocket 适合：
长连接双向实时通信音频流控制消息实时状态同步它比普通 HTTP 更像持续在线通道，但也更依赖连接状态、心跳和断线恢复。
WebSocket 常见设计点：
text frame：JSON 控制消息binary frame：音频、图片、二进制数据ping / pong：心跳保活reconnect：断线重连session resume：业务状态恢复backpressure：下游处理不过来时不能无限读写如果 Wi-Fi 模组内置 WebSocket 能力，主控要关注：
模组是否支持 text / binary frame 区分最大 frame 长度发送队列是否会阻塞接收数据如何从 UART/SPI 输出给主控心跳超时如何通知主控断线后是否需要重新建 TLS面试表达：
WebSocket 适合双向实时业务，比如音频流和控制消息。但它对连接状态、心跳、缓冲和背压要求更高。设备侧不能只管 send，还要考虑接收是否及时、下游队列满时如何处理，以及断线后如何恢复 session。
不同层失败如何恢复
Section titled “不同层失败如何恢复”建议记住这个恢复顺序：
业务协议失败-> 重建 MQTT / HTTP / WebSocket-> 重建 TCP / TLS-> 重新 DNS / DHCP-> 重新连接 Wi-Fi AP-> 重启 Wi-Fi 模组-> 整机重启不要所有问题都直接重启模组。
不同失败的处理方式：
MQTT keepalive timeout：先重建 MQTT / TCP。HTTP 401 / 403：检查 token、证书、权限，不要无限重试。DNS 失败：先重试 DNS 或切备用域名。DHCP 失败：重新 DHCP 或重连 AP。Wi-Fi disconnect：根据 reason、RSSI、channel 判断。UART overflow：优先检查主控接收、流控和 AT parser。这样回答会比“断线就重连”更像实际产品开发。
面试 30 秒总结
Section titled “面试 30 秒总结”模组写内置 TCP/IP，说明主控 MCU 不一定要自己跑完整网络协议栈。主控可以通过 UART/SPI 控制模组完成 DHCP、DNS、TCP/UDP、TLS、MQTT/HTTP/WebSocket。开发时我会把 Wi-Fi 接入、IP 就绪、DNS、TCP/TLS 连接和业务在线分成不同状态，并按失败层级做恢复：业务协议失败先重建协议连接，TCP/TLS 失败再重建 socket，DNS/DHCP 失败再处理 IP 网络，最后才考虑重连 AP 或重启模组。同时要记录 RSSI、错误码、重连次数、keepalive timeout 和离线缓存状态，方便现场定位。