小智怎么把语音送上云：WebSocket 与 MQTT+UDP 两种传输方案

上一节把音频 I/O 打通了：麦克风采的声音变成一串 PCM 字节，喇叭也能把字节还原成声音。现在盒子有了"耳朵和嘴"，可它还是个聋子对着墙自言自语——采到的音频哪儿也去不了，云端的回答也回不来。这一节来搭那条把声音送上云、再把回答接回来的"神经"：小智的联网层。

这条神经不是随便拉根网线的事。它得扛住一个拧巴的要求：一边把你正在说的话一小段一小段往上推，一边可能已经在往下收云端合成的回答——上行下行同时跑还得快，慢半拍你就觉得它"反应迟钝"。小智给了两套答案，正好对应你在 L3 学过的两条路：一条全押 WebSocket，一条把 MQTT 和 UDP 拆开用。这一节把两套方案的取舍讲透——讲的是通信架构怎么设计，不是把小智的代码抄一遍。

语音上云到底难在哪

先把需求摆清楚，你才看得懂后面为什么这么设计。语音助手一次对话，数据是这么流的：

你说话 → 设备把音频边采边往上推 → 云端做识别和大模型 → 云端把回答边合成边往下推 → 设备边收边放。

注意两个"边……边……"。它给传输层压了两条硬指标：

• 要全双工：上行的你说话、下行的它回答可能在时间上重叠——你话音刚落，云端已经在往回吐字了。一问一答的 HTTP 做不到，它得等你整段说完、上传、算完、再整段传回，中间是"死"的。
• 要低延迟、能流式：音频是连续字节流，不能攒够一整句再发，得一小段（几十毫秒）一小段推。每小段的额外开销越小越好，开销一大延迟就堆起来，体感就是"卡"。

这两条，就是评判任何一套传输方案的尺子。小智的两套方案，都是冲着满足它们去的——只是满足的路子不同。

方案一：全押 WebSocket

第一套方案最直接：上行音频、下行音频、控制消息，全走一条 WebSocket 长连接。

你在 WebSocket 那节已经把它的本质吃透了：一次 HTTP 握手把连接"升级"成长连接，之后这条管子两头随时能塞帧、谁有话谁就推。这正好精准命中语音的两条硬指标：

• 全双工天然满足——一条连接两个方向同时能推，上行音频帧和下行音频帧在同一根管子里对流，互不打断。
• 流式低延迟也满足——长连接建好后，每一小段音频就是一个 WebSocket 帧推出去，不像 HTTP 每段都要重新握手、带一大坨头。

一个关键设计：那节演示推的是文本帧（HTTPD_WS_TYPE_TEXT），而音频是裸字节流，得用二进制帧（HTTPD_WS_TYPE_BINARY）——文本帧会对内容做 UTF-8 校验，音频字节塞进去会出错。所以小智一条连接跑两种帧：二进制帧走音频流，文本帧走"开始说话""这段说完"这类控制信令（常是一小段 JSON）。

还有个方向差异：那节你写的是 ESP32-S3 当服务器让浏览器连上来；小智是设备去连云端，是客户端角色，用 esp_websocket_client 而不是 esp_http_server。方向反过来，但"握手升级成长连接、之后收发帧"是同一套概念。

这套方案好在哪： 简单。一条连接搞定所有事，握手一次、鉴权一次，代码路径清爽，排障时也只有一根管子要看。对着家用 WiFi、对着大多数云服务，这套够用且好维护——所以它常是默认方案。

它的软肋在哪： WebSocket 跑在 TCP 上，而 TCP "可靠但认死理"。它保证字节不丢、不乱序，代价是：中间某个包一丢，它会卡住等重传成功，后面已经到的包只能排队干等——这叫队头阻塞。传文件这是优点，但对实时音频反而碍事：语音丢掉几十毫秒人耳基本无感，可 TCP 非要停下来补齐，结果后面的音频全被拖延迟。实时场景里"稍微丢一点"往往比"卡一下"体验更好——这就引出了第二套方案。

方案二：控制走 MQTT，音频走 UDP

第二套方案把"控制"和"音频"这两件事拆开走两条路：

• 控制信令走 MQTT：像"开始对话""会话参数""结束了"这类不能丢、但不追求极致实时的消息走 MQTT。它长连接、断线自愈，传这类可靠消息正合适——丢一条"开始对话"整个流程就乱，所以这类消息要的是可靠，不是快那几毫秒。
• 音频流走 UDP：真正的语音字节流走 UDP。

这里得补一个 L3 没细讲的概念：UDP 是什么，为什么音频偏爱它。

TCP 和 UDP 是网络传输的两种基本方式。TCP 像挂号信：每封签收、丢了重寄、严格按顺序，可靠但慢、开销大。UDP 像明信片：写上地址扔进邮筒，不管对方收没收到、也不保证按顺序到——快、开销小，但不可靠。

对实时音频，UDP 那些"缺点"恰恰是优点：

• 容忍丢包：前面说了，语音丢几十毫秒人耳无感。UDP 丢了就丢了、绝不回头重传，于是永远不会因为补一个旧包而卡住后面的新包——没有队头阻塞。实时音频要的就是"过去的就让它过去，别耽误现在正在说的"。
• 开销小、延迟低：UDP 没有 TCP 那套握手、确认、拥塞控制的包袱，一个音频包填上就发，路上少绕好几道弯。
• 实时优先：语音里"这一刻的声音"最值钱，几秒前那个丢掉的包补回来也没意义了——UDP 的"不可靠"正好对上"实时优先、容忍丢包"的需求。

所以这套方案是：可靠的控制信令交给 MQTT、实时的音频流交给 UDP，各取所长。这是很多专业实时音视频系统（不只小智）都用的思路——控制面和数据面分离。

这套方案好在哪： 音频这条最吃实时的路走了最适合它的 UDP，弱网、抖动大的时候，体验往往比全 TCP 的 WebSocket 更稳、更跟得上。

它的代价在哪： 复杂。两条连接要分别建、分别管、分别鉴权；UDP 不可靠，你得自己在应用层操心"包乱序了怎么排、丢多了怎么办"这类 TCP 本来帮你兜住的事。用简单换实时性，还是用复杂换实时性，这就是两套方案最本质的取舍。

连接怎么建、鉴权怎么走

不管哪套方案，设备开机后要真正把这条神经接通，都绕不过一个先后顺序。这里讲通用骨架——具体字段以仓库为准。

1. 先连 WiFi、拿到 IP。 你早就跑通的第一步，wifi_init_sta() 那套。没网后面全免谈——排障第一个要确认的就是日志里有没有"拿到 IP"。
2. 报到换令牌。 设备先向一个固定的配置/认证地址报到，换回本次要用的连接地址和一个令牌（token），相当于一张"临时通行证"。这一步把"设备是谁、有没有权限"验掉，云端才认它。
3. 带令牌建连鉴权。 WebSocket 方案里，令牌通常放进握手那个 HTTP 请求的头（WebSocket 握手本质就是带特殊头的 HTTP GET），验过才回 101 升级成功。MQTT+UDP 方案里，令牌用来连 MQTT broker，UDP 那条通常靠 MQTT 阶段协商出的会话密钥来关联和保护。
4. 通道打开推音频。 上行推你说的话，下行收云端的回答。

一句话记住这条主线：连网 → 报到换令牌 → 带令牌建连鉴权 → 通道打开推音频。鉴权这一步别省——它既是云端认你的凭证，也是别人不能随便冒充你设备、偷你对话的那道锁。

小结 · 下一步

这一节你搞清了小智那条"神经"是怎么设计的：

• 语音上云的两条硬指标：全双工（上行下行同时跑）、低延迟流式（一小段一小段推）。任何传输方案都拿这两条来量。
• 方案一 · 全押 WebSocket：一条长连接，二进制帧走音频、文本帧走控制信令；胜在简单，软肋是 TCP 的队头阻塞——丢一点也要卡住等重传，对实时音频不友好。
• 方案二 · MQTT+UDP 拆分：控制信令走 MQTT（要可靠）、音频流走 UDP（要实时、容忍丢包、没有队头阻塞）；胜在弱网下更跟得上，代价是两条连接、更复杂。
• UDP 为什么适合音频：语音"过去的就让它过去"，UDP 的"不可靠、不重传"正好对上"实时优先、容忍丢包"。
• 连接与鉴权主线：连网 → 报到换令牌 → 带令牌建连鉴权 → 通道打开推音频。

神经接通了，音频能上云、回答能回来。可"回答"是怎么从你的一句话，一路走成大模型生成、再合成成语音的？下一步去 对话链路那节，把"听到 → 识别 → 思考 → 说出"这条完整的链串起来，第一次听到盒子真的答你话，就在那一步。想回看这条链在整个项目里的位置，随时翻项目总览；两套传输方案的底层，扎实补一遍 WebSocket 和 MQTT 这两节 L3。