抽丝剥茧定位一个CDN访问慢的案例

问题描述

某客户反馈使用CDN以后下载时间很慢,TTFB很长,需要定位原因。

抽丝剥茧定位一个CDN访问慢的案例

抽丝剥茧定位一个CDN访问慢的案例

排查过程

1. 分析CDN日志

根据Network下的信息后台查到CDN的日志信息,发现访问慢是因为中间有过504重试,具体过程如下

(1)客户端请求到L1(cn2620),L1回源到cache18.l2cn2635以后,cache18.l2cn2635回源504,RT时间是5182ms
(2)cache18.l2cn2635响应504以后,触发L1重试到cache12.l2cn2641,回源成功,RT时间是137ms
所以虽然最终现象看起来是访问成功了,只是速度比较慢,实际的过程中是因为有504并发生了重试,耗时主要是第一次回源504的耗时。同时查看但是客户端提供的Network下的响应头也可以进一步确认此问题,当时虽然响应了httpcode 200,但是响应头里响应了x-swift-error:orig response 5xx error

抽丝剥茧定位一个CDN访问慢的案例

2. 错误日志分析

日志服务SLS查看L2的错误日志分析,504错误基本就是聚焦在l2cn2635节点,且rt时间是5s左右。

抽丝剥茧定位一个CDN访问慢的案例

3. 听云探测

根据前面的分析,其他L2节点到源站首字节都正常,日志也正常,唯独这个L2节点到源站会504,而且首字节时间是5k ms,因此怀疑是源站做了相关安全策略,或者该节点到源站的网络问题。但是用户的源站是阿里云的SLB,且用户反馈SLB层面并没有做安全策略。由于该L2是唐山的一个L2节点,因此想到用听云到唐山地区用三大运营商探测下源站,发现也一切正常。

抽丝剥茧定位一个CDN访问慢的案例

4. 为什么会504?

CDN回源源站的时候产生了504,但是客户源站SLB的日志并没有查到504的日志,看起来这个504日志不是源站响应的,那么就有可能CDN回源超时导致的。但是根据rt时间看5s就504了,看起来并没有达到默认CDN约定的回源超时时间,默认CDN回源的超时时间是:建联超时10s (也就是说tcp连接10s超时),读客户端请求头超时时间:30s (也就是说应用层30s超时)。至此,一共有如下几个疑问需要确认:(1)看起来rt时间5s并没有达到超时时间,看起来不是超时导致,那么有可能是源站直接响应504。

(2)回源504日志显示的错误码是"0",也就是CDN认为是正常请求,并不认为是连接不上或超时断开这种情况,这也进一步印证了源站直接响应504的情况。

(3)但是现在的问题是源站查不到504日志,那么有没有可能是客户反馈的源站日志排查的结果不可靠?

抽丝剥茧定位一个CDN访问慢的案例

5. 源站抓包

为了验证到底是不是源站吐的504,因此考虑让用户在源站侧抓包,然后客户端去访问复现,出现问题以后提供chrome的har文件和源站的抓包文件。根据日志分析,第一次是cache18.l2cn2635回源504,回源的IP是101.x.xx.xx;然后L1重试到cache12.l2cn2641回源成功,回源的IP是115.xx.xx.xx。从源站的抓包文件看,可以看到来自115.xx.xx.xx的报文,但是过滤不到来自101.xx.xx.xx的报文,看起来就是101.xx.xx.xx的请求没有到源站。

抽丝剥茧定位一个CDN访问慢的案例

6. CDN抓包

目前情况看起来有点复杂了,源站SLB上没有抓到来自CDN回源IP的报文,且源站日志没有记录该504请求的CDN回源IP的日志,看现象就是CDN回源源站的回源链路有问题。为了进一步验证这个问题,只能到发生504的cache18.l2cn2635这台机器上去抓包。从抓包结果来看,的确是源站直接响应了504,而且看响应504的报文里,TTL和SYN握手报文的TTL一致,看起来也不是被劫持导致,也不像是网络问题。而且只有两台CDN机器回源有504问题,其他机器回源一切正常。

抽丝剥茧定位一个CDN访问慢的案例

7. 源站配置检查

各种证据表明,越来越像是源站有安全策略拦截了,但是源站是SLB,看SLB的一些访问控制的策略,比如IP黑白名单,即使拦截了应该也能查到403的日志,而不会是504。检查配置发现SLB开启了"透明WAF"功能。进一步了解该功能原理,SLB开启透明WAF功能以后不需要更改DNS解析,请求SLB的流量都先走TWAF(透明WAF),TWAF在CDN和SLB之间充当了一个透明代理。TWAF和client建连时借用了SLB的IP,TWAF和SLB建连时借用了client的IP。那么根据这个现象看,极有可能是CDN的请求被TWAF拦截了(在下图中,CDN的回源IP就是client)。

抽丝剥茧定位一个CDN访问慢的案例

8. TWAF拦截记录

去查了TWAF的拦截记录,发现果然有拦截记录,CDN的tproxy IP(回源IP)被WAF识别成攻击IP,被用户的访问控制策略加入到了WAF的黑名单里。致此,终于可以结案!


抽丝剥茧定位一个CDN访问慢的案例

问题原因

由于业务请求走了CDN,CDN又通过汇聚式的L2节点回源,而源站配置了透明WAF,WAF配置的安全规则认为这些频繁回源的CDN节点IP是攻击IP,被访问控制策略加入到黑名单,而TWAF通过响应504的形式拒绝了来自CDN的回源请求。根据上面的TWAF实现原理图可以知道,这个504的请求对于SLB来说完全是没有感知的,所以SLB上肯定没有日志,需要查WAF的拦截日志才能发现。

解决方案

从黑名单里移除该CDN的回源IP即可。但是由于目前配置的策略,很有可能还会继续把CDN的回源IP当成攻击IP处理,因此需要调整WAF拦截策略,或者把CDN的回源IP加入到白名单。但是这也有风险,因为CDN回源时会智能分配节点访问源站,回源的节点IP是不固定的,因此不建议将源站的回源策略白名单设置为固定的节点IP列表,这样有可能因为CDN回源IP变更,新增IP由于未在白名单导致被拦截继而发生回源失败的情况。

如果有强诉求,也可以通过调用CDN的DescribeL2VipsByDomain接口获取CDN回源的节点IP列表并添加到源站服务器的白名单中。该接口仅支持日峰值带宽为1Gbps以上的用户调用,如果符合该条件,可以提交工单,申请该接口的调用权限。

适用于

  • CDN
  • 全站加速
上一篇:OSS线上业务突发回调失败


下一篇:多线程常用方法详解及案例分析