干云服务这些年,服务过各类大客户,也遇到过各类问题,今天就简单总结记录一些,希望对大家有一定帮助。由于知识面有限,有些地方难免不周,也欢迎大家指正!
因为运营商问题,机房网络丢包严重,一般云厂商都会有相关监控,这类问题一般第一时间会联系报障运营商处理,但运营商处理速度略慢一些。这种情况属于个案,并且造成的影响并不是真的可用性降低,比如七牛云CDN的可用性是设置了超时时间,当超过他们设置的阈值的时候就算不可用。当然CDN节点之间也会有相互的PING和反向PING探测,会将异常节点的机房自动剔除掉。
目前小运营商还存在带宽资源不足,区域覆盖不全的问题,因此存在部分小运营商接入客户使用cdn过程中反馈比较卡顿,播放视频不流畅等问题,反馈就是可用性比较低。目前小运营商用的人比较少,云产商建设的机房也相对比较少,一般都是异地覆盖。常见问题中带宽资源问题不会很明显,比较常见问题是用户侧用的是别家运营商的DNS,导致解析到跨网节点,出现跨网访问导致问题。
一般建议客户端使用对于CDN云厂商提供得DNS,比如腾讯云119.29.29.29 DNS;也可以使用常见得114.114.114.114等。如果是地区多数用户普遍问题,这类一般得报障运营商处理,有可能是运营商本身做了DNS劫持。
1.提高服务器的抗ddos能力,强化自身。比如升级为抗ddos内核;
2.优化ddos域名识别方案,提高识别精准度;
3.陆续将“小水管式”cdn oc机房迁移到自建云机房中,增强抗ddos能力;
4.扩容cdn节点集群规模,增加cdn平台容量,提高抗攻击能力;
一般这种可能性会从cdn告警中体现出来,同时表现不应该是区域性质的可用性低,应该表现为短期内全国性质的可用性不佳。
回源质量不好,得确认下源站是什么运营商,是否跨运营商回源了,一般云产商默认的是中间源回源,用户什么运营商请求就会什么运营商去回源,解决办法是上三级源,比如腾讯云,中间源到三级源走的一般是内网,网络质量会好很多。
如果发现dns解析到的ip地址确认非cdn提供商的业务ip,基本可以确认为dns劫持问题;这里需要注意下,有些客户是使用了多家CDN,可以看该地区的解析是否正确解析到对于CDN提供商提供的CNAME域名上。
用户反馈的url中做了302跳转,并且curl模拟可以看到location字样,获取到跳转到的url,如果url非用户业务url而是不相干的url,基本可以确认也是劫持问题;一般可以测试看看location里面的IP,查下下是哪个地区的IP,可以判断劫持发生在哪里。要选择跟用户同一地区和运营商的机器来测试,异地测试没有意义。
用户反馈的ip,ldns和解析到的节点ip非相同或者相近区域,比如用户出口ip和ldns为北京电信,但是解析到的节点ip虽然是腾讯cdn的节点ip,但是为深圳电信。这种算是dns缓存问题,也是劫持问题的一种。需要联系运营商来清除缓存处理。
这个跟节点慢问题类似,可先确认用户当前解析的节点是不是当前的覆盖节点,如果当前覆盖是本地或者邻省,而用户却解析到较远节点,常见的是用户DNS配置错了。
无法正常加载资源,CDN节点可PING通,80端口可通,资源无法正常加载,用户网页打开有乱码或者经常打不开,虽然解析到了正确的cdn节点ip,但是在进行抓包过程中可以看到有强制插入问题。基本可以确认为应用劫持问题。
回源过程中被强插reset,见下图:
抓包显示节点ip和中间源交互被重置reset,用户所在的cdn节点回源集群节点会被新疆电信强制插入reset导致断链;
这个得先确认异常发生在哪一段链路上,如果是边缘OC节点回源到中间源上,那么回源失败监控能体现出这问题。
用户ldns为电信,但是解析结果为移动或者联通等非电信运营商去,一般为运营商dns配置有误,也属于dns劫持的一种,需要联系运营商刷新缓存。
DNS劫持问题进行以下判断:
403是没权限访问,该问题,得先确认下403是谁吐的,是CDN节点吐得,还是回源到源站吐的。
如果是CDN节点吐的,那么查看下当前CDN的配置,看是什么配置导致吐了403(referer,时间戳防盗链,IP黑白名单,特殊配置)如果是源站吐的,可直接测试下源站,如果确认源站吐403,直接分析源站逻辑即可。
场景1 url访问慢;
场景2 整站访问慢;
场景3 个别客户反馈访问慢;
是否命中节点,节点是否和客户端靠近并且在同一个运营商下面。比如广东深圳电信用户请求,访问的节点是否是广东深圳电信的或者广东电信的(有些云厂商不一定每个地方都有节点)
有可能存在多个源站,其中有源站资源不存在导致404,解决办法后台手工刷新清理缓存。
404默认缓存10s,刷新并不能解决,分析回源和访问404监控即可,看是哪里吐了404。
CDN后台存在变更,比如节点的扩容,配置系统存在误差,接入平台变更导致配置未在全网同步。
首要了解信息包括:
1.用户影响的范围:是某条url无法访问,还是整个网站无法访问,还是网站区域性质的无法访问,区域性质无法访问的话运营商是否有关联性。
2.需要收集的信息:用户ip,LDNS,解析到的节点ip,一般国内可以使用huatuo.qq.com这个工具来收集相关信息。
确认单URL,还是所有URL都不行,是单地区还是全部地区,偶现还是必现。分析是用户到边缘OC节点问题,还是CDN中间链路问题,还是回源到源站之间问题,然后逐步分析解决。
(解决办法:源站调整为支持分片;关闭cdn的回源默认分片功能)
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可有可无。
解决办法:开启中间源/超级中间源
大概几个原因
比如对业务呈现区域本地化特征的网站,资源只有在本地才被访问到,造成文件过冷,命中率低;
这种场景下建议用户对自己的业务做下动静分离,尽量对静态资源做cdn加速,提高命中率,减少回源。
这种场景下也可能会造成回源率比较高,建议用户开启一下中间源特性优化该处。
这种可能性比较小,但是也存在。
最近涉黄问题,运营商抓的比较严,如果确认涉黄,建议直接封禁处理。
当场验证确认用户证书还在有效期内,且部署正确
根本原因在于云产商cdn采用验证的证书链完整性校验,用户提供的证书到根证书如果缺少可信证书链,而云产商又没有的话,会被系统认为证书不完整导致上传校验失败。
解决办法
1.建单联系技术人员后台更新证书链;
2.提交完整的证书链证书,规避此问题;
目录刷新的时候,默认并不删除目录下的所有文件,只是在删除目录后,给目录下的所有文件按打tag标记,在有客户端来访问到文件时候,通过对比节点和源站上的mtime值(last-modified)来比较是否需要去源站回源拉取文件。
这样的设计目的是为了节省带宽,同时避免在刷新目录后大量回源导致的源站带宽耗费陡增,很容易把源站打趴下。不过对于一些特殊场景,比如:
1.用户源站的图片通过云存储厂商做了图片资源的修改,但是云存储厂家设置图片的属性都完全继承源图,这样就会造成cdn节点对比mtime发现自身缓存节点的mtime和源站的一致或者更新,从而不去回源拉取。表象就是刷新目录后访问文件并没有更新成功;
2.用户源站为集群或者为部署在不同区域不同城市的架构。这个时候由于源站不同步问题,也可能存在同一个文件在不同源站ip上mtime不一致导致部分回源不生效问题。
3.用户强制要求不判断mtime,强制回源
解决方案:对用户所在域名配配置下max_cache_sync on 就可以,相当于忽略 了304(回源的时候if-modified-since字段清零。)
风险点:从上面原来可以看到,取消mtime校验,回原流量会上升,配置前需要确认用户源站可以扛得住。
CDN的故障现象多种多样,不可能每一种都能覆盖到,也欢迎大家评论补充!
参考:
腾讯云DNS服务地址:
https://www.dnspod.cn/Products/Public.DNS/
百度公共DNS服务地址:
https://dudns.baidu.com/intro/publicdns/
阿里DNS服务地址:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。