-
Notifications
You must be signed in to change notification settings - Fork 30.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Increase HTTP/2 window size by default #38426
Comments
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). |
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. |
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? |
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.
Sure. I think it's crucial to change the default value to something higher anyway. |
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 hope this research to be available online, maybe we can see what values nginx or cloudflare use for example. |
v17.1.0 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 |
@tch1121 you've missed |
@szmarczak succeed, thank |
@szmarczak I'm |
The documentation listed the wrong event to subscribe to when calling `localWindowSize`. Also properly point out the correct event for http2 clients. Fixes: #51014 Refs: #38426 PR-URL: #51071 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: James M Snell <[email protected]>
The documentation listed the wrong event to subscribe to when calling `localWindowSize`. Also properly point out the correct event for http2 clients. Fixes: #51014 Refs: #38426 PR-URL: #51071 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: James M Snell <[email protected]>
The documentation listed the wrong event to subscribe to when calling `localWindowSize`. Also properly point out the correct event for http2 clients. Fixes: #51014 Refs: #38426 PR-URL: #51071 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: James M Snell <[email protected]>
Just in case someone who wants automatic window size, I wrote a simple utility some times ago for my h2 tunnel application and hope it would help: https://github.com/vilicvane/http2-auto-window-size |
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
abovebelow.This way, with 250ms latency the speed will be 64MB/s (512Mbps).
Describe alternatives you've considered
None.
/cc @kanongil @Rantoledo @CrucialDrew @fungiboletus @sindresorhus
The text was updated successfully, but these errors were encountered: