x/net/http2: increased memory use with ForceAttemptHTTP2

[rawat-divyanshu]

What version of Go are you using (go version)?

$ go version
go version go1.21.3 linux/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env

What did you do?

In my golang application we were using the http Client with custom TLS config, and as per the golang's x/net/http package if we provide a custom TLS Config then the support for http/2 will be disabled. So for enabling the http/2 support with custom TLS config I enabled the flag ForceAttemptHTTP2 flag, but with that I'm seeing a 200MB of memory spike in my application.

I'm running this application on a 800 Hosts setup. But as of now none of the Hosts has a http/2 support enabled still I'm seeing this memory spike.

On profiling my application I'm seeing the top contributor for my memory is bytes.growSlice which increased from 8% to whooping 30%. Profile details are as below:

1. Profile with above changes:

2. Profile without changes:

What did you expect to see?

Since I enabled the http/2 support, after the protocol negotiation since I didn't had any hosts supporting http/2 the request should fallback to http/1.1 and application should behave normally.

What did you see instead?

Though requests were falling back to http/1.1 but there was 250MB more memory usage by the application.

[seankhliao]

please provide a reproducer demonstrating the issue.
a tls connection includes a list of supported application protocols, if h2 wasn't advertised, it should never be used.

[mauri870]

I think this comment explains why:

	// TODO: let getReadBuf be configurable, and use a less memory-pinning
	// allocator in server.go to minimize memory pinned for many idle conns.
	// Will probably also need to make frame invalidation have a hook too.
	getReadBuf func(size uint32) []byte

https://github.com/golang/net/blob/547e7edf3873d6f3a9c093d3785f9e2289e00746/http2/frame.go#L282-L285

[mauri870]

Maybe we can come up with something similar to CL 539915 to optimize the memory usage and allocations.