Comparing HTTP/3 vs. HTTP/2 Performance • Hacker News Board

Re: Comparing HTTP/3 vs. HTTP/2 Performance

#81

Post by rubatuga » Wed, Apr 15, 2020, 5:06 AM UTC

tomxor wrote: post #2

> With HTTP/2, any interruption (packet loss) in the TCP connection blocks all streams (Head of line blocking). This issue is really noticeable on my crappy home mobile internet when loading web pages, in combination with the timeout being absurdly long for reasons I don't understand.

Is this necessarily true though? I know that TCP acks and seqs contain info about the packets that have already been seen, so if only one packet is missing, the client will tell the server almost immediately, at which point the onus is on the server to resend quickly. This would be at the Linux network layer however.

Found an article explaining the concept, called selective acknowledgment:

https://en.wikipedia.org/wiki/Transmission_Control_Protocol#...

Would reducing the retransmission delay be sufficient? Or simply letting the browser open two connections to a standard HTTP port?

Re: Comparing HTTP/3 vs. HTTP/2 Performance

#82

Post by DarkWiiPlayer » Wed, Apr 15, 2020, 6:34 AM UTC

ATsch wrote: post #74

rixed wrote: post #48

Earlier quoted context omitted.

Part of me consider HTTP/3 as an application protocol and disagree with this. This is not a problem for HTTP to solve but a problem for the routing protocol to solve. Is it desirable to reinvent a routing protocol at the application layer, so that we can use it as another transport protocol and so on? Shouldn't we be using a single, unique 128bit address for every device regardless of which physical network it is att…

Yes, this shouldn't be done at the application layer. This is why it's done in QUIC, which is layer 4.5-ish. HTTP/3 runs on top of that. The "flat address space" idea however is completely ridiculous. That would mean every node on the internet keeping track of the path to every singe other node. This is what ethernet does and it barely scales to ten or so thousand nodes. Routers are already struggling hard with the 7…

> The "flat address space" idea however is completely ridiculous. That would mean every node on the internet keeping track of the path to every singe other node. This is what ethernet does and it barely scales to ten or so thousand nodes. Routers are already struggling hard with the 700k table entries we have for the IPv4 internet. To the point where providers actually wrap IP packets inside of simpler protocols once they enter the network.

If anything, we need a more hierarchical structure, with stricter separations by, e.g. Continent/Country/Province and possibly down to street or even house level, so routers can more easily just throw the data in the right general direction. Note the obvious privacy problem there.

Re: Comparing HTTP/3 vs. HTTP/2 Performance

#83

Post by yencabulator » Thu, Apr 16, 2020, 6:52 PM UTC

move-on-by wrote: post #8

jrochkind1 wrote: post #5

So, as far as the results: In their synthetic benchmarks, they find negligible to no improvement: > For a small test page of 15KB, HTTP/3 takes an average of 443ms to load compared to 458ms for HTTP/2. However, once we increase the page size to 1MB that advantage disappears: HTTP/3 is just slightly slower than HTTP/2 on our network today, taking 2.33s to load versus 2.30s And in their closer to real world benchmarks,…

I'm certainly no network engineer, but my understanding is that HTTP/3 really shines in poor networking conditions. HTTP/2 was a massive improvement on HTTP/1.2 that had some really impressive stats to back it up. HTTP/3 isn't going to have that. Being on-par with HTTP/2 in excellent conditions is expected. The little game animation backs that up - if all the data arrives in both HTTP/2 & HTTP/3 then its a wash. I'm…

> I'm certainly not aware of any HTTP/3 browser implementations on mobile.

Chrome is happily using QUIC, also on Android. And for non-browser apps, every Android app that links against the recommended network client library will do QUIC transparently.

https://developer.android.com/guide/topics/connectivity/cron...

Re: Comparing HTTP/3 vs. HTTP/2 Performance

#84

Post by moderation » Wed, Apr 22, 2020, 2:23 PM UTC

eastdakota wrote: post #23

jrochkind1 wrote: post #6

Earlier quoted context omitted.

Their own conclusion seems odd to me: > Overall, we’re very excited to be allowed to help push this standard forward. Our implementation is holding up well, offering better performance in some cases and at worst similar to HTTP/2. As the standard finalizes, we’re looking forward to seeing browsers add support for HTTP/3 in mainstream versions. I feel like the conclusion should be "Hypothetical advantages of HTTP/3 st…

Because Quiche, our HTTP/3 library, only supports CUBIC for congestion control, not more modern algorithms like BBR. Even without modern congestion control, HTTP/3 performs close to as fast as HTTP/2. We expect it’s performance will improve significantly when we implement BBR and other enhancements already in more mature protocols.

It looks like CUBIC was only just added today - https://github.com/cloudflare/quiche/commit/f8bfb919ec17ef32...