面试官问：“做一个 AI 客服，答案要逐字出来，用户能随时打断，以后还要加实时语音。通信方案怎么设计？”
你答：“上 WebSocket，一条长连接全搞定。”
面试官把笔放下：“登录、上传头像、查聊天记录也走 WebSocket？下个需求是不是让它顺便煮咖啡？”
这句追问就是题眼：面试官不是让你给四种协议排座次，而是看你会不会 先拆需求。
01 REQUIREMENT —— “实时”不是 WebSocket 的通行证
AI 客服里的“实时”，至少藏着四种完全不同的动作：
- 用户提交一个问题；
- AI 持续输出文字；
- 用户偶尔点一次停止；
- 用户和 AI 低延迟语音通话。
选协议前，你得先问：谁在给谁发？发得有多频繁？传的是文字还是音视频？断线后要不要重连和补发？
这四个问题问完，协议往往自己就站好队了。
02 REQUEST —— HTTP：别嫌它朴素，大部分活还得它干
第一版客服只有一问一答。用户发问题，AI 返回完整结果：
POST /runs 创建任务，GET /runs/{id} 查状态。上传文件、查记录、登录鉴权，也继续走 HTTP。
HTTP 像办事窗口：提交请求、返回结果、结束本次交互。它很适合 有明确业务动作的一问一答。
它成熟、容易监控，鉴权、重试、日志和网关都有现成方案。
还有一个常见误区：HTTP 不是只能憋到最后一次性返回。 响应体完全可以边生成边传输。SSE 也不是 HTTP 的竞争对手，它本来就是 跑在 HTTP 上的一种事件流格式。
把 HTTP 和 SSE 当成二选一并不准确：一个是通信基础，一个是在 HTTP 响应上组织事件的方式。
03 STREAM —— SSE：AI 负责说，你先安静听
第二版要求答案逐字出现。此时大部分数据都是 AI 发给浏览器，用户只负责接收，SSE 正合适。
你可以把它想成一条 单向传送带。AI 每生成一段，就放上一张卡片：text_delta 是文字，tool_status 是工具状态，error 是报错，done 表示“本次唠完”。
SSE 是事件格式；EventSource 和 Fetch 才是浏览器读取它的方式。EventSource 适合 GET 订阅，支持自动重连和 Last-Event-ID；需要 POST、请求体或自定义请求头时，可以用 Fetch 读取并解析 SSE。
SSE 在 HTTP/1.1 上也能用，不是非 HTTP/2 不可。但并发会话多、标签页多，并且部署链路支持 HTTP/2 时，多路复用 能让多条 SSE 流共享连接，少在连接数上打架。
上线后还要防三个坑：代理缓冲 会把逐字输出攒成一坨；空闲连接可能被网关掐掉；断线续传要求服务端保留事件，客户端还要去重。
有时 AI 并没有“思考五秒”，只是 Nginx 在门口攒够一袋字才放行。
04 CANCEL —— 一个停止按钮，还不配拥有整条 WebSocket
第三版增加“停止生成”。
很多人看到“打断”又激动了：这次总该用 WebSocket 了吧？
未必。用户只点一次停止，本质上是一条 低频命令。POST /runs/{id}/cancel 就能完成，而且鉴权、重试和审计都更直接。
更重要的是，关闭 SSE 或终止 Fetch，只表示 前端“不听了”，并不代表 后台“不干了”。模型可能还在生成，工具可能还在查库存，账单也可能还在微笑。
正确做法是：创建任务时返回 run_id；前端停止读取；同时调用取消接口，让 取消信号一路传到模型和工具执行层。
停止接收和停止执行，是两件事。 这句话比“我会 WebSocket”值钱得多。
05 DUPLEX —— WebSocket：双方都话多，再把对讲机发下来
如果 AI 在执行中不断追问，用户又持续修改参数；或者场景是协同编辑、游戏操作、远程设备控制，双方都要频繁主动发消息，WebSocket 才真正舒服。
WebSocket 通常先借 HTTP 完成握手，之后进入 持久的双向消息通道。两边都能随时讲话，不需要每条消息都重新走一遍 HTTP 请求与响应语义。
但对讲机发下去，不代表通信秩序自动出现。消息类型、请求编号、确认、幂等、心跳、重连、补发和背压，一个都不会凭空长出来。
如果客户端只有一个偶尔触发的停止按钮，单独的 HTTP 取消接口通常更简单。
第四版要加语音，仍然不能听见“音频”就条件反射。
上传一段录音，HTTP 足够；简单地把音频片段持续发给服务端，WebSocket 也能做。
可一旦要求 用户边说、AI 边回，还能随时插话，并且要处理弱网、抖动、丢包和网络穿透，这就进入 WebRTC 的主场了。
WebRTC 面向 实时音视频和数据通道。它不是“跑得更快的 WebSocket”，而是在解决 通话质量问题。
它也不会单打独斗。WebRTC 不规定业务信令协议，应用通常还要通过 HTTP 或 WebSocket 交换 SDP 和 ICE candidates。ICE 负责寻找并检查可用路径，STUN 帮助端点发现公网映射，直连失败时再由 TURN 中继流量。
07 DECISION —— 面试官最后问：所以到底选哪个？
你可以这样回答：
我会先按 通信方向、消息频率、数据类型和恢复要求 拆链路。创建任务、查询状态、上传文件和取消任务走 HTTP；AI 的文字增量主要是服务端单向输出，用 SSE；只有双方频繁主动通信时，才增加 WebSocket；到了可插话、低延迟的通话级语音，再用 WebRTC 传媒体，并让 HTTP 或 WebSocket 负责信令。
如果并发 SSE 流比较多，部署链路支持时会利用 HTTP/2 多路复用，同时处理 代理缓冲、心跳和事件重放。用户点击停止时，前端断开流之外，还必须调用取消接口，确保后台任务真的停下。
换句话说：HTTP 管办事，SSE 管 AI 往外说，WebSocket 管双方频繁聊，WebRTC 管实时通话。
面试官想听的从来不是“我全都会用”，而是“它们别抢活，我知道谁该干什么”。如果你也遇到过协议选型上的纠结，不妨到 云栈社区 看看更多同行的实战经验。
发表于 3 小时前
|
查看: 3|
回复: 0
