翻译 | Alex 技术审校 | 杨硕 本文来自OTTVerse,作者为Krishna Rao Vijayanagar。
CDN
Easy Tech
010
CDN(Content Delivery Networks,内容分发网络)是分布在世界各地的服务器,它们是视频直播和点播中至关重要的基础设施。CDN位于视频播放器和源服务器之间,负责跨地理区域分发视频内容,并有效保障客户端流畅的观看体验。
在本文中,我们将学习CDN是如何工作的,如果不使用CDN会发生什么,并了解什么是Cache-Hit和Cache-Miss。让我们开始吧!
视频流架构
对于大部分视频直播和点播架构来说,下列操作是常见的步骤:
我们刚刚描述了一个直播(或点播)的视频流服务架构,这个架构在一开始可能很好用,但是当你添加更多用户、订阅者、内容或者一个视频突然火了以后,它很快就崩溃了。
让我们用一分钟来讨论一下视频突然火爆的情况。
假设有人录制了一首歌并上传到你的UGC平台,突然一下子火了。全世界都想听这首歌,源服务器上来自播放器的请求急剧增长。你认为接下来会发生什么?
首先,你的源服务器将遭到大量请求的“轰炸”:来自时长3分钟的、同一视频中的视频切片,每秒发出1000次请求。就像发生踩踏事件一样!
在这种情况下,源服务器该如何应对?
源服务器将艰难地服务所有请求。即使服务器很强大,它也无法承受如此巨量的请求。
有些播放器也许会请求视频的第一个分片,其他播放器也许会请求最后一个视频分片(具有不同的分辨率和码率)。由于进程或网络 I/O 限制,源服务器很快便无法为众多请求提供服务。
最后,你的终端用户将会遭遇如下问题:
以上这些问题都会导致糟糕的体验,这可不是正确提供视频流服务的方式。但我们所描述的情况很常见,这在那些广受大众喜爱的视频流服务中几乎每天都会发生。
所以,解决方案是什么?
内容分发网络(CDN)
让我们尝试来解决问题,以下是到目前为止我们所观察到的问题症结:
如果我们认真研究上述原因,某种模式似乎正在浮出水面,引领着我们走向问题答案。
如果所有用户端都在请求同一视频分片,为什么不像电脑上的缓存那样缓存视频分片?为什么每次都要向硬盘请求?
所以,让我们在源服务器的前面增加一个缓存层,这个缓存层可以缓存频繁被请求的视频分片并将它们分发出去,而不必每次都要访问源服务器。
然后, 为了服务不同的地理位置,我们可以在世界各地架设几个这样的缓存层,并向附近用户分发视频以及提供快速响应。
以上操作正是设计一个非常简单的CDN的开始。
好了,现在让我们更深入地理解CDN是如何工作的:
左图:无CDN 右图:有CDN (图片来自Wikipedia)
关于CDN,你还需要知道一些术语:
缓存未命中(Cache Miss):当客户端向CDN请求内容,而CDN刚好没有缓存该内容时,我们就称之为缓存未命中。发生缓存未命中时,CDN将向源服务器请求未命中内容。源服务器响应后,CDN将缓存内容并将其分发给客户端。
缓存命中(Cache Hit):当客户端向CDN请求内容时,CDN刚好缓存了此内容,这时我们就称之为缓存命中。在这种情况下,CDN将向客户端设备分发缓存内容。
TTL( Time to Live):CDN不会无限期地缓存视频分片或者其他媒体内容。它使用一个名为TTL(Time to Live)的变量来丢弃和刷新那些不被频繁请求的视频内容。这种缓存刷新可以为新内容腾出空间并智能管理磁盘空间。
使用CDN的优势
在视频流服务(直播或者点播)中使用CDN有很多好处,让我们来看下:
总 结
我希望本篇文章能帮助你理解CDN、它的工作原理以及使用CDN的优势。包括Akamai、Fastly、Cloudflare、KeyCDN、LimeLight和Medianova等在内的CDN厂商在向用户交付内容及改善视频观看体验方面都做得非常出色(不同的用例、架构和预算)。
在未来的系列文章中,我们将学习CDN技术中的Multi-CDN、边缘缓存(Edge Caches)和边缘计算(Edge Computing)等概念。
致谢
本文已获得作者Krishna Rao Vijayanagar授权翻译和发布,特此感谢。
原文链接:
https://ottverse.com/what-is-a-cdn-content-delivery-network-live-vod/
本文分享自 LiveVideoStack 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体分享计划 ,欢迎热爱写作的你一起参与!