CDN常见问题-Trouble Shooting(三)

1. 304状态码

客户端第一次向服务器成功发送请求,服务器会把内容正确返回给客户端,状态码是200,并会标记内容修改时间,和一个etag标记用来核实内容是否修改过,等下次同一客户端再次发送请求,会根据请求标记的修改时间,etag来判断文件内容在这期间是否修改过,如果没有修改过则返回304状态码,客户端直接加载web缓存内容,如果文件内容修改过则把最新内容返回给客户端,并返回最新文件修改时间,etag标记。

参考如下事例,客户端第一次访问一个图片,请求成功,服务器返回200状态码,response响应包里会包含文件最近修改时间last-modified,和etag标记,

当客户端再次访问时,会在请求头带上上次读取内容的修改时间和etag标记,如下图,服务器会根据etag和last-modified判断文档内容最近有没有修改过,如若没有则返回304状态码,如若修改过则把最新内容返回客户端,状态码则是200。

所以有时候服务器日志,或者cdn日志,oss日志都会有304状态码,这个是正常的,说明web缓存已经有这些内容了,并且在这期间这些内容并没有修改过,如果想更新web缓存,可以按ctrl+F5页面,客户端会清除本地web缓存从服务器发送请求,服务器则返回请求内容,并且状态码是200。

2. 如果在使用CDN服务时,出现了回源流量大于访问流的情况

这类问题一般是由于源站没有开启Gzip压缩,但是CDN开启了Gzip压缩导致的。

对于文本等类型的内容,Gzip的压缩比较高,所以如果源站没有开启Gzip压缩,但是客户访问CDN时,CDN进行了Gzip压缩,就可能会出现CDN回源带宽比访问带宽还高的情况,所以建议在源站上开启Gzip功能。

此外,由于使用CDN时,会添加一些CDN必须使用的header信息,比如Via的header等等,有时源站已经设置了Gzip,如下图:

无标题2.png

但是当在请求中带有Via的header时,源站可能会无法正确的响应Gzip,如下图:

无标题.png

如果是这种情况,建议在源站设置一下全部开启Gzip的规则。以nginx为例,可以进行如下设置:

      gzip_proxied            any;  

其它的web服务,请参考进行类似的修改。

3.CDN访问日志统计与CNZZ的统计结果存在差异原因

CNZZ的统计方式是在每个页面放置一段JS代码,当用户访问这个页面,并且页面加载成功时,JS才会统计到。假如有的页面加载失败,或者是有的页面没有放这段JS代码的话,就无法统计。另外,假如其它网站中引用该网站中的某个文件、某些图片的话,CNZZ也是无法统计到的。而CDN的统计则会更全面,我们是基于日志中的每一个访问请求统计的。还有一点不同的是,在计算PV的时候,如果同一个页面中有多个iframe标签的话,CDN计算的是多个PV。

4.CDN的配置回源host与源站的区别

源站:  源站决定了回源时,请求到哪个IP

回源host:回源host决定回源请求访问到该IP上的哪个站点

例子1:源站是域名
源站为www.a.com 回源host为www.b.com

那么实际回源是请求到www.a.com解析到的IP,对应的主机上的站点www.b.com

例子2:源站是IP

源站为1.1.1.1 回源host为www.b.com

那么实际回源的是1.1.1.1对应的主机上的 站点www.b.com

5.CDN支持哪些调用方式

除 CONNECT 调用方式之外,其他调用方式CDN均可支持,会透传至您的源站响应。注:

  • CDN 只对 GET 请求进行缓存,对于非 GET 请求的资源建议进行域名分离
  • 仅支持POST和 PUT方式发送带有请求体(BODY)的 HTTP请求
请求方式 描述 是否支持
GET 从指定的资源请求数据 支持
POST 向指定的资源提交要被处理的数据 支持
HEAD 与 GET 相同,但只返回 HTTP 报头,不返回文档主体 支持
PUT 上传指定的 URI 支持
DELETE 删除指定资源 支持
OPTIONS 返回服务器支持的 HTTP 方法 支持
CONNECT 把请求连接转换到透明的 TCP/IP 通道 不支持

6.使用CDN加速的网站如何设置CORS访问 

网站使用CDN加速后,如果某个CDN节点下先发生了非跨域的访问,CDN会缓存一个没有CORS头部的文件内容,在过期之前发生的跨域访问,会因为没有CORS头部信息而导致访问报错。这种情况可以利用CDN的自定义Header的方式设置CORS的头部信息的方式来避免。

1、登录CDN控制台--打开“设置HTTP头”

c1.png

2、根据需要设置“Access-Control-Allow-Origin”、“Access-Control-Allow-Methods”和“Access-Control-Max-Age”的头部信息。

c3.png

3、这时访问就可以看到设置的CORS头部信息
c2.png

注意:CDN控制台上设置的CORS等头部信息对整个加速域名生效,会覆盖掉源站设置的头部信息。

7.计费流量与日志监控流量的区别

加速域名日志中记录的流量数据,是我们应用层日志统计出的流量,但是实际产生的网络流量却要比应用层统计到的流量要高出7%-15%;这个主要的原因有两个:

1、TCP/IP包头的消耗:众所周知,我们的HTTP请求是基于TCP/IP协议的,现有的互联网中,每个包的大小最大是1500个字节,而这1500个字节中,就包含了TCP和IP协议插进来的40个字节的包头,包头部分也会产生流量,但是这个加包头的动作是由内核层的协议栈完成的,无法被应用层统计到,日志里也就不会记这40个字节的流量了,这部分的流量会占到我们通过日志计算出流量的2.74%(40/1460)以上,正常情况下,会占到3%左右。

2、TCP重传:根据互联网物理网络的负载情况,正常情况下,我们所发送的包会有3-10%左右会被互联网丢弃掉,被丢弃掉之后,服务器会对丢弃的部分进行重传,重传动作是由内核层协议栈处理的,应用层也无法统计到,这部分流量占我们日志计算出流量的比例,根据网络的好坏而不等,在凌晨互联网轻载的情况下,重传率会较低;在晚高峰互联网重载的时候,重传会上升,一般情况下,在3%-7%之间。

因此在业界标准中,会在原有流量的基础上再加上7%-15%的网络消耗做为计费流量统计,我们取平均值10%做为网络消耗统计。

8.CDN基础配置中过滤参数的作用

开启过滤参数的作用是忽略URL请求中"?"之后的参数,提高CDN缓存的命中率。

开启【过滤参数】后,访问URL无需匹配"?"之后的参数,元素就可命中CDN的缓存,提高CDN的命中率。例如:

第一次访问http://www.****.com/1.jpg,CDN没有缓存,直接回源访问数据。

第二次访问http://www.****.com/1.jpg?test1,由于开启了过滤参数"?",所以"?"后面的参数无需匹配,即可命中CDN缓存http://www.****.com/1.jpg

后续访问,不论"?"后面带的是什么参数,均命中缓存http://www.****.com/1.jpg

关闭【过滤参数】后,访问URL需精确匹配"?"之后的参数,提高请求的精确性。例如:

第一次访问http://www.****.com/1.jpg,CDN没有缓存,直接回源访问数据。

第二次访问http://www.****.com/1.jpg?test1,由于关闭了过滤参数"?",所以"?"后面的参数需精确匹配,即无法响应CDN缓存内容http://www.****.com/1.jpg,需要重新回源拉取http://www.****.com/1.jpg?test1

后续访问,"?"后面的参数要与CDN缓存精确匹配才能响应CDN缓存内容。只有精确匹配"?"后面的参数,才能响应CDN缓存内容。

9.CDN加速后页面出现空白页面

  1. 访问源站,查看Content-Length是否为0,如下图所示。

  2. 如果Content-Length为0,请求源站看源站是否返回Transfer-Encoding: chunked这个头信息。CDN对于这个头信息是不支持的,去除这个头信息即可。

 10.CDN缓存

1)CDN 读取数据过程为:用户访问您的源,先去查找CDN的1级节点,再查找CDN2级节点,2级节点没有,再查找源,源中的数据同步到2级节点,2级节点同步到1级节点,再从1级节点返回用户要访问的数据。

2) CDN 刷新缓存。

3) CDN 缓存的配置。

4)为了 CDN 使用的最优,建议您将动静态页面进行域名分离,静态页面的域名使用 CDN 的加速。

5)源站 cachecontrol,expires,lastmodify,etag都没设置,CDN 也没设置缓存规则,是不会被缓存的。

6) 源站设置了 no-cache 、private、 max-age = 0 都遵循源站,CDN 是不会进行缓存的。

CDN缓存命中率排查:

源站上缓存header设置不当,或者缺少必要的header,则根据CDN的缓存规则是不缓存的,那么自然每次访问都会MISS,影响命中率。

  • 缓存header设置不当主要是cache-control或者pragma的影响,即源站上设置了cache-control:no-cache/no-store/max-age=0/private或者Pragma:no-cache等均会被CDN当做最高优先级执行不缓存。

  • 缺少必要的header,则是指源站的response头中不包含etaglast-modified也会导致不缓存,具体哪几种情况会导致不缓存。

  • 控制台设置了不缓存的规则(比如某目录或者某种后缀的文件设置缓存时间为0秒),查询方法可以在CDN控制台查看。

  • 源站动态内容居多,目前CDN主要是加速静态资源(css、js、html、图片、txt、视频等),针对动态资源(php、jsp、包含内部逻辑处理甚至cookie等)基本都是回源。

  • CDN的访问URL中带有可变参数(举例:http://dccdn.pier39.cn/1.txt?timestamp=14378923](http://dccdn.pier39.cn/1.txt?timestamp=14378923,其中timestamp表示时间戳,每次访问均会不同)。这里CDN针对第一次访问的URL(之前未预热),无论该URL是否符合CDN的缓存规则,第一次访问肯定都是MISS的(因为节点上还没有这个文件),因为后面的参数可变,所以每次访问都是一个全新的URL,则每次都会MISS,从而影响命中率。

  • 刷新操作频繁,有定时刷新的操作,每次刷新都会导致所有已经在CDN上缓存的URL失效,那么下次访问同样的URL,自然就会MISS,从而影响命中率。

  • 文件热度不够,不经常被客户访问到,导致虽然符合上面的所有规则,但是经常有被节点下掉缓存。CDN节点上缓存的文件,可以理解为按照热度属性采取末尾淘汰制,所谓热度就是该文件在该节点上被访问的频率,文件热度不够,其实一定程度上跟这个域名本身的流量不高有关联关系。

11.如何通过浏览器审查元素判断CDN缓存是否成功?

  1. 打开浏览器(这里以Google Chrome浏览器为例),选择 工具 > 开发者工具,在地址栏输入要查看的URL。
  2. 单击Network,然后单击访问的图片(要加速的内容),您可以查看到详细的请求(request)和返回(response)的报文信息。如下图:

你需要注意以下三个字段:

  • X-Swift-SaveTime:内容开始在CDN上缓存的时间。如上图,即2015-09-22 06:33:49开始在CDN缓存。由于系统时间是GMT时间,所以需要折算成北京时间,也就是2015-09-22 14:33:49开始缓存。

  • X-Swift-CacheTime 是CDN的默认缓存时间,以秒为单位。图中的86400,即缓存24小时。

  • Age:该内容在CDN上已经缓存了的时间。图中的163s即该内容已经在CDN缓存了163秒。根据时间,从2015-09-22 14:33:49开始缓存的,当前时间则为2015-09-22 14:36:32。您可以和电脑当前时间进行对比。

12.CDN缓存命中率低案例分析 

客户用了CDN之后CDN的缓存命中率很低,通过chrom的元素审查(F12)查看每个url都是不缓存的:

但是单独摘出来每个文件的url检查发现都是缓存的X-Cache:HIT

分析过后发现不缓存的原因是:

比如这个url:http://xxxxxx.com/movie/XSHD/res/ccb/ArrowScene.ccbi?_t=1454393966147

对应的文件是ArrowScene.ccbi

这个文件在您的站点每一次打开的时候?_t=xxxxxx

这个字符串总是会改变,所以造成CDN根本不缓存。所以建议看看的业务打开CDN控制面板的 过滤参数 ,开启过滤参数之后,?后的参数将被忽略,参数不同也被视为访问同一个文件进行缓存。

猜你喜欢

转载自blog.csdn.net/Kim_Weir/article/details/85272698