我一不小心找到了Tomcat的bug！

点击上方石杉的架构笔记&＃xff0c;右上选择“设为星标”

每日早8点半&＃xff0c;精品技术文章准时送上

往期文章

BAT 面试官是如何360°无死角考察候选人的&＃xff08;上篇&＃xff09;

每秒上万并发下的Spring Cloud参数优化实战

分布式事务如何保障实际生产中99.99%高可用

记一位朋友斩获 BAT 技术专家Offer的面试经历

亿级流量架构系列之如何支撑百亿级数据的存储与计算

作者&＃xff1a;藤伦柳揶

来源&＃xff1a;https://dwz.cn/xZFW4J8S

背景介绍

为了解决分布式链路追踪的问题&＃xff0c;我们引入了实现OpenTracing的Jaeger来实现。然后我们为SpringBoot框架写了一个starter以让用户实现近零改造接入全链路。

由于公司有一个封装了SpringBoot的内部框架&＃xff0c;然后我们的starter就以最新框架所使用的SpringBoot版本为基础进行开发。所以业务系统在接入的时候需要先升级框架&＃xff0c;然后再引入我们的starter才行无缝接入全链路。

故障描述

然后有一个业务系统就按照步骤&＃xff0c;升级框架&＃xff0c;引入starter就接入了全链路系统&＃xff0c;并且功能测试压力测试都已经通过了。结果我们满怀信心地就上线了。结果&＃xff0c;线上nginx报大量http 400错误。

故障排查

出现故障后&＃xff0c;业务系统的研发人员查了所有的日志&＃xff0c;包括elk以及机器上的日志&＃xff0c;都没有发现明显的错误日志。这个就。。。

几番挣扎后还是没有在线上的日志中找到任何蛛丝马迹。这个就比较绝望了。更奇怪的是在测试环境中是正常的&＃xff0c;这个就比较诡异了。

然后我们猜想是不是之前压力测试做得不够啊&＃xff0c;我们还是在压测环境中再压测一下看看会不会复现。

然后正好之前这个业务系统做过压测&＃xff0c;那就赶紧找运维搭建一个压测环境。结果刚搭建完就非常给面子地复现了400错误。

然后运维同学就各种折腾&＃xff0c;然后神奇般地在nginx中的location下加了一行配置后就好了.

这个配置的主要是在nginx在转发htp请求的时候会加上实际的Host请求头。

如http请求是  http://abc.com/hello&＃xff0c;那么nginx在转发http请求的时候会原封不动的把host请求头(Host:abc.com)转发给后台服务。

对于nginx而言&＃xff0c;如果没有配置proxy_set_header HOST $host的时候会默认修改Host为upstream的名称。

然后我们又在压测环境中试了一下修改之前的版本&＃xff0c;发现是正常的。我们nginx的配置大体如下

那总结一下现在的现象&＃xff1a;

• 在nginx没有配置proxy_set_header HOST $host的时候&＃xff0c;修改之前的版本是正常的&＃xff0c;修改之后的版本报400错误

• 在nginx配置了proxy_set_header HOST $host之后&＃xff0c;两个版本都是正常的

那我们到底修改了什么呢&＃xff1f;

• 升级SpringBoot的版本

• 引入全链路starter

然后我们试了下去掉全链路starter的引用&＃xff0c;发现还是400错误。然后再回退SpringBoot版本&＃xff0c;发现是正常的

综上&＃xff1a;是因为升级了SpringBoot版本导致了该问题&＃xff0c;又因为是http的头部变化导致的问题&＃xff0c;故可以大胆猜测是因为升级了Tomcat版本导致的该问题。

tomcat版本从8.5.11升级到8.5.31

故障本地复现

由前面的分析可知&＃xff0c;nginx在没有配置proxy_set_header HOST $host 的时候&＃xff0c;在转发http请求的时候会默认把upstream的名称作为Host头部的内容。

也就是说新版的tomcat在接收Host为sc_java&＃xff08;带有下划线&＃xff09;的http请求报了400错误

下面我们来复现一下这个错误&＃xff0c;如下&＃xff0c;本地部署两个使用新版本tomcat的后台服务&＃xff0c;端口分别为8083和8084

nginx配置如下。重点是upstream是带下划线的

然后使用postman请求nginx&＃xff0c;复现400错误

调整nginx配置&＃xff0c;主要修改upstream为没有下划线的

然后再请求&＃xff0c;发现是正常的

故障修复方案

• 回退tomcat版本。代价较大

• 线上修改nginx配置&＃xff1a;加上配置proxy_set_header HOST $host 或者修改upstream为没有下划线的名称

根因分析

我们虽然知道了故障的原因&＃xff0c;也知道了怎么修复这个故障。但是就是不知道新版的tomcat为什么出现这个问题。

带着这个疑问&＃xff0c;我们组的同事在SpringBoot项目的issue中搜索了下400问题&＃xff0c;发现确实有相关的issue

https://github.com/spring-projects/spring-boot/issues/13236

虽然看上去跟我们的问题是一样的&＃xff0c;都是400问题&＃xff0c;但是具体发生的原因是不一样的。

这个issue是说&＃xff0c;如果domain name .ext 包含数字&＃xff0c;比如 "domain.sf1m"&＃xff0c;会出现400问题。这个问题也已经在tomcat的新版本中修复了。

但是即使我使用最新的8.5.x版本的tomcat&＃xff0c;用带有下划线的Host的http去请求tomcat的时候依然会报400错误。

也就是说&＃xff0c;带有下划线的Host的http请求&＃xff0c;tomcat认为是有问题的

那为什么之前版本的tomcat是正常的呢?带着这个疑问我们来分析一下tomcat的源代码。

由于之前没有看过tomcat的源代码&＃xff0c;所以要分析出到底是哪一行代码有问题是很困难的&＃xff0c;所以我查看了下tomcat的相关的bug

https://bz.apache.org/bugzilla/show_bug.cgi?id&＃61;62371

下面是bug中的错误stack

发现对应的代码改动如下

到这里我们也就知道了处理Host头部的类就是这个 HttpParser 类。

然后我在本次check了下tomcat8.5.31 和8.5.11的代码&＃xff0c;比对了一下HttpParser以及AbstractProcessor类。

对比结果如下:

我们发现8.5.31版本的AbstractProcessor类中多了一个parseHost的方法&＃xff0c;然后主要解析方法是Host.parse(valueMB);

到这里我们就已经知道了为什么8.5.11版本的tomcat是正常的&＃xff0c;主要是因为8.5.11版本的tomcat没有对Host头部进行校验&＃xff0c;而在8.5.31版本的tomcat增加了该校验。

我们来看一下tomcat源代码的提交记录

我们发现在 2018/4/6增加了对host/port的校验。

根因之根因

那为什么tomcat增加了这个Host的校验呢&＃xff0c;而且不允许使用带有下划线的Host呢&＃xff1f;实际上这个是有规范的。具体点击这个链接

https://www.ietf.org/rfc/rfc1034.txt

经验教训

好了&＃xff0c;到这里我们就知道了&＃xff0c;其实对于带有下划线的Host&＃xff0c;tomcat是遵循的RFC1-1034的规范的&＃xff0c;所以tomcat的处理是正确的。

但是tomcat在处理某些其他合法的Host的时候历史上出现过bug,但是对于下划线的处理一直是正确的。

所以&＃xff0c;以后nginx在配置upstream的时候不能使用带有下划线的名称&＃xff0c;还有最好在location位置上加上proxy_set_header HOST $host

END

如有收获&＃xff0c;请划至底部&＃xff0c;点击“在看”&＃xff0c;谢谢&＃xff01;

推荐阅读&＃xff1a;

• 简历写了会Kafka&＃xff0c;面试官90%会让你讲讲acks参数对消息持久化的影响&＃xff01;
  

• 面试最让你手足无措的一个问题&＃xff1a;你的系统如何支撑高并发&＃xff1f;
  

  
  

• Java高阶必备&＃xff1a;如何优化Spring Cloud微服务注册中心架构&＃xff1f;

• 高并发场景下&＃xff0c;如何保证生产者投递到消息中间件的消息不丢失&＃xff1f;

• 从团队自研的百万并发中间件系统的内核设计看Java并发性能优化&＃xff01;

• 如果20万用户同时访问一个热点缓存&＃xff0c;如何优化你的缓冲架构&＃xff1f;

更多文章&＃xff1a;

• 2018年原创汇总

• 2019年原创汇总&＃xff08;持续更新&＃xff09;

• 爆款推荐

• 面试专栏

欢迎长按下图关注公众号石杉的架构笔记

BAT架构经验倾囊相授