使用 Wowza 3.5 在 Amazon CloudFront 中缓存 HLS/HDS 流

Question

我正在努力快速了解 HDS 和 HLS 直播背后的一些底层技术。

我在 EC2 的 Amazon WebServices 实例上设置了 Wowza Media server 3.5 并通过 CloudFront 分发。我做了我的第一个现场活动，看着我的服务器负载越来越高。我想知道是否有人可以帮助我了解 HDS/HLS 直播（和 nDVR ......）的一些基础：

• Wowza 是我的云端分发的源服务器
• HDS 清单文件设置为在 CF 中缓存 2 秒（TTL 时间）
• 我检查了访问我的 Wowza 实例的所有 IP，它们实际上是 CF 缓存位置或边缘服务器
• （假设）由于所有 HDS 流量都通过端口 80，所有视频内容最终都被缓存在边缘位置（尽管 2 秒）

这就是我的问题所在：如何为视频内容提供数据（这是我的理解，请直截了当！）： - 当观众请求播放列表或 mainfest 文件时，他们会返回 XML，这会将播放器指向他们接下来需要播放的一段视频/音频（DVR 应用程序实例中的 m4fa 和 m4fv？）数据。由于这些数据也是通过端口 80 传递的，因此它也会被缓存。

如果以上陈述正确，那么以下对于 HDS 和 HLS 的优化是否有意义：

案例 1：DVR 服务： 我在 CloudFront 中设置缓存规则如下：

• 以“f4m”、“m3u8”和“?DVR”结尾的任何内容都缓存 2 秒（播放列表/清单文件）
• 其他所有内容的默认值应该缓存更长的时间（可能是一个小时，或者 24 小时......？） 这样，DVR 数据会保持缓存状态，但播放列表会每 2 秒更新一次

案例 2：没有 DVR 服务（这是更好的优化方式吗？）

• 我怀疑我们也可以通过同时终止 DVR 服务来优化服务器负载，这样通过 CF 分发的所有数据都只是最新的音频/视频数据包 - 因此所有观众都应该请求相同的播放列表和数据文件，因此，大量请求这些文件的人没什么大不了的，因为我的服务器每 2 秒从每个边缘位置受到一次访问以更新清单文件）。
• 如果媒体文件块被赋予更长的缓存时间，如果媒体仍然缓存，我们是否会终止 DVR 服务？

感谢您提供的任何见解！

Answer 1

有没有办法为媒体配置不同的站点名称？对于 DVR 会话，您希望直接从您的服务器提供 m3u8 文件（无 CF，或 2 秒 CF），但通过 CloudFront 提供媒体文件，过期时间非常长。

（对于非 DVR 会话，它都可以通过 CloudFront，因为它是可缓存的。）

CloudFront 的实用性实际上取决于您拥有多少受欢迎（和不受欢迎）的流。

例如，假设特定 POP 中有 20 个 CloudFront 盒子。如果 5 个人查看一个流，每个人都可能会点击不同的 CF 框，缓存未命中并且无论如何都需要点击您的服务器。在 CloudFront 停止访问您的服务器并从缓存中提供所有内容之前，您必须有 50 或 70 人查看来自该 POP 的流。因为有许多 POP，你可以让 100 人在世界各地观看一个流，但每个人在不同的 POP 中点击不同的框，你的服务器仍然会收到 100 个请求。