Increase HTTP/2 window size by default

[szmarczak]

Is your feature request related to a problem? Please describe.

https://gist.github.com/szmarczak/4a764b3d00ae217267c9d79caafd4082

It is now possible to set the window size on the session & its streams. By default, it's 64KB which is too small. When connecting to really remote servers, there can be even 250ms latency. That is 4 packets per second! What a fantastic speed of 256KB/s.

Okay, you might want to connect to a close server, assume 20ms ping. That's just 50 packets per second.
Meaning: 50 * 16 = 3200KB/s.

Describe the solution you'd like

There are many 1Gbps connections out there. Let's make the session window size 128MB and the stream window size at least 16MB. Okay, that's overkill, see my comment above below.

This way, with 250ms latency the speed will be 64MB/s (512Mbps).

Describe alternatives you've considered

None.

/cc @kanongil @Rantoledo @CrucialDrew @fungiboletus @sindresorhus

[szmarczak]

If 128MB seems too much, I'd prefer if we didn't go lower than 32MB for the session window size and 4MB for the stream window size.

That way, with 250ms latency the speed would be 16MB/s (128Mbps).

[h1z1]

This should be left to the OS. You may have 11 terabit cybernetic spinal tap, won't mean much if the latency is through the roof too.

[kanongil]

This should be left to the OS. You may have 11 terabit cybernetic spinal tap, won't mean much if the latency is through the roof too.

It probably should, but the HTTP2 spec did not think so, so that is not really an option. Unless you think that the implementation should be rewritten to use OS-supported HTTP/2 connections? I believe only Windows 10 and macOS provide any such APIs.

Besides, the OS will also provide its own connection window at the TCP level.

[mcollina]

I think it's clear that the window size is a fundamental to achieve good performance. As far as I understand, we are talking about the default value, or am I missing something? I do not think we are providing enough documentation on this topic - so maybe the best step is to document how to tune this parameter?

[szmarczak]

As far as I understand, we are talking about the default value, or am I missing something?

Correct. I don't think leaving the window unlimited is a good option since it might disable parallelism. We don't want one session to consume all the bandwith - there should be space left for others as well.

so maybe the best step is to document how to tune this parameter?

Sure. I think it's crucial to change the default value to something higher anyway.

[mcollina]

FWIW the higher window size become problematic in lossy networks.

Wdyt @jasnell? What should be a good default value?

My approach to determine the best value would be to run tests and simulations across all conditions. This is probably a significant chunk of work.
(I did similar research during my Ph.D.).

I hope this research to be available online, maybe we can see what values nginx or cloudflare use for example.

[tch1121]

v17.1.0
no speed increase

import http2 from "node:http2";

const url = new URL('https://nodejs.org/dist/v17.1.0/node-v17.1.0-x64.msi')

const client = http2.connect(url, () => {
  console.log('setLocalWindowSize')
  client.setLocalWindowSize(1024 * 1024 * 100)
});

client.on('error', (err) => console.error(err.message));

const req = client.request({ ':path': url.pathname });

req.on('response', (headers, flags) => {
  console.log('status:', headers[":status"])
  console.log('content-type:', headers['content-type'])
  console.log('content-length:', headers['content-length'])
});

req.on('data', (chunk) => { });

req.on('end', () => {
  console.log(`req end`);
  client.close();
});

req.end();

deno fetch can be very fast

[szmarczak]

@tch1121 you've missed initialWindowSize

[tch1121]

@szmarczak succeed, thank