阅读 153

CDN 和视频流化服务

内容分发网络(Content Delivery Network,简称 CDN),是建立并覆盖在 Internet 之上,由分布在不同区域的边缘节点服务器群组成的分布式网络。这些高性能的服务节点都会按照一定的缓存策略存储您的业务内容,当您的用户向您的某一业务内容发起请求时,请求会被调度至最接近用户的服务节点,直接由服务节点快速响应,有效降低用户访问延迟,提升可用性。

CDN 有效地解决了目前互联网业务中网络层面的以下问题:

  • 用户与业务服务器地域间物理距离较远,需要进行多次网络转发,传输延时较高且不稳定。
  • 用户使用运营商与业务服务器所在运营商不同,请求需要运营商之间进行互联转发。
  • 业务服务器网络带宽、处理能力有限,当接收到海量用户请求时,会导致响应速度降低、可用性降低。

前情提要

系统地学习计算机基础知识,并用博客记录下来。我们的教材是 计算机网络(原书第7版) (豆瓣),视频讲解 中科大郑烇、杨坚全套《计算机网络(自顶向下方法 第7版,James F.Kurose,Keith W.Ross)》课程_哔哩哔哩_bilibili

计算机网络:Internet基本原理(上)

计算机网络:Internet基本原理(下)

计算机网络:应用层协议原理

HTTP 必知必会

你应该知道的 DNS -- 计算机网络自顶向下

这篇讲述了第二章应用层之 CDN。

视频流化服务和 CDN

我们都知道,视频业务是互联网流量的杀手级应用,它网络流量占的比较多,而且最能够吸引用户。据统计,在互联网当中, 7~8 成的流量都是视频流量。

如此大规模的视频流量,也给现代互联网带来了两个挑战。

挑战一:规模性——如何同时向成千上万的人用户,提供并行的播放服务?

原来的互联网中,视频业务占的不是很多,开几台服务器,向用户提供几十个并发,甚至几百个并发,可以说完全没有问题。但现在的互联网当中视频业务的用户数量非常多,我们该怎么保证向那么多的用户提供好的视频服务呢?

挑战二:异构性——不同用户拥有不同的能力

比如,有的用户是有线接入,有的用户是移动用户,有的用户带宽丰富,而有的用户带宽受限用户。可以说每一个节点的视频处理的能力也不一样,需求也不一样。

就像手机端用户,要求的视频的解析度比较小;而电视用户,要求的解析度比较大。

那解决方式是什么呢?采用分布式的,应用层面的基础设施——CDN(Content Distribution Network),来给网络加速。

下面我们来看看 CDN 是怎么样解决互联网杀手级应用的,let‘s go!

视频

我们可以把视频看作固定速度显示的图像序列,也就是说一个个视频是由图像构成的。我们知道人的视网膜有滞留效应,大脑通过补间动画的形式创造出世界的连续性。

参考:真实世界的帧率是多少? - 知乎

我们相当习惯观看以每秒24到30帧的速度播放的视频或节目。用胶片拍摄的电影是以每秒24帧的速度拍摄的。这意味着每秒钟有24个图像闪过你的眼睛,这玩意叫“视觉暂留”,人眼会自动对两帧之间的画面进行脑补。

压缩技术

也就是说,我们可以认为那视频是一系列的图像的序列,而数字化图像是像素的阵列,每个像素被若干bits 表示。

那么网络视频的特点是什么呢?

  • 高码率,有很高的网络带宽需求
  • 可以被压缩
  • 90% 以上的网络流量是视频

我们都知道视频业务是占的带宽是非常大的,所以,视频在网络当中传输的过程当中,通常要经过压缩,转变成小码率的视频。

那压缩的技术是什么呢?

是使用图像内和图像间的冗余来降低编码的比特数,冗余又分为图像内的空间冗余相邻的图像间的时间冗余。

在上面的图片中,有帧 i 和帧 i+1。

空间冗余: 在帧 i 中,每一个红色的点表示一个像素点。可以看出在每一帧当中这些像素点的颜色是一样,或者类似的,我们把这叫做空间冗余。

所以,我们可以只发送两个数据,颜色(紫色)和重复的个数(N),也就是一个像素值持续了多少个像素点。

时间冗余: 帧 i+1,是帧 i 的下一帧。可以帧 i+1 和帧 i 有很多类似的部分,我们把这叫做时间冗余。

所以,不是发送第帧 i+1 的全部编码,而是仅仅发送和帧 ⅰ 差别的地方。

根据视频的这些特性,我们就可以把网络中传输的视频压缩成小码率。

压缩标准

而压缩的标准有很多:

  • CBR(constant bit rate):以固定速率编码

以 CBI 的标准压缩视频,码率基本上是 几百 kb 到 2 M,不会改变。所以如果视频是一个静态的景色,那么传输的量会非常非常少。但是如果视频经常切换场景,那么损失码率就会变得很高,可能出现马赛克。

  • VBR(variable bit rate):视频编码速率随时间的变化而变化

这种编码类型会根据你的需要解析度,进行编码。为什么会出现不同的解析度呢?因为不同的视频终端需求不一样,比如你手机很小,解析 800 x 600 就足够了。但如果是一个 PC 机,解析度的要求就高很多。

视频流

流服务 streaming,是我们在网络里看视频的时候经常采用的一种服务。

在看视频的时候,我们是一边看视频一边加载后面的内容,而不是一下子下载整个视频。

一边下载一边进行播放,已经下载好的视频被放在缓冲区里,后面的视频直接从缓冲当中不停地在提取出来播放。这种流服务,可以大幅度的减少用户的等待时间。

DASH:Dynamic,Adaptive Streaming over HTTP

DASH 是流服务常见的一个协议,全称是动态自适应的 HTTP 流式传输。(可以看出 HTTP 可不仅仅只用于 web,还可以用于文件的上下载、音视频的播放。HTTP 就是一个传输协议,和应用无关。)

那什么叫动态自适应的流化技术呢?

服务器

  • 将视频文件分割成多个块,一个大的视频切成一个个小的片段。

  • 每个块独立存储,编码于不同码率(8-10种),每一块有不同的解析度和编码标准。

    • 每个块可以存储在不同的服务器中,可以是源服务器,或者缓存服务器。
  • 文件(manifest file):描述了视频被切成多少块,每个块对应的 URL 是什么。

客户端

  • 在获取视频的时候,先获取告示文件(manifest file)

  • 然后,周期性地测量服务器到客户端的带宽

  • 查询告示文件,在一个时刻请求一个块,HTTP头部指定字节范围

    • 如果带宽足够,诜择最大码率的视频块
    • 会话中的不同时刻,可以切换请求不同的编码块(取决于当时的可用带宽)

也就是说,客户端是“智能”的,由客户端自适应决定以下三个条件:

  • 什么时候去请求块:保证缓存不挨饿,也不溢出
  • 请求什么编码速率的视频块:当带宽够用时,请求高质量的视频块
  • 哪里去请求块:可以向离自己近的服务器发送URL,或者向高可用带宽的服务器请求

将媒体文件切分成段,按照不同的比特率或空间分辨率进行编码。然后将这些片段放在 Web 服务器上,客户端可以通过 HTTP 标准兼容的 GET 请求下载。

服务端:如同图片里画的一样,HTTP 服务器提供三种不同的质量的服务,即 Low、 Medium 和 Best,分割成相等长度的片段。

客户端:根据带宽(Bandwidth)的不同,进行每个段比特率或分辨率的适应。例如,如果带宽允许的话,客户端可以在每个段的基础上切换到更高的比特率。

这种技术,我们把它叫 DASH 动态自适应的 HTTP 流式传输,它可以解决不同客户端的需求问题,和不同网络的能力的问题。

怎么部署?

下面问题来了,我们要怎么部署这些段的资源,才能让服务器通过网络同时向上百万用户提供流化视频内容呢?

方案一:服务中心“mega-server”

有的同学可能会说,这还不简单,直接部署在一台服务器上不就可以啦。如果这样的话,这将会是一个巨大的超级服务中心。

但是,如果大家都是从一个或者非常少的服务器获取流化服务,会带来什么问题?

服务器遇到了问题,首先可能会想,是不是我自身努力不够呀

所以服务器不停地提高它的服务能力,把网卡升级,周边的网络的接入带宽也升级。但还没有用,因为服务器到客户端路径上跳数较多,瓶颈链路的带宽小会导致停顿。服务器可以优化自身,但是不能优化网络。

所以说,仅仅靠服务器的努力是不够的,它自身的努力不能解决流化服务器播放质量的问题。

第二,“ニ八规律”决定了网络同时充斥着同一个视烦的多个拷贝,网上的重复流量比较多,整个网络的传输资源被严重浪费。

而且,还存在着单点故障可靠性、性能瓶颈的问题,还有整个服务器群周边网络拥塞的问题。

综上所诉,我们可以得到结论,这个方法相当简单,但是不可扩展。

方案二:CDN

因此,就有了CDN 内容分发网络,它解决了单个服务器(超级服务集群),向用户数量非常多的用户,提供流化服务时遇到的问题,它可以向用户提供的服务更好。

那么,是 CDN 怎么解决问题的呢?

思路很简单,在全球的网络中部署很多的 CDN 节点,把一些内容预先部署到这些缓存的节点当中。

当用户来访问的时候,他不一定要从源服务器那里去获得视频内容的流化服务,而是通过域名解析的重定向到离它最近的、向他提供服务质量最好(如果网络路径拥塞,可能选择不同的拷贝)的缓存节点,从而提高用户的体验。

我们把它叫内容加速服务

如果用户访问的内容已经部署这些缓存节点里了,在访问的时候,经过域名解析的重定向,就可以找离用户最近的缓存节点。

CDN 服务由 CDN 的运营商提供,比如蓝汛、七牛云。

CDN 节点部署策略

我们现在知道,CDN 要在全球的范围内部署很多的缓存节点,那么怎么部署这些节点呢?

主要有两种方法:enter deep(左) 和 bring home(右)。

enter deep,将 CDN 服务器深入到许多接入网。 就是在很多的 local ISP 的范围内部署了很多的缓存节点,把一些内容预先部署到这一缓存节点当中。

这种部署方式更接近用户,节点数量多、离用户近,用户请求资源时跳数更少,网络带宽大。但是因为部署的节点非常靠下,所以需要部署非常多的节点,这些节点管理起来很困难。

还有一种叫方式 bring home, 部署在少数(10个左右)关键位置节点上,比如将服务器簇安装于 POP (网络服务提供点 Point of presence)附近,离若干一级 ISP POP 较近的位置。就是在一些上层的 ISP,有很多的数据中心机房的关键节点,然后我选的位置离那些关键数据中心机房比较近。

这样的话,只要我卡住这些关键的位置,也可以向用户提供一些好的服务。

完整流程

最后,我们来看一个接入 CDN 后的完整案例,深入理解它的解析过程。

  1. 当终端用户(广州电信)向 www.baidu.com 下的某资源发起请求时,首先查看是否有配置host文件及DNS缓存记录。
  2. 向 Local DNS(本地DNS)发起域名解析请求。
  3. Local DNS 检查缓存中是否有 www.baidu.com 的 IP 地址记录。如果有,则直接返回给终端用户;如果没有,则向权威 DNS 查询。
  4. 权威 DNS 解析 www.baidu.com 时,返回域名对应的 CNAME www.baidu.com
  5. 域名解析请求发送至 CDN 的 DNS 调度器,并根据 Local DNS 的信息为请求分配最佳节点IP地址。
  6. Local DNS 获取 DNS 返回的解析 IP 地址。
  7. 用户获取解析 IP 地址,向获取的 IP 地址发起对该资源的访问请求。
  8. 如果 CDN 该 IP 地址有缓存对应的内容,则直接返回给用户。
  9. 如果该 IP 没有对应的缓存,则会向上一级缓存节点或源站请求内容,直到将内容返回给用户。
文章分类
前端
文章标签