解决浏览器 WebSocket 认证难题：豆包语音识别的代理方案实践
💡
原文中文，约8600字，阅读约需21分钟。
📝
内容提要
本文探讨了如何通过后端代理解决浏览器 WebSocket API 不支持自定义 HTTP header 的问题，特别是在豆包语音识别服务中。采用后端代理方案后，成功实现了安全传递认证信息，并在 HagiCode 项目中验证了其可行性和稳定性。
🎯
关键要点
- 浏览器 WebSocket API 不支持自定义 HTTP header，给语音识别服务带来挑战。
- 选择后端代理方案以安全传递认证信息，避免将凭证暴露在前端。
- 在 HagiCode 项目中验证了后端代理方案的可行性和稳定性。
- 原生 WebSocket 轻量高效，适合简单场景。
- 采用每连接单会话模式，简化实现和调试。
- 前后端消息协议分离控制信号和音频数据，提高处理清晰度。
- 敏感凭证存储在后端配置文件中，确保安全性。
- 建议使用 Docker 部署代理服务，方便扩展和管理。
- 监控连接状态和错误处理，确保系统稳定性。
- 音频格式要求严格，确保识别效果良好。
❓
延伸问答
为什么浏览器 WebSocket API 不支持自定义 HTTP header 会影响语音识别服务？
因为语音识别服务需要通过 HTTP header 传递认证信息，而浏览器 WebSocket API 只能在 URL 中传递参数，无法设置 headers。
后端代理方案是如何解决 WebSocket 认证问题的？
后端代理方案通过在后端实现 WebSocket 代理，安全地传递认证信息，避免将凭证暴露在前端。
HagiCode 项目中如何验证后端代理方案的可行性？
在 HagiCode 项目中，后端代理方案最初在 playground 试验场验证，确认稳定后才应用到生产环境。
使用原生 WebSocket 的优缺点是什么？
原生 WebSocket 轻量、简单，适合简单场景，但需要手动处理连接管理。
如何确保敏感凭证的安全性？
敏感凭证存储在后端配置文件中，避免暴露给前端，并支持多环境配置。
在部署代理服务时有哪些建议？
建议使用 Docker 部署代理服务，方便扩展和管理，同时实现负载均衡和健康检查。
➡️
