CDN技术详解

这书随便读一读就好，网上资料也不多，稍微整理一下。  

HTTP协议中的缓存技术

（1）HTML META标签和HTTP头信息

（2）使用Expires（过期时间）头信息控制保鲜期

（3）验证

（4）Cache-Control（缓存控制）HTTP头信息

（5）Pragma HTTP头信息   

Web Cache性能指标

（1）并发量

（2）吞吐量

（3）命中率

（4）响应时间和丢包率

具体包括以下方面：

DNS解析时间：0.18-0.3s为正常，小于0.18s为优秀

建立连接时间：指浏览器与Web服务器建立TCP/IP连接所消耗的时间。0.15-0.3秒为正常，小于0.15秒为优秀。

重定向时间：指从收到Web服务器重定向指令到Web服务器提供的第一个数据包之前的消耗时间，通常小于0.1s。

首包时间：指从浏览器和Web服务器请求结束开始，到收到第一个数据包所消耗的时间。主要考量的动态或回源的性能，正常时间为0.2-0.4s。

图片下载时间：通常采用150KB大小的图片下载所需要的时间来评测CDN元素级加速性能，正常时间为1-2s。

页面总下载时间：指页面所有内容全部到达浏览器的时间，通常在10s以内。

丢包率：指的是Web Cache响应数据传输过程中所丢失的数据包数量占所发送数据包的比例，丢包率越高导致重传的数据量越大，从而延长Cache响应时间。

  

Cache集群协同交互方法

ICP

ICP用于在Web Cache服务器之间互相查询Web资源信息，以确定当前被请求资源是否存在于其他服务器上。反馈信息包括hit & miss。ICP使用UDP，以保证快速响应。ICP的请求和应答中不包括与资源相关的HTTP头信息，如访问控制，缓存指示等。

HTCP

HTCP是用于发现HTTP高速缓存服务器和缓存数据的协议。HTCP有ICP v2一样的功能，但HTCP请求和应答中可以包含完整的HTTP头文件的信息。HTCP还采用了可变长度的消息格式，并扩展了Cache管理功能，如能够监控远程Cache的增删，请求立即删除，发送Web对象提示（例如被缓存对象的第三方存放位置以及那些不可被缓存或者不可用的Web对象的第三方存放位置）。

一个HTCP消息包括三个部分：头消息，数据，认证。

头信息部分主要用于告知消息的长度和协议的版本

数据部分主要用于描述具体的HTCP消息，其中包含各种HTCP操作码和操作数据，如用于测试缓存应答是否存在的TST，用于告知邻居更新缓存目标头文件的SET，用于告知邻居从其Cache中清除目标的CLR，监控邻居Cache活动的MON等。

认证部分是可选的，用于体现事务操作的认证信息。

HTCP可选TCP或UDP连接传送。一般使用HMAC-MD5认证。

Cache Digest

Cache Digest主要是为了解决ICP和HTCP协议在使用过程中的网络延迟和拥塞问题。不采用请求-问答模式的带内查询方法，二是在服务器间建立对等关系。是一种空间换时间的思路，即利用Cache服务器本地的存储空间保存邻居服务器的Cache内容信息，从而节省每次查询过程中在网络上的传输延迟。Cache Digest推荐试用pull的方式主动从其他服务器上拉文件，以降低摘要文件被篡改而造成的大流量等安全问题。

Cache Pre-filling

Cache Pre-filing是一种推送Cache内容的机制，它能很好地应用在IP多播网络中。多在卫星通信中使用，能够同时向多个分布的地面卫星接收器告诉传输大容量数据。

CARP

CARP本质上是一个分布式的缓存协议，通过建立哈希函数用于划分Cache服务器集群的URL空间。CARP通过哈希算法将用户对URL的请求准确路由到服务器阵列中的任一成员上，消除了阵列中重复的缓存数据，实现了对Cache资源的高效定位。因为无须考虑更多的不可逆性和加密要求，CARP采用的算法非常简单，具有极高的性能。

考虑到不同的Cache服务器的处理能力差异，还引入的负载因子。CARP是一种紧耦合的Cache通信方式，相对松耦合的Cache通信，CARP的主要优势体现在：

（1）无须咨询查询的请求和应答过程，避免网络影响，降低传输开销。

（2）消除重复缓存数据，系统中每个URL内容只保留一份，节省空间。

（3）具有更好的扩展性，因为无须和众多其他Cache服务器进行网络交互。

（4）可以灵活增删服务器节点，哈希算法的应用能够最小化节点数量变化导致的数据分布影响。

（5）能够确保所有的URL数据都能够有效地缓存在系统中。

 

流媒体传送协议体系

RTP & RTCP & RTSP & RTMP

RTP（Realtime Transport Protocol）实时传输协议，RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。

RTCP（Realtime Transport Control Protocol）实时传输控制协议负责在会话参与者之间交互控制信息，RTCP分组包中含有已发送的数据包的数量，丢失的数据包的数量等统计数据。

RTSP（Real Time Streaming Protocol），实时流传输协议，用来实现播放控制的协议。

RTMP（Real Time Messaging Protocol），是Adobe为Flash播放器和流媒体服务器之间传输音频，视频和数据开发的私有协议。

HTTP Streaming

HTTP Streaming首先将视频数据在服务器上进行编码，然后将编码后的数据进行更细粒度的分片，再把每个分片通过HTTP协议传输到客户端。HTTP Streaming支持点播和直播，并可以对分片文件进行加密。HTTP Streaming基于TCP协议来传输，使用80端口进行数据传输。

  

防盗链

方法1：利用HTTP Referer字段

方法2：利用登录信息

方法3：使用cookie携带动态验证信息

方法4：使用POST下载

方法5：使用图形验证码

方法6：使用动态密钥

方法7：在内容中插入数据

方法8：打包下载

 

目前国内几家CDN厂商使用感受：

1.不做专门优化的CDN是渣。

2.最近有接触到一个客户，使用了蓝讯，快网，帝联的CDN，我在基调测了一个礼拜，拿到些数据，简单做下对比。

帝联各种数据屌爆，速度一直是最快的，可用率基本都是100%的。连快网的人都说，太硬了，但根据客户的反应，他们后台管理比较烂。

快网速度稍微比帝联差一些，一开始可用率不高，在联系快网的人优化节点下来，就明显好看多了。

蓝讯速度最差，有时候还是差蛮多，可用性一直处于第二，但快网优化后，两家的可用性就差不多了。

3.网宿貌似也很牛B，暂时还没有接触到。

  

各CDN厂商CNAME域名

网宿

.lxdns.com.

.wscdns.com.

.cdn20.com.

快网

.fastcdn.com.

.fwcdn.net.

fwdns.net.

.cloudcdn.net.

蓝汛

ccgslb.net.

.chinacache.net.

我在SF上看到一位大哥说了下CDN，说得蛮好：

原文链接：http://segmentfault.com/q/1010000000119794

1 你说的拉取式CDN，本质上是反向代理，甚至有的小CDN厂商找几个机房，搞几台低端硬件，装上squid就开始干活了。国内的代表（是反向代理类的大厂代表，不是小CDN代表啊）应该是中国擦车网（ChinaCache）、快网（FastWeb）、Weblucker

2 拉取式和推送式的DNS设置复杂度是完全一样的。不存在谁更麻烦的问题，都是设置DNS CNAME。只不过你在用又拍云的时候根，直接使用了又拍云的子域名，图片不在sfcdn.com这样的域名下，又拍也支持DNS CNAME，绑定你自己的sfcdn.com的。而中国擦车网等均不支持你直接使用CDN厂商的子域名。

3 这两者在逐渐融合。中国擦车网也有接口，允许你调用这个接口，主动将你指定的目录/文件同步到CDN节点上。又拍的反向代理模式也即将推出，时间我不知道。

4 推送式（又拍）的优点在于节省源站带宽，提前将要分发的内容放到CDN节点上了，当某个流量高峰来临时，不会把你的源站带宽占满（源站还要留点带宽提供动态HTML啊）。打个比方，类似聚划算的每天10点开团，如果没有主动推送，你的源站在10点将会迎来一个流量高峰，你不得不为源站服务器购买更大的BGP带宽，以便CDN每天10点拉文件。缺点是需要针对CDN做接口开发，在被分发内容生成时主动上传给CDN

5 抓取式（反向代理）的优点在于实在太简单，签个合同，做个DNS CNAME解析就完成了CDN的实施

6 像贵站这样的小公司，没有历史项目的包袱，有自己的研发团队，建议将来重点使用主动推送类的CDN，之所以说是将来，是因为目前又拍自己的中心结点往全国节点同步的时候还存在分钟级的延时，又没其它的同类厂商，给创业企业多一些包容和支持，相信又拍会越做越好。

7 动态合并JS不是问题。你完全可以合并好了之后上传到又拍上去，比如10个JS要动态合并，也就100种组合，全部合并好了传上去，HTML中引用合并好之后的js路径，这需要打包发布工具的支持，适合新公司，不适合老公司。

8 CDN行业不是大家以前想的那种傻大黑粗（跟电信关系好，搞几台机器装squid就开始赚钱了），也有很多公司在研发自己特色的东西，比如fastweb拥有自己的反向代理软件，还有动态内容（PHP，Java）加速服务（意义不是太大，且太贵，我举这个例子只是说他们有研发新东西）；比如又拍提供分布式存储和缩略图；比如ChinaCache研发了针对FLV视频网站CDN（这个投资很失败，大视频网站有几个不自己做CDN的啊？土豆跟它的合约一终止，它就开始变卖服务器回笼资金了）

9 在中国，大网站最终都要自己做CDN的，像Instagram这样10亿美元了还全部用Amazon的奇葩公司未来5年都不会出现。最终CDN的走向嘛，我想会出现几家综合性的“fastweb+又拍”服务商。