Menu
For a long time, browsers have used a maximum of 6 concurrent HTTP 1.1 connections per host to retrieve assets from web page. Going (far) beyond this golden standard is perceived as DOS and get you banned from a server.
Now there is HTTP/2 and we can multiplex many HTTP requests on a single connection. Should we still use similar limits on the number of concurrent requests that we multiplex on a connection in order to prevent overloading servers? Or is there no harm in multiplexing many more requests on a single connection?
Anyone knows what limits browsers use per host and per connection for HTTP/2 servers?
848
Multiplexing HTTP requests allows the usage of a single connection per client, meaning that a single connection between the client and the webserver can be used to serve all requests asynchronously, enabling the webserver to use less resources, thus support more users at the same time.
Chrome has a limit of 6 connections per host name, and a max of 10 connections. This essentially means that it can handle 6 requests at a time coming from the same host, and will handle 4 more coming from another host at the same time.
HTTP/2 connections typically have a limit on the number of maximum concurrent streams (active HTTP requests) on a connection at one time. By default, most servers set this limit to 100 concurrent streams.
First, because they received requests in large batches instead of smaller, more spread-out batches. And secondly, because with HTTP/2, the requests were all sent together—instead of staggered like they were with HTTP/1.1—so their start times were closer together, which meant they were all likely to time out.
The number of streams that client and server can initiate isn't unlimited, it's mandated by the SETTINGS_MAX_CONCURRENT_STREAMS parameter of the SETTINGS frame that each peer sends at the beginning of the connection: see section 6.5.2 of RFC 7540 The default is unlimited, and the RFC has the following recommendation:
It is recommended that this value be no smaller than 100, so as to not unnecessarily limit parallelism.
The number of streams is however not the only parameter to take into account when considering parallelism in HTTP/2. Weights and stream dependencies also come into play.
Each stream is given a weight, and the RFC recommends that the server assign resources to streams based on their weight. Client side, Firefox assigns higher weights to the CSS than images. See this great presentation for more details about how each browser prioritizes and organizes its streams. Chrome uses dependencies so that the most important elements (CSS, HTML) are higher in the dependency chain than others. See this tool that illustrates the dependecy tree that Chrome generates. Server side, H2O, a new and fast HTTP server, implements an O(1) scheduler per connection in order to send the streams to the client based on the dependencies and weights. That means that if you request 500 elements with default dependency, each stream will get 1/500th of the server resources.
There shouldn't be any downside to request as much elements as possible (for regular web browsing). According to HTTPArchive, 40% of the pages contain more than 100 elements, and I would think it's reasonable to ask them all at the same time (provided the number of streams stays below SETTINGS_MAX_CONCURRENT_STREAMS. I believe that what matters is to be able to request them in the order that will allow the browser to render it as fast as possible.
156
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
