server.max-http-header-size与OOM不得不说的故事

今天的故事是从nacos的升级开始的，出于性能、服务治理等原因我司想把从dubbo2.7.x升级到3.2.x，但在这之前有个前提，那就是nacos首先要升级到2.x，于是乎就开始了我多灾多难的nacos升级之旅。

一开始我以为这会是个很简单的事情，毕竟很多人已经从1.x升级到2.x了，但当运维把测试环境的nacos升级到2.x后没多会涌现了一堆告警，全都是找不到dubbo的服务提供者，我这边立马登到nacos容器中查看，整个nacos的堆已经到了32G，且在一直不停地fullgc过了一会更是健康检查失败被k8s重启了，确认了是堆满了以后这边也是立马dump了一份堆快照到持久卷。

然后就是一顿分析

看的出来是直接原因是有大量5M的byte数组，然后分析引用发现是tomcat的nio请求对象的消息头，难不成是因为请求的消息头非常大？

这边也是分析出来大部分的请求都是/v1/cs/configs/listener

于是我在client和server端都查看了这个请求的消息头，发现消息头的内容很少，但消息头的大小确占用了5M，byte数组后面充斥着大量的0。这是怎么回事呢，忽然我看到nacos的jvm中有这么一项参数

--server.max-http-header-size=5242880

5242880 / 1024 / 1024 = 5M

这大大的可疑啊。

Max-HTTP-Header-Size in Spring Boot 2 | Baeldung

这个配置项的含义是Spring Boot 2中的最大HTTP标头大小，这里有个很坑的地方就是虽然叫最大，但是这个最大是指所有http请求中可能最大的header的大小，当http的请求的header大于此大小时该请求将会报HTTP Status 400 – Bad Request，而在请求创建的时候就会申请此大小的byte数组用于存储消息头（但不限于消息头这也是一个常见的误区后面会讲到）。

但一个请求5M这听着很奇怪啊，这个参数是不是我们运维瞎几把加的，我到了nacos的github上看了一眼好嘛参数确实是有的但人家是

--server.max-http-header-size=524288

大概是512k，好像合理了很多。问了下运维运维说应该是他手抖多加了个0，我尼玛，这个事情折磨了我好几周，竟然是因为你小子的手抖。

但我对max-http-header-size这个参数就产生了好奇，nacos为什么要加这个参数，在issue找到了作者的解释

https://github.com/alibaba/nacos/issues/9575

但作者的说法比较模棱两可，所以我又从git log中找到了这次提交是因为/v1/ns/instance/beat

这个心跳接口出现了请求失败

https://github.com/alibaba/nacos/issues/1069

开发者直接添加了max-http-header-size参数作为一个临时方案

git log说的蛮清楚的作为临时方案解决问题，只是没想到这个临时竟然都临到了5年后。。。

事情到此我本以为告一段落，但翻看源码时，我忽然发现beat的请求参数是挂在http的query中的，并不是放在消息头里，那为什么url参数过长需要调整max-http-header-size这个参数呢？这玩意不是控制消息头吗，本着实事求是的原则我在自己的测试应用测试了一下，当url超过8192时报错内容如下

org.apache.coyote.http11.Http11Processor: Error parsing HTTP request header
 Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level. java.lang.IllegalArgumentException: Request header is too large
	at org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:781) ~[tomcat-embed-core-9.0.39.jar:9.0.39]
	at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:451) ~[tomcat-embed-core-9.0.39.jar:9.0.39]
	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:261) ~[tomcat-embed-core-9.0.39.jar:9.0.39]
	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) ~[tomcat-embed-core-9.0.39.jar:9.0.39]
	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) ~[tomcat-embed-core-9.0.39.jar:9.0.39]
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1590) ~[tomcat-embed-core-9.0.39.jar:9.0.39]
	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) ~[tomcat-embed-core-9.0.39.jar:9.0.39]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_301]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_301]
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) ~[tomcat-embed-core-9.0.39.jar:9.0.39]
	at java.lang.Thread.run(Thread.java:748) ~[?:1.8.0_301]

好家伙，url超长怎么报了个header过大，然后我调大max-http-header-size竟然又可以正常请求了，我开始凌乱了，不得不又埋头扎进了tomcat的源码。

最后通过阅读org.apache.coyote.http11.Http11InputBuffer#fill方法我发现虽然URL和请求头部在 HTTP 请求中有着不同的用途，但它们实际上都属于HTTP请求的一部分，都包含在HTTP报文中。在处理 HTTP 请求时，服务器需要将整个请求报文（包括请求行、请求头部、请求体等）读入内存中进行解析和处理。因此，服务器需要为整个请求报文分配一块缓冲区，并设置一个大小限制以防止恶意或错误的请求导致服务器资源耗尽。因此，即使URL和请求头部在概念上是独立的，但它们都被视为请求报文的一部分，都会占用服务器的缓冲区。因此，在许多Web服务器中，URL和请求头部的大小都受到相同的配置项的限制。

最后的最后为nacos提了一个优化建议https://github.com/alibaba/nacos/issues/11810，如果能优化掉server.max-http-header-size这个参数想必对内存的使用会有明显的降低。

原文地址：https://pebble-skateboard-d46.notion.site/server-max-http-header-size-OOM-281b1227772941f4b57c17d375bb0fc9?pvs=25