【问题标题】:Implementing an audio stream service similar to Spotify实现类似于 Spotify 的音频流服务
【发布时间】:2016-05-03 00:28:18
【问题描述】:

高级描述

假设我有一个客户端程序(在我的特定情况下是一个 iOS 应用程序),它应该与远程主机上运行的服务器程序通信。该系统应按如下方式工作:

  • 服务器有一组索引音频文件,并使用索引作为标识符将它们公开给客户端
  • 客户端可以向服务器查询具有给定标识符的项目,服务器应流式传输其内容,以便客户端可以实时播放它
  • 服务器流式传输的数据只能由客户端本身使用,即嗅探流量的人不应该能够解释内容,用户也不应该能够访问数据。

在我看来,这是 Spotify 所做工作的简单实现。

技术问题

  • 应该如何在服务器和客户端之间传输音频数据?应该使用什么协议?我知道,在 TLS 之上使用某些东西可以保护信息免受嗅探流量的人的影响,但是如果用户有权访问加密密钥,它不会保护信息免受用户本人的影响。

【问题讨论】:

    标签: networking server audio-streaming tcp-ip


    【解决方案1】:

    服务器流式传输的数据只能由客户端本身使用,即嗅探流量的人不应该能够解释内容......

    HTTPS 是最好的方法。

    …并且用户应该无法访问数据。

    这是不可能的。即使你有某种魔法来阻止解密数据的捕获(这是不可能的),总有人可以记录音频输出,甚至是数字化的。

    在我看来,这是 Spotify 所做工作的简单实现。

    Spotify 不这样做。没有人这样做,也没有人可以。不可能。如果客户端必须解码数据,那么您无法阻止某人修改该数据的解码方式。

    你能做什么

    • 使用 HTTPS
    • 签署您的 URL,以便原始媒体只能在短时间内访问。每个人都有效地获得了自己的媒体 URL。 (查看 AWS S3 如何处理这个问题,这是一个很好的例子。)
    • 如果你真的很担心,你可以watermark your files on-the-fly,在其中编码一个 ID,这样如果有人泄露了媒体,你可以根据他们的帐户数据追踪他们。这很昂贵,因此请确保您确实有这样做的商业案例。

    【讨论】:

    • 感谢您的回答。这几乎就是我想要的。
    猜你喜欢
    • 1970-01-01
    • 2020-03-22
    • 2015-06-26
    • 2013-03-05
    • 1970-01-01
    • 2017-10-30
    • 1970-01-01
    • 1970-01-01
    • 2015-08-10
    相关资源
    最近更新 更多