我已经搜索了几天，似乎找不到解决方案。我希望这里有人能指出我正确的方向。
我正在使用 Cordova/Angular 构建一个无线电 iOS 应用程序，并且我有一个正在使用 HTML5 播放的 mp3 流 ( http://mp3lg3.tdf-cdn.com/5593/goo_102004.mp3 )。
我想找到一种方法来继续流式传输，即使设备失去连接几分钟，如果连接恢复，继续正常流式传输。目前，如果我关闭 wifi 或将设备打开“飞行模式”，它会立即停止流式传输。
我对音频世界相当陌生，希望有经验的人可以提供帮助。
HTTP 渐进式流的工作原理是在一个连续的流中简单地发送数据，而接收端则在数据进入时播放数据。网络的本质是数据以块的形式出现，而不是完全连续的，因此播放音频的客户端具有几秒钟的缓冲区，以在数据的周期性突发中幸存下来。
为了避免一分钟的丢失，客户端将来必须接收超过一分钟的数据。这是通过在服务器上缓冲一分钟的数据，然后在连接时尽快将该缓冲区刷新到客户端来实现的。虽然它不会同时到达客户端，但它应该相当快地到达那里，然后您将拥有可以在断开连接后幸存的缓冲区。也就是说，如果您的服务器比客户端提前一分钟，并且具有完整 1 分钟缓冲区的客户端失去连接，它可以继续播放大约一分钟，然后才不得不退出。
不过，这只是问题的一半。当你重新连接时你会做什么？客户端如何与服务器同步？不幸的是，没有支持同步方式的实时 HTTP 渐进式公共服务器。我已经对Range标头进行了一些试验，哪些不起作用，但需要一个自定义客户端。（但是 VLC 确实有效......）
您还必须考虑音频立即停止的原因。如果您试图通过打开飞行模式来模拟网络中断或慢点，那么这不是一个合适的测试。操作系统禁用网络接口，这会立即断开所有 TCP 连接，立即终止通向应用程序的管道。大多数应用程序将在此时停止播放，除非它们有一些额外的缓冲区，而不管网络连接如何。在您的网络连接质量受到影响的情况下，TCP 连接实际上很少被丢弃......数据包只是延迟导致音频最终在缓冲区耗尽时停止。
综上所述，有两种解决方案，具体取决于您的需求：
这很简单。增加刷新到客户端的服务器端缓冲区。我通常使用 20 秒。
请注意，并非所有客户端都会接受如此大的缓冲区。有些会降低 TCP 窗口大小，防止服务器发送过多的音频数据。
（注意：如果您不知道如何使用现有的流媒体服务器执行此操作，可以在我创建的 AudioPump CDN 上使用缓冲区配置。它尚未普遍可用，但您可以通过 brad 给我发送电子邮件@audiopump.co 试试看。）
对于这种情况，您需要一个全新的流协议。 HLS就是你想要的。
HLS 的工作原理是分段必须由多个 HTTP 请求请求的流。因此，客户端可以更改地址（例如从移动网络转到 WiFi），并且流仍然可以工作。
不幸的是，客户端不支持 HLS，但服务器端很容易。大多数情况下，任何 HTTP 服务器都可以。编码器是需要更改的，用于编码和上传片段。
如果是没有直播内容的普通流，也许你可以将其转换为字节数组（2 倍速），然后以正常速度播放。不过做起来有点复杂。