HTTP/1与HTTP/2请求CPU使用率对比：curl测试中为何HTTP/2更耗CPU？

哈哈，这个测试结果乍一看反常识——毕竟大家都默认HTTP/2是更高效的协议，结果你测出来150次HTTP/2请求的CPU占用比400次HTTP/1还高，其实这背后是HTTP/2的核心特性带来的额外计算开销，咱们一条条说清楚：

• 头部压缩与二进制解析的额外计算：HTTP/1用的是明文文本头部，虽然冗余大，但解析起来就是简单的字符串处理，几乎没什么额外CPU消耗；而HTTP/2会用HPACK算法对头部做压缩，还把整个报文拆成了二进制帧。压缩和解压缩需要计算，二进制帧的解析也比文本复杂得多，尤其是HPACK还要维护动态字典来优化重复头部的压缩效率，这部分都是CPU的额外开销。

• 多路复用的调度复杂度：HTTP/2的核心优势是同一个TCP连接里可以同时跑N个请求（多路复用），但这就要求服务器要对这些并发的请求做调度、流控制、帧的拆分重组，还要处理优先级排序。这种复杂的调度逻辑，可比HTTP/1里“一个连接对应一个请求”的简单模型要费CPU得多。你测试里HTTP/1的400次请求大概率是分散在多个TCP连接里，每个连接的处理逻辑简单；而HTTP/2的150次请求挤在少数几个连接里，调度的开销就凸显出来了。

• TCP连接的维护开销：HTTP/2通常会复用更少的TCP连接，为了让这些连接保持高效，协议内置了很多维护机制——比如PING帧检测连接活性、动态调整流量控制窗口、处理连接上的并发流状态等等。这些额外的协议交互动作都会消耗CPU，而HTTP/1很多时候是短连接，用完就断开，不需要这么多额外的维护操作。

• 服务器实现的优化差异：不同Web服务器对HTTP/2的优化程度不一样。很多服务器在HTTP/1上做了十几年的性能调优，各种缓存、解析逻辑都磨得很顺滑；而HTTP/2的实现可能还没跟上，有些处理逻辑不够高效，也会导致CPU占用偏高。

另外要补充一句：这种CPU占用的差异在高并发场景下可能会反转。当请求量足够大时，HTTP/2的多路复用能大幅减少TCP连接的数量，节省连接建立、三次握手、慢启动这些开销，整体CPU使用率反而会比HTTP/1更低。你现在的测试是150 vs 400次请求，属于中低并发区间，这时候HTTP/2特性带来的额外开销盖过了它的优势，所以才会出现CPU占比更高的情况。

内容的提问来源于stack exchange，提问作者SIVAKUMAR K.