微信号:hj-academy

介绍:关注开发者在实际应用中遇到的问题.提供最真实的干货,以技术会友,为广大的开发者提供最直接的交流平台.

从错误码406说起

2017-11-16 18:10 安冬

作者:安冬
本文原创,转载请注明作者及出处


背景

前一段时间,我突然接到运营的同事通报,沪江的一位老师在国外登录不上了沪江帐号。这本来是很普通的故障,但是在排查问题过程并不简单,我们意外获得了不少收获,在这里与大家分享。

我们首先判断,从故障现象来看,应该和后端无关,而是与前端有关,所以我们迅速查看了前端的日志,从日志来看,主要是用于判断客户端的地理位置接口持续出现错误,出现大量的HTTP Status Code 406(24小时之内出现了1w多条)。按照HTTP Status Code的规范,4开头的错误码和客户端有关,考虑到这个故障只出现在一位老师那里,初步判断406就是问题的根源。

随着掌握信息的增加,分析的加深,我们迅速解决了那位外教的故障,不幸的是,确认它和406没有关系。

但是,我们并不能就此打住。毕竟正常情况下响应的HTTP Status Code应该是200,那么大量的406到底是什么呢?为什么我们都无法复现?它们是如何引发的?如此大量的爆发应当引起用户的反馈了?为什么线上的反馈这么平静呢?

下图为日志平台中406错误的情况

排查过程

为了保障性能,我们的 Node 端并没有详细记录每个请求,所以单纯看406的日志并不能知道具体的原因。为了排查这个问题,我们紧急发布了在线补丁,具体记录每个请求的详细信息,然后在日志平台中看到了下面的请求

为了便于对比,我们在浏览器上截取了正常的请求。如下图

仔细对比这两个请求,结合错误码406的定义,我们的目光集中到了 Accept 这个header

日志中

 
           
  1. Accept: text/html,application/xhtml+xml,application/xml;

而正常浏览器的行为

 
           
  1. Accept: */* ;

于是,我们在 Postman 中模拟了错误的请求,果然,我们复现了406错误,所以可以确认问题是 Accept 字段导致。

406 Not Acceptable 状态码表示客户端错误,表示请求的资源的内容特性无法满足请求头中的条件,因而无法生成响应实体。 译自HTTP协议规范RFC文档

我们上网查阅资料并也跟后端同事讨论了406的错误码,得知,如果请求头的 Accept 不符合事先约定的契约,就会返回406错误。报错的是 API 服务,返回的是 application/json 格式的数据, 然而请求中的 Accept 说明它并不支持这种格式,所以会报出406错误。

我们仔细检查了常见浏览器发送的请求,发现全部都包含 Accept: */* ;。看来,这些引发406的请求并不是普通用户发出来的。那么,究竟是谁发出了这些请求呢?

难道是CDN?

CDN 的全称是Content Delivery Network,即内容分发网络。 其目的是使用户可就近取得所需内容,解决Internet网络拥挤的状况,提高用户访问网站的响应速度。 CDN 网络可以将服务器的内容缓存到分布全球的CDN节点,根据用户的访问 IP,就近连接 CDN,提高网站响应速度。(引用自google.com)

如今CDN已经是各种公司的普遍配置,沪江也不例外。我们仔细研究了引发406的请求来源IP,发现都是来自北京联通的少数节点。这样看来,CDN的嫌疑很大,大概有两种可能:1、原始请求头部的Accept 字段就是错的;2、原始请求头部的 Accept 字段是对的,但是在经过 CDN 节点的时候被 CDN 篡改了。由于以前遇到过 CDN 篡改头部的问题,我们初步判断是 CDN 的问题。

接下来,我们将北京联通的节点暂时回源,验证是不是 CDN 篡改了头部,同时也拿到了最终的用户 IP。 上网搜索这个IP详细的信息,上面赫然写着某搜索引擎的爬虫。原来,406并不是来自于普通用户,而是搜索引擎的爬虫。

花絮

在写文章的这几天,发现错误日志下降了很多,406错误都没有了。以为某某搜索引擎幡然悔悟,于是用当时出错的 IP 去日志平台搜索,发现该搜索引擎只是换了个策略。它的 Accept 字段做了修改,UA 头中加上了该搜索引擎特有的标识,摇身一变又成了正规的搜索引擎。

小结

对开发人员来说,当站点遇到大量的406错误的时候,不用太担心,好好查下日志,它很有可能是搜索引擎的爬虫导致的。

总结下本次406错误码事件,某搜索引擎在爬取沪江页面的时候,请求头设置 Accept 与后端服务所接受的 Accept 字段不同,从而导致大量的406错误。

最后详细讲解下Header中 Accept 的相关知识

Accept

header中用它来告知客户端可以处理的内容类型,这种内容类型用MIME类型来表示(引用自MDN)

内容类型

text/html,application/xhtml+xml,application/xml 都是 MIME 类型,也可以称为媒体类型和内容类型。

 
           
  1. Accept:application/json

示例中,application的是类型,json是子类型。它说明,客户端只能够接收application/json这种类型的响应。如果服务端不能返回这种类型的响应,服务端应当返回406错误。

通配符 * 代表任意类型

例如:Accept: /代表浏览器可以处理所有类型

Accept可以支持用,分隔的多个类型

借助内容协商机制,服务器可以从诸多备选项中选择一项进行应用,并使用 Content-Type 应答头通知客户端它的选择。

 
           
  1. Accept: text/html,application/xhtml+xml,application/xml

它说明,客户端能够接收的响应类型只有三种:text/html,application/xhtml+xml,application/xml。

因子权重(q)

q是一个0-1之间的数值, q的默认值是1, q=0代表不可接受,q 值越大,请求越倾向于获得其“;”之前的类型表示的内容

 
           
  1. Accept: text/html;q=0.9,application/xhtml+xml;0.7,application/xml,*/*;q=0.5

它说明,客户端优先选择text/html格式的响应,其次是application/xhtml+xml,最后才是application/xml,*/*。

技术沙龙推荐

点击下方图片即可阅读


如何优雅的设计 React 组件


安卓推送“有救”了?从工信部统一推送联盟说起


Callback 与 Promise 间的桥梁 —— promisify


使用合适的设计模式一步步优化前端代码


 
沪江技术学院 更多文章 技术沙龙 | 移动应用开发及性能优化 活动推荐 | Kotlin 开发者技术沙龙 COSCon'17 中国开源年会门票大放送 如何优雅的设计 React 组件 安卓推送“有救”了?从工信部统一推送联盟说起
猜您喜欢 想成为机器学习工程师?这份自学指南值得你收藏 SaaS行业全景:采用率、商业效益和主流的提供商 我们都开学了,你还在迷茫啥? ❲infoQ❳百度袁华良:如何快速搭建一个完整的移动端直播系统 【接棒2015】打了兴奋剂的2016人工智能更加不会辜负你的眼球!