http://stream9.music.soso.com/12579982.wma
Access Denied. Generated Fri, 30 Apr 2010 14:42:19 GMT by cache.51cdn.com (Cdn Cache Server V2.0)
CDN & Nginx gzip
CDN 对压缩文件是支持的，但是源服务器(Nginx Server)上文件要增加一个标准的 Vary: Accept-Encoding ，标头，
http://192.168.119.104/javascript/js410/jquery.js
http firebug
响应头信息
响应头信息 Server nginx/1.0.1 Date Wed, 14 Sep 2011 08:47:25 GMT Content-Type application/x-javascript Last-Modified Thu, 26 May 2011 18:27:46 GMT Vary Accept-Encoding Expires Sat, 17 Sep 2011 08:47:25 GMT Cache-Control max-age=259200 Content-Encoding gzip
请求头信息
请求头信息 Host 192.168.119.104 User-Agent Mozilla/5.0 (Windows NT 5.2; rv:6.0.2) Gecko/20100101 Firefox/6.0.2 Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language zh-cn,zh;q=0.5 Accept-Encoding gzip, deflate Accept-Charset GB2312,utf-8;q=0.7,*;q=0.7 Connection keep-alive If-Modified-Since Thu, 26 May 2011 18:27:46 GMT Cache-Control max-age=0
这样CDN会根据用户的请求提供相应的压缩文件和非压缩文件；
不然就可能偶然有用户请求了非压缩文件并缓存下来后，就一直提供非压缩的文件了。
这个标头，最好是在源服务器上添加下；
如果NGINX添加不了的话，CDN也可以根据文件类型来添加，不过这样没有源上添加的效率高
/usr/local/nginx/conf/nginx.conf
add gzip_vary on;
...
gzip on;
gzip_vary on;
gzip_min_length 1000;
#gzip_http_version 1.1;
gzip_buffers 4 8k;
#gzip_disable "MSIE [1-6].";
#gzip_disable "MSIE [1-6] \.";
#gzip_types text/plain application/x-javascript text/css text/html application/xml;
gzip_types text/plain application/x-javascript text/css text/htm application/xml;
...
产品选型：ChinaCache（北京）、世纪互联（北京）、网宿科技（上海）
--------------------------------------------------------------------------------
http://lindows.iteye.com/admin
您所请求的网址（URL）无法获取
当尝试读取以下网址（URL）时： http://lindows.iteye.com/admin
发生了下列的错误：
无法将您输入的主机名称：lindows.iteye.com转换成 IP 地址
域名服务器返回以下讯息：
Refused: The name server refuses to perform the specified operation.
这表示：
The cache was not able to resolve the hostname presented in the URL.
Check if the address is correct.
缓存服务器无法解析您输入网址（URL）中的主机名称，
请检查该名称是否正确。
本缓存服务器管理员：[email protected]
Generated Sat, 06 Mar 2010 03:02:37 GMT by cache.cdn.com (squid/2.7.STABLE7)
您所请求的网址（URL）无法获取
--------------------------------------------------------------------------------
http://www.jx.xinhuanet.com/review/2010-03/06/content_19176589.htm
当尝试读取以下网址（URL）时： http://www.jx.xinhuanet.com/review/2010-03/06/content_19176589.htm
发生了下列的错误：
无法将您输入的主机名称：www.jx.xinhuanet.com转换成 IP 地址
域名服务器返回以下讯息：
Timeout
这表示：
The cache was not able to resolve the hostname presented in the URL.
Check if the address is correct.
缓存服务器无法解析您输入网址（URL）中的主机名称，
请检查该名称是否正确。
本缓存服务器管理员：[email protected]
--------------------------------------------------------------------------------
Generated Sat, 06 Mar 2010 15:34:43 GMT by cache3.cdn.com (squid/2.7.STABLE7)
浅析CDN网络加速解决方案
http://betafox.iteye.com/blog/231347
经过近些年来的高速发展，互联网已经成为现今媒体传播的主要力量。这一点在大型体育赛事的报道与转播上，体现的尤为明显。更及时的信息内容、更多样的报道形式、更齐全的资料组成、更方便的阅读查询、更具互动性的报道方式，再一次诠释着互联网作为新兴媒介的价值与独特优势。
不断变化的客户需求
新的特点、新的优势必定会带来新的需求与新的问题。特别是Web2.0的推广与普及，使得互联网网站信息传播的方式有了更多选择。但是，无论信息的表现 形式如何变化，内容如何加工，一些基本的规则还是被人们广泛认同和遵守的。例如8秒钟定律。如何保证在用户增多的情况下，使每一个客户仍然能都获得理想的 访问体验，这就成为门户网站运营人员在不停增加网站内容，改进信息表现形式的同时所要面临的新挑战。
以某著名门户网站为例，其需求主要呈现以下几个方面特点：
• 用户众多，分布广泛，各类用户以及各地互联网接入情况差异较大；
• 信息量随特殊日期、事件而变化，造成门户网站带宽需求高低值差异巨大；
• 网站服务稳定性和请求响应要求高；
• 易遭受黑客和病毒攻击，网站安全性要求高；
• 架构复杂，应用多种网络技术；
• 个性化、差异化需求明显，特色服务带来特色应用需求服务；
考虑到大新体育赛事及其相关报道的特殊需求，在上述需求特点之外，用户又突出强调需要加强带宽冗余、访问保障、大批量文件快速传输、信息实时更新保障等新的要求，以确保赛事及其相关报道的顺利进行。
量身订造的解决方案
CDN是一种新型的网络构建方式，它是为了实现在传统的互联网平台发布多媒体信息而特别优化的网络覆盖层。CDN代表了一种基于质量与秩序的网络服务模 式。通过调整数据的计算、存储与传输这三者之间的关系，并将三者的负载在全网范围内进行均衡安排；利用分布式存储、负载均衡、网络请求的重定向和内容管理 4个要件，达到提高网站访问速度，提升用户体验的效果。CDN的核心是针对内容进行管理，所谓内容管理的一个基础是缓存服务器，也称作代理缓存；它位于网 络的边缘，距用户仅有“一跳之遥”。上图可以有效地说明CDN工作原理：
CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络"边缘"，使用户可 以就近取得所需的内容，解决Internet网络拥挤的状况，提高用户访问网
站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题。
CDN互联网内容发布网络（Content Delivery Network） CDN技术是近年来在美国首先兴起并迅速发展起来的一种解决互联网性能不佳问题的有效手段。 其基本思路就是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳。通过在网络各处放置节点服务器所构成的在现有的 互联网基础之上的一层智能虚拟网络，cdn系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导 向离用户最近的服务节点上。
实际上，内容分发布网络(CDN)是一种新型的网络构建方式，它是为能在传统的IP网发布宽带丰富媒体而特别优化的网络覆盖层；而从广义的角度，CDN代 表了一种基于质量与秩序的网络服务模式。简单地说，内容发布网(CDN)是一个经策略性部署的整体系统，包括分布式存储、负载均衡、网络请求的重定向和内 容管理４个要件，而内容管理和全局的网络流量管理(Traffic Management)是CDN的核心所在。通过用户就近性和服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务。总的来说，内 容服务基于缓存服务器，也称作代理缓存(Surrogate)，它位于网络的边缘，距用户仅有"一跳"(Single Hop)之遥。同时，代理缓存是内容提供商源服务器（通常位于CDN服务提供商的数据中心）的一个透明镜像。这样的架构使得CDN服务提供商能够代表他们 客户，即内容供应商，向最终用户提供尽可能好的体验，而这些用户是不能容忍请求响应时间有任何延迟的。据统计，采用CDN技术，能处理整个网站页面的 70%～95％的内容访问量，减轻服务器的压力，提升了网站的性能和可扩展性。
与目前现有的内容发布模式相比较，CDN强调了网络在内容发布中的重要性。通过引入主动的内容管理层的和全局负载均衡，CDN从根本上区别于传统的内容发 布模式。在传统的内容发布模式中，内容的发布由ICP的应用服务器完成，而网络只表现为一个透明的数据传输通道，这种透明性表现在网络的质量保证仅仅停留 在数据包的层面，而不能根据内容对象的不同区分服务质量。此外，由于IP网的"尽力而为"的特性使得其质量保证是依靠在用户和应用服务器之间端到端地提供 充分的、远大于实际所需的带宽通量来实现的。在这样的内容发布模式下，不仅大量宝贵的骨干带宽被占用，同时ICP的应用服务器的负载也变得非常重，而且不 可预计。当发生一些热点事件和出现浪涌流量时，会产生局部热点效应，从而使应用服务器过载退出服务。这种基于中心的应用服务器的内容发布模式的另外一个缺 陷在于个性化服务的缺失和对宽带服务价值链的扭曲，内容提供商承担了他们不该干也干不好的内容发布服务。
纵观整个宽带服务的价值链，内容提供商和用户位于整个价值链的两端，中间依靠网络服务提供商将其串接起来。随着互联网工业的成熟和商业模式的变革，在这条 价值链上的角色越来越多也越来越细分。比如内容／应用的运营商、托管服务提供商、骨干网络服务提供商、接入服务提供商等等。在这一条价值链上的每一个角色 都要分工合作、各司其职才能为客户提供良好的服务，从而带来多赢的局面。从内容与网络的结合模式上看，内容的发布已经走过了ICP的内容（应用）服务器和 IDC这两个阶段。IDC的热潮也催生了托管服务提供商这一角色。但是，IDC并不能解决内容的有效发布问题。内容位于网络的中心并不能解决骨干带宽的占 用和建立IP网络上的流量秩序。因此将内容推到网络的边缘，为用户提供就近性的边缘服务，从而保证服务的质量和整个网络上的访问秩序就成了一种显而易见的 选择。而这就是内容发布网(CDN)服务模式。CDN的建立解决了困扰内容运营商的内容"集中与分散"的两难选择，无疑对于构建良好的互联网价值链是有价 值的，也是不可或缺的最优网站加速服务。
目前，国内访问量较高的大型网站如新浪、网易等，均使用CDN网络加速技术，虽然网站的访问巨大，但无论在什么地方访问都会感觉速度很快。而一般的网站如果服务器在网通，电信用户访问很慢，如果服务器在电信，网通用户访问又很慢。
它采取了分布式网络缓存结构（即国际上流行的web cache技术），通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的cache服务器内，通过DNS负载均衡的技 术，判断用户来源就近访问cache服务器取得所需的内容，解决Internet网络拥塞状况，提高用户访问网站的响应速度，如同提供了多个分布在各地的 加速器，以达到快速、可冗余的为多个网站加速的目的。
CDN的特点
1、本地Cache加速 提高了企业站点（尤其含有大量图片和静态页面站点）的访问速度，并大大提高以上性质站点的稳定性
2、镜像服务 消除了不同运营商之间互联的瓶颈造成的影响，实现了跨运营商的网络加速，保证不同网络中的用户都能得到良好的访问质量。
3、远程加速 远程访问用户根据DNS负载均衡技术 智能自动选择Cache服务器，选择最快的Cache服务器，加快远程访问的速度
4、带宽优化 自动生成服务器的远程Mirror（镜像）cache服务器，远程用户访问时从cache服务器上读取数据，减少远程访问的带宽、分担网络流量、减轻原站点WEB服务器负载等功能。
5、集群抗攻击 广泛分布的CDN节点加上节点之间的智能冗于机制，可以有效地预防黑客入侵以及降低各种D.D.o.S攻击对网站的影响，同时保证较好的服务质量 。
CDN中的关键技术包含以下几个方面；
（1）内容发布：它借助于建立索引、缓存、流分裂、组播（Multicast）等技术，将内容发布或投递到距离用户最近的远程服务点（POP）处；
（2）内容路由：它是整体性的网络负载均衡技术，通过内容路由器中的重定向（DNS）机制，在多个远程POP上均衡用户的请求，以使用户请求得到最近内容源的响应；
（3）内容交换：它根据内容的可用性、服务器的可用性以及用户的背景，在POP的缓存服务器上，利用应用层交换、流分裂、重定向（ICP、WCCP）等技术，智能地平衡负载流量；
（4）性能管理：它通过内部和外部监控系统，获取网络部件的状况信息，测量内容发布的端到端性能（如包丢失、延时、平均带宽、启动时间、帧速率等），保证网络处于最佳的运行状态。
P4P与传统CDN、P2P的对比
7月30日消息：德国一个名为iPoque的研究机构在2007年研究了一百多万网民将近3TB的匿名数据流量，调查地区包括澳大利亚、东欧、德国、中东 和南欧地区。调查发现，目前网络带宽“消费大户”是P2P文件共享，在中东占据了49%，东欧地区占据了84%。从全球来看，晚上时段的网络带宽有95% 被P2P占据。据国内权威部门统计，当前P2P流量已经占整个互联网流量的约70%，并且正在以每年350%的速度增长。P2P流量消耗了巨大的网络带 宽，尤其是国际带宽，使网络基础设施不堪重负，运营商苦不堪言。
问题的症结不在于P2P，而在于交换的机制。P2P过于强调“对等”，每个节 点之间的交换完全是无序的。一个北京的用户，既可能和广州的用户进行文件片段的交换，也可能和远在美国的某用户进行交换。显然，无序的交换导致了无谓的跨 地区甚至是跨国的“流量旅行”，这耗费了宝贵的国内和国际带宽资源，代价巨大。
如果正好用户都在同一个地区，那么，本地化的交换的成 本就会大大降低。这也正是P4P的简单原理——让P2P也玩“同城”。 P4P全称是“Proactive network Provider Participation for P2P（电信运营商主动参与P2P网络）”。与P2P随机挑选Peer(对等机)不同，P4P协议可以协调网络拓扑数据，能够有效选择节点，从而提高网络 路由效率。仍以上述例子来说，北京的用户就可以优先和北京同城的用户来实现文件片段的交换，再扩展至较远的地区，有十分的必要时，才会出国进行文件片段交 换。当然，P4P的运行机制，要远远超过“同城交换”的概念，它还会根据用户的上行、下载带宽进行综合判断，以进行最有效选择，最大化整体交换的效率。
一个CDN问题 - 处理动态请求
http://www.iteye.com/topic/136521
当网站的负载达到一定负荷，需要扩容的时候，CDN正在成为网站的非常热门的选择。但是对于动态内容占绝大多数的网站，CDN是否还可以如期发挥作用呢？
我们都知道，CDN可以把网站的程序部署到不同的节点服务器上，并且就近响应用户的请求，这样可以缓解网站的负荷，有时候还可以防止攻击。
但是，一般的动态网站，数据库感觉很难同步部署到CDN的各个节点上。一方面是因为数据库一般不会直接暴露在公网中，另外一方面，数据库的数据实时性非常高，很难及时在远隔千里的节点去同步。
这样的话，各个节点的应用如果接收到动态的请求，因为本地没有数据库，并且由于数据库存在中心节点的内部网段，所以只好把请求转发给中心服务器去处理，等待处理完毕后，再把处理结果返回给CDN的服务器。感觉这种情况不仅不能有效地减轻负荷，反而适得其反。
也许像门户网站，存在大量静态内容，比如新闻，比如视频等，才适合用CDN ?
一种比较常规的cdn处理动态请求的做法，是通过专用的超快速通道把节点的请求转发到主站，然后再把结果返回给节点。因为专用通道速度很快，所以用户几乎感觉不到。有点类似于把主站当代理服务器的意思。
CDN 一般用来做静态文件的加速， 对于动态的数据的加速需要专用的设备。
我说的动态数据是指根据请求从源站点返回的数据。
在国内做的最大的是chinacache。
关于cdn对动态网站加速的一些看法
http://jspengxue.iteye.com/blog/45075
cdn技术采取了分布式网络缓存结构（即国际上流行的web cache技术），通过在现有的internet中增加一层新的网络架构，将网站的内容发布到最接近用户的cache服务器内，通过dns负载均衡的技 术，判断用户来源就近访问cache服务器取得所需的内容，解决internet网络拥塞状况，提高用户访问网站的响应速度，如同提供了多个分布在各地的 加速器，以达到快速、可冗余的为多个网站加速的目的。
由于cdn基本的加速手段是“dns智能选择最近的镜像”＋“镜像缓存静态内容”，所以在传统的观点中，cdn只是对静态页面加速，对动态页面没有效果。
对于动态网站的加速，网上大部分人都认为“不可能做到”，“加速效果不明显”，“它怎么能把数据库进行加速”。现在就我个人对cdn动态加速的了解，进行一一的说明。
（1）首先对于，大家所致疑的“能不能实现动态数据的加速”这个问题，我的理解如下：首先明确的是，对于大家针对动态代码和数据库的安全性考 虑，大多数据客户不会把动态代码和数据库的数据让cdn服务商发布到每个cache结点上。这一点大家都是这么做。毕竟是一个不能公开的部分。
如我们在南方电信a点访问没有加速前的动态网站b（放置在北方网通机房），慢，打开一个网站需要尽1分钟以上，ping a，得到的平均时间为：600ms以上ms。而使用cdn动态加速后，我们在a到b之间，插入了一个cdn的cache（c点）。这样得到的结果是从a到 c点的时间很快，大约10ms以内。现在我们看的就是从c点到b的时间。就cdn服务商的说法，一定是小于直接从a到b的时间减少a到c的时间，倒底是不 是呢？现在我们分析cdn服务商的布置cache节点的作用。它们在全国如果布有节点的话。并具有智能dns系统的话。它们就会在cdn服务提供的 cahce结点内部去寻找一条最短的路径，使从c到b的时间缩短。这就是大家常说的最佳路由。有以上的两个假设，一般对于动态网站的加速就能够达到且速度 比原来的时间到缩短50%以上。一般的像帝联，chinacahe都具有智能dns系统与在全国的布了多的节点。
（2）对于像一些图片等静态数据，仍采用静态加速的办法。综合起来的，可以达到对动态网站的加速效果，这里有一点注意的是，动态网站一般不会对数据库本身进行加速。这一点大家需要明白。
因此，动态cdn加速并不是一种虚妄的说法，其效果还是值得肯定，目前市场上也确实有服务商提出这样的口号，但是我们也要意识到，如果某个动 态页面的大部分内容都是由脚本代码产生，那么这个页面使用cdn加速是没有多大效果的，毕竟这个页面的主要内容没办法被存入镜像；但是对于图片较多的动态 页面，例如图片论坛，我想这种加速还是有意义的。
上海世纪互联
http://www.21vianet.com.cn/cn/product/prodetail.asp?id=736&m=1
wangzhongqiang 15938550430 / 18512512663
end