第一章 引言
1.1 CDN的基本概念和产生背景
CDN: Content Distribute Network: 内容分发网络,或者,Content Delivery Network:内容交付网络
我们常说的互联网,是广义的互联网,由两层组成:一层是以TCP/IP为代表的网络层(也就是狭义互联网概念),另一层是以万维网为代表的应用层。
以TCP/IP为核心的狭义的互联网,实际上是广义互联网的下层,是网络基础,更一般的说法就是TCP/IP网络。这一层的主要作用是通过计算机之间的互联,将各种信息的数据报文以极低的成本进行传输,俗称“管道”,所有的信息和内容在这个管道里进行传输。
互联网的设计理念是:网络是中立和无控制的,任何人都没有决定权;网络是应用无关的,它的任务就是如何更好地将数据包进行端到端传输。
SP: Service Provider 服务提供商
从网络层面看,在互联网整个链路中,有四个拥堵点:
- 网站服务器接入互联网的链路所能提供的带宽,这个带宽决定了一个网站能为用户提供的访问速度和并发访问量。
- 用户接入带看。用户的平均接入带宽,是影响互联网上层应用发展的决定性因素之一
- 对等互联接口。是指不同基础运营商之间的互联互通。一般两个运营商之间只有两三个互联互通点。
- 长途骨干传输。
1.3 CDN发展历史
Akamai 是全球第一家CDN网络运营商。
1998年,国内第一家专业CDN服务公司--蓝汛(ChinaCache)成立
2000年,网宿成立
第二章 CDN技术概述
CDN基于这样的原理:
- 挑选最优设备为用户提供服务
- 如果某个内容被很多用户所需要,它就被缓存到距离用户最近的节点中
2.1 功能架构
负载均衡 系统是一个CDN系统的神经中枢,主要功能是负责对所有发起服务请求的用户进行访问调度,确定提供给用户的最终实际访问地址
GSLB: 全局负载均衡
SLB: 本地负载均衡
GSLB : 主要根据用户就近性原则,通过对每个服务节点进行“最优”判断,确定向用户提供服务的Cache的物理位置。
SLB: 主要负责节点内部的设备负载均衡,当用户请求从GSLB 调度到SLB时,SLB会根据节点内各Cache设备的实际能力或内容分布等因素对用户进行重定向
2.1.2 部署架构
1. 中心和区域节点一般称为骨干点,主要作为内容分发和边缘未命中时的服务点
边缘节点又被称为POP(point-to-presence)节点,CDN POP主要作为直接向用户提供服务的节点
2.2 CDN 系统分类
可以从两个角度来对CDN基本服务进行分类,一是基于不同内容承载类型视角,二是基于不同内容生成机制视角
2.2.1 基于不同内容承载类型的分类
1. 网页加速
2. 流媒体加速
流媒体加速的实现是通过将流媒体内容推送到离用户最近的POP点,使得用户能够从网络边缘获取内容,从而提高视频传输质量,缩短访问时间,节省主干网络流量,避免单一中心节点的服务器瓶颈问题。
流媒体加速服务又可以分为两类:
* 流媒体直播加速(Live)
*流媒体点播加速(on_demand)
3. 文件传输加速
文件传输加速服务一直是一项重要的CDN服务,通过使用CDN的分布式POP点提供下载服务,网站可以将大量文件下载的性能压力和带宽压力交给CDN来分担,提高用户的下载速度
4. 应用协议加速
2.2.2 基于内容生成机制的分类和分层加速服务
从内容的生成机制来看,互联网上的内容主要有两类:一是静态内容,二是动态内容。
静态内容主要是指内容完全又网页HTML文件提供,任何人在任何时间浏览静态内容看到的都是一样的东西
动态内容是指不同的访问者或在不同时间访问同一个Web页面时可能得到不同的页面内容,内容具有实时性,访问的过程具有交互性。
主流的Web 网站系统中逻辑上分为三个层次:表现层,业务逻辑层,数据访问层
第三章 内容缓存工作原理及实现
3.1 内容缓存技术的发展背景
3.1.1 网站的问题和需求
互联网最常见的访问模式是B/S模式,即浏览器(Browser)到网站服务器(Server)的访问模式
3.1.2 CDN出现前的网站服务技术
1. 扩展技术 Scale up / Scale out
Scale up, 是指提高网站服务器的硬件水平
Scale out , 采用服务器集群
2. 镜像技术 Mirroring
镜像是冗余的一种类型,比如一个磁盘上的数据在另一个磁盘上存在一个完全相同的副本就成为磁盘镜像。镜像主要用于备份,在数据媒体服务和分发领域,是指数字媒体的服务能力和完整内容都备份到网络上不同地址的另一个地方
基于镜像技术的主要应用方式是镜像网站,即对整个网站中的内容进行镜像复制,并对镜像网站多点部署。这样用户在访问网站时可以自主选择速度较快的镜像站点,从而得到更快更好的服务,降低主网站/原始网站的负载。
3. 缓存技术 Cache
缓存是将访问过的数字媒体存储起来,为后续的重复访问使用
3.2 Cache设备的工作方式和设计要求
1. 通常来说,根据cache内容的不同可以将设备分为Web Cache 和流媒体Cache 两大类。Web Cache 主要用于缓存普通网页的内容和对象,同时大多数设备也具备文件下载、流媒体服务等能力;
流媒体Cache 设备主要是针对视频流媒体服务进行加速,功能相对单一。
3.3.2http 协议工作原理
1. http 与TCP的关系
通常情况下http都是架构在TCP传输协议上的,有时出于安全的考虑,http 还需要经过TLS或者SSL层的封装,架构在SSL层上的http协议通常称为https(hypertext Transfer Protocol over Secure Socket Layer)
2. http 是一个无状态的协议,即客户端向服务端发送请求时,服务器并没有存储关于该客户端和请求的任何状态信息。
3. HTTP协议相关概念
连接(connection): 为通信而在两个程序之间建立的传输层虚拟链路,如TCP 连接
消息(message): HTTP通信的基本单位,包括一个结构化的八元组序列并通过连接传输。
请求(Request):一个从客户端到服务器的请求信息包括应用于资源的方法、资源的标识符和协议的版本号
响应(Response): 一个从服务器返回的信息,包括HTTP协议的版本号、请求的状态以及其他一些信息,比如说文档的MIME类型。
资源(Resource):由URI标识的网络数据对象或服务,比如说存储在服务器中的一个HTML文件。
实体(Entity):数据资源或来自服务资源响应的一种特殊表示方法,它可能被包围在一个请求或响应信息中,是请求或响应消息的有效承载信息。一个实体包括实体头和实体信息。
客户端(client):为发送HTTP请求而建立连接的应用程序,比如说浏览器
服务器(server):一个接受客户端连接请求并对请求返回信息的应用程序。
源服务器(origin server): 是一个特定资源可以在其上驻留或被创建的服务器。在Web访问中,源服务器通常是编辑产生网页并保持最新变动的源站。
代理(proxy):是一个处于客户端和服务器之间的中间程序。它对于客户端来说可以充当一个服务器,为客户端直接提供服务;对服务端来说可以充当一个客户端,在接收到其他客户端的请求后,自身再以一个客户端的方式向源服务器发送请求。
网关(gateway):也是一个作为中间媒介的服务器。代理主要代表客户端发起请求和提供服务,而网关则是代表源服务器来接收请求和提供服务,发出请求的客户端并没有意识到它在同网关打交道,而是感觉从服务端获得了响应。
隧道(Tunnel):是作为两个连接中继的中介程序。
4.
5.
6.
7. 状态码由三位数字组成,第一位定义了响应的类别
3.3.3 HTTP中的cookie和session
1. cookie
cookie在RFC 2965 中进行描述,每个客户端最多保持300个cookie,每个域名下最多20个cookie,而每个cookie的大小最大为4KB。cookie并不那么安全。
cookie文件保存在用户机器中。
cookie信息通过请求信息从客户端发送到服务器的过程中,进攻者会从网络中截获这部门信息,虽然这部分信息往往已经通过MD5加密,但进攻者可以不需要解码这部分信息,而是通过套用这个cookie信息来冒充真正用户骗取服务器的信任,这种方法成为cookie欺骗。
2. session
当用户请求时,服务器就为这个用户分配了一个全局唯一的标识,称为session ID,标识与这个用户的这次会话
服务器将session ID返回给浏览器的方法有两种:
一种是cookie方法,即采用HTTP协议中的cookie机制来实现,服务器产生session ID后,通用Set_Cookie 扩展头将session ID传送到浏览器,而浏览器此后的每一次请求都会在Cookie头里带上这个ID
一种是URL重写。也就服务器在返回用户请求的页面之前,将页面内所有的URL后面附上session ID,这样用户在收到响应后,无论点击哪个链接,都会再带上session ID,从而就实现了会话的保持。
把session ID附加在URL后面有两种方式,一种是作为URL路劲的附加信息,表现形式为
http://.../xxx;sessionid=...;
一种是作为查询字符串附加在URL后面,表现形式为:
http://.../xxx?sessionid=...;
这两种方式对于用户来说没有区别,只是服务器在解析时的处理机制不一样,采用第一种方式比较有利于把session Id 的信息和正常程序参数区别开来。
P76
第六章 流媒体CDN系统的组成和关键技术
6.1 流媒体系统工作原理
1. 播放一个视频分为以下4个步骤:
1. Access,文件获取,指系统将多媒体文件从硬盘读入内存
2. Demux, 解复用,就是把通常合在一起的音频和视频分离,有的还有字幕
3. Decode : 解码,将压缩编码后的音频和视频进行解码
4. output, 输出,包括音频输出和视频输出
6.2 流媒体传输协议体系
6.2. 1 RTP和RTCP
1. RTP:Realtime Transport Protocol, 实时传输协议, 定义包含音视频数据、序号、时间戳已经其他有用信息的标准分组结构的协议。简单的说,RTP的任务就是提供时间信息和实现流同步。
2. RTCP: RealTime Transport Control Protocol, 实时传输控制协议。 负责在会话参与者之间交互控制信息,RTCP分组包中含有已经发送的数据包的数量、丢失的数据包的数量等统计数据,服务器可以利用这些信息动态地改变传输速率,甚至改变有效载荷类型。
RTP和RTCP配合使用,能以有效的反馈和较小的开销使传输效率最优化。在UDP中,RTP如果使用一个偶数端口号,则相应的RTCP使用其后的奇数端口号。
3. RTP 通常运行在UDP之上
4. RTSP :Real Time Streaming Protocol , 实时流传输协议,RTSP是一个应用层协议,属于TCP/IP协议体系,位于RTP和RTCP之上。
RTSP是一个用来实现播放控制的协议,而不是一个流媒体压缩协议或者传送协议。
5. RTSP 专业术语
表示(presentation): 作为一个完整的媒体信息,传送给客户端的一个或多个流的集合
媒体流: 单个媒体实例,比如一个音频流或者一个视频流,当使用RTP时,流包括由RTP会话(session)中同一个源所创建的所有RTP和RTCP包
会话(session):指一次RTSP事务(transaction)的全过程。
连接:是以通信为目的,在传输层建立的两个程序之间的虚拟通道
6. RTSP是一个C/S 方式的带外协议(out-of-band Protocol), RTSP报文和媒体流使用不同的端口号,通常RTSP使用端口号544.
7 . RTSP可以采用TCP传输,也可以采用UDP传输。
6.2. 3 RTMP
RTMP: Real Time Message Protocol , 即实时消息传送协议,是Adobe Systems 公司为Flash播放器和流媒体服务器之间传输音频、视频和数据所开发的私有协议,后来2009年开放了RTMP协议。
1. 协议控制消息
2. 命令消息
AMF编码方式是Adobe公司开发的一种通信协议,它采用二进制形式,为基于Flash的播放器和远程服务器提供一种轻量级的、高效能的通信方式。
6.2.4 HTTP Streaming
1. HTTP Streaming 的前身是Progressive Download(渐进式下载), 它也是通过HTTP协议来传输文件。
Progressive Download在用户点击播放视频节目时,会给用户发送视频文件,用户可以边下载、边播放,而无须等到文件下载完毕。如果用户暂停播放,服务器依然会给客户端发送视频文件,直到整个文件下载完毕或者用户关闭视频。这样,用户在决定退出视频时可能已经下载了较多的未播放文件,对于带宽资源是一种较大的浪费,尤其在并发访问较多的高峰时段。
HTTP Streaming 首先会将视频数据(包括直播的视频流和点播的视频文件)在服务器上进行编码,然后将编码后的数据进行更细粒度的分片,再把每个分片通过HTTP协议传输到客户端。与Progressive Download中客户端通过一个Http请求来下载整个视频文件的方式不同,HTTP Streaming 的客户端需要对每个视频文件的每个分片都发出一个HTTP请求,这样,在视频播放速度低于下载速度的情况下,客户端可以灵活控制HTTP请求的发出速度,从而保证用户在中途退出时不会出现下载浪费。
HTTP Streaming 具有以下特点:
HTTP Streaming支持点播和直播,而Progressive Download只支持点播;
HTTP Streaming可以对分片文件进行加密,保证数字版权,而Progressive Download方式直接把媒体文件下载到客户端并进行缓存,无法 保障版权所有;
HTTP Streaming 是把媒体文件分割成多个小文件分片,支持在播放过程中根据网络带宽进行码率切换,而Progressive Download始终是以固定码流进行播放,不支持码率切换。
2. Apple HTTP Live Streaming
从概念上讲,HTTP Live Streaming 流化技术主要涉及三个部分:服务器组件、分发组件和客户端软件。
6.2.5 MPEG-2 TS
1. MPEG-2 TS 指TS格式封装的,MPEG-2编码的流媒体流。之所以把这种组合方式拿出来讲一下,是因为目前大多数IPTV系统使用的是这种内容源,其他业务系统如果使用来自电视台,电影公司和广电企业的内容源,基本都是这种格式的。
MPEG-2 是“活动图像及有关声音信息的统用编码”(Generic Coding of Moving Picture Associated Audio Information), 由MPEG (Moving Picture Experts Group )开发
2. MPEG-2 系统定义了复用一个或多个音频、视频和数据元素流的方法。MPEG-2系统标准有节目流(PS)和传输流(TS)两种数据流,PS用可变长度包,TS用固定尺寸包(188字节)。
3. TS具有很好的开放性,能支持多种编码标准,包括MPEG-1 、 MPEG-2、MPEG-4、H264 、VC-1, 也包括我国的AVS标准
4. 随着H.264编码的广泛应用,广电系统也逐步转向支持H.264(MPEG-4 AVC )over TS 封装格式
可以简单理解为:H.264这一层完成原始文件的压缩编码,TS负责音视频的复用以及同步,RTP负责流的顺序传输,UDP负责数据包的交换,IP层负责传输路由选择。
6.3 流媒体业务对CDN提出的要求和挑战
1. CDN对内容采取的分发方式分为pull 和push 两种,pull是被动下拉的方式,push 是主动推送的方式
对于流媒体内容,系统一般会选择对热点内容采取push方式的预分发,而普通网页内容几乎100%是pull方式的。通过push方式降低CDN回源对源站服务器的压力
6.3.2 流媒体CDN系统架构描述
1.流媒体CDN系统总体上符合CDN系统通用架构,由管理支撑子系统、负载均衡子系统、内容管理子系统、流媒体服务子系统组成。
2. 管理支撑子系统是CDN系统的网络管理和业务管理系统,主要功能包括:
网络管理: 提供拓扑管理、节点管理、设备管理、配置管理、故障管理、性能管理以及网络安全管理等;网络管理模块不仅负责提供对整个系统进行日常运维的手段,还要负责收集执行业务策略所需要的实时统计数据,比如为GSLB提供调度策略执行依据,在全网范围内配置业务属性,分配网络和能力资源。
运营管理:负责客户管理、客户自服务实现、产品/业务能力管理、工单管理、认证管理、计费和结算管理等。这些功能使CDN系统对外提供服务、销售称为可能,也为CDN的客户提供了友好的业务操作界面。因此,虽然运营管理模块并没有参与具体业务能力提供,但却对整个CDN系统的商业竞争力起到至关重要的作用。
统计分析:包括日志管理功能和数据筛选、分析功能,以及报表生成功能。统计分析功能应该对按照不同的指标对CDN网络运行情况和服务情况进行统计分析,同时以灵活的、有针对性的方式向客户呈现。
业务接口:负责和其他系统之间的接口适配功能,包括与外部BOSS系统的接口、与门户系统的接口,并向SP提供自助服务接口。
3. 负载均衡子系统
负责用户访问调度,根据对用户位置、设备负载、内容位置等信息的判定,执行预先设置的负载均衡策略,将用户调度到最合适的节点设备上进行服务。
在流媒体CDN系统中,用户访问的调度更多会考虑内容命中,主要是因为流媒体内容文件体积大,业务质量要求高,如果从其他节点拉内容再向用户提供服务会带来额外的延迟,影响用户体验。
为进一步提高命中率,流媒体CDN系统普遍采用了对热点内容实施预先PUSH的内容分发策略,因此,负载均衡子系统与内容管理子系统之间会有比较频繁的交互查询行为。
4. 流媒体服务子系统
是指为用户提供流媒体服务的各种设备组成的服务系统,具体来说就是一些Cache 设备或者Cache的集群,以及对集群和设备进行资源统计、配合负载均衡系统和运营管理系统进行功能所需要的周边网元设备。
在流媒体服务系统中,主要关注的技术是对不同流媒体协议、不同编码格式、不同播放器、不同业务质量要求等的适应。一般来说,CDN服务商会在流媒体子系统中采用垂直业务能力的方式,也就是说,从中心Cache到区域Cache、边缘Cache统一部署单独的业务能力。
6.3.3 小结
1.
现在投入商用的CDN系统,基本都是同时提供Web CDN能力和流媒体CDN能力的,而且这两种能力的实现在系统内部几乎都是相互隔离的,从调度系统到节点设备都么有交叉互用,说明这两条技术路线已经差别比较大了
2.
6.4 流媒体CDN系统的关键技术实现
6.4.1 Cache 的设计实现
1. CDN的Cache 设备是直接为用户提供内容的设备,主要有两个功能:一是对内容进行缓存,而是直接响应用户的内容访问请求。
2. 流媒体设备面向资源,设计重点是对存储设备、内存、存储I/O、CPU运算等多种资源的有效协调。流媒体Cache设备的直接设计目标和性能衡量指标是用户接收的媒体质量、用户端启动延迟,以及传输多媒体数据对网络资源的消耗等。
6.4.2 负载均衡系统设计实现
1. 有两种GSLB实现方式,一种是基于DNS的,一种是基于应用层重定向的。基于HTTP重定向方式的负载均衡由于能够看到用户IP和请求的具体内容,因而能够实现更精细、更准确的调度。因此,流媒体CDN大多会选用HTTP重定向方式,有的是与DNS方式结合使用,有的是直接使用。
6.4.3 内容分发机制设计实现
1. pull , 是一种被动的下拉方式,通常由用户请求驱动。当用户请求的内容在边缘Cache上未命中时,边缘Cache启动pull方法从内容源或者其他Cache实时获取内容。边缘Cache需要支持边拉边放,即一边从其他位置获取内容,一边将内容流化后提供给用户。在pull方式下,内容的分发是按需的。
2. push, 是一种主动推送的方式,通常是由内容管理系统发起的,将内容从源或者中心媒体资源库分发到各边缘的Cache节点。通过Push 分发的内容一般是访问热度高的内容,这些内容通过push方式预推到边缘Cache,可以迅速响应用户请求访问。
6.4.4 组网模式
1. 对于使用CDN服务的SP来说,CDN的作用在于尽量就近为用户提供服务,帮助SP解决长距离IP传输和跨域传输带来的种种业务质量问题。
2. 从网络分层上看,Web CDN通常是两级架构,即中心-边缘。而流媒体CDN通常有三级以上架构,即中心-区域-边缘。
采用这种区别的原因在于流媒体回源成本比较高,源站服务器响应一次流媒体内容回源请求,要比Web内容回源消耗更多资源。尤其对于流媒体直播业务来说,主要直播节目没结束,服务器就需要长时间持续吐流,如果没有第二次节点作为中继,那么中心节点的压力将是不可想象的。
3. 边缘Cache离用户越近,服务质量越好,但覆盖的用户量越少,部署成本越高。这是一个平衡问题。
6.4.5 内容文件预处理技术
内容文件预处理是指视频内容进入CDN以后,进入内容分发流程之前,CDN系统对内容进行的一系列处理过程。
这个预处理目的有几个:
1. 为全网内容管理提供依据,比如对内容进行全网唯一标识,对内容基础信息进行记录等;
2. 为提高CDN服务效率或降低系统成本提供手段,比如内容切片;
3. 为满足业务要求提供能力,比如对同一内容进行多种码率的转换以满足动态带宽自适应或三屏互动业务要求
1. 视频转码
视频转码(video transcoding)是指将已经压缩编码封装完成的视频流转换成另一个视频码流,以适应不同的网络带宽,不同的终端和不同的用户要求。转码本质上是一个先解码、再编码的过程。
视频转码的功能包括:
码流转换:不改变编码格式,只是将原始码率转换成新的码率以适应网络传送要求,一般是将高码率视频转换成低码率视频。
空间分辨率转换:指通过全解全编架构中添加采样模块,利用采样算法和运动矢量的映射算法以及伸缩算法来降低视频码流的空间分辨率。
时间分辨率转换:通过降低视频序列的帧率,降低对解码设备处理能力的要求。降低帧率并不是简单的丢弃帧。
编码格式转换:将原始视频内容所采用的编码格式转换成终端能够解码的播放格式。这是典型的先解码再编码的过程。
2. 文件切片
文件切片是指按照一定的规则把一个完整的文件切成大小一致的若干个小文件,这不是流媒体CDN的新技术。
文件切片的一个目的是:使边缘Cache能够支持自适应码率业务。
自适应码率的原理是:同一个视频节目预先压缩从低到高几种码率的文件,并采用统一策略对这几种码率的文件进行切片。比如按照统一的时间长度,或者统一的字节数等。在具体提供流服务时,Cache会与终端先协商一个初始码率,以这个初始码率进行传送。传送过程中,终端和Cache都会不断探测流传送的速度,当发现当前码率低于可用带宽时,就切换到高码率文件进行传送,反之则切换到低码率文件。这种码率切换的同时又要保证用户观看的视频流不中断,其基础就是不同码率的文件预先都进行了切片,码率切换过程是在两个独立切片之间完成的,对终端来说,每个切片都是一个完整的小文件,所以不会感觉到中断。
6.4.6 防盗链机制和实现
1. 网站的盗链是指通过技术手段,直接在本网站页面上向最终用户提供其他网站的内容,从而免费获取其他网站的优质资源。
防盗链常用实现方式:
防盗链方法1: 利用HTTP Refer字段
网站服务器通过判断浏览器请求内容的HTTP 数据包头的Refer字段值,能够获得浏览器所处的页面地址,这样就知道用户此时是指本网站的页面上,还是在其他不合法的页面上。
防盗链方法2: 利用登录验证信息
这个方法应用于需要用户登录认证才能浏览的网站,比如论坛、社区、会员制网站等。
防盗链方法3: 使用cookie携带动态验证信息
方法是网站在页面里产生一个动态的cookie,服务器在处理资源请求时先判断请求中是否携带了正确的动态cookie,如果没有则返回错误提示信息。
防盗链方法4: 使用post下载
客户端浏览器请求资源时都使用的是HTTP的get 方法,服务器使用post方法向客户端返回数据。
防盗链方法5:使用图形验证码
这个方法保证资源的使用者是人,而不是其他网站的服务器或者下载工具。
防盗链方法6:使用动态密钥
当用户点击一个资源链接时,服务器先计算一个临时的key, 然后记录这个key以及它所对应的资源ID或文件名,再通过一定的算法或规则为资源生成一个新的URL,这个新的URL里需要包含这个key。当浏览器向服务器请求这个资源时,程序先检测URL里是否有合法的key 存在,如果存在则返回对应的资源数据。
防盗链方法7:在内容中插入数据
是指在内容的某个地方插入一些随机的字节,比如mp3 的tag区中。
防盗链方法8:打包下载
这种方法不适用于在线流媒体业务,只能用于下载业务。
第七章 动态内容加速服务的实现
p250
第八章 CDN商业化服务现状
8.1 CDN产业分析
8.1.1 CDN产业链分析
1. 在整个产业链中,从平台设备、内容到最终用户,各角色各负其责,内容提供商和用户位于价值链的两侧,中间依靠网络服务提供商将其串接起来。互联网内容的提供经过了SP自建集群服务器、IDC内容托管、镜像网站、CDN分发4个阶段。
2. 但是IDC并不能解决内容的有效发布问题,托管在IDC中的内容还是位于网络的中心,所有不能解决网络骨干带宽的占用问题和建立IP网络上的流量秩序。因此将内容推到网络的边缘,为用户提供就近性的边缘服务,从而保证了服务的质量和整个网络上的访问秩序就成立一种显而易见的选择。
而这就是CDN的服务模式
8.1.3 CDN服务运营方式分析
CDN主要有以下三种运营方式:自建、租用和混合
自建:自建CDN是指内容提供商自己租用带宽和托管服务,并自行开发和管理响应的CDN系统和平台。自建CDN需要内容提供商的规模足够大,足以支持一个全网的CDN服务,同时具备相当的技术力量和维护力量,需求相对单一明确,复杂度不高,个性化较强。各大门户网站和视频网站均有自建的CDN网络。
租用:CDN运营商向电信运营商采购接入和托管服务,加入CDN技术增值之后,将CDn网络带宽出租给内容供应商,即利用CDN为内容供应商提供有质量保证和局部个性化的内容分发服务,而以占用的带宽和存储容量为标准向内容供应商收费。
混合:混合方式是指内容供应商采用自建和租用混合的方式对自己的CDN服务进行整体布局规划,混合的选择标准包括地域、业务和峰值分担等。
8.2 CDN的商业服务模式
8.2.1 CDN的计费方式
1. CDN服务一般有两种计费方式,即带宽计费和流量计费。
带宽的单位是bit/s , 流量的单位是bit. 带宽指的是一种传送速度,而流量是一种传送数量。
2. 采用带宽计费时,根据取值方法的不同,可以分为峰值计费和95计费
峰值计费采用一个时间段内的最高点作为计费依据,这种计费方式在遇到特殊流量变化时,往往会造成费用激增。
95计费:即在一个计费周期内,每5分钟采集一个平均带宽(5分钟内流量除以以秒为单位的时长),一个月内采集8000多个计费值,抛弃掉前5%的计费值,剩下的最高值作为计费依据。
根据一般经验,95计费大约为峰值计费的80%左右
8.4 典型服务商介绍
8.4.1 国外CDN运营商的先驱-Akamai
Akamai 采用的运营模式主要是租用电信带宽形成CDN网络,再将CDN网络带宽以电信带宽3~4倍的价格卖给或租给互联网网络运营者,而以占用的带宽和存储容量为标准向内容网站收费。
第九章 CDN发展展望
附录A CDN实验床实施指南
A.1 试验床架构概述
1. 实验床涵盖了CDN系统实施和运行中的关键组件,包括源站点、站点代理缓存、集群负载均衡、全局负载均衡等。其整体架构图如下:
A.2. 1 服务器虚拟化环境部署
1. 检测物理服务器的硬件虚拟化支持情况
KVM的实现要基于硬件支持的虚拟化技术,对CPU剧透较高的要求。
A.3.1 Apache HTTP服务器的安装与配置
1. 下载地址:http://httpd.apache.org/download.cgi
执行./configure --prefix=/usr/local/apache & make &make install
2. 启动HTTP服务
cd /usr/local/apache/bin
[root@localhost bin]# ./apachectl start
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using localhost.localdomain. Set the 'ServerName' directive globally to suppress this message
apache 启动后进程:
[root@localhost bin]# ps -ef|grep apache
root 3895 1 0 14:15 ? 00:00:00 /usr/local/apache/bin/httpd -k start
daemon 3896 3895 0 14:15 ? 00:00:00 /usr/local/apache/bin/httpd -k start
daemon 3897 3895 0 14:15 ? 00:00:00 /usr/local/apache/bin/httpd -k start
daemon 3898 3895 0 14:15 ? 00:00:00 /usr/local/apache/bin/httpd -k start
root 4017 3505 0 14:24 pts/1 00:00:00 grep --color=auto apache
访问apache 服务器:
在访问Apache服务器时,有可能访问失败。原因是没有关闭虚拟机的防火墙,centos7 0默认使用的是firewall作为防火墙,所有首先要关闭防火墙
[root@localhost install]# firewall-cmd --state
running
[root@localhost install]# systemctl stop firewalld.service
[root@localhost install]# systemctl disable firewalld.service
Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.
Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.
[root@localhost install]# firewall-cmd --state
not running
3. 跟nginx差不多, apache/conf 目录下的httpd.conf 就是Apache的配置文件
/usr/local/apache/conf/httpd.conf:
#
# ServerName gives the name and port that the server uses to identify itself.
# This can often be determined automatically, but we recommend you specify
# it explicitly to prevent problems during startup.
#
# If your host doesn't have a registered DNS name, enter its IP address here.
#
ServerName yang.root:80
重要的配置参数见下图,注意一点就是都是大写开头
4. apache/logs 目录下面也是Apache的log文件,跟nginx相同,也有httpd.pid 进程id , access_log 和error log 日志
[root@localhost logs]# ll
total 8
-rw-r--r--. 1 root root 0 Jun 14 17:25 access_log
-rw-r--r--. 1 root root 700 Jun 17 14:15 error_log
-rw-r--r--. 1 root root 5 Jun 17 14:15 httpd.pid
[root@localhost logs]# tail -f error_log
[Mon Jun 17 14:15:15.686192 2019] [mpm_event:notice] [pid 3895:tid 139638609901376] AH00489: Apache/2.4.39 (Unix) configured -- resuming normal operations
[Mon Jun 17 14:15:15.687729 2019] [core:notice] [pid 3895:tid 139638609901376] AH00094: Command line: '/usr/local/apache/bin/httpd'
[root@localhost logs]# tail -f access_log
10.216.184.122 - - [17/Jun/2019:14:28:42 +0800] "GET / HTTP/1.1" 200 45
10.216.184.122 - - [17/Jun/2019:14:28:42 +0800] "GET /favicon.ico HTTP/1.1" 404 209
p351