Amazon web services 使用Wowza 3.5在Amazon CloudFront中缓存HLS/HDS流媒体

我试图快速了解HDS和HLS直播背后的一些底层技术

我已经在EC2中的AmazonWebServices实例上设置了WowzaMediaServer3.5，并通过CloudFront分发。我做了我的第一个现场活动，看着我的服务器负载越来越高。我想知道是否有人能帮助我了解HDS/HLS直播（和nDVR…）的一些基础：

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

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

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

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

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

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

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

---

感谢您提供的任何见解

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

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

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

---

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

我认为您理解得正确。我只想问一个问题——在URL中使用sessionid是否会导致缓存混乱？是的，vipw，这就是我看到的行为。如果您有任何想法，我目前正在文档中查找禁用这些唯一会话ID的方法！谢谢你的建议！我认为你需要做一个推式的方法。您可以让脚本从Wowza初始化会话，并将它读取的内容推送到CloudFront正在读取的S3。但是我已经好几年没有使用Wowza了，他们可能有更好的解决方案。你在他们的论坛上问过吗？根据我的经验，他们非常有帮助。谢谢你的回答。您确定情况确实如此，而且我们在100多名用户之后会看到CF的好处吗？没有办法确保用户只点击同一个CF框吗？因为如果不是的话，似乎很难验证它是否工作。我是说，如果你的用户数量很少，CF将不会减轻你上游服务器的负载。（由于网络原因，使用CF可能仍然有意义。）请注意，AWS为您提供缓存命中统计数据，以便您可以验证它是否正常工作。