Microsoft eCDN 技术概述

简介

Microsoft eCDN 运行基于 WebRTC 的对等 (P2P) CDN，可提供 HLS 和 MPEG-DASH 视频流。 无需额外的软件/客户端插件或硬件即可使解决方案正常工作。 只需要一个符合 HTML5 标准的 Web 浏览器或 Teams 桌面应用程序。

Microsoft eCDN 解决了大型流式处理事件（如全手会议）期间发生的网络拥塞问题。 如果每个员工都尝试同时watch相同的流，则办公室 ISP 链接将饱和。 但是，部署 Microsoft eCDN 时，在这些大型流式处理事件期间会形成高效的 P2P 网格网络，从而显著减少 ISP 链接上的负载。

作为 100% 基于标准且仅限 SaaS 的服务还意味着：

1. 测试和部署 Microsoft eCDN 所需的时间仅为几天。

2. Microsoft eCDN 本质上是安全的，因为它遵循所有 Microsoft O365 安全标准，并且由 JavaScript 代码组成，这些代码在标准 Web 浏览器或流式处理平台客户端的有限沙盒环境中运行。

系统概述

Microsoft eCDN 作为一种服务运行，可协调对等方，同时提供分析和控制。 该系统设计为与现有行业标准和技术兼容。 这意味着它设计用于：

• 基于 HTTP 的流式处理协议，例如 HLS 和 MPEG-DASH。

• 基于 HTML5 的视频播放器 (JWPlayer、Video.js、Clappr、Kaltura 等 ) 以及任何本机 Android 或 iOS 播放器 (ExoPlayer、AVPlayer 等 )

• 基于 HTTP 的 CDN：Akamai、Fastly、CloudFront、Cloudflare、Azure CDN 等。

• 流式处理服务器：Wowza、Nimble、Nginx rtmp 模块等。

• DRM 技术：Widevine、PlayReady、FairPlay 等。

• 为了与现有技术和基础结构完全兼容，但仍能够增强现有技术和基础结构，Microsoft eCDN 采用的内容交付模型是混合模型。 也就是说，每个查看者都可以同时从 P2P 网络和 HTTP 网络下载资源。

概括而言，eCDN 系统由以下部分组成：

• 对等互连发现服务：负责对等发现。

• Switchboard：负责在观看者之间创建初始 P2P 连接。

• 数据管道：使用所有服务遥测数据并将其存储在数据仓库中以供分析使用。

• 播放器插件：负责截获视频相关请求并将其转发到客户端 SDK。

• 客户端 SDK：负责从 HTTP/P2P 智能请求视频资源，并实时缝合数据缓冲区。

  • 客户端 SDK 与后端 (对等互连发现服务、交换机、数据管道) 进行连接。

  • 发现服务会向客户端 SDK 发送一组对等方，相信这些对等方将使此特定查看器受益。 根据网络邻近度、缓存分配、流相关性等参数选择对等方。

  • 客户端 SDK 在 Switchboard 的帮助下与指定的对等集建立 WebRTC 数据通道连接。

  • 由视频播放器生成的 HTTP 请求被播放器插件截获并转发到 Microsoft eCDN 客户端 SDK，该 SDK 根据实时度量决定是同时从 P2P 网络还是从 HTTP 提取所需资源，还是同时从这两者中提取所需资源，以便以最高效、最及时的方式将资源提供回播放器。

  • 始终从 HTTP 边缘服务器检索清单请求、DRM 许可证和加密，以便获取最新副本并遵守授权机制。

  • 单独，客户端 SDK 请求授权以从 Microsoft eCDN 后端创建对等连接。 授权后，客户端 SDK 将开始从 HTTP 和 P2P 下载资源。

客户端逻辑概述

客户端 SDK 同时从 HTTP 和 P2P 源提取内容。 这意味着，用户体验不会受到未及时提取的段的负面影响，也不会因为 P2P 源的连接速度不足而受到负面影响。

安全性

Microsoft eCDN 符合 Microsoft O365 安全标准。

该服务与任何传统的基于服务器的 CDN 服务一样安全。 由于它是混合解决方案（将 eCDN 与传统 HTTP 服务器结合使用），因此我们利用客户已有的现有安全基础结构 (令牌、密钥、Cookie 等 ) 。

在通信方面，对等方通过 WebRTC 数据通道相互连接，这是一种安全管道，通过 DTLS 加密使用 SCTP 协议。 此外，每个查看器都通过使用 TLS 加密的安全 Websocket 连接连接到后端。 因此，在查看者之间发送的数据以及每个查看器与后端之间发送的元数据都不能泄露。

在流安全性方面，有多种方案：

会话启动时的身份验证

在这种情况下，每个会话都从服务器要求查看者提供用户 ID 和密码开始。 如果这些凭据有效，服务器将向查看者发送清单文件，视频播放器将开始从 HTTP 服务器相应地请求段和其他清单。 Microsoft eCDN 不会将自身插入验证过程，并且无论是否部署 Microsoft eCDN，查看器都必须通过相同的身份验证入口。 只有获得流授权的观看者才能参与该流的 P2P 共享，并且仅在他们实际观看流时共享。

URL 计时标记化

在这种情况下，清单 URL 具有一个附加令牌，该令牌对查看者的用户代理 (IP 地址、过期时间等 ) 的一些详细信息进行编码。 通过登录或其他方式以某种方式获取清单 URL 的恶意用户可以将其分发给未经授权的查看者，但这些查看者无法访问流，因为清单 URL 已标记化，并且 HTTP 服务器将拒绝任何验证尝试，无论是因为 IP 地址或其他用户代理不匹配，还是由于时间过期。 使用 Microsoft eCDN，所有清单请求都直接发送到 HTTP 服务器，因此验证不会受到威胁。

视频段内容保护

获得流 URL 访问权限的未授权用户仍可能尝试通过其他对等方访问视频段的内容。 如果段未加密，则存在以下风险：未经授权的用户可以从其他用户接收段的 URL，查找具有此相关资源的其他对等方，并尝试直接从这些用户请求此资源 (即使媒体服务器/CDN 不允许访问此资源) 。

启用内容标记化后，我们确保在资源级别对用户进行身份验证，然后其他对等方才能向该用户发送数据。 这是一种精细机制，可以授予对某些资源的访问权限，并拒绝对同一会话上其他资源的访问权限。

进一步的保护措施包括加密：

加密

例如，以 AES-128 加密保护的 HLS 流为例。 恶意用户可以向未经授权的观看者甚至视频片段本身发送清单 URL，但只要未经授权的观看者无权访问解密密钥，他们就无法watch流。 可以通过多种方式向最终用户发送密钥，例如，通过main清单、HTML 页面或其他路径。 无论如何，服务不会将自身插入到此过程中，并且无论是否部署服务，密钥都会使用相同的机制传递给视频播放器，这意味着密钥在 Microsoft eCDN 中或不使用 Microsoft eCDN 时都同样安全。

Drm

DRM 用例类似于加密用例。 唯一的区别是，许可证和密钥由 DRM 机制而不是广播公司分发。 在这里，Microsoft eCDN 不会干扰许可证或密钥的分发，因此不会泄露它们。