CDN技术介绍

一、CDN概述

1.1 CDN定义

CDN即Content Delivery Network （内容分发网络）。CDN是建立在现有IP网络基础结构之上的一种增值网络。是在应用层部署的一层网络架构。

CDN技术实现将多点负载均衡，路由或缓存技术结合起来，利用智能分配技术，将内容根据来访用户的地点，按照就近访问的原则分配到多个节点。

在传统的IP网络中，用户请求直接指向基于网络地址的原始服务器，而CDN业务提供了一个服务层，补充和延伸了Internet网络，把频繁访问的内容尽可能向用户推进，提供了处理基于内容进行流量转发的新能力，把路由导引到最佳服务器上。动态获得需要的内容。它改变了分布到使用者信息的方式，从被动的内容恢复转为主动的内容转发。

1.2 CDN的实现原理

在描述CDN的实现原理，让我们先看传统的未加缓存服务的访问过程，以便了解CDN缓存访问方式与未加缓存访问方式的差别：

用户提交域名→浏览器对域名进行解释→得到目的主机的IP地址→根据IP地址访问发出请求→得到请求数据并回复

由上可见，用户访问未使用CDN缓存网站的过程为:

1. 用户向浏览器提供要访问的域名；
2. 浏览器调用域名解析函数库对域名进行解析，以得到此域名对应的IP地址；
3. 浏览器使用所得到的IP地址，向域名的服务主机发出数据访问请求；
4. 浏览器根据域名主机返回的数据显示网页的内容。

通过以上4个步骤，浏览器完成从用户处接收用户要访问的域名到从域名服务主机处获取数据的整个过程。CDN网络是在用户和服务器之间增加Cache层，如何将用户的请求引导到Cache上获得源服务器的数据，主要是通过接管DNS实现，下面让我们看看访问使用CDN缓存后的网站的过程：

 

通过上图，我们可以了解到，使用了CDN缓存后的网站的访问过程变为：

1. 用户向浏览器提供要访问的域名；
2. 浏览器调用域名解析库对域名进行解析，由于CDN对域名解析过程进行了调整，所以解析函数库一般得到的是该域名对应的CNAME记录，为了得到实际IP地址，浏览器需要再次对获得的CNAME域名进行解析以得到实际的IP地址；在此过程中，使用的全局负载均衡DNS解析，如根据地理位置信息解析对应的IP地址，使得用户能就近访问；
3. 此次解析得到CDN缓存服务器的IP地址，浏览器在得到实际的IP地址以后，向缓存服务器发出访问请求；
4. 缓存服务器根据浏览器提供的要访问的域名，通过Cache内部专用DNS解析得到此域名的实际IP地址，再由缓存服务器向此实际IP地址提交访问请求；
5. 缓存服务器从实际IP地址得得到内容以后，一方面在本地进行保存，以备以后使用，另一方面把获取的数据返回给客户端，完成数据服务过程；
6. 客户端得到由缓存服务器返回的数据以后显示出来并完成整个浏览的数据请求过程。

通过以上的分析我们可以得到，为了实现既要对普通用户透明(即加入缓存以后用户客户端无需进行任何设置，直接使用被加速网站原有的域名即可访问，又要在为指定的网站提供加速服务的同时降低对ICP的影响，只要修改整个访问过程中的域名解析部分，以实现透明的加速服务，下面是CDN网络实现的具体操作过程。

1. 作为ICP，只需要把域名解释权交给CDN运营商，其他方面不需要进行任何的修改；操作时，ICP修改自己域名的解析记录，一般用cname方式指向CDN网络Cache服务器的地址。
2. 作为CDN运营商，首先需要为ICP的域名提供公开的解析，为了实现sortlist，一般是把ICP的域名解释结果指向一个CNAME记录；
3. 当需要进行sortlist时，CDN运营商可以利用DNS对CNAME指向的域名解析过程进行特殊处理，使DNS服务器在接收到客户端请求时可以根据客户端的IP地址，返回相同域名的不同IP地址；
4. 由于从cname获得的IP地址，并且带有hostname信息，请求到达Cache之后，Cache必须知道源服务器的IP地址，所以在CDN运营商内部维护一个内部DNS服务器，用于解释用户所访问的域名的真实IP地址；
5. 在维护内部DNS服务器时，还需要维护一台授权服务器，控制哪些域名可以进行缓存，而哪些又不进行缓存，以免发生开放代理的情况。

二、CDN技术详解

2.1 引言  

“第一公里”是指万维网流量向用户传送的第一个出口，是网站服务器接入互联网的链路所能提供的带宽。这个带宽决定了一个网站能为用户提供的访问速度和并发访问量。如果业务繁忙，用户的访问数越多，拥塞越严重，网站会在最需要向用户提供服务时失去用户。“中间一公里” 和“最后一公里”分别代表互联网传输和万维网流量向用户传送的最后一段接入链路。

从互联网的架构来看，不同网络之间的互联互通带宽，对任何一个运营商网络的流量来说，占比都比较小，收敛比是非常高的，因此这里通常都是互联网传输中的拥堵点（运营商互联互通的问题）。

其次是骨干网堵塞问题，由于互联网上的绝大部分流量都要通过骨干网络进行传输，这就要求骨干网络的承载能力必须与互联网的应用同步发展，但实际上两者并不是同步的，当骨干网络的升级和扩容滞后于互联网之上的应用的发展时，就会阶段性地使得大型骨干网的承载能力成为影响互联网性能的瓶颈（区域互联互通问题，骨干网带宽瓶颈）

在互联网领域有一个“8秒定律”，用户访问一个网站时，如果等待网页打开的时间超过8秒，会有超过30%的用户放弃等待。

使用CDN会极大简化网站的系统维护工作量，网站维护人员只需将网站内容注入CDN的系统，通过CDN部署在各个物理位置的服务器进行全网分发，就可以实现跨运营商、跨地域的用户覆盖

对于电信运营商，CDN是真正体现管道智能化的技术

2.2 CDN技术概述

2.2.1 关键技术

缓存算法决定命中率、源服务器压力、POP节点存储能力。分发能力取决于IDC能力和IDC策略性分布。负载均衡（智能调度）决定最佳路由、响应时间、可用性、服务质量。基于DNS的负载均衡以CNAME实现[to cluster]，智取最优节点服务，缓存点有客户端浏览器缓存、本地DNS服务器缓存。缓存内容有DNS地址缓存、客户请求内容缓存、动态内容缓存。支持协议如静动态加速（图片加速、https带证书加速）、下载加速、流媒体加速、企业应用加速、手机应用加速。

CDN关键技术：

1. 缓存算法[Squid]；

2. 分发能力；

3. 负载均衡[Nginx]

4. 基于DNS[BIND]；

5. 支持协议；

2.2.2 详细介绍

CDN提供一种机制，当用户请求内容时，该内容能够由以最快速度交付的Cache来向用户提供，这个挑选“最优”的过程就叫做负载均衡。

从功能上看，典型的CDN系统由分发服务系统，负载均衡系统和运营管理系统组成。

分发服务系统：最基本的工作单元就是Cache设备，cache（边缘cache）负责直接响应最终用户的访问请求，把缓存在本地的内容快速地提供给用户。同时cache还负责与源站点进行内容同步，把更新的内容以及本地没有的内容从源站点获取并保存在本地。Cache设备的数量、规模、总服务能力是衡量一个CDN系统服务能力的最基本的指标。

负载均衡系统：主要功能是负责对所有发起服务请求的用户进行访问调度，确定提供给用户的最终实际访问地址。两级调度体系分为全局负载均衡（GSLB）和本 地负载均衡（SLB）。GSLB主要根据用户就近性原则，通过对每个服务节点进行“最优”判断，确定向用户提供服务的cache的物理位置。SLB主要负 责节点内部的设备负载均衡。

运营管理系统：分为运营管理和网络管理子系统，负责处理业务层面的与外界系统交互所必须的收集、整理、交付工作，包含客户管理、产品管理、计费管理、统计分析等功能。

负责为用户提供内容服务的cache设备应部署在物理上的网络边缘位置，即CDN边缘层。CDN系统中负责全局性管理和控制的设备组成中心层（二级缓存），中心层同时保存着最多的内容副本，当边缘层设备未命中时，会向中心层请求，如果在中心层仍未命中，则需要中心层向源站回源（如果是流媒体，代价很大）。

CDN骨干点和CDN POP点在功能上不同，中心和区域节点一般称为骨干点，主要作为内容分发和边缘未命中时的服务点；边缘节点又被称为POP（point of presence）节点，CDN POP点主要作为直接向用户提供服务的节点。

2.2.3 协议加速

应用协议加速：企业应用加速主要是动态加速和SSL加速

广域网应用加速：

SSL应用加速：由于需要大量的加密解密运算，SSL应用对服务器端的资源消耗是非常巨大。CDN提供SSL应用加速后，由CDN的专用SSL加速硬件来完成加密解密运算工作。

网页压缩：HTTP1.1提出对网页压缩的支持。在服务器端可以先对网页数据进行压缩，然后将压缩后的文件提供给访问用户，最后在用户浏览器端解压显示（但要衡量加解压时间）。

2.3 内容缓存工作原理

 有CDN前的网站服务技术：

• 硬件扩展：高成本，灵活性和可扩展性比较差。
• 镜像技术（mirroring）：镜像服务器安装有一个可以进行自动远程备份的软件，每隔一定时间，各个镜像服务器就会到网站的源服务器上去获取最新的内容。
• 缓存技术（caching）：缓存代理缓存被访问过的内容，后续的相同内容访问直接通过缓存代理获得服务。

CDN是缓存技术的基础上发展起来的，是缓存的分布式集群实现。

从技术层面看，Web架构的精华有3处：

• 超文本技术HTML实现信息与信息的连接；
• 统一资源标志符URI实现全球信息的精确定位；
• 应用层协议HTTP实现分布式的信息共享。

HTTP1.1采用了效率更高的持续连接机制，即客户端和服务器端建立TCP连接后，后续相关联的HTTP请求可以重复利用已经建立起来的TCP连接，不仅整个Web页面（包括基本的 HTML文件和其他对象）可以使用这个持续的TCP连接来完成HTTP请求和响应，而且同一个服务器内的多个Web页面也可以通过同一个持续TCP连接来 请求和响应。通常情况下，这个持续的TCP连接会在空闲一段特定的时间后关闭，而这个最大空闲时间时可以设置的（连接复用）。

HTTP协议中的缓存技术：新鲜度（时间值）和验证（验证信息如ETag或last-modified）时确定内容可否直接提供服务的最重要依据。如果缓存内容足够新鲜，缓存的内容就能直接满足HTTP访问的需求了；如果内容过期，而经源服务器验证后发现内容没有发生变化，缓存服务器也会避免将内容从源服务器重新传输一遍。

验证的目的就是检验缓存内容是否可用。当中间缓存存在一个过期的缓存内容，并且对应的访问请求到达时，缓存应该首先向源服务器或者其他保存有未过期的缓存服务器请求验证来确定本地的缓存内容是否可用。（缓存内容过期，但源服务器没有更新内容，即缓存内容仍可用）。

• Web缓存代理软件：Squid；
• 负载均衡软件：Nginx；
• DNS服务器软件：BIND。

2.4 集群服务与负载均衡 

WEB 集群与负载均衡，基本概念，Web集群是由多个同时运行同一个web应用的服务器组成，在外界看来就像一个服务器一样，这多台服务器共同来为客户提供更高性能的服务。集群标准的定义是：一组相互独立的服务器在网络中表现为单一的系统，并以单一系统的模式加以管理，此单一系统为客户工作站提供高可靠性的服务。

负载均衡的任务就是负责多个服务器之间（集群内）实现合理的任务分配，使这些服务器（集群）不会出现因某一台超负荷、而其他的服务器却没有充分发挥处理能力的情况。负载均衡有两个方面的含义：首先，把大量的并发访问或数据流量分担到多台节点上分别处理，减少用户等待响应的时间；其次，单个高负载的运算分担到多台节点上做并行处理，每个节点设备处理结束后，将结果汇总，再返回给用户，使得信息系统处理能力可以得到大幅度提高。

因此可以看出，集群和负载均衡有本质上的不同，它们是解决两方面问题的不同方案，不要混淆。

集群技术可以分为三大类：

1、高性能性集群(HPC Cluster)；

2、高可用性集群(HA Cluster)；

3、高可扩展性集群。

 2.4.1 高性能性集群

指以提高科学计算能力为目标的集群技术。该集群技术主要用于科学计算。

 2.4.2 高可用性集群

指为了使群集的整体服务尽可能可用，减少服务宕机时间为目的的集群技术。如果高可用性集群中的某节点发生了故障，那么这段时间内将由其他节点代替它的工作。当然对于其他节点来讲，负载相应的就增加了。

为了提高整个系统的可用性，除了提高计算机各个部件的可靠性以外，一般情况下都会采用该集群的方案。

对于该集群方案，一般会有两种工作方式：主主和主从。

2.4.2.1 主主工作方式

主-主(Active-Active)工作方式：

这是最常用的集群模型，它提供了高可用性，并且在只有一个节点时也能提供可以接受的性能，该模型允许最大程度的利用硬件资源。每个节点都通过网络对客户机提供资源，每个节点的容量被定义好，使得性能达到最优，并且每个节点都可以在故障转移时临时接管另一个节点的工作。所有的服务在故障转移后仍保持可用，但是性能通常都会下降。

     

这是目前运用最为广泛的双节点双应用的Active/Active模式。

支撑用户业务的应用程序在正常状态下分别在两台节点上运行，各自有自己的资源，比如IP地址、磁盘阵列上的卷或者文件系统。当某一方的系统或者资源出现故障时，就会将应用和相关资源切换到对方的节点上。

这种模式的最大优点是不会有服务器的“闲置”，两台服务器在正常情况下都在工作。但如果有故障发生导致切换，应用将放在同一台服务器上运行，由于服务器的处理能力有可能不能同时满足数据库和应用程序的峰值要求，这将会出现处理能力不够的情况，降低业务响应水平。

2.4.2.2 主从工作方式

 主-从(Active-Standby)工作方式：

 为了提供最大的可用性，以及对性能最小的影响，主-从工作方式需要一个在正常工作时处于备用状态的节点，主节点处理客户机的请求，而备用节点处于空闲状态，当主节点出现故障时，备用节点会接管主节点的工作，继续为客户机提供服务，并且不会有任何性能上影响。

         

两节点的Active/Standby模式是HA中最简单的一种，两台服务器通过双心跳线路组成一个集群。应用Application联合各个可选的系统组件如：外置共享的磁盘阵列、文件系统和浮动IP地址等组成业务运行环境。

PCL为此环境提供了完全冗余的服务器配置。这种模式的优缺点：

缺点：Node2在Node1正常工作时是处于“闲置”状态，造成服务器资源的浪费。

优点：当Node1发生故障时，Node2能完全接管应用，并且能保证应用运行时的对处理能力要求。

2.4.3 高可扩展性集群

这里指带有负载均衡策略（算法）的服务器群集技术。带负载均衡集群为企业需求提供了更实用的方案，它使负载可以在计算机集群中尽可能平均地分摊处理。而需要均衡的可能是应用程序处理负载或是网络流量负载。该方案非常适合于运行同一组应用程序的节点。每个节点都可以处理一部分负载，并且可以在节点之间动态分配负载，以实现平衡。对于网络流量也是如此。通常，单个节点对于太大的网络流量无法迅速处理，这就需要将流量发送给在其它节点。还可以根据每个节点上不同的可用资源或网络的特殊环境来进行优化。

负载均衡集群在多节点之间按照一定的策略（算法）分发网络或计算处理负载。负载均衡建立在现有网络结构之上，它提供了一种廉价有效的方法来扩展服务器带宽，增加吞吐量，提高数据处理能力，同时又可以避免单点故障。

 

2.5 负载均衡

负载均衡就是智能调度。

负载均衡的任务就是负责多个服务器之间（集群内）实现合理的任务分配，使这些服务器（集群）不会出现因某一台超负荷、而其他的服务器却没有充分发挥处理能力的情况。

负载均衡有两个方面的含义：首先，把大量的并发访问或数据流量分担到多台节点上分别处理，减少用户等待响应的时间；其次，单个高负载的运算分担到多台节点上做并行处理，每个节点设备处理结束后，将结果汇总，再返回给用户，使得信息系统处理能力可以得到大幅度提高。

2.5.1 全局负载均衡

全局负载均衡（GSLB）的负载均衡主要是在多个节点之间进行均衡，其结果可能直接终结负载均衡过程，也可能将用户访问交付下一层次的（区域或本地）负载均衡系统进行处理。GSLB最通用的是基于DNS解析方式、HTTP重定向、IP路由等方法。

2.5.1.1 DNS

DNS就是IP地址和网址互换。

当需要访问abc.com这个站点时，实际上我们想要浏览的网页内容都存放在互联网中对应某个IP的服务器上，而浏览器的任务就是找到我们想要访问的这台服务器的IP地址，然后向它请求内容。

本地DNS服务器（local DNS server）是用户所在局域网或ISP网络中的域名服务器。当客户端在浏览器里请求abc.com时，浏览器会首先向本地DNS服务器请求将 abc.com解析成IP地址，本地DNS服务器再向整个DNS系统查询，直到找到解析结果。

DNS给使用它的互联网应用带来额外的时延，有时时延还比较大，为了解决问题，需要引入“缓存”机制。缓存是指DNS查询结果在主机（local DNS server）中缓存。在区内主机对某个域名发起第一次查询请求时，负责处理递归查询的DNS服务器要发送好几次查询（先查.root，再查.com之 类，再定位IP地址等）才能找到结果，不过在这过程中它也得到了许多信息，比如各区域权威DNS服务器（就是告诉你最终abc.com在哪里的DNS服务 器）和它们的地址、域名解析最终结果。他会把这些信息保存起来，当其他主机向它发起查询请求时，它就直接向主机返回缓存中能够找到的结果，直到数据过期。

客户端浏览器也可以缓存DNS响应信息。

Internet类资源记录分为：

• A记录（address）：域名->多个IP的映射。对同一个域名，可以有多条A记录；
• NS记录（name server）：指定由哪台DNS服务器来解析；
• SOA记录（start of authority）：指定该区域的权威域名服务器；
• CNAME记录（canonical name）：多个域名->服务器的映射；
• PTR记录（pointer record）：IP->域名的映射；

2.5.1.2 负载均衡

DNS系统本身是具备简单负载分配能力的，这是基于DNS的轮询机制。如果有多台Web服务器（多源）同时为站点 abc.com提供服务，abc.com的权威服务器可能会解析出一个或多个IP地址。权威域名服务器还可以调整响应中IP地址的排列方式，即在每次响应中将不同的IP地址置于首位（取决于可服务能力和服务质量），通过这种方式实现对这些Web服务器的负载均衡

通过CNAME方式实现负载均衡：域名服务器获得CNAME记录后，就会用记录中的别名来替换查找的域名或主机名（实现多个域名->服务器映射）。后面会查询这个别名的A记录来获取相应的IP地址。

具体操作为：先将GSLB的主机名定义为所查询域名的权威DNS服务器的别名，然后将GSLB主机名添加多条A记录，分别对应多个服务器的IP地址。这样，本地DNS服务器会向客户端返回多个IP地址作为域名的查询结果，并且这些IP地址的排列顺序是轮换的。客户端一般会选择首个IP地址进行访问。

负载均衡器作为权威DNS服务器：负载均衡器就会接收所有对这个域名的DNS请求，从而能够根据预先设置的一些策略来提供对域名的智能DNS解析。F5的DNS具有完整的DNS功能以及增强的GSLB特性。

负载均衡作为代理DNS服务器：负载均衡器被注册为一个域名空间的权威DNS服务器，而真正的权威域名服务器则部署在负载均衡器后面。所有的DNS请求都会先到达负载均衡器，由负载均衡器转发到真正的权威DNS服务器，然后修改权威DNS服务器返回的响应信息。真正的权威 DNS服务器正常响应浏览器的DNS请求，返回域名解析结果列表，这个响应会先发送到负载均衡器，而负载均衡器会根据自己的策略选择一个性能最好的服务器 IP并修改需要实现GSLB的域名的DNS查询响应，对其他请求透明转发，这样就不会影响整个域名空间的解析性能。

在基于DNS方式下无论采用何种工作方式，都会有一些请求不会到达GSLB，这是DNS系统本身的缓存机制在起作用。当用户请求的域名在本地DNS或本机（客户端浏览器）得到了解析结 果，这些请求就不会达到GSLB。Cache更新时间越短，用户请求达到GSLB的几率越大。由于DNS的缓存机制屏蔽掉相当一部分用户请求，从而大大减轻了GSLB处理压力，使得系统抗流量冲击能力显著提升，这也是很多商业CDN选择DNS机制做全局负载均衡的原因之一。但弊端在于，如果在DNS缓存刷新间隔之内系统发生影响用户服务的变化，比如某个节点故障，某个链路拥塞等，用户依然会被调度到故障部位去

2.5.2 智能DNS

智能DNS功能，它在向本地DNS返回应答之前会先根据一些静态或动态策略进行智能计算。

• 服务器的“健康状况”；
• 地理区域距离；
• 会话保持；
• 响应时间；
• IP地址权重；
• 会话能力阈值；
• 往返时间（TTL）；
• 其他信息，包括服务器当前可用会话数、最少选择次数、轮询等。

2.5.3 GSLB的部署问题

关于内容的缓存问题（如何智能调度最有效）和配置

在有些CDN中（用于视频网站加速的情况较多），网站需要加速的内容全部先缓存在OCS（内容中心），然后再将一部分 （通常是热门的内容）分发到个POP节点（Cache边缘集群），所以POP节点在某些时候会出现本地未命中而需要回OCS取内容或者从其他POP节点取内容的情况

纯粹基于DNS方式的GSLB只能完成就近性判断。为实现智能调度，大多数解决方案需要在GSLB设备附近以旁路的方式部署一台辅助设备（为方便描述，我们可称之为GRM——全局资源管理设备），用以实现和各POP节点的本地资源管理设备进行通信，完成CDN对各POP节点的状态检查，并根据POP节点的状态和流量情况，重新制订用户调度策略，将策略实时发送到GSLB中去执行。

因为DNS服务采用以UDP为基础的、默认无连接的访问方式，给分布式攻击（DDoS）带来了更大的便利。

隐藏节点的存在很大程度上可以避免GSLB被攻击致瘫痪的机会，实际隐藏节点的实现方法就是在实际组网时除了部署正常工作的GSLB以外，再部署一台备份的GSLB设备，并将这一备份GSLB设备隐藏起来，不对外公布。

HTTP重定向（CDN GSLB用302重定向）：在HTTP协议中，有三类重定向状态吗：301永久性转移（permanently moved）、302暂时转移（temporarily moved）、meta fresh在特定时间后重定向到新的网页。

HTTP重定向只适用于HTTP应用，不适用于任何其他应用。比如微软的MMS协议，RTSP协议，就不能使用这种方式进行重定向。其次，由于HTTP重定向过程需要额外解析域名URL，还需要与URL建立TCP连接并且发送HTTP请求，使得响应时间加长。不同于 DNS方式，没有任何用户请求能被外部系统终结（不能缓存），所有请求都必须进入GSLB系统，这将成为性能和可靠性的瓶颈。（流媒体用的比较多）。

2.5.4 基于IP路由的GSLB

基于路由协议算法选择一条路由到达这两个本地均衡器中的一个。因为每次访问请求的终端IP地址不同，路由条件也不同，所以在多个路由器上优选的路由不同，从统计复用的角度来看基本是在负载均衡器1和2之间均匀分布的。

IP路由在多个POP点之间实现的负载均衡是一种概率上的均衡，而不是真正的均衡（没做智能调度）。

比较项

基于DNS解析方式

基于HTTP重定向方式

基于IP路由方式

性能

本地DNS服务器和用户终端DNS缓存能力使GSLB的负载得到有效分担

GSLB处理压力大，容易成为系统性能的瓶颈

借助IP网络设备完成负载均衡，没有单点性能瓶颈

准确度

定位准确度取决于本地DNS覆盖范围，本地DNS设置错误会造成定位不准确

在对用户IP地址数据进行有效维护的前提下，定位准确且精度高

就近性调度准确，但对设备健康性等动态信息响应会有延迟

效率

效率约等于DNS系统本身处理效率

依靠服务器做处理，对硬件资源的要求高

效率约等于IP设备本身效率

扩展性

扩展性和通用性好

扩展性较差，需对各种应用协议进行定制开发

通用性好，但适用范围有限

商用性

在Web加速领域使用较多

国内流媒体CDN应用较多

尚无商用案例

 

三、流媒体CDN系统的组成

3.1 流媒体

流媒体业务是一种对实时性、连续性、时序性要求非常高的业务，无论从带宽消耗上还是质量保障上来说，对best-effort的IP网络都是一个不小的冲击。

• 高带宽要求
• 高QoS要求
• 组播、广播要求（目前IP网络无法实现端到端的组播业务）

播放一个视频分为以下4个步骤

1. Access；
2. Demux（音视频分离）；
3. Decode（解码解压缩）；
4. Output。

3.2 协议

3.2.1 RTP相关

 

RTCP：Real-time Transport Control Protocol或RTP Control Protocol或简写RTCP；

RTP：Real-time Transport Protocol；

RTSP：Real Time Streaming Protocol；

RTP、RTCP、RTSP、RTMP的关系：RTSP协议用来实现远程播放控制，RTP用来提供时间信息和实现流同步，RTCP协助RTP完成传输质量控制<=（播放控制），

=>（传输控制）RTMP和HTTP streaming则是将流同步、播放控制、质量控制集成起来的企业自有流媒体传送协议。

RTMP协议架构在TCP层之上，但RTMP消息并不是直接封装在TCP中，而是通过一个被称为消息块的封装单元进行传输。消息在网络上发送之前往往需要分割成多个较小的部分，这样较小的部分就是消息块，属于不同消息流的消息块可以在网络上交叉发送。

RTSP/RTP和HTTP streaming是目前应用最广泛的流化协议，目前电信运营商在IPTV（特殊通道的基于IP的流媒体播放）的流化上主要以RTSP/RTP技术为主，而互联网视频网站（点播/直播）则多倾向于使用HTTP streaming的流化技术。

3.2.2 HTTP streaming

HTTP streaming前身是progressive download（渐进式下载：边下载边播放，直到下载完）。HTTP streaming首先会将视频数据（包括直播的视频流和点播的视频文件）在服务器上进行编码，然后将编码后的数据进行更细粒度的分片，再把每个分片通过 HTTP协议传输到客户端。HTTP streaming的客户端需要对视频文件的每个分片都发出一个HTTP请求，这样，在视频播放速度低于下载速度的情况下，客户端可以灵活控制HTTP请 求的发出速度，从而保证用户在中途退出时不会出现下载浪费。另外，因为采用分片的特点，HTTP streaming还可以实现媒体播放过程中的码率切换（码率自适应），结合网络带宽资源，为用户提供更好的体验。

HTTP streaming

Progressive download

支持点播、直播

仅支持点播

可对分片文件加密，保证数字版权

直接把媒体文件分割成多个小文件分片，无法保障版权所有

因为分片传输，支持码率自适应

只支持固定码率

 

HTTP streaming

RTSP/RTP

基于TCP，更高可靠性，也可以直接利用TCP的流控机制来适应带宽的变化

基于UDP

可将播放过的内容保存在客户端

不能保存在客户端

使用80端口，能穿越防火墙

使用特殊端口

采用标准的HTTP协议来传输，只需要标准的HTTP服务器支撑

需要特殊的流媒体服务器

• HTTP streaming的几个主流阵营：
• 3GPP adaptive HTTP Streaming
• Microsoft IIS Smooth Streaming
• Adobe HTTP Dynamic Streaming (HDS)
• Apple HTTP Live Streaming (HLS)

3.2.2.1 HLS

HLS流化技术主要分三个部分：服务器组件、分发组件和客户端软件。

服务器组件主要负责从原始的音视频设备捕捉相应的音视频流，并对这些输入的媒体流进行编码，然后进行封装和分片，最后交付给分发组件来进行传送；

分发组件主要负责接收客户端发送的请求，然后将封装的流媒体分片文件连同相关的索引文件一起发送给客户端。对于没有采用CDN服务的源服务器，标准的Web服务器就是一个分发组件，而对于大型的视频网站或者类似的大规模应用平台，分发组件还应包括支持RTMP协议的CDN。

客户端软件负责确定应该请求的具体媒体流，下载相关资源，并在下载后通过拼接分片将流媒体重新展现给用户。

HLS音视频流或流媒体文件在经过编码、封装和分片后，变成多个以.ts结尾的分片文件。流分割器产生的索引文件是以.M3U8为后缀的，用户可以直接通过Web访问来获取。

分发组件负责将分片文件和索引文件通过HTTP的方式发送给客户端，无须对现有的Web服务器和Cache设备进行额外的扩展、配置和升级

客户端组件根据URL来获取这个视频的索引文件。索引文件包含了可提供分片文件的具体位置、解密密钥以及可用的替换流。

HDS，点播内容是通过一个简单的预编码生成MP4片段以及Manifest清单文件；直播的内容准备工作流程相对复杂一点，在播放的过程中生成MP4.（直播推荐用RTMP，使用FMS推流器）。

MPEG-2 TS是指TS格式封装的、MPEG-2编码格式的媒体流。大多数IPTV系统使用这种内容源。H.264这一层完成原始文件的压缩编码，TS这一层负责音 视频的复用以及同步，RTP这一层负责流的顺序传输，UDP这一层负责数据包的交付，IP层负责传输路由选择。

流媒体加速的回源要求：因为流媒体文件传送带宽需求高，而且往往需要维持TCP长连接，所以一旦CDN回源比例过高，源站服务器I/O将不堪负荷。CDN对内容采取分发方式分为pull和push两种。Pull是被动下拉的方式，push是主动推送的方式。对于流媒体内容，系统一般会选择对热点内容采取push方式的预分发，而普通的网页内容几乎100%是pull方式的。

在流媒体CDN系统中，用户访问的调度会更多考虑内容命中，主要是因为流媒体内容文件体积大，业务质量要求高，如果从其他节点拉内容再向用户提供服务会带来额外的延迟，影响用户体验。为进一步提高命中率，流媒体CDN系统普遍采用了对热点内容实施预先push的内容分发策略。

3.2.2.2 流媒体CDN与Web CDN

在流媒体服务系统中，主要关注的技术是对不同流媒体协议、不同编码格式、不同播放器、不同业务质量要求等的适应。

流媒体CDN与Web CDN的对比（业务差异）

主要差异点

流媒体CDN

Web CDN

内容类型

大文件、实时流、QoS要求高

小文件、固定大小、QoS要求低

用户行为

拖曳、暂停等播放控制

下载后浏览

内容管理

内容冷热度差异明显（对命中率要求高），内容生命周期长

内容冷热度差异不明显，内容生命周期短

回源要求

回源比例小

回源比例大

现在已经投入商用的CDN系统，基本都是同时提供Web CDN能力和流媒体CDN能力的，而且这两种能力的实现在系统内部几乎都是互相隔离的，从调度系统到节点设备都没有交叉互用。

流媒体CDN与Web CDN的设计差异（设计差异）：

主要差异点

流媒体CDN

Web CDN

Cache

支持多种流化协议，硬件配置大存储、高I/O

支持多协议（HTTP、FTP等）硬件配置小存储、高性能CPU

负载均衡

DNS+HTTP重定向方式

DNS方式

内容分发方式

热片PUSH，冷片PULL

全PULL方式

组网

多级组网，可能要求组播、单播混合组网

两级组网

3.2.3 缓存和部署

流媒体CDN的Cache设备与Web Cache无论在软件实现还是硬件要求上差异都很大，我们很少看到这两种业务共用同一台设备。

当用户请求的内容在Cache上命中时，Cache直接向用户提供流服务，此时Cache设备充当流媒体服务器的角色； 当用户请求内容未能在Cache上命中时，Cache会从上一级Cache（二级缓存设备或中间缓存设备）或者源站服务器获取内容，再提供给用户。 Cache在用户与另一个流媒体服务器之间扮演代理的角色。

分布式存储技术因其大容量、低成本的特点，目前也被业界关注和研究作为流媒体CDN系统的存储解决方案之一。常用的分布式存储技术包括分布式文件系统和分布式数据库，由于采用了数据副本冗余（每份数据复制2~3份）、磁盘冗余（Raid1、Raid10、Raid5）等技术，通常可以提供良好的数据容错机制，当单台存储设备断电或者单个存储磁盘失效时，整个存储系统仍能正常工作。

负载均衡设备在进行用户访问调度时，会综合考虑很多静态的、动态的参数，包括IP就近性、连接保持、内容命中、响应速度、连接数等。但没有哪个CDN会考虑所有参数，而是会根据业务特点进行一些取舍，否则均衡系统就太复杂了。而流媒体CDN在进行用户访问调度时，会更多考虑内容命中这一参数。

从网络分层上看，Web CDN通常是两级架构（也有三级架构以减少回源），即中心-边缘。而流媒体CDN通常有三级以上架构，即中心-区域-边缘。产生这种区别的原因在于流媒体 回源成本比较高，源站服务器响应一次流媒体内容回源请求，要比Web内容回源消耗更多资源。尤其对于流媒体直播业务来说，只要直播节目没结束，服务器就需 要长时间持续吐流，如果没有第二层节点作为中继，那么中心节点的压力将是不可想象的。

分层部署的方式，对点播业务而言的主要意义是节省存储成本，对直播业务而言在于减少带宽成本。在点播业务中，边缘Cache只需存储用户访问量大的内容或者内容片断，其余内容存储在区域Cache中。

在直播业务中，边缘Cache从区域中心获取直播流，而不需要直接向中心节点（源站）获取，从而节省了区域中心到中心节点这一段的大部分带宽。因为直播流在各个Cache中都不需要占用很大的存储空间，只需少量缓存空间即可，所以直播业务方面并不用注重考虑存储成本。

考虑到电信运营商的IP拓扑和流量模型，区域中心Cache通常部署在重点城市的城域网出口的位置，以保障向各个边缘 Cache的链路通畅。边缘Cache的位置选择则以整个节点能够提供的并发能力为主要依据，依据业务并发数收敛比，计算出单个Cache需要覆盖的用户 规模，从而选择一个合适的部署位置。当然，边缘Cache离用户越近，服务质量越好，但覆盖的用户数越少，部署成本越高。

3.2.4 内容文件预处理

是指视频内容进入CDN以后，进入内容分发流程之前，CDN系统对内容进行的一系列处理过程。这个预处理过程的目的有几个：

• 为全网内容管理提供依据，比如对内容进行全网唯一标识，对内容基础信息进行记录等；
• 为提高CDN服务效率或降低系统成本提供手段，比如内容切片；
• 为满足业务要求提供能力，比如对同一内容进行多种码率的转换以满足动态带宽自适应或三屏互动业务要求。

视频转码(video transcoding)

• 码率转换
• 空间分辨率转换
• 时间分辨率转换
• 编码格式转换。编码格式主要包括H.264、MPEG-4、MPEG-2、VC-1、REAL、H.263、WMV。通常是把其他编码格式转换成H.264

3.2.5 文件切片

文件切片是指按照一定的规则把一个完整的文件切成大小一致的若干个小文件。由于流媒体CDN需要提供的内容体积越来越大，传统整片存储带来的成本消耗超出了CDN服务商的承受范围。切片的另一个目的是，使边缘Cache能够支持自适应码率业务。

防盗链机制和实现

• 基于IP的黑白名单；
• 利用HTTP header的referer字段；
• 使用动态密钥（随机生成的key通过算法生成新的url）；
• 在内容中插入数据（对有版权内容进行加密（DRM），如Microsoft的playready，Google的Widevine）；
• 打包下载：在原文件的基础上进一步封装，使得资源的hash 值改变。

四、动态内容加速服务的实现

4.1 WEB

随着Web2.0的兴起，产生了动态网页、个性化内容、电子交易数据等内容的加速，这些就涉及了动态内容加速技术。

4.2 动态加速

静态内容的加速，都是对于表现层的加速，对于动态页面等内容的加速，则要涉及逻辑层和数据访问层的加速技术。动态内容的提供不仅仅是HTML页面的设计及编辑，它还需要有后台数据库、应用逻辑程序的支持，以实现与用户的动态交互。

Web系统由表现层、业务逻辑层、数据访问层+用户数据层。

表现层是Web系统与外部系统的交互界面，这一层通常由HTTP服务器组成，负责接收用户端的HTTP内容访问请求，从文件系统中读取静态文件。

业务逻辑层负责处理所有业务逻辑和动态内容的生成。

数据访问层位于系统的后端，负责管理Web系统的主要信息和数据存储，通常由数据库服务器和存储设备组成。

用户数据层负责存储用户信息数据和关联关系，内容来自用户提供和用户行为分析结果。

Web网站借助CDN技术能够获得更好的扩展性和高性能，核心在于CDN采用的缓存（caching）和复制（replication）机制，其中缓存是将最近经常被访问的源服务器拥有的内容复制到边缘服务器上，可被视为具有特定策略的复制。

CDN的复制机制是指将源Web系统逻辑架构的各个层次的相应功用复制到边缘服务器上实现，以缓解源系统的处理压力。

Web系统表现层的复制，就是静态内容的复制。边缘服务器又被称为代理服务器，通过反向代理加速静态文件的交付。

• Web系统业务逻辑层的复制。CDN被用于改进动态生成内容的交付性能。即将应用程序和业务组件直接在CDN的边缘服务器中计算，从而直接在靠近用户的地方生成动态Web内容
• Akamai边缘计算部署模型，包括用户（使用浏览器）、企业J2EE应用系统（运行业务逻辑、原有系统、数据库等）、分布式网络服务器（Edge computing平台）运行支持J2EE应用编程模型的WebSphere或者Tomcat应用服务器
• Web系统数据访问层复制。CDN边缘服务器能够具备生成动态内容和掌管内容生成数据的能力
• 利用边缘服务器代替源钻Web系统的后台数据访问层中的数据库系统，及时响应业务逻辑层提出的数据查询需求。
• Web系统用户文件的复制。

4.3 应用加速

应用加速技术实际上是传统的网络负载均衡的升级和扩展，综合使用了负载均衡（智能调度）、TCP优化管理（TCP keep-alive connection，更激进的TCP窗口策略，基于HTTP1.1），链接管理（routing）、SSL VPN、压缩优化（代码压缩，图片压缩）、智能网络地址（NAT-公私网IP转换）、高级路由、智能端口镜像等技术。

TCP的问题：

• TCP窗口大小的限制（TCP窗口大小随传输成功而变大，而一旦发生传输失败，其窗口大小会立即缩小）；
• TCP协议慢启动（三握手）和拥塞控制。

广域网加速关键技术：

针对层次

优化技术

优化原理

传输发起端

原始数据优化

通过压缩、重复数据删除和字典等技术，可节省绝大多数传输数据量，节约带宽，提高服务器性能

数据缓存技术

将类HTTP的业务、图片、文字等缓存在本地，只传输动态内容，减少带宽占用

物理层（硬件）

提升设备性能

基于现有TCP/IP，通过硬件方式提高性能，提高大量TCP并发连接和会话重组等处理能力

网络层（IP）

QoS和流量控制

通过协议识别，实现在同一端口中不同应用的真正区分，进而通过分流实现时延敏感应用的带宽保障

传输层（TCP）

代理设备

在传输两端各架设代理设备，所有的响应报文都在本地完成，只有真正发起请求时才通过链路，相当于同时在服务器和客户端进行协议欺骗

 

TCP协议优化

通过在广域网两端部署专用设备，在不影响基本传输情况下，通过各种手段对TCP窗口、响应、启动等机制进行改进，从而提高协议机制的效率

应用层

应用代理（缓存）

将常用的应用程序缓存在本地并配置好，用户可不用在本地等待类似于认证等会话过程，而是直接开始下一个应用，实现流水作业

数据碎片化，就是在应用层将数据分成一个个小的数据块，便于后续的数据比对使用。广域网加速设备在传输数据前会将缓存中的数据与数据切块进行对比，从而找出那些数据是重复数据，不再发送，哪些数据是新鲜的、需要传输的数据。

数据压缩和指针技术一般是放在一起使用的，在对数据分段后，会对每一段数据生成一个数据指针，对于重复内容，只传输指针。在压缩算法设计上，要求同时兼顾数据压缩比和压缩/解压缩时间。

高速TCP传输技术

• 自适应拥塞窗口；
• 有限制地快速重传；
• 连接池：通过维护一个预先建立好的TCP连接池，当有数据传输需求时，从连接池中挑选一条可用连接今次那个传输。

4.4 SSL

SSL加速技术

• SSL加密是一种处理器密集型加密算法，如果用服务器软件处理会消耗大量CPU资源，一般会在提供业务能力的服务器外围部署专门的SSL加速设备，采用硬解密方式实现；
• SSL加密分对称秘钥和非对称秘钥（计算资源消耗更大）。

SSL的基本原理和实现

• 可认证性（authentication）；
• 隐私性（privacy）；
• 完整性（integrity）；
• 不可抵赖性（undeniability）：发送者不能自称没有发出过接受者从他那里收到的内容。

SSL加速

• 通常是基于硬件的SSL加速；
• 通过在服务器上安装一块SSL加速板卡，可有效分担服务器CPU处理SSL事务的压力。

五、卡顿问题

尽管已经采用了CDN加速，直播类App仍然经常出现访问慢、卡顿等问题，导致大量用户投诉，其主要原因是当前架构中存在问题。

5.1 无法就近接入

运营商Local DNS配置不合理导致无法就近接入。

5.2 用户手机网络制式切换

假设用户A从移动4G切换到家中联通的wifi网络，仍然按照原先的CDN节点进行加速会出现跨ISP调度，访问质量差的悲剧事件。通过用户使用的DNS服务器来判断客户端所在的网络位置，从而返回对应的服务IP。

5.3 BGP

BGP即Border Gateway Protocol（边界网关协议），业内简称BGP。BGP的技术原理往简单的说就是允许同一IP在不同网络中广播不同的路由信息，效果就是同一个IP，当电信用户来访问时走电信网内的路由，联通用户来访问时走的联通的路由。所以BGP技术对跨运营商的访问带来了巨大的便利，特别是直播场景。不同于传统的文件缓存场景，一个图片哪怕第一次是跨了遥远的距离从源站获取后，本地网络进行缓存，后面的访问都走本地网络。直播加速是流式的，并且当要做到低延迟的时候，中间的缓存要尽可能少。BGP相当于给跨网的用户就近搭建了一坐桥梁，不必绕远路，延时和稳定性都大大提高了。

在国内一般而言相同的接入运营商（电信、联通、移动）并且地理位置最近的情况网络延迟最优，小于15ms。跨省同运营商的网络延迟25~50ms，跨运营商情况更复杂一些，在50~100ms。总结起来，直播当中每个包的延时可以缩短100ms，由于网络的叠加效果，反射到上层是秒级的延迟缩减。

HTML5的设计目的是为了在移动设备上支持多媒体。新的语法特征被引进以支持这一点，如video、audio和canvas 标记。

5.4 解决办法

可以通过接入HTTPDNS解决，终端源站配合的解决方案。

 

下面通过推流阶段2个场景说明改进方案如何确保调度到最佳CDN节点。

5.4.1 用例1

Local DNS配置问题导致没有调度到最优节点的场景：

1. 用户手机上Local DNS配置不准确，域名解析阶段为域名dn返回的是CDN节点B的IP_b，而非最优的CDN节点IP IP_a；
2. 推流的终端应用需要向CDN节点发起鉴权请求，CDN节点在收到鉴权请求后，需要提取终端的公网IP_c，然后除了转发鉴权相关信息到视频源站之外，还必须带上推流终端的公网IP_c 给源站；
3. 源站收到鉴权信息和终端IP后，首先做鉴权工作，然后源站利用推流的域名dn和推流终端公网IP IP_c向HTTPDNS服务器发起请求，获取最优的CDN节点IP_a，并将IP_a回传给推流终端，告知推流终端IP_a是最佳接入节点；
4. 终端推流时可以直接向CDN IP_a推流，或者等到发现出现卡顿、慢时切换到IP_a。

5.4.2 用例2

用户网络制式切换（如移动4G切联通wifi）的场景

1. 假设之前移动4G网络下最佳CDN节点是IP_b，用户网络制式切换成联通wifi后，最佳节点换成了IP_a。网络切换后，终端第一步仍然向CDN节点IP_b推流，此时会鉴权失败；
2. 重复场景1的Step 2到Step 4，推流终端最终可以找到最佳CDN节点IP_a并通过IP_a推流。