PS：网宿是CDN公司中我见到的目前产品和售前最强的公司。偶尔看到一位网宿前售前的读书笔记，收藏。javascript
一本好的入门书是带你进入陌生领域的明灯，《CDN技术详解》绝对是带你进入CDN行业的那盏最亮的明灯。所以，虽然只是纯粹的重点抄录，我也要把《CDN技术详解》的精华放上网。公诸同好。java
第一章 引言 算法
“第一千米”是指万维网流量向用户传送的第一个出口，是网站服务器接入互联网的链路所能提供的带宽。这个带宽决定了一个网站能为用户提供的访问速度和并发访问量。若是业务繁忙，用户的访问数越多，拥塞越严重，网站会在最须要向用户提供服务时失去用户。（还有“中间一千米”和“最后一千米”分别表明互联网传输传输和万维网流量向用户传送的最后一段接入链路）数据库
从互联网的架构来看，不一样网络之间的互联互通带宽，对任何一个运营商网络的流量来讲，占比都比较小，收敛比是很是高的，所以这里一般都是互联网传输中的拥堵点（运营商互联互通的问题）编程
其次是骨干网堵塞问题，因为互联网上的绝大部分流量都要经过骨干网络进行传输，这就要求骨干网络的承载能力必须与互联网的应用同步发展，但实际上二者并非同步的，当骨干网络的升级和扩容滞后于互联网之上的应用的发展时，就会阶段性地使得大型骨干网的承载能力成为影响互联网性能的瓶颈（区域互联互通问题，骨干网带宽瓶颈）swift
在互联网领域有一个“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
第四章 集群服务与负载均衡
第五章 全局负载均衡 （GSLB）
负载均衡就是智能调度
全局负载均衡（GSLB）的负载均衡主要是在多个节点之间进行均衡，其结果可能直接终结负载均衡过程，也可能将用户访问交付下一层次的（区域或本地）负载均衡系统进行处理。GSLB最通用的是基于DNS解析方式，还有HTTP重定向、IP路由等方法
DNS就是IP地址和网址互换
当须要访问abc.com这个站点时，实际上咱们想要浏览的网页内容都存放在互联网中对应某个IP的服务器上，而浏览器的任务就是找到咱们想要访问的这台服务器的IP地址，而后向它请求内容。
本地DNS服务器（local DNS server）是用户所在局域网或ISP网络中的域名服务器。当客户端在浏览器里请求abc.com时，浏览器会首先向本地DNS服务器请求将abc.com解析成IP地址，本地DNS服务器再向整个DNS系统查询，直到找到解析结果。客户端能够配置DNS服务器或经过DHCP来分配
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->域名的映射
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的3DNS具备完整的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）带来了更大的便利。
隐藏节点的存在很大程度上能够避免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份）、磁盘冗余（Raid一、Raid十、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.26四、MPEG-四、MPEG-二、VC-一、REAL、H.26三、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事务的压力
转自：http://zsvalue.com/201405/foundation-of-cdn-%E3%80%8Acdn%E6%8A%80%E6%9C%AF%E8%AF%A6%E8%A7%A3%E3%80%8Bnote/