4 ms·

That is a very low number. I can think of many reasons why one would end up with more. Does anyone know why it is so low?

apitman 2y ago
Historical reasons. The HTTP/1.1 spec actually recommends limited to 2 connections per domain. That said, I'm not sure why it's still so low. I would guess mostly to avoid unintended side effects of changing it.
- gsnedders 2y ago
  > The HTTP/1.1 spec actually recommends limited to 2 connections per domain. This is no longer true. From RFC 9112 § 9.4 (https://httpwg.org/specs/rfc9112.html#rfc.section.9.4 https://httpwg.org/specs/rfc9112.html#rfc.section.9.4): > Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many applications. As a result, this specification does not mandate a particular maximum number of connections but, instead, encourages clients to be conservative when opening multiple connections.
  - apitman 2y ago
    If this was a MUST would it have required a bump from 1.1?
- dontchooseanick 2y ago
  Because you're supposed to use a single connection with HTTP Pipelining for all your ressources [1] When index.html loads 4 CSS and 5 JS : 10 ressources in HTTP 1.0 needed 10 connections, with 10 TLS negociations (unless one ressource loaded fast and you could reuse it's released connection) With HTTP1.1 Pipelining you open only one connection, including a single TLS nego, and ask 10 ressources. Why not only 1 per domain so ? IIRC it's because the 1st ressource index.html may take a lot of Time to complete and well race conditions suggest you use another one that the 'main thread' more or less. So basically 2 are sufficient. [1] https://en.m.wikipedia.org/wiki/HTTP_pipelining https://en.m.wikipedia.org/wiki/HTTP_pipelining
  - immibis 2y ago
    HTTP pipelining isn't used by clients.
foota 2y ago
Probably because without http/2 each would require a TCP connection, which could get expensive.
raggi 2y ago
The number was set while Apache was dominant and common deployments would get completely tanked by a decent number of clients opening more conns than this. c10k was a thing once, these days c10m is relatively trivial
giantrobot 2y ago
Because 30 years ago server processes often (enough) used inetd or served a request with a forked process. A browser hitting a server with a bunch of connections, especially over slow network links where the connection would be long lived, could swamp a server. Process launches were expensive and could use a lot of memory. While server capacity in every dimension has increased the low connection count for browsers has remained. But even today it's still a bit of a courtesy to not spam a server with a hundred simultaneous connections. If the server implicitly supports tons of connects with HTTP/2 support that's one thing but it's not polite to abuse HTTP/1.1 servers.

apitman 2y ago

Historical reasons. The HTTP/1.1 spec actually recommends limited to 2 connections per domain. That said, I'm not sure why it's still so low. I would guess mostly to avoid unintended side effects of changing it.

gsnedders 2y ago
> The HTTP/1.1 spec actually recommends limited to 2 connections per domain. This is no longer true. From RFC 9112 § 9.4 (https://httpwg.org/specs/rfc9112.html#rfc.section.9.4 https://httpwg.org/specs/rfc9112.html#rfc.section.9.4): > Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many applications. As a result, this specification does not mandate a particular maximum number of connections but, instead, encourages clients to be conservative when opening multiple connections.
- apitman 2y ago
  If this was a MUST would it have required a bump from 1.1?
dontchooseanick 2y ago
Because you're supposed to use a single connection with HTTP Pipelining for all your ressources [1] When index.html loads 4 CSS and 5 JS : 10 ressources in HTTP 1.0 needed 10 connections, with 10 TLS negociations (unless one ressource loaded fast and you could reuse it's released connection) With HTTP1.1 Pipelining you open only one connection, including a single TLS nego, and ask 10 ressources. Why not only 1 per domain so ? IIRC it's because the 1st ressource index.html may take a lot of Time to complete and well race conditions suggest you use another one that the 'main thread' more or less. So basically 2 are sufficient. [1] https://en.m.wikipedia.org/wiki/HTTP_pipelining https://en.m.wikipedia.org/wiki/HTTP_pipelining
- immibis 2y ago
  HTTP pipelining isn't used by clients.

foota 2y ago

Probably because without http/2 each would require a TCP connection, which could get expensive.

raggi 2y ago

The number was set while Apache was dominant and common deployments would get completely tanked by a decent number of clients opening more conns than this. c10k was a thing once, these days c10m is relatively trivial

giantrobot 2y ago

Because 30 years ago server processes often (enough) used inetd or served a request with a forked process. A browser hitting a server with a bunch of connections, especially over slow network links where the connection would be long lived, could swamp a server. Process launches were expensive and could use a lot of memory. While server capacity in every dimension has increased the low connection count for browsers has remained. But even today it's still a bit of a courtesy to not spam a server with a hundred simultaneous connections. If the server implicitly supports tons of connects with HTTP/2 support that's one thing but it's not polite to abuse HTTP/1.1 servers.