http 400错误解决

首先给大家推荐一下我老师大神的人工智能教学网站。教学不仅零基础,通俗易懂,而且非常风趣幽默,还时不时有内涵黄段子!点这里可以跳转到网站

产品上线后,在试单过程中,出现一个硬bug,我们系统接入的是百度系统,出现一个http 400错误,这硬bug难倒10几个英雄汉。接下来描述下问题,及我们解决问题的方法及教训:

我们的系统与百度系统是专线访问通道,在上线前肯定确保应用系统是没问题的。双方的访问时基于http协议,接口对接。

访问流程是:百度应用发出一条命令,经过百度网关,然后到达我们的负载,然后是网关,最后转发到应用系统。

问题来了:在百度发出命令后,通过专线到达我们的网关后,我们网关服务器上部署的Apache报出400错误,应用系统没有打印任何日志。

然后我们就找原因:

思考1.400是谁报出来的,已确定只要到达应用,应用就会打印日志,目前应用没有打印日志,就不是应用层;网关的Apache的error没有相关日志,只有正常access文件中有访问日志,那就说明我们的Apache没有坏。但是网关服务器只做转发功能,不做任何报文的转换。

为了排除我们这边的原因,我们做了以下测试:

测试1.使用curl命令,网关IP,正常的报文,从网关自我访问。发现应用层能够正常打印日志。排除了网关向应用层转发错误的可能。

测试2.使用curl命令,负载IP,正常的报文,从负载上自我访问。发现应用层能够正常打印日志。排除了负载向网关转发错误的可能。

测试3.使用curl命令,正确的URL,报文错误的参数,从负载上自我访问。发现应用层能够正常打印日志。排除了报文错误的可能。

思考2.网上查资料,看到400错误可能的原因:1.http版本不一致;2.报文过长;3.报文内容类型与报文内容不匹配(content-type:form与json)。我们观察百度发来的报文与其他合作商发来的报文的区别,发现版本号确实不一致,报文也不短,有1000多字节。然后就自我访问,按照网上资料可能的错误原因进行测试:

测试4.使用curl命令,负载IP,正常的URL,http版本换成百度报文中的版本。发现应用层能够正常打印日志。排除了http版本错误的可能。

测试5.使用curl命令,负载IP,正常的URL,报文长度到达5000字节。发现应用层能够正常打印日志。排除了报文过长的可能。

测试6.使用curl命令,负载IP,正常的URL,将form类型的报文,在content-type中修改为json。发现应用层能够正常打印日志。排除了报文参数值错误的可能。

思考3.经过这些测试,我们基本确定不是应用的问题,而是应用前后各种报文转换配置的问题,那么到底是哪里的出错了呢?然后我们与百度方沟通,是否是在传递命令时,百度方的网关或我们的网关有添加或修改报文。

然后我们猜测是否在网络传输过程丢包了。然后我们就进行抓包测试,从百度发命令,我们在我们的网关入口抓包。经对比分析,没有丢失任何内容。

思考4.那么问题到底在哪,双方几个大拿,开会讨论,确定测试方案。我们既然找不出原因,那么就抽丝剥茧,像剥洋葱一样,从外向里拨,一点点排除各环节的错误。

先写一个简单的页面,以防影响其他的业务,防止业务应用报出错误混淆这个400,便于查看返回数据。

首先是网关对网关,将页面部署到网关Apache上。从百度网关访问我们网关。结果能够正常返回页面数据;排除网关对网关访问异常。

然后是网关对应用,将页面部署到应用服务器上的Tomcat上。从百度网关访问我们的网关,结果能正常返回页面数据;排除网关正常访问我们的应用异常。

最后是应用对应用,将页面部署到应用服务器上的Tomcat上。从百度应用访问我们的网关,结果报出http-400错误;问题定位:百度应用发出的命令经过百度网关后,转换了报文,导致我们的网关直接报错。

到目前为止,已经过去4天了。我们终于将范围缩小到百度应用到百度网关加了什么东西,让我们的系统识别失败。

问题终于找到了。在第5天时,百度人终于找到了问题:

“1.我们在接收http请求时,网关按照header里的 host 字段来进行了一次过滤,过滤的方式应该是正则匹配了ip
2.百度的proxy在转发时host改写为nginx upstream的名字,和我们的网关过滤不匹配”

教训

这次找bug事件中我得出了一些教训:

1.不要总找自身原因。

2.加强沟通

3.解决问题要有调理。有调理的,像剥洋葱一样,一点点剖析、排除问题。

4.什么职位做什么事,既然是产品经理就不要试图指挥技术解决技术的问题。

5.提高双方的配合度。

点这里可以跳转到人工智能网站

发表评论