时间戳

首页 > 解决方案 > 实时音频流网络应用程序的架构

websocket - 实时音频流网络应用程序的架构

问题描述

需要您对实时音频流应用程序的架构提出意见。

目前，我正在本地网络上对其进行测试，一切似乎都可以正常工作，但我怀疑它在生产中的效果如何。

我的架构：

                         1               2 
Broadcaster HTTP client ---> App Server ---> Listening clients (React.js App)

1— 通过 HTTP 进行通信，2— 通过 HTTP 和 WebSocket 进行通信

我想做的事：

  1. 当用户打开我的 React 应用程序并且广播器还没有流式传输时，React 应该显示类似“OFFLINE”的内容
  2. 接下来，当 Broadcaster 开始流式传输到 App Server 时，React App 应显示“流已启动”并自动开始播放。
  3. 最后，当 Broadcaster 停止流式传输时，React App 应该再次显示“OFFLINE”。

我目前是如何做到的： 我的应用服务器使用两种协议：HTTP（用于音频流和其他内容）和 WebSocket（仅用于发送服务器上发生的 JSON 状态消息）。

  1. 当 Broadcaster 开始流式传输到 App Server（通过 HTTP）时，App Server 向 React App 发送 WebSocket 消息：“流已经开始，您可以在 ie 处访问它，http://my-domain/stream即 App Server 通过常规 HTTP 将音频流式传输到 React。
  2. React App 看到此消息并呈现 HTML<audio>元素并开始播放音频。
  3. 当 Broadcaster 停止流式传输时，App Server 向 React App 发送 WebSocket 消息“流式传输完成”，React 隐藏播放器，显示“OFFLINE”

因此，我通过 HTTP 进行所有流式传输（从 Broadcaster 到 App Server 以及从 App Server 到 React 客户端），并使用 WebSocket 来传达实时流状态更新。

这种架构有多好？

标签： websocketarchitecturesingle-page-applicationaudio-streaminghttp-streaming

解决方案

这种架构有多好？

这不是好坏的问题，而是它是否适合您的用例的问题。我注意到这基本上就是 SHOUTcast 和 Icecast 等互联网广播服务器已经工作了 20 多年的方式，所以它不会那么糟糕。:-)

推荐阅读