CDN技术详解
一本好的入门书是带你进入陌生领域的明灯，《CDN技术详解》绝对是带你进入CDN行业的那盏最亮的明灯。因此，虽然只是纯粹的重点抄录，我也要把《CDN技术详解》的精华放上网。公诸同好。
第一章 引言
“第一公里”是指万维网流量向用户传送的第一个出口，是网站服务器接入互联网的链路所能分享的带宽。这个带宽决定了一个网站能为用户分享的访问速度和并发访问量。如果业务繁忙，用户的访问数越多，拥塞越严重，网站会在最需要向用户分享服务时失去用户。（还有“中间一公里”和“最后一公里”分别代表互联网传输传输和万维网流量向用户传送的最后一段接入链路）。
从互联网的架构来看，不同网络之间的互联互通带宽，对任何一个运营商网络的流量来说，占比都比较小，收敛比是非常高的，因此这里通常都是互联网传输中的拥堵点（运营商互联互通的问题）。
其次是骨干网堵塞问题，由于互联网上的绝大部分流量都要通过骨干网络进行传输，这就要求骨干网络的承载能力必须与互联网的应用同步发展，但实际上两者并不是同步的，当骨干网络的升级和扩容滞后于互联网之上的应用的发展时，就会阶段性地使得大型骨干网的承载能力成为影响互联网性能的瓶颈（区域互联互通问题，骨干网带宽瓶颈）。
在互联网领域有一个“8秒定律”，用户访问一个网站时，如果等待网页打开的时间超过8秒，会有超过30%的用户放弃等待。
使用CDN会极大简化网站的系统维护工作量，网站维护人员只需将网站内容注入CDN的系统，通过CDN部署在各个物理位置的服务器进行全网分发，就可以实现跨运营商、跨地域的用户覆盖。
对于电信运营商，CDN是真正体现管道智能化的技术。
第二章 CDN技术概述
CDN关键技术：
1. 缓存算法[Squid]；2. 分发能力；3. 负载均衡[Nginx]（4. 基于DNS[BIND]）；5. 支持协议；
缓存算法决定命中率、源服务器压力、POP节点存储能力
分发能力取决于IDC能力和IDC策略性分布
负载均衡（智能调度）决定最佳路由、响应时间、可用性、服务质量
基于DNS的负载均衡以CNAME实现[to cluster]，智取最优节点服务，
缓存点有客户端浏览器缓存、本地DNS服务器缓存
缓存内容有DNS地址缓存、客户请求内容缓存、动态内容缓存
支持协议如静动态加速（图片加速、https带证书加速）、下载加速、流媒体加速、企业应用加速、手机应用加速
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点主要作为直接向用户分享服务的节点
应用协议加速：企业应用加速主要是动态加速和SSL加速
广域网应用加速：
SSL应用加速：由于需要大量的加密解密运算，SSL应用对服务器端的资源消耗是非常巨大的。CDN分享SSL应用加速后，由CDN的专用SSL加速硬件来完成加密解密运算工作
网页压缩：HTTP1.1提出对网页压缩的支持。在服务器端可以先对网页数据进行压缩，然后将压缩后的文件分享给访问用户，最后在用户浏览器端解压显示（但要衡量加解压时间）
第三章 内容缓存工作原理
有CDN前的网站服务技术：
– 硬件扩展：高成本，灵活性和可扩展性比较差
– 镜像技术（mirroring）：镜像服务器安装有一个可以进行自动远程备份的软件，每隔一定时间，各个镜像服务器就会到网站的源服务器上去获取最新的内容
– 缓存技术（caching）：缓存代理缓存被访问过的内容，后续的相同内容访问直接通过缓存代理获得服务
– CDN：是缓存技术的基础上发展起来的，是缓存的分布式集群实现
从技术层面看，Web架构的精华有三处：
– 超文本技术HTML实现信息与信息的连接；
– 统一资源标志符URI实现全球信息的精确定位
– 应用层协议HTTP实现分布式的信息共享
TCP连接在每一次HTTP（HTTP 1.0）请求和响应完成后就关闭，如果客户端还要请求其他对象，需要重新为每个对象建立TCP连接。当一个Web页面内包含多个对象并全部显示时，客户端需要与服务器建立的TCP连接数较多，对整个时延和网络流量造成了较大的影响
HTTP1.1采用了效率更高的持续连接机制，即客户端和服务器端建立TCP连接后，后续相关联的HTTP请求可以重复利用已经建立起来的TCP连接，不仅整个Web页面（包括基本的 HTML文件和其他对象）可以使用这个持续的TCP连接来完成HTTP请求和响应，而且同一个服务器内的多个Web页面也可以通过同一个持续TCP连接来请求和响应。通常情况下，这个持续的TCP连接会在空闲一段特定的时间后关闭，而这个最大空闲时间时可以设置的（连接复用）。
HTTP协议中的缓存技术：新鲜度（时间值）和验证（验证信息如ETag或last-modified）时确定内容可否直接分享服务的最重要依据。如果缓存内容足够新鲜，缓存的内容就能直接满足HTTP访问的需求了；如果内容过期，而经源服务器验证后发现内容没有发生变化，缓存服务器也会避免将内容从源服务器重新传输一遍
如果要通过META标签来控制页面不缓存，一般情况下会在Web页面的<head>区域中增加”pragma:no-cache”
验证的目的就是检验缓存内容是否可用。当中间缓存存在一个过期的缓存内容，并且对应的访问请求到达时，缓存应该首先向源服务器或者其他保存有未过期的缓存服务器请求验证来确定本地的缓存内容是否可用。（缓存内容过期，但源服务器没有更新内容，即缓存内容仍可用）
HTTP1.1介绍了cache-control显示指令来让网站发布者可以更全面地控制他们的内容，并对过期时间进行限制（控制是否缓存，怎么缓存）
HTTP gzip压缩：大多数情况需要压缩的文件时网页中出现最频繁的HTML、CSS、javascript、XML等文件，这类本身是没有经过压缩的文本文件，可以取得较好的压缩效果
Web缓存代理软件：Squid
负载均衡软件：Nginx
DNS服务器软件：BIND
第四章 集群服务与负载均衡
WEB 集群与负载均衡(一)基本概念-上
Web集群是由多个同时运行同一个web应用的服务器组成，在外界看来就像一个服务器一样，这多台服务器共同来为客户分享更高性能的服务。集群更标准的定义是：一组相互独立的服务器在网络中组成单一的系统，并以单一系统的模式加以管理，此单一系统为客户工作站分享高可靠性的服务。
而负载均衡的任务就是负责多个服务器之间（集群内）实现合理的任务分配，使这些服务器（集群）不会出现因某一台超负荷、而其他的服务器却没有充分发挥处理能力的情况。负载均衡有两个方面的含义：首先，把大量的并发访问或数据流量分担到多台节点上分别处理，减少用户等待响应的时间；其次，单个高负载的运算分担到多台节点上做并行处理，每个节点设备处理结束后，将结果汇总，再返回给用户，使得信息系统处理能力可以得到大幅度提高
因此可以看出，集群和负载均衡有本质上的不同，它们是解决两方面问题的不同方案，不要混淆。
集群技术可以分为三大类：
1、高性能性集群(HPC Cluster)
2、高可用性集群(HA Cluster)
3、高可扩展性集群
一、高性能性集群(HPC Cluster)
指以提高科学计算能力为目标的集群技术。该集群技术主要用于科学计算，这里不打算介绍，如果感兴趣可以参考相关的资料。
二、高可用性集群(HA Cluster)
指为了使群集的整体服务尽可能可用，减少服务宕机时间为目的的集群技术。如果高可用性集群中的某节点发生了故障，那么这段时间内将由其他节点代替它的工作。当然对于其他节点来讲，负载相应的就增加了。
为了提高整个系统的可用性，除了提高计算机各个部件的可靠性以外，一般情况下都会采用该集群的方案。
对于该集群方案，一般会有两种工作方式：
①主-主(Active-Active)工作方式
这是最常用的集群模型，它分享了高可用性，并且在只有一个节点时也能分享可以接受的性能，该模型允许最大程度的利用硬件资源。每个节点都通过网络对客户机分享资源，每个节点的容量被定义好，使得性能达到最优，并且每个节点都可以在故障转移时临时接管另一个节点的工作。所有的服务在故障转移后仍保持可用，但是性能通常都会下降。
这是目前运用最为广泛的双节点双应用的Active/Active模式。
支撑用户业务的应用程序在正常状态下分别在两台节点上运行，各自有自己的资源，比如IP地址、磁盘阵列上的卷或者文件系统。当某一方的系统或者资源出现故障时，就会将应用和相关资源切换到对方的节点上。
这种模式的最大优点是不会有服务器的“闲置”，两台服务器在正常情况下都在工作。但如果有故障发生导致切换，应用将放在同一台服务器上运行，由于服务器的处理能力有可能不能同时满足数据库和应用程序的峰值要求，这将会出现处理能力不够的情况，降低业务响应水平。
②主-从(Active-Standby)工作方式
为了分享最大的可用性，以及对性能最小的影响，主-从工作方式需要一个在正常工作时处于备用状态的节点，主节点处理客户机的请求，而备用节点处于空闲状态，当主节点出现故障时，备用节点会接管主节点的工作，继续为客户机分享服务，并且不会有任何性能上影响。
两节点的Active/Standby模式是HA中最简单的一种，两台服务器通过双心跳线路组成一个集群。应用Application联合各个可选的系统组件如：外置共享的磁盘阵列、文件系统和浮动IP地址等组成业务运行环境。
PCL为此环境分享了完全冗余的服务器配置。这种模式的优缺点：
- 缺点：Node2在Node1正常工作时是处于“闲置”状态，造成服务器资源的浪费。
- 优点：当Node1发生故障时，Node2能完全接管应用，并且能保证应用运行时的对处理能力要求。
三、高可扩展性集群
这里指带有负载均衡策略（算法）的服务器群集技术。带负载均衡集群为企业需求分享了更实用的方案，它使负载可以在计算机集群中尽可能平均地分摊处理。而需要均衡的可能是应用程序处理负载或是网络流量负载。该方案非常适合于运行同一组应用程序的节点。每个节点都可以处理一部分负载，并且可以在节点之间动态分配负载，以实现平衡。对于网络流量也是如此。通常，单个节点对于太大的网络流量无法迅速处理，这就需要将流量发送给在其它节点。还可以根据每个节点上不同的可用资源或网络的特殊环境来进行优化。
负载均衡集群在多节点之间按照一定的策略（算法）分发网络或计算处理负载。负载均衡建立在现有网络结构之上，它分享了一种廉价有效的方法来扩展服务器带宽，增加吞吐量，提高数据处理能力，同时又可以避免单点故障。
WEB 集群与负载均衡(一)基本概念-下
前面已经说过负载均衡的作用是在多个节点之间按照一定的策略（算法）分发网络或计算处理负载。负载均衡可以采用软件和硬件来实现。一般的框架结构可以参考下图。
后台的多个Web节点上面有相同的Web应用，用户的访问请求首先进入负载均衡分配节点(可能是软件或者硬件)，由它根据负载均衡策略（算法）合理地分配给某个Web应用节点。每个Web节点相同的内容做起来不难，所以选择负载均衡策略（算法）是个关键问题。下面会专门介绍均衡算法。
web 负载均衡的作用就是把请求均匀的分配给各个节点，它是一种动态均衡，通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把请求理分配出去。对于不同的应用环境（如电子商务网站，它的计算负荷大；再如网络数据库应用，读写频繁，服务器的存储子系统系统面临很大压力；再如视频服务应用，数据传输量大，网络接口负担重压。），使用的均衡策略（算法）是不同的。所以均衡策略（算法）也就有了多种多样的形式，广义上的负载均衡既可以设置专门的网关、负载均衡器，也可以通过一些专用软件与协议来实现。在OSI七层协议模型中的第二（数据链路层）、第三（网络层）、第四（传输层）、第七层（应用层）都有相应的负载均衡策略（算法），在数据链路层上实现负载均衡的原理是根据数据包的目的MAC地址选择不同的路径；在网络层上可利用基于IP地址的分配方式将数据流疏通到多个节点；而传输层和应用层的交换（Switch），本身便是一种基于访问流量的控制方式，能够实现负载均衡。
目前，基于负载均衡的算法主要有三种：轮循（Round-Robin）、最小连接数（Least Connections First），和快速响应优先（Faster Response Precedence）。
①轮循算法，就是将来自网络的请求依次分配给集群中的节点进行处理。
②最小连接数算法，就是为集群中的每台服务器设置一个记数器，记录每个服务器当前的连接数，负载均衡系统总是选择当前连接数最少的服务器分配任务。这要比"轮循算法"好很多，因为在有些场合中，简单的轮循不能判断哪个节点的负载更低，也许新的工作又被分配给了一个已经很忙的服务器了。
③快速响应优先算法，是根据群集中的节点的状态（CPU、内存等主要处理部分）来分配任务。这一点很难做到，事实上到目前为止，采用这个算法的负载均衡系统还很少。尤其对于硬件负载均衡设备来说，只能在TCP/IP协议方面做工作，几乎不可能深入到服务器的处理系统中进行监测。但是它是未来发展的方向。
上面是负载均衡常用的算法，基于以上负载均衡算法的使用方式上，又分为如下几种：
1、DNS轮询
最早的负载均衡技术是通过DNS来实现的，在DNS中为多个地址配置同一个名字，因而查询这个名字的客户机将得到其中一个地址，从而使得不同的客户访问不同的服务器，达到负载均衡的目的。
DNS负载均衡是一种简单而有效的方法，但是它不能区分服务器的差异，也不能反映服务器的当前运行状态。当使用DNS负载均衡的时候，必须尽量保证不同的客户计算机能均匀获得不同的地址。由于DNS数据具备刷新时间标志，一旦超过这个时间限制，其他DNS服务器就需要和这个服务器交互，以重新获得地址数据，就有可能获得不同IP地址。因此为了使地址能随机分配，就应使刷新时间尽量短，不同地方的DNS服务器能更新对应的地址，达到随机获得地址，然而将过期时间设置得过短，将使DNS流量大增，而造成额外的网络问题。DNS负载均衡的另一个问题是，一旦某个服务器出现故障，即使及时修改了DNS设置，还是要等待足够的时间（刷新时间）才能发挥作用，在此期间，保存了故障服务器地址的客户计算机将不能正常访问服务器
2、反向代理服务器
使用代理服务器，可以将请求转发给内部的服务器，使用这种加速模式显然可以提升静态网页的访问速度。然而，也可以考虑这样一种技术，使用代理服务器将请求均匀转发给多台服务器，从而达到负载均衡的目的。
这种代理方式与普通的代理方式有所不同，标准代理方式是客户使用代理访问多个外部服务器，而这种代理方式是代理多个客户访问内部服务器，因此也被称为反向代理模式。虽然实现这个任务并不算是特别复杂，然而由于要求特别高的效率，实现起来并不简单。
使用反向代理的好处是，可以将负载均衡和代理服务器的高速缓存技术结合在一起，分享有益的性能。然而它本身也存在一些问题，首先就是必须为每一种服务都专门开发一个反向代理服务器，这就不是一个轻松的任务。
代理服务器本身虽然可以达到很高效率，但是针对每一次代理，代理服务器就必须维护两个连接，一个对外的连接，一个对内的连接，因此对于特别高的连接请求，代理服务器的负载也就非常之大。反向代理方式下能应用优化的负载均衡策略，每次访问最空闲的内部服务器来分享服务。但是随着并发连接数量的增加，代理服务器本身的负载也变得非常大，最后反向代理服务器本身会成为服务的瓶颈。
3、地址转换网关
支持负载均衡的地址转换网关，可以将一个外部IP地址映射为多个内部IP地址，对每次TCP连接请求动态使用其中一个内部地址，达到负载均衡的目的。很多硬件厂商将这种技术集成在他们的交换机中，作为他们第四层交换的一种功能来实现，一般采用随机选择、根据服务器的连接数量或者响应时间进行选择的负载均衡策略来分配负载。由于地址转换相对来讲比较接近网络的低层，因此就有可能将它集成在硬件设备中，通常这样的硬件设备是局域网交换机。
第五章 全局负载均衡 （GSLB）
负载均衡就是智能调度
全局负载均衡（GSLB）的负载均衡主要是在多个节点之间进行均衡，其结果可能直接终结负载均衡过程，也可能将用户访问交付下一层次的（区域或本地）负载均衡系统进行处理。GSLB最通用的是基于DNS解析方式，还有HTTP重定向、IP路由等方法
DNS就是IP地址和网址互换
当需要访问tao-s.com这个站点时，实际上我们想要浏览的网页内容都存放在互联网中对应某个IP的服务器上，而浏览器的任务就是找到我们想要访问的这台服务器的IP地址，然后向它请求内容。
本地DNS服务器（local DNS server）是用户所在局域网或ISP网络中的域名服务器。当客户端在浏览器里请求tao-s.com时，浏览器会首先向本地DNS服务器请求将 tao-s.com解析成IP地址，本地DNS服务器再向整个DNS系统查询，直到找到解析结果。客户端可以配置DNS服务器或通过DHCP来分配
DNS给使用它的互联网应用带来额外的时延，有时时延还比较大，为了解决问题，需要引入“缓存”机制。缓存是指DNS查询结果在主机（local DNS server）中缓存。在区内主机对某个域名发起第一次查询请求时，负责处理递归查询的DNS服务器要发送好几次查询（先查.root，再查.com之类，再定位IP地址等）才能找到结果，不过在这过程中它也得到了许多信息，比如各区域权威DNS服务器（就是告诉你最终tao-s.com在哪里的DNS服务器）和它们的地址、域名解析最终结果。他会把这些信息保存起来，当其他主机向它发起查询请求时，它就直接向主机返回缓存中能够找到的结果，直到数据过期。
客户端浏览器也可以缓存DNS响应信息。
Internet类资源记录分为
– A记录（address）：域名->多个IP的映射。对同一个域名，可以有多条A记录
– NS记录（name server）：指定由哪台DNS服务器来解析
– SOA记录（start of authority）：指定该区域的权威域名服务器
– CNAME记录（canonical name）：多个域名->服务器的映射
– PTR记录（pointer record）：IP->域名的映射
DNS系统本身是具备简单负载分配能力的，这是基于DNS的轮询机制。如果有多台Web服务器（多源）同时为站点 tao-s.com分享服务，tao-s.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特性，Foundry、Nortel、Cisco和Radware的产品能实现部分DNS功能
负载均衡作为代理DNS服务器：负载均衡器被注册为一个域名空间的权威DNS服务器，而真正的权威域名服务器则部署在负载均衡器后面。所有的DNS请求都会先到达负载均衡器，由负载均衡器转发到真正的权威DNS服务器，然后修改权威DNS服务器返回的响应信息。真正的权威 DNS服务器正常响应浏览器的DNS请求，返回域名解析结果列表，这个响应会先发送到负载均衡器，而负载均衡器会根据自己的策略选择一个性能最好的服务器 IP并修改需要实现GSLB的域名的DNS查询响应，对其他请求透明转发，这样就不会影响整个域名空间的解析性能。
在基于DNS方式下无论采用何种工作方式，都会有一些请求不会到达GSLB，这是DNS系统本身的缓存机制在起作用。当用户请求的域名在本地DNS或本机（客户端浏览器）得到了解析结果，这些请求就不会达到GSLB。Cache更新时间越短，用户请求达到GSLB的几率越大。由于DNS的缓存机制屏蔽掉相当一部分用户请求，从而大大减轻了GSLB处理压力，使得系统抗流量冲击能力显著提升，这也是很多商业CDN选择DNS机制做全局负载均衡的原因之一。但弊端在于，如果在DNS缓存刷新间隔之内系统发生影响用户服务的变化，比如某个节点故障，某个链路拥塞等，用户依然会被调度到故障部位去。
智能DNS功能，它在向本地DNS返回应答之前会先根据一些静态或动态策略进行智能计算。
– 服务器的“健康状况”
– 地理区域距离
– 会话保持
– 响应时间
– IP地址权重
– 会话能力阈值
– 往返时间（TTL）
– 其他信息，包括服务器当前可用会话数、最少选择次数、轮询等
关于GSLB的部署问题
关于内容的缓存问题（如何智能调度最有效）和配置
在有些CDN中（用于视频网站加速的情况较多），网站需要加速的内容全部先缓存在OCS（内容中心），然后再将一部分（通常是热门的内容）分发到个POP节点（Cache边缘集群），所以POP节点在某些时候会出现本地不命中而需要回OCS取内容或者从其他POP节点取内容的情况
纯粹基于DNS方式的GSLB只能完成就近性判断。为实现智能调度，大多数解决方案需要在GSLB设备附近以旁路的方式部署一台辅助设备（为方便描述，我们可称之为GRM——全局资源管理设备），用以实现和各POP节点的本地资源管理设备进行通信，完成CDN对各POP节点的状态检查，并根据POP节点的状态和流量情况，重新制订用户调度策略，将策略实时发送到GSLB中去执行
因为DNS服务采用以UDP为基础的、默认无连接的访问方式，给分布式攻击（DDoS）带来了更大的便利。（有DNSSEC可以分享某程度的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系统，这将成为性能和可靠性的瓶颈。（流媒体用的比较多）
基于IP路由的GSLB
基于路由协议算法选择一条路由到达这两个本地均衡器中的一个。因为每次访问请求的终端IP地址不同，路由条件也不同，所以在多个路由器上优选的路由不同，从统计复用的角度来看基本是在负载均衡器1和2之间均匀分布的。
IP路由在多个POP点之间实现的负载均衡是一种概率上的均衡，而不是真正的均衡（没做智能调度）。
比较项 | 基于DNS解析方式 | 基于HTTP重定向方式 | 基于IP路由方式 |
性能 | 本地DNS服务器和用户终端DNS缓存能力使GSLB的负载得到有效分担 | GSLB处理压力大，容易成为系统性能的瓶颈 | 借助IP网络设备完成负载均衡，没有单点性能瓶颈 |
准确度 | 定位准确度取决于本地DNS覆盖范围，本地DNS设置错误会造成定位不准确 | 在对用户IP地址数据进行有效维护的前提下，定位准确且精度高 | 就近性调度准确，但对设备健康性等动态信息响应会有延迟 |
效率 | 效率约等于DNS系统本身处理效率 | 依靠服务器做处理，对硬件资源的要求高 | 效率约等于IP设备本身效率 |
扩展性 | 扩展性和通用性好 | 扩展性较差，需对各种应用协议进行定制开发 | 通用性好，但适用范围有限 |
商用性 | 在Web加速领域使用较多 | 国内流媒体CDN应用较多 | 尚无商用案例 |
第六章 流媒体CDN系统的组成
流媒体业务是一种对实时性、连续性、时序性要求非常高的业务，无论从带宽消耗上还是质量保障上来说，对best-effort的IP网络都是一个不小的冲击
– 高带宽要求
– 高QoS要求
– 组播、广播要求（目前IP网络无法实现端到端的组播业务）
播放一个视频分为以下四个步骤：
– Access
– Demux（音视频分离）
– Decode（解码解压缩）
– Output
RTP、RTCP、RTSP、RTMP的关系：RTSP协议用来实现远程播放控制，RTP用来分享时间信息和实现流同步，RTCP协助RTP完成传输质量控制<=（播放控制），
=>（传输控制）RTMP和HTTP streaming则是将流同步、播放控制、质量控制集成起来的企业自有流媒体传送协议
RTMP是adobe的传输协议。RTMP的基本通信单元：消息块（chunk）和消息（message）
RTMP协议架构在TCP层之上，但RTMP消息并不是直接封装在TCP中，而是通过一个被称为消息块的封装单元进行传输。消息在网络上发送之前往往需要分割成多个较小的部分，这样较小的部分就是消息块，属于不同消息流的消息块可以在网络上交叉发送。
RTSP/RTP和HTTP streaming是目前应用最广泛的流化协议，目前电信运营商在IPTV（特殊通道的基于IP的流媒体播放）的流化上主要以RTSP/RTP技术为主，而互联网视频网站（点播/直播）则多倾向于使用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)
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的内容分发策略
在流媒体服务系统中，主要关注的技术是对不同流媒体协议、不同编码格式、不同播放器、不同业务质量要求等的适应。
流媒体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方式 |
组网 | 多级组网，可能要求组播、单播混合组网 | 两级组网 |
流媒体CDN的Cache设备与Web Cache无论在软件实现还是硬件要求上差异都很大，我们很少看到这两种业务共用同一台设备
当用户请求的内容在Cache上命中时，Cache直接向用户分享流服务，此时Cache设备充当流媒体服务器的角色；当用户请求内容未能在Cache上命中时，Cache会从上一级Cache（二级缓存设备或中间缓存设备）或者源站服务器获取内容，再分享给用户。 Cache在用户与另一个流媒体服务器之间扮演代理的角色
分布式存储技术因其大容量、低成本的特点，目前也被业界关注和研究作为流媒体CDN系统的存储解决方案之一。常用的分布式存储技术包括分布式文件系统和分布式数据库，由于采用了数据副本冗余（每份数据复制2~3份）、磁盘冗余（Raid1、Raid10、Raid5）等技术，通常可以分享良好的数据容错机制，当单台存储设备断电或者单个存储磁盘失效时，整个存储系统仍能正常工作
负载均衡设备在进行用户访问调度时，会综合考虑很多静态的、动态的参数，包括IP就近性、连接保持、内容命中、响应速度、连接数等。但没有哪个CDN会考虑所有参数，而是会根据业务特点进行一些取舍，否则均衡系统就太复杂了。而流媒体CDN在进行用户访问调度时，会更多考虑内容命中这一参数
有两种GSLB实现方式，一种是基于DNS的，一种是基于应用层重定向的
PUSH方式适合内容访问比较集中的情况，如热点的影视流媒体内容，PULL方式比较适合内容访问分散的情况
对使用CDN服务的SP来说，CDN的作用在于尽量就近为用户分享服务，帮助SP解决长距离IP传输和跨域传输带来的种种业务质量问题（通过空间换取时间）。因此，为用户分享服务的Cache设备一定部署在离用户比较近的地方。另一方面，CDN的建设者从成本角度考虑，又不能把所有内容都存放在这些离用户最近的节点中，这会消耗大量存储成本，所以这些分享服务的Cache设备会根据需要从源站服务器或者其他Cache获取内容。这样就形成了CDN网络分层部署的概念。
从网络分层上看，Web CDN通常是两级架构（也有三级架构以减少回源），即中心-边缘。而流媒体CDN通常有三级以上架构，即中心-区域-边缘。产生这种区别的原因在于流媒体回源成本比较高，源站服务器响应一次流媒体内容回源请求，要比Web内容回源消耗更多资源。尤其对于流媒体直播业务来说，只要直播节目没结束，服务器就需要长时间持续吐流，如果没有第二层节点作为中继，那么中心节点的压力将是不可想象的。
分层部署的方式，对点播业务而言的主要意义是节省存储成本，对直播业务而言在于减少带宽成本。在点播业务中，边缘Cache只需存储用户访问量大的内容或者内容片断，其余内容存储在区域Cache中。
在直播业务中，边缘Cache从区域中心获取直播流，而不需要直接向中心节点（源站）获取，从而节省了区域中心到中心节点这一段的大部分带宽。因为直播流在各个Cache中都不需要占用很大的存储空间，只需少量缓存空间即可，所以直播业务方面并不用注重考虑存储成本
考虑到电信运营商的IP拓扑和流量模型，区域中心Cache通常部署在重点城市的城域网出口的位置，以保障向各个边缘 Cache的链路通畅。边缘Cache的位置选择则以整个节点能够分享的并发能力为主要依据，依据业务并发数收敛比，计算出单个Cache需要覆盖的用户规模，从而选择一个合适的部署位置。当然，边缘Cache离用户越近，服务质量越好，但覆盖的用户数越少，部署成本越高。
内容文件预处理
是指视频内容进入CDN以后，进入内容分发流程之前，CDN系统对内容进行的一系列处理过程。这个预处理过程的目的有几个：
– 为全网内容管理分享依据，比如对内容进行全网唯一标识，对内容基础信息进行记录等
– 为提高CDN服务效率或降低系统成本分享手段，比如内容切片
– 为满足业务要求分享能力，比如对同一内容进行多种码率的转换以满足动态带宽自适应或三屏互动业务要求
视频转码(video transcoding)
– 码率转换
– 空间分辨率转换
– 时间分辨率转换
– 编码格式转换。编码格式主要包括H.264、MPEG-4、MPEG-2、VC-1、REAL、H.263、WMV。通常是把其他编码格式转换成H.264
文件切片是指按照一定的规则把一个完整的文件切成大小一致的若干个小文件；由于流媒体CDN需要分享的内容体积越来越大，传统整片存储带来的成本消耗超出了CDN服务商的承受范围；切片的另一个目的是，使边缘Cache能够支持自适应码率业务
防盗链机制和实现
– 基于IP的黑白名单
– 利用HTTP header的referer字段
– 使用动态密钥（随机生成的key通过算法生成新的url）
– 在内容中插入数据（对有版权内容进行加密（DRM），如Microsoft的playready，Google的Widevine）
– 打包下载：在原文件的基础上进一步封装，使得资源的hash 值改变
第七章 动态内容加速服务的实现
随着Web2.0的兴起，产生了动态网页、个性化内容、电子交易数据等内容的加速，这些就涉及了动态内容加速技术。
静态内容的加速，都是对于表现层的加速，对于动态页面等内容的加速，则要涉及逻辑层和数据访问层的加速技术
动态内容的分享不仅仅是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系统用户文件的复制。
（PS：暂时来说，网宿还没有实现真正意义的动态加速，虽然现在已经实现一部分，如搜索结果动态缓存，重用的动态页面智能缓存。其他更多的是通过智能管道来加快用户与源钻的访问效率）
（应用加速技术实际上是传统的网络负载均衡的升级和扩展，综合使用了负载均衡（智能调度）、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连接池，当有数据传输需求时，从连接池中挑选一条可用连接今次那个传输。
SSL加速技术
– SSL加密是一种处理器密集型加密算法，如果用服务器软件处理会消耗大量CPU资源，一般会在分享业务能力的服务器外围部署专门的SSL加速设备，采用硬解密方式实现
– SSL加密分对称秘钥和非对称秘钥（计算资源消耗更大）
SSL的基本原理和实现
– 可认证性（authentication）
– 隐私性（privacy）
– 完整性（integrity）
– 不可抵赖性（undeniability）：发送者不能自称没有发出过接受者从他那里收到的内容
SSL加速
– 通常是基于硬件的SSL加速
– 通过在服务器上安装一块SSL加速板卡，可有效分担服务器CPU处理SSL事务的压力
CDN的实现原理
在描述CDN的实现原理，让我们先看传统的未加缓存服务的访问过程，以便了解CDN缓存访问方式与未加缓存访问方式的差别：
用户提交域名→浏览器对域名进行解释→得到目的主机的IP地址→根据IP地址访问发出请求→得到请求数据并回复
由上可见，用户访问未使用CDN缓存网站的过程为:
1)、用户向浏览器分享要访问的域名；
2)、浏览器调用域名解析函数库对域名进行解析，以得到此域名对应的IP地址；
3)、浏览器使用所得到的IP地址，向域名的服务主机发出数据访问请求；
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第四章WEB 集群与负载均衡基本概念来源：http://blog.csdn.net/lovingprince/article/details/3290916
CDN原理实现来源：http://www.cnblogs.com/rayray/p/3553696.html
下载仅供下载体验和测试学习，不得商用和正当使用。
下载体验