4 ms·
Yes, it has. And it's one of the prime reasons HTTP/2 is slower for lots of applications than pure HTTP/1.1. The tricky part of HTTP/2 is that you now have 2 f
by Matthias247 6y ago
Yes, it has. And it's one of the prime reasons HTTP/2 is slower for lots of applications than pure HTTP/1.1.
The tricky part of HTTP/2 is that you now have 2 flow control algorithms running on top of each other. And they are rather good at harming the other one instead of cooperating. E.g. a too small HTTP window can lead to poor performance as you observed. However a too big HTTP window can lead to excessive buffering in the application for HTTP/2 streams.
It's a rather hard challenge to get to a good compromise solution here (and not a lot of people have arrived there yet).
In doubt the rule of thumb is to use HTTP/2 for small requests where the benefit of multiplexing is biggest. And stick to HTTP/1.1 (a non multiplexed TCP connection) for high throughput.
- mobilio 6y agoThis is fixed on HTTP/3
- Matthias247 6y agoHow do you define "fixed"? Quic still defines per stream plus per connection flow control windows, on top of the lower level congestion control algorithm.
- xxpor 6y agoDoes it not use UDP?
- mobilio 6y agoIt uses UDP because simply can't change all TCP infrastructure worldwide. Example - i'm still using on some place router Linksys WRT54GL with kernel 2.4 that is almost 15 years old. Because device still works and there was low network requirements.
- xxpor 6y agoSure, I totally get that. But my point is UDP doesn't have any underlying congestion control you have to fight.
- Matthias247 6y agoRight - it does. My point was that Quic still has 2 layers which determine the amount of data that is sent to peers. On the lower level, there is a congestion controller - which can be like Cubic, New Reno, BBR, etc. This part does not know anything about Quic streams yet. On a higher level you have the Quic streams, which carry user data. These are subject to flow control windows, and there also exists a shared per-connection window. Depending on the implementation the layers might not be very much aware of each other, which can also lead to imperfect utilization. That said the situation is obviously still different than with TCP, since the congestion controller does not limit the amount of user data but packets in general (which includes retransmits, etc). So the outcomes will certainly be different than what we observe with HTTP/2.
- mobilio 6y agoHTTP/3 is built with TLS 1.3 and have faster handshake. Second - HTTP/3 define some "idle" state of connections like 30 seconds or even more. So you can download something and then nothing. Here HTTP 0.9/1.0/1.1 and /2 closes connections. On HTTP/3 it was set to idle - nor closed. And let say after 15 sec you need new resource. On HTTP/3 connection flow continue where was stopped. On previous versions you must make TLS handshake and then to make new request. This mean performance penalty because congestion control will start with values similar to 0.
- Matthias247 6y agoThis is pretty much unrelated to the discussion earlier on (which was about the interaction of different flow control mechansisms). But nevertheless one answer that tries to clear up some misunderstandings: You can reuse connections with every HTTP version up from HTTP/1.1. The main difference between HTTP/1.1 and HTTP/2 and /3 is that you can't make concurrent requests on a single connection with HTTP/1.1, but you can with /2 and /3. For how long a connection will stay open after a request will be determined by keepalive settings on the client and server side. All HTTP versions up from 1.1 allow you not to use a connection for 30s and then make another request.
- the8472 6y ago> In doubt the rule of thumb is to use HTTP/2 for small requests where the benefit of multiplexing is biggest. And stick to HTTP/1.1 (a non multiplexed TCP connection) for high throughput. Alas, if you want to upload the browser doesn't let you choose, so you would have to set up another host or port.