【深圳电信dns】UCloud:cdn内容分发网络常见问题场景白皮书（一）

前言

Cdn内容分发网络已成为云计算服务的基本产品。和云主机数据库一样，它正在成为云客户必备的“三大部件”。由于cdn产品的使用过程涉及用户源站、存储体系结构、运营商线路质量、cdn服务商节点质量、用户配置等多种因素，因此在使用过程中会出现各种未知问题。

问题类型1 用户反馈可用性低问题

场景1 运营商问题网络丢包严重导致可用性降低

是因为运营商问题，机房网络丢包严重，并且有监控，已经第一时间自动报障运营商了，但运营商处理速度略慢一些，这种属于个案。

并且造成的影响并不是真的可用性降低，七牛的可用性是设置了超时时间，当超过他们设置的阈值的时候就算不可用。

场景2 是否为长宽教育等小运营商

目前小运营商还存在带宽资源不足，区域覆盖不全的问题，因此存在部分小运营商接入客户使用cdn过程中反馈比较卡顿，播放视频不流畅等问题，反馈到基调上来就是可用性比较低。

解决方法

1.短期内小客户可以做下话术方面的解释。大客户可以联系后台开启下超级中间源做下优化。

2.长期内TEG正在加紧小运营商资源方面的建设，相信该问题可以逐步追齐友商。

场景3 用户反馈区域存在dns劫持问题；

cdn的劫持问题是一类比较常见的问题，下面我会专门整理文档进行讲解。这里先埋一个伏笔！

场景4 用户反馈区域节点存在ddos攻击导致短期不可用拉低了整体的可用性；

针对ddos对cdn平台的攻击，已经规划如下方案提高防御能力

1.提高服务器的抗ddos能力，强化自身。比如升级为抗ddos内核；

2.优化ddos域名识别方案，提高识别精准度；

3.陆续将“小水管式”cdn oc机房迁移到自建云机房中，增强抗ddos能力；

4.扩容cdn节点集群规模，增加cdn平台容量，提高抗攻击能力；

5.增加单机的虚拟jip，提高识别的精准度；

场景5 源站回源质量不好，导致全面的回源失败比较高，影响了可用性

一般这种可能性会从cdn告警中体现出来，同时表现不应该是区域性质的可用性低，应该表现为短期内全国性质的可用性不佳。

场景6 其他客户切入导致中间源的负载被拉高，使得边缘节点到中间源的回源时延增高，导致可用性降低

（其实并不是真正的可用性降低，只是因为超过了规定的时延，导致了系统认为短期不可用）

场景7节点所在部分节点机房流量受限导致任务超时触发的

场景8 其他未知问题，需要查看听云基调数据后建单给运维排查

问题类型2 CDN劫持问题类

场景1 解析到非预期节点信息

用户反馈过来的dns解析到的ip地址确认非腾讯cdn业务ip，基本可以确认为dns劫持问题；

221.182.134.172

图16 检验解析到的ip非cdn节点ip

图17 基调获取到监测ip信息

场景2 302跳转–典型的跳转劫持

用户反馈的url中做了302跳转，并且curl模拟可以看到location字样，获取到跳转到的url，如果url非用户业务url而是不想干的url，基本可以确认也是劫持问题；

场景3 解析到较远区域

用户反馈的ip,ldns和解析到的节点ip非相同或者相近区域，比如用户出口ip和ldns为北京电信，但是解析到的节点ip虽然是腾讯cdn的节点ip，但是为深圳电信。这种算是dns缓存问题，也是劫持问题的一种。需要联系运营商来清除缓存处理。

场景4 解析正常但是应用无法使用

无法正常加载资源，CDN节点可PING通，80端口可通，资源无法正常加载，用户网页打开有乱码或者经常打不开，虽然解析到了正确的cdn节点ip，但是在进行抓包过程中可以看到有强制插入问题。基本可以确认为应用劫持问题。

基调显示为与服务器链接超时

图19 基调显示为与服务器链接超时

抓包分析

图20 抓包显示节点ip和中间源交互被重置reset

用户所在的cdn节点回源集群节点会被新疆电信强制插入reset导致断链

图21 同图20

场景5 用户ldns解析跨运营商

用户ldns为电信，但是解析结果为移动或者联通等非电信运营商去，一般为运营商dns配置有误，也属于dns劫持的一种，需要联系运营商刷新缓存。

图22 解析到节点跨运营商

参考案例

-------未完待续-------