网站使用CDN加速的优化建议

网站使用CDN加速的优化建议
2012-7-26
网宿科技股份有限公司
目录
1 网站硬件架构部署推荐 (3)
2 网站内容管理优化建议 (4)
2.1 动静态内容域名分离 (4)
2.2 页面静态化处理 (4)
2.3 按应用特性进行规类 (4)
2.4 网站网页结构优化建议 (5)
2.5 多子域名时采取泛域名加速 (5)
2.6 避免使用重新定向 (5)
3 HTTP Header头的配置项建议 (6)
3.1 Header头选项配置建议 (6)
3.2 特殊标头配置建议 (7)
3.2.1 长连接应用（Connection）头 (7)
3.2.2 Keep-alive头 (7)
3.2.3 Vary头 (7)
4 其余注意事项 (8)
4.1 获取最终用户IP (8)
4.2 通过X-FORWARD-FOR (9)
4.3 防火墙 (9)
1网站硬件架构部署推荐
根据经验，对于大流量、大并发量的网站系统架构来说，除了硬件上使用高性能的服务器、负载均衡、CDN等之外，在软件架构上需要重点关注下面几个环节：使用高性能的操作系统（OS）、高性能的网页服务器（Web Server）、高性能的数据库（Databse）、高效率的编程语言、高性能的存储设备等，建议进行如下图示的平台构建（以下图片仅作架构示意）：
以上图片仅作架构示意
如上图所示，通过各服务器群组之间内容调用的合理部署、任务的分配及各服务器群组应用的单一化，使得网站可以应对大流量、大并发量同时增加了可管理性、稳定性及安全性。

2网站内容管理优化建议
2.1动静态内容域名分离
静态内容相比动态文件来说，静态内容可以分发并缓存到各边缘节点上，本身需要的服务器运算量也较小；而动态内容需要与源站服务器进行运算并处理。

由于CDN的使用是以域名为单位的，动静态分离后，静态内容使用专业的静态文件平台与静态文件缓存策略，动态内容使用特有的动态应用加速平台。

这样规划后，一方面可以更加有效的进行负载均衡设置，对存储和运算量进行优化；另一方面能够使域名管理更佳灵活，并且方便对内容的管理和更新。

因此，建议将jpg,gif,png等的图片格式、js、css、swf、htm、html等静态内容使用单独域名发布，将需要源提供数据的动态内容使用另外的单独域名发布。

例如：论坛，博客、电子商务类客户，建议将其中的图片内容分离到新的加速域名下，以便在网站的访问量达到一定程度时分别使用不同的加速平台，实现成本与加速效果的最优化。

2.2页面静态化处理
鉴于3.1的建议，可以进一步考虑将部分访问频率高的、重要的内容发布为静态页面。

如果无法全部用静态网页实现，应采取静动结合的方法来解决。

静动结合，有两方面的含义：一方面是指，对于一些重要的、而且内容相对固定的网页制作为静态网页，如包含有丰富关键词的网站介绍、用户帮助、网站地图等；另一方面，可以将动态实现的网页通过一定的技术，在发布出来之后转化为静态网页，这种方式尤其适合于发布后内容无需不断更新的网页（如新闻等）。

2.3按应用特性进行规类
为了便于后续在使用CDN加速时，更有针对性的配置个性化的缓存策略，建议把更新频率相近、单个文件大小相近的内容统一采用不同的目录或域名进行规类发布；所有内容的更新（包括新增、修改等）操作建议自动生成全新的URL，避免采用同名的方式做修改，这
样可以减轻后续维护网站的工作量。

2.4网站网页结构优化建议
对于网站各页面的结构设计方面，可以参考如下几个建议将有助于网站页面打开有更好的体验，如下：
1）单个页面的数据量大小控制在2M以内为最佳，总体http请求数控制在150个以内为最佳；
2）基于IE浏览器的工作原理，单个页面建议采用3－4个子域名对内容进行交叉调用，提高IE浏览器对元素的并发调用；
3）基于IE浏览器本身限制，对于js,css的加载，必须是以串行的方式加载，即必须等前端的CSS及JS加速完成之后才加载后面的元素，所以CSS与JS的设计情况将直接影响整个页面的加载速度，因此，建议做一定优化，减少CSS及JS的数量，少使用CSS嵌套，尽量把JS放页面的后面加载。

2.5多子域名时采取泛域名加速
子域名特多且都解析到同一个IP上时，就可以采用泛域名进行解析。

1）例如：*域名需要做泛域名解析，解析到1.1.1.1，泛域名别名我们会提供一个泛域名别名接口，一般都为 ，通过此别名接口进行正常解析。

当数据进入CDN网络时，则通过我们内部DNS进行泛域名解析回源。

2）网宿科技——卓越的互联网平台提供商
3）子域名源不一致时，不能配置泛域名解析
4）有些DNS服务商不支持泛域名别名。

2.6避免使用重新定向
网站应尽量避免使用多个文件名标志同样内容的页面或文件。

因为这将增加延迟，影响用户访问体验，更重要的，它还可能给用户使用CDN服务后的内容刷新和同步工作带来一些混乱。

3HTTP Header头的配置项建议
3.1Header头选项配置建议
通过合理的配置http header选项的各项参数，可以实现有效的自主管理内容在CDN节点上缓存时间，提高缓存的命中率，提高访问效果，一般需要配置的标准http header选项如下图示：
如上图示可知，我们可以根据不同的内容及业务性质配置不同的header头参数，实现控制内容是否可以缓存，应该缓存多久。

几点建议如下：
1）缓存的设置根据不同的格式建议设定不同的值，对于静态文件如图片文件，应尽量设置较长的缓存时间，只要确保没有同名更新即可；
2）建议通过配置cache-control:max-age=*XX*，来设置文件的过期时间，CDN节点会根据max-age来决定文件的缓存时间，而不是通过expries，同时这样可以让IE也缓存住文件，在某种程度上也能提高访问速度。

同时可能减少304回源请求，提高平台的性能。

3.2特殊标头配置建议
（特殊标头使用，http 1.1协议的特殊标头配置等）
3.2.1长连接应用（Connection）头
使用CDN时建议打开连接，connection配置为connection: keep-alive。

3.2.2Keep-alive头
对于keep-alive有做连接数限制的情况，将会导致CDN节点在回源时可能会受此连接数的限制而影响回源获取数据，导致回源异常。

该值可以通过keep-alive的max值来确认，一般推荐修改到3000s以上，max值太小，容易出问题。

3.2.3Vary头
有的源服务器对于没有Accept-Encoding: gzip, deflate的请求，不返回vary头。

根据HTTP 协议，这意味着源不让代理服务器根据用户请求进行判断返回压缩/不压缩的内容。

这会导致CDN返回非压缩内容给最终用户。

为解决这个问题，需要修改源服务器配置，对于没有Accept-Encoding: gzip, deflate的请求，也要返回vary头。

4其余注意事项
（cdn_src_ip，cookie ，源服务器防火墙等设置）
4.1获取最终用户IP
1) 通过Cdn_src_ip（该方法为我司默认提供的获取IP的方法）
由于在您切换使用CDN服务后，由于您服务器实际收到请求为我司节点所发起的请求，故无法依照之前的方式获取最终用户IP地址，如果您需要获取最终用户IP，则可根据您网站编写的脚本语言自行选择下列代码。

另外，需要注意的是以下代码需要在切换后才能正式生效，如未切换则可能导致获取IP错误。

Php:
$user_IP = ($_SERVER["HTTP_CDN_SRC_IP"]);
Asp:
<% Request.ServerVariables("HTTP_Cdn-Src-Ip") %>
Java:
String srcIp = request.getHeader("Cdn-Src-Ip");
Asp(用C#):
String srcIp = Request.Headers["Cdn-Src-Ip"];
:
如您用ServerVariables来获取参数，因为ServerVariables有编码解码的过程，因此应该用应该用HTTP_Cdn_Src_Ip来获取变量，如：
result = HttpContext.Current.Request.ServerVariables["HTTP_Cdn_Src_Ip"];
4.2通过X-FORWARD-FOR
有些客户无法通过我司默认的CDN_SRC_IP获取，可以通过我司另外配置来获取，即：x-forward-for
4.3防火墙
源站有配置防火墙，针对配置了防火墙的用户需要确认防火墙上的配置规则。

主要的有：是否有IP限制、是否有单IP连接数限制。

1) 针对IP限制：因为CDN有一定的安全防护能力，可以建议考虑去除，如果坚持要保留IP访问限制可以提供我司的节点IP白名单给客户，添加到防火墙中，允许访问。

2) 针对单IP连接数限制：建议客户去除，或者设置一个较大值。

特别针对一些动态回源请求的文件，如果有单IP连接数限制，会导致回源出现503/504类似源无法提供服务的假象，其实是因为IP连接数限制导致的。