先在开篇说一句做过流式 TTS 服务的人大概率都被同一个问题问过——SSE 也能一段一段推数据为什么生产环境里大家最后还是选了 WebSocket而不是更轻量的 SSE答案是流式 TTS 对传输通道有三个绕不开的硬约束二进制帧、签名鉴权、双向控制。这三件事凑在一起SSE 的结构性短板就暴露得很明显。这篇文章我把当年的选型过程、代码骨架、以及后来在线上踩过的坑一起整理出来适合正在做语音合成服务的后端也适合对接 TTS 的前端同学。1. 流式 TTS 对传输通道的三个硬性要求1.1 需求一低延迟、按帧可达的二进制音频先对齐一个基本概念流式 TTS 不是“服务端合成完整个音频文件再一次性返回”而是模型一边推理音频一边被切分成小块下发。客户端拿到第一小块音频就可以开始播放而不是等整段文本全部合成结束。对用户来说感知差异非常明显。一段 30 字的话非流式方案可能需要 1.5 秒以上才能听到声音流式方案可以把首字出声压缩到 300 毫秒左右。这个体验差别在长文本、客服播报、视频配音这类场景里尤其致命。但流式也带来一个前提传输通道必须能承载二进制音频数据。TTS 引擎输出的音频编码通常是 PCM、Opus、MP3 这类字节流不是 UTF-8 文本。二进制数据对通道的要求是能准确表达帧边界不能被文本解析器“吃掉”特殊字符也不能因为编码转换导致字节内容被改写。我最早做某个客服机器人的语音播报时第一版用的是 SSE把 PCM 音频块做 Base64 编码后放进事件流本地测试一切正常到了线上用户量一起来延迟和流量双双变差。后来才意识到用文本通道传二进制本质上是在给传输层“加刑”。1.2 需求二随时可打断、可调整的双向控制流式合成不是“发一次文本就躺平等结果”的模型。用户在播放过程中随时可能触发新的动作比如取消当前合成立刻静音暂停播放等一会儿再继续换一个发音人下一句开始用新音色调语速、调音量这些动作有一个共同特点它们必须作用于一条正在进行的、活跃的音频流上而且越及时越好。如果用户点了暂停结果音频帧还在哗哗往下推那这个“暂停”就是假的。问题在于SSE 天生是单向的。服务端可以推给客户端但客户端不能在同一条连接上把控制指令回传给服务端。你只能额外再发一个 HTTP 请求去“打断”这就牵扯到两条连接之间的顺序、归属和一致性问题。后面我会专门讲双向控制这里先记住结论一个真正好用的流式 TTS 通道必须让音频流和控制指令在同一管道里有序流动。1.3 需求三连接级和任务级的双重鉴权实时长连接比普通 HTTP 请求更容易被滥用。一方面连接保持时间长另一方面它承载的是持续的数据流。如果只在建立连接时校验一次身份之后这条连接被谁复用、被用来做什么服务端完全没有感知。流式 TTS 里常见的做法要拆成两层连接级鉴权客户端能不能建立 WebSocket 连接靠握手阶段的签名和 Token 决定任务级鉴权连接建立后每发起一次合成任务都要带上任务 ID、时间戳、签名服务端在业务入口再验一次这两层缺一不可。只有连接级鉴权的话一旦连接被中间层复用或者客户端被攻击者拿到长连接句柄整条链路都会暴露。只有任务级鉴权而连接层不设防也不行服务端会浪费大量资源去握手和拒绝无效连接。2. WebSocket 与 SSE协议层面的真实差异2.1 SSE 不是没用而是方向不对SSE 全称 Server-Sent Events它本质上是“一个挂在 HTTP 上的长响应”。浏览器通过 EventSource 发起请求服务端返回Content-Type: text/event-stream然后不断往响应体里写事件。协议规定了事件格式以data:开头空行分隔事件可以直接通过id:做断点续传。这套设计对“服务端单方向推送文本通知”非常合适比如股票行情、系统告警、消息中心提醒。但注意两个词单方向、文本。单方向意味着客户端无法在同一条连接里发送语义化的控制消息。文本意味着所有 payload 都必须能被 UTF-8 解析。这两个限制单独看都不致命可一旦合成到流式 TTS 的需求里就成了结构性矛盾。另外SSE 的标准实践里浏览器 EventSource 只能通过 GET 请求建立连接不允许自定义 Header。你想在握手时带一个复杂的签名头对不起标准 API 做不到。通常得把 Token 塞进 query string或者干脆自己用 fetch 模拟一个流式的读取通道但那已经不算标准的 SSE 了。2.2 WebSocket 等于一条带边界语义的双向字节管道WebSocket 的握手阶段同样基于 HTTP但通过Upgrade: websocket请求头把协议切换到独立的 TCP 长连接上。切换完成后连接上传输的不再是 HTTP 报文而是 WebSocket 帧。每一个 WebSocket 帧有四类核心信息FIN 标记、opcode、payload length、payload data。其中 opcode 决定了帧类型比如0x1是文本帧0x2是二进制帧。这个设计对 TTS 的好处是直接的文本帧可以用来传 JSON 控制指令二进制帧可以直接放 Opus/PCM 音频字节每个帧自带长度和边界不会出现“接收方不知道当前这块数据在哪结束”的问题全双工通道允许客户端随时往服务端写指令服务端也能同时往客户端推音频用一个不太严谨但好懂的比喻SSE 是一条“只能从山上往下传纸条的溜索”WebSocket 是一条“双向通行的管道车”纸条和货物都能运还自带箱子标签。2.3 关键能力对照表对比维度SSEWebSocket数据方向服务端到客户端单向双向全双工数据格式文本UTF-8文本帧 二进制帧二进制音频需要 Base64 编码字节直传同连接内控制指令不支持支持帧边界事件级自行设计协议级自带握手鉴权Header 受限常见放 queryHeader / query / subprotocol 均可断线重连浏览器自带自动重连需自行实现心跳重连复杂度低中高结论很直白SSE 的优点是简单特别适合“单向文本通知”业务。流式 TTS 要的是“双向、二进制、可控”这三点恰好都是 WebSocket 的舒适区。3. 二进制帧音频数据为什么不能靠 Base64 凑合3.1 Base64 的 33% 体积膨胀不是小数目Base64 的编码规则大家都清楚把每 3 字节原始二进制转成 4 个字节的 ASCII 字符。数学上就是 4/3也就是体积膨胀 33.3%。放在 TTS 场景里这个膨胀会直接变成带宽成本和播放延迟。举个例子一段 8kbps 的音频流如果走 Base64实际网络传输量会变成约 10.7kbps。遇到高码率场景更夸张比如 CD 音质无损 PCM1411kbpsBase64 之后接近 1.9Mbps对移动网络非常不友好。你可能觉得“现在网络都快多传 33% 无所谓”。但流式 TTS 通常不是单路连接服务端可能同时开着几千路合成流每路都多 33%整体的带宽预算、网关流量费用、机房出口成本都会明显上涨。流量费用在中大型语音平台上不是小数能省一点是一点。3.2 编解码开销会摊到每一帧身上Base64 的代价不只是体积。服务端每生成一个音频块要先encode成 Base64 文本客户端收到后再decode回二进制。一来一回每一帧都有 CPU 开销。在低码率、低并发下这个开销可以忽略。但流式 TTS 的特点就是高频次、小数据块。如果每 20 毫秒一个音频块一秒至少 50 次编码客户端同一时间也在 50 次解码。放大到几千路并发这部分 CPU 时间就变得很可观。另外Base64 文本混在 SSE 事件里还会带来额外的解析成本。客户端要先把事件按行拆开再处理data:前缀然后再解 Base64最后才得到二进制。三步操作一步都省不掉。而 WebSocket 二进制帧到了客户端只要判断opcode直接取出 ArrayBuffer 交给播放器或者解码器路径短得多。3.3 帧边界问题为什么 WebSocket 的 message 边界值钱TCP 本身是字节流没有消息边界。音频数据如果直接裸裸地写在 TCP 上接收方根本不知道哪一段是一个完整的音频帧。SSE 实际上也有这个问题它的事件边界靠换行符和空行来标记一旦音频二进制经过编码后恰好产生了特殊字符解析就容易出幺蛾子。WebSocket 在协议层解决了边界问题。每个帧头携带 payload length接收方知道这一帧从哪个字节开始、到哪个字节结束不需要额外设计分隔符也不需要自己维护“缓冲攒包”的逻辑。这不是一个“省事”级别的差异而是直接关系音频数据完整性。音频流一旦错位播放出来的就是爆音或者乱码这种问题在真机上极其难排查。用开发经验来说如果你发现自己写 SSE 传二进制时还需要自己定义LENGTH_PREFIX JSON BASE64_DATA这种复合格式那说明你正在用错误协议解决本来不属于它的问题。4. 签名鉴权从握手到任务级的完整链路4.1 连接级鉴权握手请求里的凭证怎么放WebSocket 的握手请求是一个标准的 HTTP GET里面可以带 Header也可以带 query 参数还可以通过子协议字段做额外协商。常见的鉴权放法有三种URL query 里带token和expire例如wss://api.example.com/tts?tokenxxxexpire1700000000Header 里带Authorization: Bearer xxx适合非浏览器环境通过 WebSocket subprotocol 字段传递认证凭据这里有个坑必须提醒浏览器原生 WebSocket API 不允许你自定义 Header。你在前端new WebSocket(url)时Header 是浏览器自己生成的没法塞一个Authorization进去。所以浏览器场景下最常见的就是把短期 Token 放在 query 里或者利用 subprotocol 传一个简单的协议名加 Token。服务端拿到 query 参数后解析出 Token校验签名和有效期再决定接受还是拒绝握手。连接建立后客户端还会周期性发送心跳心跳消息可以顺带带上一个轻量级的 token 快照方便服务端判断连接是否仍然属于同一个授权主体。4.2 任务级鉴权一条合成指令也要验签连接级鉴权解决的是“谁能建立连接”但流式 TTS 里一条长连接上通常会跑多个任务。最简单的情况用户先合成一段新闻接着再合成一段天气。这两段文本可能对应不同的权限范围、不同的计费维度。如果只在握手时校验一次后续每一条指令都默认可信那一旦连接被截获或者 Token 泄漏攻击者可以在这条连接上随意发起合成请求。所以我在项目里的做法是每条start指令都要带独立的签名参数。一个典型的 start 消息长这样{ type: start, task_id: 20240914103012001, text: 你好欢迎使用流式语音合成, voice: zh-CN-xiaobei, timestamp: 1726300812, sign: aHqO9sLd... }服务端收到后先查 task_id 是否已存在再看 timestamp 是否在有效窗口内最后用共享密钥对task_id timestamp voice计算 HMAC和消息里的 sign 比对。每一项都合法才开始合成。4.3 防重放、签名算法与常见坑签名鉴权最容易被忽视的是防重放。一个合法签名的消息如果被攻击者截获他可以反复重放这条消息除非服务端能识别“这一条已经用过了”。我的处理方式分两步时间窗口timestamp 和当前时间偏差超过 300 秒直接拒绝一次性任务task_id 唯一已经被消费过的 task_id 再次出现就拒绝签名算法用 HMAC-SHA256 就足够了不需要引入复杂的非对称加密。示例代码import hmac import hashlib import base64 import time def generate_sign(secret: str, task_id: str, timestamp: int) - str: message f{task_id}\n{timestamp}.encode(utf-8) digest hmac.new(secret.encode(utf-8), message, hashlib.sha256).digest() return base64.urlsafe_b64encode(digest).decode(utf-8)实际踩过的坑有几个一是客户端和服务端时间不同步导致签名明明是对的却被误判为过期。二是计算签名之前没有对参数做规范化拼接服务端拼接顺序和客户端不一致签名永远对不上。三是日志系统把 URL query 完整打印出来token 直接写进日志文件这种泄漏防不胜防。鉴权逻辑不管多严谨最后都要过一遍日志脱敏至少不能让 Token、签名和完整 query 出现在明文日志里。5. 双向控制同一条连接为什么比两条路更稳5.1 竞态问题SSE 加 HTTP 控制的失败场景假设你用 SSE 推音频同时用另一个 HTTP POST 接口来控制“暂停”。客户端点了暂停按钮后浏览器发一个POST /tts/pause请求。问题来了这个 POST 请求和 SSE 的连接是两条独立的 TCP 连接。在服务器那儿处理 SSE 连接的进程和处理 POST 请求的进程可能处于不同节点甚至不同机房。当用户点击暂停请求发出去了但这之前已经从 SSE 连接里发出来的音频帧还在网络里“飞”。等 POST 请求到达服务端的时候音频帧队列里面可能还积压着几百毫秒的数据。表现就是用户明明点了暂停声音还在继续播一阵子才停。这种感觉非常差尤其是直播、客服交互这类对实时性敏感的产品。更麻烦的是顺序无法保证。客户端先发暂停语音合成服务端可能晚一步才收到结果又把后续的音频帧推出去。为什么因为两条连接之间没有天然的先后顺序约束。5.2 同连接保证顺序的机制WebSocket 把控制指令和音频数据放在同一条 TCP 连接里天然解决了顺序问题。TCP 是可以保证全双工下的消息有序性的。客户端发出去的控制帧和音频帧在同一连接里按序到达服务端也按序读取。当你发了一个“cancel”指令它排在当前音频帧的后面发送服务端读到的时候就知道这条连接上后续的任务已经被取消了我不应该再把后面的音频发出去。反过来服务端的音频帧和客户端的状态确认也能在同一条连接里得到顺序上的自然约束。不需要额外设计优先级队列不需要全局时钟连接本身就带来了顺序语义。这里我强调一下WebSocket 的“双向”不是简单意义上“客户端能发、服务端能收”而是客户端和服务端可以在同一条连接上交叉发送任意消息而消息顺序在单方向上是严格有序的。这个特性对 TTS 的价值很多人低估了。5.3 信令与状态机的设计实践一个好的流式 TTS 控制协议至少需要下面这些消息类型方向消息类型说明客户端 - 服务端start发起合成任务带文本、音色、语速等参数客户端 - 服务端cancel取消当前合成任务客户端 - 服务端pause / resume暂停 / 恢复播放客户端 - 服务端ping心跳检测连接存活服务端 - 客户端state当前任务状态synthesizing / done / error服务端 - 客户端audio二进制帧音频块服务端 - 客户端text同步文本字幕用于展示服务端 - 客户端pong对心跳的回应任务状态机不需要复杂四个状态基本就够idle - synthesizing - done任意状态遇到异常都进error。cancel可以从synthesizing直接跳到done。定义清楚状态机之后所有消息处理逻辑都围绕状态迁移来做不容易出竞态问题。我做客户端的时候会给每条start消息生成一个递增序号服务端每次返回状态也携带当前序号。序号一旦对上双方都知道当前处理的是哪一次任务排查问题的时候非常省事。6. 实操一套可落地的 WebSocket 流式 TTS 方案6.1 服务端骨架连接建立、任务接收、音频帧推送这里用 Python FastAPI 举一个最基本的例子框架无关逻辑是通的import asyncio import json from fastapi import FastAPI, WebSocket app FastAPI() async def synthesize(text: str): 模拟 TTS 引擎按 20ms 一个音频块产出。 for i in range(10): chunk b\x00\x01\x02\x03 * 100 # 伪音频数据 yield chunk await asyncio.sleep(0.02) app.websocket(/tts) async def websocket_endpoint(ws: WebSocket): await ws.accept() current_task None try: while True: message await ws.receive() if message[type] websocket.disconnect: break data message.get(text) if data is not None: req json.loads(data) if req.get(type) start: # 此处做任务级验签 current_task asyncio.create_task( send_audio(ws, req) ) elif req.get(type) cancel: if current_task: current_task.cancel() current_task None await ws.send_text(json.dumps({type: state, state: done})) elif message.get(bytes) is not None: # 客户端主动发来的二进制数据可以定义为录音或其他上行数据 pass except asyncio.CancelledError: pass async def send_audio(ws: WebSocket, req: dict): async for chunk in synthesize(req.get(text, )): await ws.send_bytes(chunk) await ws.send_text(json.dumps({type: state, state: done}))几个关键点receive()返回的 message 会区分 text 和 bytes服务端可以根据类型路由send_bytes发送的就是二进制帧客户端那边收到的opcode就是0x2cancel 时直接取消合成任务避免多余音频继续下发实际生产里你还要把鉴权、错误处理、并发限制加进去但核心骨架就是这样一个循环收指令、开任务、推音频。6.2 客户端骨架文本帧和二进制帧的区分浏览器端实现非常直接const ws new WebSocket(wss://api.example.com/tts?tokenxxxexpire1700000000); ws.binaryType arraybuffer; ws.onopen () { ws.send(JSON.stringify({ type: start, task_id: task_001, text: 今天天气怎么样, voice: zh-CN-xiaobei, timestamp: Math.floor(Date.now() / 1000), sign: ... })); }; ws.onmessage (event) { if (typeof event.data string) { const msg JSON.parse(event.data); if (msg.type state) { console.log(合成状态, msg.state); } } else { // 二进制帧直接交给播放器解码 const audioData new Uint8Array(event.data); playAudioChunk(audioData); } };注意ws.binaryType arraybuffer这行不设置的话浏览器默认把二进制帧包装成 Blob处理起来多一层异步转换。设置成 arraybuffer 之后所有音频二进制帧直接以 ArrayBuffer 形式进入事件回调播放链路短很多。客户端播放端还要维护一个缓冲队列。网络情况下音频帧到达间隔不是完全均匀的播放器要预读 200 毫秒到 300 毫秒再开始播放用来对抗抖动。缓冲太小会卡顿缓冲太大又会让交互式暂停变得迟钝这个值要根据线上网络质量调。6.3 心跳、重连与任务恢复长连接最大的不稳定因素是网络空闲后被中间设备关闭。常见做法是每 30 秒发送一个 ping 帧服务端回一个 pong 帧进行确认。如果连续三次没有收到 pong客户端主动断开连接走重连流程。重连不能只是简单把 WebSocket 重新打开还要考虑当前正在合成的任务怎么恢复。我的方案是重连后立刻发送一个resume消息带上最近一次收到的音频块序号服务端根据序号重新下发缺失的音频块如果服务端已经释放了任务资源重新走一次 start从文本头开始这个机制看起来简单实际加上“任务序号”和“缓存窗口”才能做到无缝恢复。没有这个设计用户会在网络抖动时听到一句被截断的播报体验非常糟糕。7. 常见问题与排查技巧实录7.1 浏览器 WebSocket 不能自定义 Header鉴权参数怎么带如前面所说浏览器原生 WebSocket 无法自定义 Header所以我见过很多团队在 query 里带完整的 Token。这个做法能用但有风险query 会被网关日志、代理日志完整记录下来。我的建议是分两步走握手 query 里只放短期 token有效期控制在 5 分钟以内控制指令里再带任务级签名。即使日志泄露了短期 token别人也只能在 5 分钟内建立连接拿不到任务级签名的话依然没法发起真正的合成任务。日志脱敏也很重要。检查所有打印请求 URL 的地方把 query 参数替换成掩码或者干脆不打 URL 只打 task_id。7.2 反向代理把连接切断了怎么办很多团队在 WebSocket 服务前面还挂了一层反向代理。默认情况下反向代理对长连接并不友好经常出现“连接 60 秒没数据传输就被切断”的情况。排查时先确认反向代理是否开启了 WebSocket 升级支持需要在 location 里做 connection 相关的特殊处理。常见的配置调整包括提升proxy_read_timeout、proxy_send_timeout到几千秒开启协议升级的转发开关。如果中间还有其他网关类似的参数都要跟着调。有一个更隐蔽的问题反向代理对 WebSocket 的空闲连接也超时。即使没有数据代理层只要看到连接长时间没有任何字节也会按空闲超时掐断。解决方法是客户端和服务端保持心跳确保连接有持续的小流量而不是真的空着。7.3 首字延迟大、播放卡顿怎么调首字延迟大的原因通常不在传输层而在合成服务逻辑。有些系统为了降低实现复杂度会把多个音频块攒成一个大帧再发送比如等积累了 500 毫秒的音频才推一次。这样做确实减少了网络包数量但首字延迟也会被顶到 500 毫秒以上。我实测下来的经验是第一个音频块只要引擎一旦产出就立刻推送后续块可以按 20-40 毫秒一个包平稳输出。客户端那边预留 200-300 毫秒的缓冲窗口不要把所有块都直接灌进播放器。这样可以做到“首字快、后续稳”。如果播放卡顿先看丢包重传情况而不是直接改缓冲。网络抖动严重的场景优先调小音频块的包体例如从 40ms 一个包改成 20ms轻微丢包时对听感的影响会小很多。注意这里的前提是客户端解码器能接受更小粒度输入PCM 没问题Opus 大多数情况也没问题。7.4 签名总校验失败问题出在哪签名校验失败90% 是三个原因时间戳不一致。客户端和服务端系统时间差超过窗口需要先检查服务端返回的time字段让客户端按服务端时间校准。签名原文的拼接顺序不一致。两端约定好的拼法task_id \n timestamp服务端验签时也必须用同样的顺序和分隔符多一个空格都不行。参数在 URL 传递过程中被重新编码。比如文本里包含中文和特殊符号如果encodeURIComponent的规则两边不一致签名算出来天然对不上。排查这类问题最有效的办法是先加一条临时日志把服务端实际收到的 task_id、timestamp、sign 以及本地重新计算的 sign 全部打出来并排对比。看到底是原始参数被改动还是算法本身不一致一目了然。我做语音合成的固化流程是先在本地构造一条固定文本用固定的 secret 算出一条固定签名作为测试用例写进自动化测试。任何一次代码变更如果连这条用例都验不过那就说明签名链路往哪一步改了但没人知道。一点个人体会这几年接到实时语音相关的活儿我都会先逼自己把需求清单写清楚而不是看到某个协议看起来很灵活就直接套进项目。SSE 用在不同步通知、监控大屏、消息推送里确实很顺手但流式 TTS 的核心矛盾是双工控制、二进制数据、连接复用和任务级安全这几件事叠加在一起WebSocket 几乎就是唯一能完整兜住的选择。如果现在让我给一个最小可行方案我依然会选 WebSocket 作为传输主通道文本帧走控制、二进制帧走音频、握手和任务双重视验签、心跳加断点恢复兜底。这套组合我已经在几个项目里反复验证过稳定性和体验都说得过去。你要是正在做类似服务直接照着这个骨架搭大概率不会踩到协议层面的大坑。