干云服务这些年，服务过各类大客户，也遇到过各类问题，今天就简单总结记录一些，希望对大家有一定帮助。由于知识面有限，有些地方难免不周，也欢迎大家指正！
CDN一般会遇到哪些问题场景？
问题类型一：用户反馈可用性低问题
- 原因场景1 运营商问题网络丢包严重导致可用性降低
因为运营商问题，机房网络丢包严重，一般云厂商都会有相关监控，这类问题一般第一时间会联系报障运营商处理，但运营商处理速度略慢一些。这种情况属于个案，并且造成的影响并不是真的可用性降低，比如七牛云CDN的可用性是设置了超时时间，当超过他们设置的阈值的时候就算不可用。当然CDN节点之间也会有相互的PING和反向PING探测，会将异常节点的机房自动剔除掉。
- 原因场景2 是否为长宽教育等小运营商
目前小运营商还存在带宽资源不足，区域覆盖不全的问题，因此存在部分小运营商接入客户使用cdn过程中反馈比较卡顿，播放视频不流畅等问题，反馈就是可用性比较低。目前小运营商用的人比较少，云产商建设的机房也相对比较少，一般都是异地覆盖。常见问题中带宽资源问题不会很明显，比较常见问题是用户侧用的是别家运营商的DNS，导致解析到跨网节点，出现跨网访问导致问题。
- 原因场景3 用户反馈区域存在dns劫持问题
一般建议客户端使用对于CDN云厂商提供得DNS，比如腾讯云119.29.29.29 DNS；也可以使用常见得114.114.114.114等。如果是地区多数用户普遍问题，这类一般得报障运营商处理，有可能是运营商本身做了DNS劫持。
- 原因场景4 用户反馈区域节点存在ddos攻击导致短期不可用拉低了整体的可用性；
1.提高服务器的抗ddos能力，强化自身。比如升级为抗ddos内核；
2.优化ddos域名识别方案，提高识别精准度；
3.陆续将“小水管式”cdn oc机房迁移到自建云机房中，增强抗ddos能力；
4.扩容cdn节点集群规模，增加cdn平台容量，提高抗攻击能力；
- 原因场景5 源站回源质量不好，导致全面的回源失败比较高，影响了可用性
一般这种可能性会从cdn告警中体现出来，同时表现不应该是区域性质的可用性低，应该表现为短期内全国性质的可用性不佳。
回源质量不好，得确认下源站是什么运营商，是否跨运营商回源了，一般云产商默认的是中间源回源，用户什么运营商请求就会什么运营商去回源，解决办法是上三级源，比如腾讯云，中间源到三级源走的一般是内网，网络质量会好很多。
问题类型二：CDN劫持问题类
- 原因场景1 解析到非预期节点信息
如果发现dns解析到的ip地址确认非cdn提供商的业务ip，基本可以确认为dns劫持问题；这里需要注意下，有些客户是使用了多家CDN，可以看该地区的解析是否正确解析到对于CDN提供商提供的CNAME域名上。
- 原因场景2 302跳转-典型的跳转劫持
用户反馈的url中做了302跳转，并且curl模拟可以看到location字样，获取到跳转到的url，如果url非用户业务url而是不相干的url，基本可以确认也是劫持问题；一般可以测试看看location里面的IP，查下下是哪个地区的IP，可以判断劫持发生在哪里。要选择跟用户同一地区和运营商的机器来测试，异地测试没有意义。
302跳转- 原因场景3 解析到较远区域
用户反馈的ip,ldns和解析到的节点ip非相同或者相近区域，比如用户出口ip和ldns为北京电信，但是解析到的节点ip虽然是腾讯cdn的节点ip，但是为深圳电信。这种算是dns缓存问题，也是劫持问题的一种。需要联系运营商来清除缓存处理。
这个跟节点慢问题类似，可先确认用户当前解析的节点是不是当前的覆盖节点，如果当前覆盖是本地或者邻省，而用户却解析到较远节点，常见的是用户DNS配置错了。
- 原因场景4 解析正常但是应用无法使用
无法正常加载资源，CDN节点可PING通，80端口可通，资源无法正常加载，用户网页打开有乱码或者经常打不开，虽然解析到了正确的cdn节点ip，但是在进行抓包过程中可以看到有强制插入问题。基本可以确认为应用劫持问题。
回源过程中被强插reset，见下图：
被强插reset抓包显示节点ip和中间源交互被重置reset，用户所在的cdn节点回源集群节点会被新疆电信强制插入reset导致断链；
这个得先确认异常发生在哪一段链路上，如果是边缘OC节点回源到中间源上，那么回源失败监控能体现出这问题。
- 原因场景5 用户ldns解析跨运营商
用户ldns为电信，但是解析结果为移动或者联通等非电信运营商去，一般为运营商dns配置有误，也属于dns劫持的一种，需要联系运营商刷新缓存。
DNS劫持问题进行以下判断：
- 用户配置的dns是否正确（是否是该地区运营商的DNS）
- 客户该地区配置的解析是否正确（DIG工具判断）
- CDN当地覆盖节点配置有无问题（查询节点覆盖）
问题类型三 CDN访问反馈403问题类
403是没权限访问，该问题，得先确认下403是谁吐的，是CDN节点吐得，还是回源到源站吐的。
如果是CDN节点吐的，那么查看下当前CDN的配置，看是什么配置导致吐了403（referer,时间戳防盗链，IP黑白名单，特殊配置）如果是源站吐的，可直接测试下源站，如果确认源站吐403，直接分析源站逻辑即可。
问题类型四 反馈访问慢问题
场景1 url访问慢；
场景2 整站访问慢；
场景3 个别客户反馈访问慢；
是否命中节点，节点是否和客户端靠近并且在同一个运营商下面。比如广东深圳电信用户请求，访问的节点是否是广东深圳电信的或者广东电信的（有些云厂商不一定每个地方都有节点）
问题类型五 访问cdn出现404问题
- 原因场景1 源站资源不存在导致节点缓存404；
有可能存在多个源站，其中有源站资源不存在导致404，解决办法后台手工刷新清理缓存。
404默认缓存10s，刷新并不能解决，分析回源和访问404监控即可，看是哪里吐了404。
- 原因场景2 用户源站硬件性能达到极限，比如硬盘存储空间已满导致回源失败反馈404；
- 原因场景3 cdn节点配置不同步导致；
CDN后台存在变更，比如节点的扩容，配置系统存在误差，接入平台变更导致配置未在全网同步。
- 原因场景4 因为用户软件兼容性问题导致；
- 原因场景5 源站头部可以正常的返回但是body太大或者代码设计有问题导致长时间下载不下来超时引起404；
- 问题类型六 接入cdn后完全/部分无法打开
首要了解信息包括：
1.用户影响的范围：是某条url无法访问，还是整个网站无法访问，还是网站区域性质的无法访问，区域性质无法访问的话运营商是否有关联性。
2.需要收集的信息：用户ip，LDNS，解析到的节点ip，一般国内可以使用huatuo.qq.com这个工具来收集相关信息。
收集客户信息确认单URL，还是所有URL都不行，是单地区还是全部地区，偶现还是必现。分析是用户到边缘OC节点问题，还是CDN中间链路问题，还是回源到源站之间问题，然后逐步分析解决。
- 原因场景1 用户的源站存在安全策略或者对节点匹配到安全策略；
- 原因场景2 用户公司路由器dns设置问题：整个公司都存在打不开的问题时候适用；
- 原因场景3 用户解析到的cdn节点遭受到攻击被下线处理；
- 原因场景4 回源过程因为跨运营商出现问题；
- 原因场景5 源站配置参数设置有问题导致
- 原因场景6 云产商GSLB调度出现问题导致dns无法正常解析分配节点ip
- 原因场景7 源站不支持分片导致数据传输失败，引发节点无法打开；
（解决办法：源站调整为支持分片；关闭cdn的回源默认分片功能）
- 原因场景8 源站开启了长链接但是没有声明文件的大小长度，导致无法正常打开；
CDN对源站的HTTP协议有较严格的校验
A. 严格校验 content-length声明长度和实际吐出长度的匹配。如果不匹配连接会被直接RST。
B. 回源默认支持长连接，如果源站声明Connection:keep-alive， 需要同时带上Content-Length字段来表明body长度，否则会导致连接回源超时。
知识点：
长连接：HTTP1.1中设计增加了持久连接的支持，也就是头信息加入了这行代码Connection:keep-alive 来声明自己的会话是支持长链接的。在长链接中，TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接好处多多，主要有以下的几点：
优点1 更少的建立和关闭tcp连接，可以减少网络流量。
优点2 因为已建立的tcp握手，减少后续请求的延时。
优点3 长时间的连接让tcp有充足的时间判断网络的拥塞情况，方便做出下步操作
content-length：在HTTP协议中，Content-Length字段用于描述HTTP消息实体的传输长度。在HTTP协议中，消息实体长度和消息实体的传输长度是有区别，比如说gzip压缩下，消息实体长度是压缩前的长度，消息实体的传输长度是gzip压缩后的长度。
在具体的HTTP交互中，客户端基于下面的几个规则来获取消息长度：
1.响应为1xx，204，304或者head请求，则直接忽视掉消息实体内容。
2.如果有Transfer-Encoding，则优先采用Transfer-Encoding里面的方法来找到对应的长度。比如说Chunked模式，在header中就不能有Content-Length，有也会被忽视。
3.“如果head中有Content-Length，那么这个Content-Length既表示实体长度，又表示传输长度。如果实体长度和传输长度不相等（比如说设置了Transfer-Encoding），那么则不能设置Content-Length。如果设置了Transfer-Encoding，那么Content-Length将被忽视”。一言以蔽之，有了Transfer-Encoding，则不能有Content-Length。
4.Range传输
5.Content-Length如果存在并且有效的话，则必须和消息内容的传输长度完全一致。（经过测试，如果过短则会截断，过长则会导致超时。）
6.如果采用短连接（http1.1之前的版本），则直接可以通过服务器关闭连接来确定消息的传输长度，且在Http 1.0及之前版本中，content-length字段可有可无。
7.在http1.1及之后版本如果是keep alive，则content-length和chunk必然是二选一。若是非keep alive，则和http1.0一样。content-length可有可无。
长链接声明文件的大小长度
长链接但是没有声明文件的大小长度- 原因场景9 边缘oc节点回源时候不稳定导致回源超时引发偶然的页面打不开问题；
解决办法：开启中间源/超级中间源
问题类型七 回源率高/命中率低
大概几个原因
- 原因场景1 是否有开启中间源；
- 原因场景2 均开启了全路径缓存，文件做精确匹配缓存；
- 原因场景3 跟用户业务类型有很大关系
比如对业务呈现区域本地化特征的网站，资源只有在本地才被访问到，造成文件过冷，命中率低；
- 原因场景4 部分节点中间源容量不足，有淘汰机制，非热点文件会被淘汰掉
- 原因场景5 在cdn中缓存策略不恰当，缓存时间太短导致文件过期频繁回源拉取；
- 原因场景6 用户业务请求突增，因为节点上没有缓存导致大量回源请求引起回源率高；
- 原因场景7 用户网站文件类型中动态文件占比比较多，cdn对动态文件是直接回源的，造成回源率比较高。
这种场景下建议用户对自己的业务做下动静分离，尽量对静态资源做cdn加速，提高命中率，减少回源。
- 原因场景8 文件频繁回源拉取，相当于源站和oc节点之间没有缓冲；
这种场景下也可能会造成回源率比较高，建议用户开启一下中间源特性优化该处。
- 原因场景9 cdn为共享存储模式，因为其他用户存在大量的更新操作导致其他用户缓存文件被挤压删除，导致回源增加。
这种可能性比较小，但是也存在。
- 原因场景10 存在源站不同云产商情况，比如使用腾讯云CDN，使用了阿里云源站，阿里云对腾讯云回源节点ip做安全拦截导致回源率高
问题类型八 cdn涉黄涉政涉赌违规类
最近涉黄问题，运营商抓的比较严，如果确认涉黄，建议直接封禁处理。
问题类型九 https证书问题类
- 原因场景1 https证书更新部署后部分节点未生效
- 原因场景2 https证书功能失效
当场验证确认用户证书还在有效期内，且部署正确
- 原因场景3 https上传证书时候报“私钥链校验不正确”
根本原因在于云产商cdn采用验证的证书链完整性校验，用户提供的证书到根证书如果缺少可信证书链，而云产商又没有的话，会被系统认为证书不完整导致上传校验失败。
解决办法
1.建单联系技术人员后台更新证书链；
2.提交完整的证书链证书，规避此问题；
问题类型十 刷新不生效问题类
- 场景1 目录刷新，其中url不生效
目录刷新的时候，默认并不删除目录下的所有文件，只是在删除目录后，给目录下的所有文件按打tag标记，在有客户端来访问到文件时候，通过对比节点和源站上的mtime值（last-modified）来比较是否需要去源站回源拉取文件。
这样的设计目的是为了节省带宽，同时避免在刷新目录后大量回源导致的源站带宽耗费陡增，很容易把源站打趴下。不过对于一些特殊场景，比如：
1.用户源站的图片通过云存储厂商做了图片资源的修改，但是云存储厂家设置图片的属性都完全继承源图，这样就会造成cdn节点对比mtime发现自身缓存节点的mtime和源站的一致或者更新，从而不去回源拉取。表象就是刷新目录后访问文件并没有更新成功；
2.用户源站为集群或者为部署在不同区域不同城市的架构。这个时候由于源站不同步问题，也可能存在同一个文件在不同源站ip上mtime不一致导致部分回源不生效问题。
3.用户强制要求不判断mtime，强制回源
解决方案：对用户所在域名配配置下max_cache_sync on 就可以,相当于忽略 了304（回源的时候if-modified-since字段清零。）
风险点：从上面原来可以看到，取消mtime校验，回原流量会上升，配置前需要确认用户源站可以扛得住。
- 场景2 用户刷新url已经达到云产商上限
- 场景3 部分边缘节点因为请求过高或者遭受到攻击导致请求响应不过来刷新失败
- 场景4 用户源站采用rsync或者跨区域复制方案或者其他原因导致源站相同配置不同步，最终影响到cdn中刷新不生效，表现为出现多个软件版本问题。
CDN的故障现象多种多样，不可能每一种都能覆盖到，也欢迎大家评论补充！
参考：
腾讯云DNS服务地址：
https://www.dnspod.cn/Products/Public.DNS/
百度公共DNS服务地址：
https://dudns.baidu.com/intro/publicdns/
阿里DNS服务地址：
https://www.alidns.com/
