42 ms·
what? https://web.dev/performance-http2/ https://web.dev/performance-http2/ With HTTP/1.x, if the client wants to make multiple parallel requests to
by preseinger 4y ago
what?
https://web.dev/performance-http2/ https://web.dev/performance-http2/
With HTTP/1.x, if the client wants to make multiple
parallel requests to improve performance, then multiple TCP
connections must be used (see Using Multiple TCP
Connections ). This behavior is a direct consequence of the
HTTP/1.x delivery model, which ensures that only one
response can be delivered at a time (response queuing) per
connection. Worse, this also results in head-of-line
blocking and inefficient use of the underlying TCP
connection.
The new binary framing layer in HTTP/2 removes these
limitations, and enables full request and response
multiplexing, by allowing the client and server to break
down an HTTP message into independent frames, interleave
them, and then reassemble them on the other end.
it very often makes sense "to do that"
- mgaunard 4y agoNo, it doesn't. Why do you think they made HTTP/3? Because the whole idea of multiplexing multiple parallel streams onto a single sequential TCP stream is stupid. As it says in the thing you quoted, the correct approach is to use multiple TCP connections. The only advantage of HTTP/3 over that is that it only pays for the latency overhead of connection establishment once instead of once per stream. This is a very small optimization that is only relevant in a very narrow set of cases.
- preseinger 4y agowhat on earth are you talking about? making 10 concurrent HTTP GET requests to the same server should not require you to make 10 connections to that server muxing multiple logical connections/streams over a single physical connection is, like, networking 101 type stuff you're out of your element donny, go home