Microsoft eCDN 技術概觀
簡介
Microsoft eCDN 會操作 WebRTC 型點對點 (P2P) CDN，以提供 HLS 和 MPEG-DASH 視訊串流。 解決方案不需要額外的軟體/用戶端外掛程式或硬體即可運作。 您只需要 HTML5 相容的網頁瀏覽器或 Teams 桌面應用程式。
Microsoft eCDN 可解決大型串流事件期間發生的網路壅塞問題，例如全手會議。 如果每位員工同時嘗試watch相同的資料流程，辦公室 ISP 連結就會變得飽和。 不過，部署 Microsoft eCDN 時，在這些大型串流事件期間會形成有效率的 P2P 網格網路，這可大幅降低 ISP 連結的負載。
以 100% 標準為基礎且僅限 SaaS 的服務也表示：
測試和部署 Microsoft eCDN 只需要幾天的時間。
Microsoft eCDN 原本就是安全的，因為它遵循所有 Microsoft O365 安全性標準，並包含 JavaScript 程式碼，其會在標準網頁瀏覽器或串流平臺用戶端的有限沙箱化環境中執行。
系統概觀
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 系統是由下列專案所組成：
對等互連探索服務：負責對等探索。
切換板：負責建立檢視者之間的初始 P2P 連線。
資料管線：取用所有服務遙測，並將它儲存在資料倉儲中以供分析取用。
播放機外掛程式：負責攔截和轉送影片相關要求至用戶端 SDK。
用戶端 SDK：負責從 HTTP / P2P 以智慧方式要求視訊資源，並即時拼接資料緩衝區。
用戶端 SDK 會與後端連線 (對等互連探索服務、切換板、資料管線) 。
探索服務會傳送一組對等給用戶端 SDK，它認為這些對等會讓這個特定檢視器受益。 會根據網路鄰近性、快取配置、串流相關性以及其他參數來選取對等。
用戶端 SDK 會在 Switchboard 的協助下，使用指定的對等集建立 WebRTC 資料通道連線。
播放機外掛程式會攔截視訊播放程式所產生的 HTTP 要求，並轉送到 Microsoft eCDN 用戶端 SDK，這會根據即時度量來決定要從 P2P 網路或 HTTP 擷取所需的資源，還是同時從兩者擷取所需的資源，以便以最有效率且及時的方式將該資源提供給播放機。
資訊清單要求、DRM 授權和加密一律會從 HTTP Edge Server 擷取，以取得最新的複本並遵守授權機制。
用戶端 SDK 會獨立要求授權，以從 Microsoft eCDN 後端建立對等連線。 授權之後，用戶端 SDK 就會開始從 HTTP 和 P2P 下載資源。
用戶端邏輯概觀
用戶端 SDK 會同時從 HTTP 和 P2P 來源擷取內容。 這表示使用者體驗不會受到未及時擷取的區段或因為 P2P 來源的連線速度不足而造成負面影響。
安全性
Microsoft eCDN 符合 Microsoft O365 安全性標準。
此服務與任何傳統伺服器型 CDN 服務一樣安全。 因為它是混合式解決方案，其中一個搭配傳統 HTTP 伺服器使用 eCDN 的解決方案，所以我們會利用現有的安全性基礎結構 (客戶已備妥的權杖、金鑰、Cookie 等 ) 。
就通訊而言，對等會透過 WebRTC 資料通道彼此連線，這是透過 DTLS 加密使用 SCTP 通訊協定的安全管道。 此外，每個檢視器都會透過使用 TLS 加密的安全 Websocket 連線連線到後端。 因此，在檢視者之間傳送的資料，或在每個檢視器與後端之間傳送的中繼資料，都無法遭到入侵。
就串流安全性而言，有幾個案例：
會話啟動時的驗證
在此情況下，每個會話都是從要求檢視器輸入使用者識別碼和密碼的伺服器開始。 如果這些認證有效，伺服器會將資訊清單檔案傳送給檢視器，而視訊播放程式會據此開始向 HTTP 伺服器要求區段和其他資訊清單。 Microsoft eCDN 不會將自己插入驗證程式，而且無論是否部署 Microsoft eCDN，檢視器都必須通過相同的驗證閘道。 只有獲得資料流程授權的檢視者可以參與該資料流程的 P2P 共用，而且他們只會在實際監看串流時共用。
URL 定時權杖化
在此情況下，資訊清單 URL 會有額外的權杖，其會將檢視器使用者代理程式的一些詳細資料編碼 (IP 位址、到期時間等 ) 。 透過登入或其他方式取得資訊清單 URL 的惡意使用者可以將它散發給未經授權的檢視者，但這些檢視者將無法存取資料流程，因為資訊清單 URL 已權杖化，而且 HTTP 伺服器會拒絕任何驗證嘗試，可能是因為 IP 位址或其他使用者代理程式不相符或因為時間過期。 使用 Microsoft eCDN 時，所有資訊清單要求都會直接傳送至 HTTP 伺服器，因此驗證無法遭到入侵。
影片區段內容保護
未經授權的使用者若能存取串流 URL，仍可能嘗試透過其他對等存取影片區段的內容。 如果區段未加密，則存在下列風險：未經授權的使用者可以從不同的使用者接收區段的 URL、尋找具有此相關資源的其他對等，並嘗試直接向這些使用者要求此資源 (即使媒體伺服器/CDN 不允許存取此資源) 。
啟用內容權杖化時，我們會先確定使用者已在資源層級上進行驗證，其他對等才能將資料傳送給該使用者。 這是一個細微的機制，可以授與特定資源的存取權，並拒絕存取相同會話上的其他資源。
進一步的保護措施包括加密：
加密
例如，讓我們採用使用 AES-128 加密保護的 HLS 資料流程。 惡意使用者可以將資訊清單 URL 傳送給未經授權的檢視者，甚至是視訊區段本身，但只要未經授權的檢視者無法存取解密金鑰，他們就無法watch資料流程。 金鑰可以透過許多方式傳送給使用者，例如透過主要資訊清單，或透過 HTML 頁面或其他路徑。 不論是否部署服務，服務都不會將自己插入此程式，而且無論是否部署服務，金鑰都會使用相同的機制傳遞給視訊播放程式，這表示無論是否使用 Microsoft eCDN，金鑰都一樣安全。
Drm
DRM 使用案例類似于加密使用案例。 唯一的差別在於授權和金鑰是由 DRM 機制散發，而不是由廣播者散發。 此外，Microsoft eCDN 也不會干擾授權或金鑰的散發，因此不會危害它們。