Web对讲与广播系统实战：WebSocket与WebRTC选型及Spring Boot集成

Web对讲／广播功能听起来不复杂，但真做起来容易踩坑。这个功能最常见的落地场景不外乎三种：楼宇对讲、园区广播、车间调度。更具体一点，就是在巡逻亭、中控室或值班大屏上，值班员既能对着麦克风喊话，让所有终端立即播报，也能跟某个终端单独双向通话。技术圈里问得最多的是“Web端能不能做实时语音”“要不要上WebRTC”“Spring Boot集成WebSocket怎么配”。

这篇文章把我实际改造一套中控对讲系统的完整过程整理出来，涵盖方案选型、前端麦克风采集、后端WebSocket转发、ESP32作为内嵌网页的广播终端，以及联调中遇到的坑。适合正在做Web实时语音相关功能、但不确定到底选WebSocket还是WebRTC的同学参考。

1. 先想清楚：对讲和广播到底有什么不一样

很多人把对讲和广播混在一起做，最后做出来四不像。这两个模式本质上对实时性和交互方向的要求完全不同，技术方案也跟着有差异。

1.1 两种模式的需求本质

广播是单向的：一个说话人，N个接收终端。要求是“发声终端尽量多、延迟可容忍一点、恢复要及时”。比如值班室喊一句“各班注意，现在开始交接”，远端摄像头支架上的音箱喇叭必须能响，但迟个两三百毫秒大家也感觉不到。对讲则是双向的：A说话B听，B插话A听，要求的是“往返延迟低、无回声、不撕裂”。

从这个区别能推出一大堆设计决策：广播可以接受1到2秒的缓冲，对讲必须把端到端延迟压在300毫秒以内；广播只要一台上行、其余下行，对讲必须维护一套完整的会话状态；广播断线可以重连后从头播，对讲断线直接导致沟通失败。

所以在做整体设计前，我们必须先把产品需求问清楚：是要做单向喊话，还是要做双向呼叫，还是两个都要？这两个都有的系统，在代码层面可以共用很多模块，但业务逻辑一定要分开写，否则后期排查问题会非常痛苦。

1.2 技术路线怎么选：WebSocket还是WebRTC

这是整个项目里最核心的一个决策点。

WebSocket方案是把麦克风采到的音频数据编码后，用二进制帧不断推给服务器，服务端再广播给其他连接。这个方案的好处是架构简单，一台Spring Boot服务就能完成信令和数据转发，Nginx接入、负载均衡都是现成一套。缺点是音频缓冲、丢包重传、回声消除全部要自己实现，对前端AudioContext体系不熟的同学容易卡住。

WebRTC方案则是浏览器天生支持的实时音视频引擎，RTCPeerConnection负责P2P连接，内部原生实现了前向纠错、抖动缓冲、回声消除（AEC）、降噪（NS）、自动增益（AGC）。对讲场景选WebRTC几乎是想都不用想的，省太多事。但WebRTC的代价是服务器端要处理SFU（比如MediaSoup、LiveKit）或者至少自己维护PeerConnection的协商信令，部署复杂度高一个量级。

还有一个混合方案，也是我最终采用的：信令和实时对讲走WebRTC，单向广播走WebSocket。理由很简单，广播本来就不需要低延迟交互，WebSocket在服务器实现广播拓扑时分外顺手，代码量小，折腾起来快。而双向对讲采用WebRTC，服务质量交给浏览器底层，我只负责写好房间管理信令。

如果你是一个人维护整个系统、且场景以单向广播为主，那就别犹豫，直接WebSocket方案。如果场景是客户两手抓、而且对音质和回声有硬性要求，那就必须上WebRTC，别想着用WebSocket硬扛双向对讲，后面改起来很痛苦。

1.3 我采用的总体架构

最终落地的架构是三层：

浏览器终端（中控大屏、巡逻手机）通过HTTPS页面打开，获取麦克风权限。双向对讲时，浏览器互相建立WebRTC连接，信令走WebSocket。单向广播时，广播人把音频通过WebSocket二进制帧推到服务端，服务端按“房间”把音频分发给所有在该房间内的WebSocket连接；连接分为浏览器监听端和ESP32设备端。

这里的关键点是“房间”和“设备类型”两个维度。房间用于隔离不同区域的广播，设备类型用于区分浏览器端和嵌入式端，因为浏览器端可以播放WebSocket推过来的音频流，而ESP32收到数据后要走I2S输出到功放。两端的代码处理方式完全不同。

我最初的架构没有做设备类型区分，结果ESP32和浏览器共用一种音频编码格式，稍微一调就发现ESP32的编解码能力跟不上，最后才拆开。所以设计阶段就要把终端形态问清楚，这个决定后面能省掉至少一周的改造时间。

2. 前端实时语音采集：从浏览器抠出麦克风数据

2.1 采集音频流并处理权限和上下文

浏览器端要拿到麦克风数据，离不开navigator.mediaDevices.getUserMedia({ audio: true })。这个接口有三个前置条件：页面必须处于安全上下文（HTTPS或localhost）、必须由用户点击等手势触发、用户必须允许麦克风权限。

我们有一次把系统部署在内网IP上用HTTP访问，结果麦克风权限直接拿不到，控制台报错信息也不够直观。后来在Nginx层做了HTTPS终结，并给证书配了IP SAN，问题才解决。如果你只是内网测试，最简单的办法是访问http://localhost而不是内网IP，浏览器对localhost有特殊豁免。

拿到stream之后，需要选择一个采样率。Web Audio的AudioContext有sampleRate属性，通常默认是48000或44100。这里建议统一在服务端约定使用48000，因为Opus编码器对48K采样率支持最好，WebRTC底层用的音频也是48K。如果你的AudioContext采样率跟约定不一样，别慌，可以在代码里通过AudioContext的resample参数吗？其实做不到，实际做法是让后端或编码层做重采样，或者干脆使用浏览器自带的MediaRecorder来输出固定格式。

前端采集时的权限交互也是个细节。如果页面一打开就立刻请求麦克风，很多浏览器会直接拒绝或“静默失败”，因为用户还没有明确的交互意图。最好是用户点击“开始广播”按钮时再调用getUserMedia，同时把按钮状态的变更绑定到stream的onended事件上，否则用户在中控屏上误点了浏览器右上角的摄像头图标，应用层根本察觉不到，广播就“哑了”。

2.2 编码与分包：把音频数据送上WebSocket

这里有两种主流做法。

第一种，用MediaRecorder录制音频流，它会自动编码成WebM/Opus或者WebM/PCM，然后我们通过dataavailable事件拿到Blob，转成ArrayBuffer后走WebSocket发送。优点是代码量很少，兼容性好，chrome和edge都非常稳定；缺点是控制粒度笨。延迟控制很差，一段录音可能要几百毫秒才给一个chunk，而且它在Broadcast场景下容易产生持续延迟累积。

第二种，用AudioWorklet或ScriptProcessorNode在音频渲染线程里直接读PCM帧，然后自己封装成自定义二进制协议走WebSocket。这条路延迟能压得很低，但需要自己处理分片、粘包、采样率转换，如果在嵌入式终端上还要考虑对齐。我的广播模块最终是折中处理的：取AudioContext.createMediaStreamSource，用ScriptProcessorNode以4096个采样点为一片（约85ms），把PCM的Float32Array转成Int16Array的字节流发送。这样一个数据包大概8KB，延迟基本听不太出来。

一定要提防ScriptProcessorNode的onaudioprocess回调，它不保证实时性，在负载高的时候可能产生明显延迟抖动。为此我在发送端做了一个队列，一旦队列积压超过阈值就丢弃旧包、只发最新的。广播场景丢几个包无所谓，但堆积造成越来越慢就必须避免。

接收端则是反过来。收到WebSocket二进制消息后，不能直接扔给AudioContext播放。因为音频帧到达间隔是不均匀的，需要做抖动缓冲。我在接收端维护了一个数组队列，缓冲区达到200毫秒时才开始播放，播放时以AudioContext的时钟为准逐帧读出数据。这200毫秒的缓冲在纯广播场景下是完美的折中：既能平滑网络抖动，又不会让听众觉得“声音拖了半拍”。

2.3 接收端播放缓冲与回声消除

单向广播不需要AEC。但双向对讲场景里，如果扬声器和麦克风距离很近，扬声器播放的声音会被麦克风再次采进去，对方就能听到自己的回声。我们有一次在值班室测试对讲时，中控台音箱距离麦克风不到一米，效果非常糟糕，声音像在井里说话一样。

我试过几个思路。最省钱的办法是“让用户戴耳机”，但值班员根本不可能配合。其次是用WebRTC的getUserMedia自带的回声消除，但这里有个误区，getUserMedia里提供的echoCancellation约束只对系统音频管线有效，当我们用Web Audio方式自己处理PCM时，processed stream不一定自动带AEC。所以更可靠的做法是：对讲模块整体走WebRTC，通过RTCPeerConnection建立连接，音轨直接通过track发送，让浏览器内置AEC做了它该做的事。

如果通信用的是自己推的WebSocket PCM方案，那就要在代码里想办法引入AEC处理模块，比如WebRTC AudioProcessing模块，把它编译成WASM再喂给音频帧。这是一条很难走的路，我强烈建议不要在生产环境尝试。被回声折磨过的同学一定明白：WebSocket能干广播的活，对讲就交给WebRTC吧。

2.4 浏览器自动播放策略这个坑

在所有前端“坑”里，自动播放策略是我觉得最隐蔽的。浏览器为了防骚扰，禁止网页在没有任何用户手势的情况下自动播放带声音的媒体。但在广播场景下，用户的需求恰恰是：“只要我收到服务端的广播通知，就要立刻播放声音，即使值班员没在键盘前。”

如果你在页面加载后直接调用audio.play()，结果往往是拒绝，控制台报NotAllowedError。解决方法是提前“解锁”音频上下文：在用户第一次点击页面任意位置时，就创建一个AudioContext并立即suspend，同时播放一段长度为一帧的静音数据。这样浏览器视为“用户已经交互过”，之后再通过系统指令触发的播放就不会被拦截。

我自己的做法是在页面上放一个巨大的“启动值班终端”按钮，值班员进入页面就必须点它，点了之后系统把扬声器加入白名单（即创建一段静音缓冲并播放成功），随后所有广播、对讲呼入都走这段已经解锁的AudioContext来播放。这套方案在Chrome和基于Chromium的Edge上实测都稳定，Firefox也兼容，但在一些国产浏览器上偶发失灵，建议测试时重点关照。如果系统里有挂壁式触摸屏终端，务必用Chromium内核的浏览器或套壳。

3. 服务端与接入层：Spring Boot WebSocket如何承载广播

3.1 WebSocket端点设计与yml配置

服务端我选的是Spring Boot，因为项目本来就在Java技术栈，集成WebSocket的成本最低。核心依赖是spring-boot-starter-websocket，只需在配置类上添加@EnableWebSocket，然后注册一个WebSocketHandler。

yml里通常不需要太多配置，但要注意几个参数：server.port不用多解释；spring.websocket没有原生的连接数上限配置，连接限制基本靠Servlet容器；如果是内嵌Tomcat，需要调大server.tomcat.max-connections，默认8192。在一套几十个终端的广播系统里这个数够用了，但如果在生产环境跑大量并发对讲，要留意线程池配置。

server: port: 8443 tomcat: max-connections: 20000 threads: max: 200

这里有个容易被忽略的点：如果使用HTTPS，WebSocket就该是wss协议。常规做法是在Nginx挂证书并代理升级头，Spring Boot后端只监听ws。Nginx配置片段大概是：

location /ws/ { proxy_pass http://internal-server:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 3600s; }

注意proxy_read_timeout必须比浏览器心跳间隔长，否则Nginx会因空闲超时直接断开长连接。我第一次测的时候设了60秒，浏览器里看连接正常，可每隔一分钟就掉线一次，排查半天才反应过来是Nginx在“热心”地关连接。

3.2 转发、房间与鉴权

WebSocketHandler的核心实现可以拆成三块逻辑：afterConnectionEstablished做鉴权与入房、handleBinaryMessage做音频数据转发、handleTextMessage做信令控制。

鉴权很重要。WebSocket连接建立时没法在URL上带Token，因为日志会记录URL，Token泄露风险很大。我是用Stomp风格的CONNECT帧，在第一条文本消息里携带token和roomId，服务端解析后绑定到Session上，然后才允许后续二进制帧转发。如果没有收到合法的CONNECT，服务端在5秒后主动关闭这条连接。

音频转发的代码不复杂，核心就是一个连接管理器，维护ConcurrentHashMap<String, CopyOnWriteArrayList<WebSocketSession>>，按房间号分组存放。收到二进制消息后，先确认是哪个房间，再遍历该房间其他连接并发送。这里必须用session.isOpen()判断一下，否则发消息给一个已经半关闭的连接会抛异常。

同时我加了“广播优先级”的概念，比如应急广播可以抢占普通广播：当高优先级广播开始时，服务端会向所有低优先级广播的发送端推送一条forced_stop文本消息，让它们彻底停发，避免两个声源叠加。

3.3 ESP32内嵌网页作为广播接收终端

很多广播终端不是浏览器，而是小硬件。我们现场有一批ESP32的挂墙喇叭，原本是走MQTT接收指令然后播本地音频文件的，但新的需求是希望它也能实时接收中控台喊话广播。此时ESP32内置一个小型Web服务器，把这个接收逻辑做成了一个“内嵌Web网页”形态的配置页。

ESP32端用Arduino框架跑WebServer和WebSocket Client，连接同一个Spring Boot服务。服务端WebSocket地址需要配置到ESP32的固件里，它没有浏览器UI，但可以通过SPIFFS存一个JSON配置，再用网页方式修改。

音频通道上，ESP32收到二进制的Int16 PCM帧后，经过简单的音量转换，通过I2S接口发送给外接功放模块。整个流程不搞复杂算法，因为ESP32的算力有限，直接做线性PCM输出。要注意的是，ESP32的WiFi可能不稳定，必须加上主动重连逻辑。我们在固件里实现了固定5秒重试一次，同时服务端也要容忍连接频繁掉线重连，定期清理死连接。

这个方案真正工作起来后，广播的实时性出乎意料地好，声音几乎感受不到延迟。因为局域网内网络质量稳定，WebSocket推PCM帧的开销并不大。缺点是一旦跨公网，或者WiFi信号差，就会明显卡顿，所以给ESP32的广播终端接有线以太网（用ESP32-Ethernet）反而是最稳的扩展项。

3.4 广播消息的可靠性与弱网优化

WebSocket本身没有应用层的确认机制。对广播来说，最怕的是“A说话，B只听到一半，然后连接断了，重新连接后继续播但上下文丢了”。我们的思路是：不追求可靠重传，而是追求“连着播不中断”。做法是每个音频包自带一个序号（sequence number），接收端通过序号判断是不是连续帧，如果出现跳号，就直接清空缓冲，重新等待下一段连续包。不做缺失补传，因为广播场景下补传旧的音频没有意义。

具体序列号字段放在二进制帧的前4字节，后面是音频数据。前端解析时先读序列号，如果发现帧序号出现跳变，就触发缓冲重建。这比在SIP等传统对讲协议里做RTP序号判断要直观得多。

更进一步的弱网优化，是发送端的动态码率调整。浏览器采集的PCM是固定的48K/16bit，在不被察觉的前提下，可以在服务端按需转码成低码率的Opus编码。但实操中我发现直接在服务端转码太耗CPU，改成在发送端浏览器做选择：当检测到网络往返延时超过阈值时，音频帧降采样到16K/16bit，字节数变为原来的三分之一。虽然保真度下降，但至少广播还能打通。

4. 联调与排障实录：我踩过的那些坑

4.1 常见问题速查表

这里整理出我在项目联调时遇到的高频问题以及排查方向，直接照着对照能少走很多弯路。

4.2 排查延迟的逐跳分析法

做实时语音最重要的指标就是延迟。当用户反馈“声音太慢”时，我一般按四个环节逐一测时间：采集时间、网络传输时间、服务端转发时间、播放端缓冲时间。

采集时间可以通过控制台打印ScriptProcessorNode回调间隔来粗略估算；网络传输时间在浏览器Network面板里没法直接看WebSocket的帧耗时，我是在发送和接收两侧分别打时间戳，通过服务端记录差值来估算；服务端转发时间通常是微秒级的，不是瓶颈；播放端缓冲时间其实是最大的延迟来源，缓冲越长越稳，但听觉延迟也越大，需要权衡。

实测广播系统在局域网内，采集85ms、网络2ms、转发1ms、缓冲200ms，总延迟约290ms，主观感觉是“基本同步”。一旦把缓冲降到80ms，声音明显变“脆”，偶发卡顿也更能察觉。我的最终策略是按终端能力可配置缓冲时间：浏览器终端默认200ms，ESP32默认300ms，因为前者解码能力强、后者受限于WiFi稳定性。

4.3 从广播到对讲的降级方案

在实际运行中我们还发现一套有意思的降级策略。当某个终端处于弱网环境，WebRTC对讲建立不起来时，系统自动切换到WebSocket广播式“半双工对讲”。说白了就是一方说话时，音频通过WebSocket广播给另一方；另一方回应时，也走同样通道。因为WebSocket总带宽有限，半双工模式在同一时刻只有一个人说话，信号质量自然就上来了。

这个功能听起来简单，但实现时要注意发送端尽量避免同时有两路声音上行。我在服务端做了发言权管理：一个房间同一时刻只允许一个终端处于“讲话中”状态，其他终端如果想插话，需要先申请发言权，服务端把发言权抢过来，同时给当前讲话者推送一个静音指令。这就是半双工对讲协议的简化版，代码量不大但体验提升很明显。

有一次客户现场出现一种神奇的问题：两个终端同时广播，声音互相撕扯。后来排查发现是终端的WebSocket重连机制导致两个旧session没被正常关闭。我加了session里存deviceId，重连时强制踢掉旧连接，这个问题就彻底消失了。如果你也用了自动重连，请务必在Server端做deviceId幂等处理，不然同一个终端会残留大量僵尸连接。

末尾再分享一点个人体会

做Web对讲和广播，最容易栽跟头的地方其实不是协议本身，而是对“实时”的理解。广播系统允许缓冲、允许丢包，但绝不能允许声音“断断续续”；对讲系统则相反，哪怕是几百毫秒的延迟都会让人烦躁。搞懂自己的场景，选对传输通道，比把代码写得花哨重要得多。

如果你现在正准备做一个新项目，我给的建议是：先花点时间把产品经理和现场使用的人拉在一起，确认到底只需要单向广播，还是一定要有双向对讲。单向广播用Spring Boot加WebSocket就够了，简单到一个人两天能跑通；双向对讲就老老实实引入WebRTC，别自己去造音频轮子。ESP32做内嵌网页的终端是个好点子，前提是必须在局域网里用，或者做好足够健壮的断线重连和缓冲策略。这个项目的后续扩展空间还很大，比如给广播加上定时任务、把对讲录音存下来做事件回溯、用AI做语音告警辨识，都是很好的延伸方向，但核心的那套选型逻辑，我劝你一定要提前想明白。