cdn 的 gzip

对于大多数的 cdn 厂商来说,默认是不会开启 gzip 压缩的,不然没法赚钱了,这个跟之前闹的火热的 Heroku 为了赚钱修改路由一样的手法。

要判断 cdn 是否开了 gzip 很简单,通过 curl 既可完成:
$ curl -I -H "Accept-Encoding: gzip,deflate" "$URL" --silent | grep -i "Content-Encoding:"
从网上抄了简单的脚本:
gzipchk(){ curl -I -H 'Accept-Encoding: gzip,deflate' "[email protected]" | grep –color 'Content-Encoding:'; }
$ gzipchk http://www.redhat.com

对于 apache 来说,需要开启 mod_deflate 或者 mod_gzip 这两个模块。
对于 nginx 来说,需要加上下面则个指令:
gzip  on;
当然,前提是编译的时候有 "HTTP_GZIP=YES" 选项。另外,如果想针对单独的 user agent 做设置,可以像下面这样:
gzip_disable "msie";

这里还提到了一个有趣的问题,作者下下来的文件是 file.gzip 文件,需要经过一个 pipe 才能查看:
$ curl "http://example.com" | gunzip
下面有人给出了答案,通过 –compressed 的方式

如果不会使用 curl,直接打开这个网址就好了。

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 比较常用。
Continue reading

CDN 简介(三)

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

第 4 章 集群服务与负载均衡技术
CDN 内部的一些细节并没有一个标准来统一,所以下面说的这些也只是一家之谈,但是大的方向不会错。

CDN 是典型的负载均衡集群系统。其集群之间的通信可以分为松耦合和紧密耦合两类,其中前者有 ICP、HTCP、Cache Digest、Cache Pre-filling 等;后者以 CARP 为主。其中 CARP 相比松散的耦合有更明显的优势。
对于 LB,要解决的无非是 LB 请求的分发、会话保持、服务健康监测、故障隔离、自动恢复等问题。
分发其采取的算法基本类似,包括静态和动态两大类,静态的意思是按照预先设置好的策略进行分发,而不考虑服务器当前的实际负载状况,比较简单快捷,包括轮询、加权轮询、基于源/目的 IP 的 hash 等;动态的就是能够根据当前服务器状况进行分发,包括最小连接,加权最小连接等。
会话保持可以采取根据源 IP 地址的持续保持、cookie 持续保持等方式。
健康检测的问题,这个大部分都是从 ICMP、TCP、HTTP 层面进行检测。
目前主流的有 L4 和 L7 两种,L7 颗粒更细,但对系统的要求也比较高,因为需要针对 7 层上面的不同的协议做不同的识别分发机制,用的比较多的就是 HTTP 协议,通常使用专门的硬件实现。软件比较流行的有 LVS,Nginx,Haproxy。
Continue reading

CDN 简介(二)

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

第 3 章 内容缓存工作原理及实现
互联网最终的就是 cache,CDN 也不列外。在 CDN 出现之前,有如下的一些技术来解决部分的问题:
1. scale up/scale out
这个当然目前还在使用,前者是提高服务器配置,后者就是直接加机器。不过这些不能很好的解决问题,尤其对于距离较远的用户。

2. mirroring
这个目前还是有不少网站在用的,就是做一个跟源站一模一样的 mirror,然后可以通过 IP 或者 DNS 解析来定向用户的访问,不过大部分时候是用户自己选择,你得把用户都当作傻逼,因此他们选错了非但不能起到加速的效果,反而由于跨了运营商而拖了后腿。其次就是这个由于是这个资源的 mirror,需要大量的资源的堆积。

3. cache
这个已经有 CDN 的雏形在里面了,减少重复的访问,节约带宽。

下面这些问题是一个网站发展过程中都会遇到的,CDN 能够很大程度上解决这些问题。
1. 无法及时满足用户的并发需求
2. 在没有 mirror 之前,远距离访问很痛苦
3. 有了 mirror,不能及时同步
4. 一个 mirror 失效,不能及时调度
5. 部署了多套 mirror 之后,成本会显著增加
6. 中心机器的 IP 暴露,安全性问题

cache 一般都是作为 proxy 使用的,说到 proxy 也就有正向、反向和透明三种模式。
正向在公司内部使用较多,主要是控制灵活,用户需要将 GW 设置为这个 cache 的 IP。这样可以节约带宽,上网行为审计,同时也可以加速网页访问。
反向一般部署在网站前面,对于用户来说,是透明的。这样第一比较安全,第二也能起到一定的 LB 作用,这时候就可以通过 GSLB 来对全网的 cache 设备做 LB。
透明跟正向类似,但是用户不需要设置 GW 为这个代理的 IP。当用户请求一个 url 时,其请求被透明,然后他检查是 hit 了还是 miss 了,如果 miss 则帮助用户取回数据然后返回给用户。

cache 最起码有下面几个好处:
1. 减少相应延时
2. 较少带宽
3. 减轻服务器压力
Continue reading

CDN 简介(一)

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

第 1 章 引言
用户访问网络,会遇到下面四个地方的瓶颈。
1. 第一公里,也就是网站接入互联网提供的带宽,访问量越大,带宽消耗也就越多,如果在某个时间段内,超过了预计的带宽使用,会造成网络拥塞,严重的直接丢包,用户无法访问。
2. 最后一公里,就是用户接入互联网的那段链路,也就是用户的接入带宽,早期家庭的带宽比较小,近几年光纤发展,10M 甚至 20M 的带宽成为了可能。
3. 运营商之间的互联互通,这个是大陆的特色,跨运营商的带宽非常的小,而且结合的点比较少,因此电信要访问联通的资源就会比较慢。
4. 骨干带宽拥塞,这个不单单是大陆的问题,骨干网络的核心节点一般承载的压力都比较大,路由饱和也时有发生,造成的结果就是排队或者直接丢包。
大家可以看《中国电信2009年chinanet网络优化方案交流》这个幻灯片,感谢 @yangzhe1990 同学提供,省与省之间的带宽大的也不过就几十 G 的样子。看看现在 IDC 的建设,动不动就是 10G 的网络,40G 也早就实现了。

对于互联网来说,时间就是金钱,一个网站,如果用户等待的时间超过 8s 就会流失 30% 的用户。每增加 1s 的等待时间,转化率就会降低 7%。
通过 CDN,对用户来说,可以提高访问的速度,对网站来说,通过将访问压力分散到各个边缘节点,避免了网站的某个或者某几个节点压力过大的问题,同时可以节约宝贵的双线或者多线的的带宽成本,从而降低整个带宽成本,明显是个三赢的局面。

最早开始商业化运作的,也是目前全球最大的 Akamai,目前占据整个互联网 20% 的流量,由 World Wide Wait 变成了 World Wide Web。大陆做的比较好的也就那么几家,蓝汛,帝联,网宿,还有个前段时间被收购的快网。

第 2 章 CDN 技术概述
CDN 其实是个很庞大的系统,可以分为几个大的部分:
分发服务系统:静态内容、动态内容、流媒体、应用协议加速等以及日志的采集
负载均衡系统:域名解析、全局/区域/本地负载均衡、流量管理
运营系统:客户管理、计费、数据展示等
网络管理系统:设备管理、链路监控、故障处理恢复等

主要就上面的这些,其他的大同小异,灵活变通就好了。

CDN 的最终目的是为了减少用户的等待时间,因此需要在 POP(point of presence)节点、区域或者中心节点部署大量的 cache 设备。CDN 系统中负责管理调度的设备组成中心节点,其保存了最多的副本,当 POP 设备未命中时,会向中心节点请求,如果中心的仍未命中,则出现了回源,也就是向源站取数据。
对于一个节点来说,其 cache 设备以及 LB 的设备部署大体有两种方式,一个是旁路,一个是穿越,其实就类似 LVS 着哦你活该的 DR 以及 Nat 方式了,但是安全性方便显然是 nat 好些,但是从扩展的角度来说,DR 方式更好。
一般商业的 CDN 也会根据不同业务,划分了普通的网页加速、流媒体加速、大文件加速、动态加速、应用协议加速,前面几个比较好理解,动态加速最大的问题就是要保证各个节点与源站之间副本一致的问题,尤其涉及到 DB 的更新时;应用协议大部分时候是指 HTTPS 协议,这个要耗大量的 cpu 资源,因此可以通过专门的 SSL 硬件来实现加解密,同样的,单节点访问量大了即使有 SSL 硬件也撑不住,这个交给 CDN 做比较好。

CDN 行业报告研究

这篇报告归纳了当前 CDN 市场的整体行情,各个公司的实力,大陆的、国外的均有涉及,有些绝对的技术参数不是很准,但是我们看参照值就好了,可以参考。当然你也可以参照着去投资 ;-)

ref:
http://www.xcf.cn/zjfxs/yjzs/tx/201210/t20121003_359530.htm