CDN 简介(四)

这个系列的文章主要参考《CDN 技术详解》,作为大陆第一本介绍 CDN 的,写的确实比较烂,根本就谈不上『详解』,但是『介绍』的性质已经达到了。因此,我会结合这本书以及自己的经验感受,皮毛的总结下 CDN 技术,因为很多具体的原体我也不是很清楚。

第 6 章 流媒体 CDN 系统的组成和关键技术
流媒体相比于静态文件,其对带宽,QOS,网络的稳定延时抖动等都比其他的业务要高得多,另外流媒体还有比较强的热点集中性的特点,当热点事件到来时,服务器的压力会飙升。另外由于需要有组播的需求,除了对服务器的要求相对较高外,对网络设备也有一定的要求。而 IP 组播的问题可以通过 CDN 节点服务器的流复制功能实现应用层的组播代替。
Internet 创建之初就是以传送简单的文本文件为目的的,流媒体显然是违背了这个理念的,因此就需要有相应的协议来解决上面说到的这些问题,具体的有 RTP/RTCP,RTSP,RTMP 等协议。由于 Flash 使用的是 RTMP 协议,因此其应用范围也比价广;另外还有中叫 HTTP Streaming 的技术用的也比较广,一般目前主流的如优酷等都是通过 HTTP Streaming 的技术实现的,通过 HTTP 来传输文件,通过 TCP 来保证可靠性以及流控。
相比于静态的,流媒体的回源比例更低,这个是必须的,一旦回源比例高了,再加上大带宽,高 I/O,最源的压力会非常的大。因此命中率这个指标对于流媒体来说是很重要的,因为未命中的向源查询请求所造成的资源消耗会比 Web Cache 高的多。
另外,大多时候,流媒体采用 PUSH 的方式进行内容分发,也就是源主动给 CDN 预分发,尤其是热点内容,而普通的网页,基本都是 PULL 方式。
流媒体一般是通过 DNS+HTTP 结合的方式进行解析负载,或者直接通过 HTTP,这样能够实现更精确的调度,而普通的更多是 DNS 解析的方式。
流媒体 CDN 要理解的各种流媒体协议比较多,其次是其缓存算法要求也很高。
除此之外,流媒体的 CDN Cache 一般都是大存储,高 I/O,这个跟普通的 Cache 完全不是一个类型,硬件差异很大。这个也是最重要的一点,Web Cache 更多的是小文件,高并发,对 CPU 要求比较高,而流媒体则是对大文件的持续高 I/O,TCP 长连接。
从组网的角度来看,普通的 Cache 通常是中心+边缘的结构。流媒体会多一层,通常是三层架构,中心+区域+边缘的架构,原因很简单,因为流媒体回源的成本很高,尤其对于直播来说,只要直播没结束,源站将持续压力。因此,这种三层的架构对于直播来说会大大的节约带宽,而对于一般的点播来说,则会节约存储。一般区域的会部署在重点的城市,而边缘的则部署在二三线城市,边缘离用户越近,质量越好,但是覆盖的用户的也越少,成本也越高,这个需要综合考虑。
由于流媒体对传统的存储消耗越来越大,因此现在很多厂商都使用文件切片的技术来实现文件的读取,每个 cache 都存储文件的部分切片,其余的从相邻的 cache 中获取,这个跟 P2P 的实习方式类似。切片的另外一个好处是支持自适应码率的业务。

跟静态文件一样,流媒体也面临防盗链的问题。有下面几种方式。
1. 利用 HTTP referer
2. 利用登录信息验证,这个必须要求用户身份进行验证
3. 使用 cookie 携带动态验证信息
4. 使用 POST 下载
5. 使用图形验证码
6. 使用动态密钥
7. 在内容中插入数据
8. 打包下载

其中 2、5 这两个明显不是很适合的。1 比较常用。

第 7 章 动态内容加速服务的实现
动态内容加速会涉及到业务逻辑,会有 DB 的访问。CDN 主要通过将源逻辑的各个层次复制到边缘节点实现分发。包括表现层以展示静态内容;业务逻辑的复制,讲应用程序直接放在边缘节点计算,也叫边缘计算;DB 的复制,负责动态内容的生成等;用户文件的复制,负责生成用户定制化内容的数据。
对于数据库的复制,主要分为整体复制以及分类复制两类,后者又包括不可感知的内容缓存(Content-Blind Caching)和可感知的内容缓存(Content-Aware Caching)两种。

不可感知内容的缓存是将源站经常被使用的逻辑查询的数据复制到边缘中,也就是说边缘保存的总是源站此前被查询过的内容。这种不缓存数据内容,而只是直接缓存查询结果的方式在复制数据库的访问层中使用比较广泛。在大部分为『读』的操作中,这种方式比较好,但是如果有大量的修改操作,这种查询结果缓存就是就不适用了,该技术只适用于那些重复发送相同查询结果要求的应用。
可感知的内容缓存是在边缘运行自己的 DB,保存源站中的部分试图。
数据库的整体复制则是保存一个跟源站一模一样的副本,但是依然存在数据一致性的问题,需要及时将写操作更新同步至各个副本。这个跟 DB 的 MS 结构很类似,S 负责读,M 负责写。

下面是应用加速的内容,首先是广域网加速的问题,首先是带宽瓶颈,其次是时延,这个比带宽的影响还大,然后还有应用层协议的低效率的问题。解决也是从这几个方面解决,比如像 sangfor 推出的广域网优化设备,这个貌似两端都是要部署的。然后还有个比较重要的就是 SSL 的加速问题,软件解决的对 CPU 的压力将会很大,所以一般也是交给专业的 SSL 加速板卡解决,这个会存在会话保持的问题,尤其在 LB 的架构上。于是出来了单独的带有 SSL 板卡的硬件设备,这样客户端跟 SSL 设备走 HTTPS,而 SSL 设备跟服务器走普通的 HTTP,这样就完全终结了 SSL 会话问题,服务器也可以安心的做本分工作了,另外,更多的时候 SSL 设备跟 LB 是连在一起的。

第 8 章 CDN 商业化服务现状
CDN 真是养活了一大批的人,从底层到上层的,设备供应,内容/广告提供商,服务提供商,宽带供应商,终端供应直至最终的用户。
对于比较大的互联网公司尤其像视频网站这种对带宽需求极大的公司,一般都是自建+采购集合的方式,在有突然流量的时候,比如搞促销等会加大对 CDN 服务商的采购。
关于计费方式,大多都是以带宽的方式来计费,而非流量。基本大陆就是 95 值计费、弟 4 峰值计费,以及平均值计费的方式。
95 计费是取每日 12×24 个点,从高到低排序,选第 15 个带宽点最问本日的,然后选择 30 天中最大的那个点作为计费点。
第四峰值计费,也就是每天的最大值,然后 30 天从高到低排序,选第四高的那个作为本月的带宽。
平均值计费就是每天的最大值,然后 /30 平均作为带宽。
各个计费方式各有优缺点需要根据各自的业务来选择。

CDN 除了能提供正常的加速之外,用他来做防 DDos 是种很好的方法,DDos 其实就是拼带宽,这个是 CDN 的强项,很少有攻击者的带宽能达到几百 G 的能力的。另外,其收集的 log 对来说也是笔巨大的财富,这个服务商只能进行简单的分析,剩下的还得靠自己。

实际使用 CDN 的过程中,需要考虑以下的问题:
1. 提供多少的节点
2. 这些节点分布在哪些地域,其运营商的信息
3. 命中率的问题,回源比例
上面这些是需要有量化指标的,除此之外,服务质量,技术实力也是需要考虑的。其实大陆之内的服务商很好选择,就那几家,然后找几家网络性能评估的服务商做测量,基本就能得出结论了,测试这个不能完全依靠第三方,自己在有限的范围内需要自我测试,如果自己这边都通不过,可以直接 pass 了。
最重要的是,在测试使用了 CDN 前后的对比,是否达到了预期的目标。

跟 CDN 一样热的就是云计算了,这个比较成功案例就是 Netflix 了,CDN 由 Akimai 提供,基础运维设施由 Amazon 的 EC2, S3 等提供。
国外的 CDN 比较多,资源技术水平也比大陆的雄厚,Akamai,11 年 Q2 的时候有接近 10W 的机器,20% 的全球网络流量。排在第一梯队的还有 Limelight,其次有 CDNetworks, Level 3 等。国内的就 ChinaCache, Chinanetcenter, dnion 这类专业的 CDN 服务商,以及自建的,比如优酷土豆等,当然,还有电信等,只能在自己的圈子里面玩玩过家家的小游戏的,除了资源,没有什么竞争力可言。CDN 在美帝的渗透率已经达到 80%,大陆不足 10%,钱/前途一片光明。

对于 CDN 的今后发展,大陆早就进入了 3G 时代,但是目前没有针对 3G 平台,也就是移动互联网的加速优化,我认为还有有必要针对不同的平台,针对性的做一些优化的。另外,目前 90% 以上的流量都是视频,高清、超清对 CDN 的要求也越来越高。最后就是调度算法的优化,存储成本的下降等。最后,可能考虑将 CDN 与 P2P 相结合。