警惕！HTTP2 通信的潜在失败原因分析报告
2023-12-26 21:56:59
一次 HTTP2 通信失败的原因分析
人们总说知己知彼，方能百战不殆。但IT领域何曾出现过对等关系，绝大多数情况下，都是IT人员以卵击石，用血泪换取知识。因此，对于IT领域的问题，第一步的分析显得尤为重要。这就跟病人看病一样，第一步是采集病人信息。只要信息采集全面，医生才能有针对性地开方用药。
第一步分析——信息采集
这次HTTP2 通信失败是小伙伴测试HTTP2新特性时碰到的问题。他是这样问题的：
HTTP2明明启动了，为什么做个比较耗时的事时会失败？失败日志里看到了一个错误，会不会跟这个错误有关？
这里，小伙伴提供了三个信息：HTTP2启动了、失败日志里有错误、失败场景是一个比较耗时的事。但这些信息还不足以确定问题所在，因此，我询问了小伙伴如下问题：
- HTTP2 启动了是怎样判断的？
- 错误日志里是什么错误？
- 一个比较耗时的事具体是指什么？
- 什么场景下会失败？
- 失败的现象是什么？
通过以上问题，获得了以下信息：
- HTTP2 启动是通过curl命令中 --http2 参数确定的。
- 错误日志里的错误信息是"use of closed connection"。
- 一个比较耗时的事是请求一个内容很大的文件。
- 失败场景是同时用多个进程请求文件，或者一个进程多次连续请求文件。
- 失败的现象是连接失败，服务器返回错误码503。
信息采集完成，剩下的就是分析验证。
第二步分析——分析验证
信息采集完成后，需要对信息进行分析验证，这就好比医生把病人的信息进行专业分析，进而得出结论。这里，根据获得的信息，可以得出以下结论：
- HTTP2启动时会建立多个连接。
- HTTP2连接是复用的，因此HTTP2一个请求可能会在不同的连接中传输。
- 因此，可能HTTP2请求在连接还没有完全建立好时，就开始了数据的传输，进而导致"use of closed connection"错误。
经过分析验证，得出了一个猜想：也许HTTP2连接复用时没有完全建立好，就开始了数据的传输。为了验证这个猜想，可以做如下操作：
ab -k -c 10 -n 10 -H "Content-Length: 10000" http://your-host/test.html
这样，就可以模拟单一进程多次请求文件。我按照上述命令做了验证，果不其然，"use of closed connection"错误信息再次出现了。
第三步解决问题
有了确切的结论，解决问题就变得简单了。搜索关于HTTP2的资料，发现Nginx中确实存在这个问题。HTTP2最早是在Nginx1.9.5版本发布，但从那时到小伙伴测试HTTP2新特性时，已经发布了多个版本，所以这个问题应该是已经修复了。于是，让小伙伴把Nginx升级到最新版本，HTTP2通信失败的问题就消失了。
问题分析到这里就结束了。我们可以看到，通过一步步的分析验证，最终解决了问题。由此可见，拿到一个不熟悉的问题，我们应该怎么分析处理：
- 信息采集：获取问题相关的信息，越全面越好。
- 分析验证：对获取的信息进行分析验证，得出可能的结论。
- 解决问题：验证结论正确后，进行问题修复。
这只是我分析处理问题的习惯，也许你觉得不适合你，但有一点，我觉得值得大家学习，就是遇到问题时不要盲目地去找人帮忙解决，先自己尝试着分析处理，养成分析处理问题的思维习惯。
小结
这篇分析过程看似平淡无奇，跟侦探的推理完全扯不上关系。但这恰恰是计算机领域的魅力所在，它有明确的规则、逻辑，只要符合规则、逻辑，最终一定会解决问题。如果你觉得现在从事的工作没有挑战性，那么可以尝试一下软件开发。这里有无数的挑战等着你，等着你用逻辑、推理去征服。
这一次，我们一起解决了HTTP2 通信失败的问题。下次，当您遇到类似的问题时，希望您能使用相同的方法来分析和解决问题。在本文的结尾，我想说的是，不要害怕挑战，要敢于尝试新的事物，因为只有这样，您才能不断进步，成为一名优秀的程序员。
