http2: tune control flow defaults

[ronag]

The current defaults are unnecessarily conservative which makes http2 control flow over high latency connections (such as public internet) unbearably slow.

[nodejs-github-bot]

Review requested:

• @nodejs/http2
• @nodejs/net

[ronag]

I'm unsure about the relationship between request window size (initialWindowSize) and connection window size (connectionWindowSize). But I assume it's ok to have a 1:2 relationship. 🤷

[ronag]

This affects UPLOAD speed, i.e. data to server.

[ronag]

We should actually apply the default settings and not just assume that they are the same as nghttp2 will do.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.49%. Comparing base (d9cf867) to head (bb77aed).
⚠️ Report is 1118 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #61036      +/-   ##
==========================================
- Coverage   88.58%   88.49%   -0.10%     
==========================================
  Files         704      703       -1     
  Lines      207815   208557     +742     
  Branches    40036    40198     +162     
==========================================
+ Hits       184102   184571     +469     
- Misses      15758    16019     +261     
- Partials     7955     7967      +12     

Files with missing lines	Coverage Δ
lib/internal/http2/core.js	93.85% <100.00%> (-1.36%)	⬇️
lib/internal/http2/util.js	92.74% <100.00%> (+0.05%)	⬆️

... and 152 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

lgtm

I think this might require a doc change too

[mcollina]

lgtm

[pimterry]

I'm unsure about the relationship between request window size (initialWindowSize) and connection window size (connectionWindowSize). But I assume it's ok to have a 1:2 relationship. 🤷

My understanding is they are overlapping limits: if sending any byte would go over the receiver's window for the connection or the window for the specific stream, then you have to wait. That means a 1:2 ratio only lets 2 streams fully using their windows at any time - beyond that, streams are fighting for bandwidth. Similarly, if you're handling lots of streams on a single connection, it means 2 busy streams start to starve all the others.

Concrete numbers: with this specific setting, with 256KB/512KB stream/connection windows on a 100ms latency connection, each stream can use ~2.5MB/s (i.e. 20mbps) and the entire connection across all streams can use 5MB/s.

Imo, 1:2 seems a touch conservative still, I'd be happy to go a few multiples further, but ofc if we want to really get into this we'd need to measure a bunch of scenarios in a lot more detail, and trying to do some kind of dynamic optimization instead as mentioned in Slack would make more sense anyway.

Still a very significant improvement though regardless, so I'm all aboard as-is, very happy to ship this 👍. We can bikeshed & tweak further later as feedback comes in.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/70522/

[github-actions]

Failed to start CI

- Validating Jenkins credentials
✔  Jenkins credentials valid
- Querying data for job/node-test-pull-request/70522/
[SyntaxError: Unexpected token '<', ..."    
  https://github.com/nodejs/node/actions/runs/24120621083

[RafaelGSS]

Shouldn't it be flagged as semver-major?

[github-actions]

Failed to start CI

- Validating Jenkins credentials
✔  Jenkins credentials valid
- Querying data for job/node-test-pull-request/70522/
[SyntaxError: Unexpected token '<', ..."    
  https://github.com/nodejs/node/actions/runs/24164427109