首先要纠正这个问题,动态内容是没办法缓存的。
动态内容需要的是信息的实时交互,如果采用了缓存,会影响正常业务。
举个例子,国航官网,订票内容就是动态的,如果这时候将这部分进行缓存,那当用户订票的时候,官网显示剩余10张票,并且在缓存过期内,会一直显示10张票。而实际数据库里已经没有票了。这时候势必会影响到客户体验。
动态内容的CDN加速其实还是链路和协议的优化。
首先,国内ISP复杂,南北互通的问题,会导致访问速度慢,CDN厂商有覆盖全国的PBL网络(可以理解为CDN提供商自己的私有网络,独立的ISP),当采用动态加速时,将内容引入CDN供应商的网络内,再根据分布在全国的CDN节点作为接入和落地口,达到链路的最优。
其次,CDN供应商会针对TCP等协议进行优化和调整,使正常的TCP三次握手减少到1次,从而减少计算机与计算机、路由之间的信息传递环节,从而达到加速目的。
虽然来的比较迟,不过题主可能使用的是七牛云存储这一类的CDN吧,和各位想象的有点区别就是了,现阶段的解决方式只能通过正则替换解决了,可以给静态资源的地址加个前缀,前缀通过配置文件定义,这样以后修改的时候就方便啦,如果要改为本地文件...
1、以Amazon的CloudFront为代表,内容发布者主动将需要发布的资源推送到CDN发布服务器上,然后由CDN服务商分发到其各节点。国内的提供商有UpYun。
2、以CloudFlare为代表,与前者不同,内容不需要主动发布,而是在浏览器向CDN请求资源时,CDN服务才主动向后端的资源服务器抓取资源。国内的提供商有WebLuker。
这两种服务,一种推送,一种拉取。后者除了在DNS设置上稍显麻烦外,其它方便性均超过前者,特别是因为内容源在自己的服务器上,可以灵活的设置url,比如动态合并js之类的功能,都可以实现了。
而前者除了多一个存储备份的功能外,内容的组织形式较为死板,必须按照静态目录的方式组织,不适合较为灵活的开发。似乎后者才是大势所趋。