3 ms·

> These are the situations where it shines and runs away from HTTP/2. And this has been the promised advantage from the outset, and is literally the problem it

by troupo 2y ago

> These are the situations where it shines and runs away from HTTP/2. And this has been the promised advantage from the outset, and is literally the problem it is designed to solve. And yet it's somehow being pushed as a be-all solve-all replacement despite this: --- start quote --- We experimentally demonstrate that QUIC’s performance degradation affects not only bulk file transfers but also other applications including video content delivery and web browsing, despite their intermittent traffic patterns. QUIC incurs a video bitrate reduction of up to 9.8% compared to HTTP/2 when delivering DASH (Sodagar, 2011) video chunks over high-speed Ethernet and 5G. Again, such QoE degradation only exhibits when the underlying bandwidth is sufficiently high. For example, the impact is hidden over 4G but unleashed over 5G. QUIC’s page load time (PLT) is 3.0% longer than HTTP/2’s, averaged across 100 representative websites, with a long tail of page load time gaps over 50%. --- end quote --- Latency is all good ... until latency isn't the only thing affecting the performance > Of course there is no advantage -- and in fact is an expected disadvantage -- when your client and server are 0ms from each other with 0% packet loss. Now put them 100ms from each other with 5% packet loss/reordering/retransmission and multiplexing. Indeed, why not claim something that article never claimed and then claim moral superiority for yourself. Nowhere in the article do authors claim to have servers 0ms from each other with 0 packet loss. Additionally, if your performance degrades even in these ideal conditions, what does this promise for non-ideal conditions?

llm_nerd 2y ago
>And yet it's somehow being pushed as a be-all solve-all replacement But it isn't a be-all solve-all replacement. The whole point of HTTP/3 is that you can still use HTTP/2 all you want in your build-outs, and it uses as appropriate. If large file, many packet, high speed sustained performance is your thing and you've got problems with HTTP/3, deploy it on an HTTP/2 server. Go nuts. Positively nothing will go awry. Everything will be fine. You're arguing a strawman. >Additionally, if your performance degrades even in these ideal conditions, what does this promise for non-ideal conditions? This is an absolutely nonsensical statement. HTTP/3 is quite literally built for situations where you have many small requests, often in suboptimal situations. The average web user interacting with an average web page over something other than their local ethernet connection, exchanging tens of thousands of back and forths for different resources and navigations and posts. Screeching, with moral superiority I might add, that if it pins the CPU using their oddball no-name server -- oh, and where they bizarrely forced the HTTP/3 server to use HTTP/2 congestion control because that made the results funner -- with their client machine with a CPU 1/4 the performance of my smartphone, downloading a many GB file, isn't the big win you seem to think it is.
- troupo 2y ago
  > If large file, many packet, high speed sustained performance is your thing and you've got problems with HTTP/3, deploy it on an HTTP/2 server. Ah yes. Basically back to some links I discussed. Oh, it's amazing but you have to be careful what you deploy, and when, and you have to switch between HTTP/2 and HTTP/3 for some unspecified criteria which may or may not be better in one or another while the article we're in comments to decries "why oh why so few implement HTTP/3" > HTTP/3 is quite literally built for situations where you have many small requests, often in suboptimal situations. That is what Google markets it as, for sure. The rest of that sentence I could not parse.
  - llm_nerd 2y ago
    >That is what Google markets it as, for sure. Can you point me to this Google "marketing"? Google doesn't particularly care if you use HTTP/3. They don't even build it into the tools they build like Go or Dart, at least not in a timely manner. There was a passing bit of technical notes for RFCs and as they added it in Chromium, but otherwise they've been remarkably silent about it. Yet they moved trillions of web requests to HTTP/3. Maybe they really don't know what they're doing. Cloudflare also clearly hasn't the slightest, right? Fools! >while the article we're in comments to decries HTTP/3 is complex to implement. Very complex. It's pretty simple to understand why it hasn't seen wide implementation in every random tool. And for many people HTTP/2 is fine, especially as you're probably just going to drop Cloudflare (which has HTTP/3) with caching in front of it anyways.

by troupo 2y ago

llm_nerd 2y ago

>And yet it's somehow being pushed as a be-all solve-all replacement But it isn't a be-all solve-all replacement. The whole point of HTTP/3 is that you can still use HTTP/2 all you want in your build-outs, and it uses as appropriate. If large file, many packet, high speed sustained performance is your thing and you've got problems with HTTP/3, deploy it on an HTTP/2 server. Go nuts. Positively nothing will go awry. Everything will be fine. You're arguing a strawman. >Additionally, if your performance degrades even in these ideal conditions, what does this promise for non-ideal conditions? This is an absolutely nonsensical statement. HTTP/3 is quite literally built for situations where you have many small requests, often in suboptimal situations. The average web user interacting with an average web page over something other than their local ethernet connection, exchanging tens of thousands of back and forths for different resources and navigations and posts. Screeching, with moral superiority I might add, that if it pins the CPU using their oddball no-name server -- oh, and where they bizarrely forced the HTTP/3 server to use HTTP/2 congestion control because that made the results funner -- with their client machine with a CPU 1/4 the performance of my smartphone, downloading a many GB file, isn't the big win you seem to think it is.

troupo 2y ago
> If large file, many packet, high speed sustained performance is your thing and you've got problems with HTTP/3, deploy it on an HTTP/2 server. Ah yes. Basically back to some links I discussed. Oh, it's amazing but you have to be careful what you deploy, and when, and you have to switch between HTTP/2 and HTTP/3 for some unspecified criteria which may or may not be better in one or another while the article we're in comments to decries "why oh why so few implement HTTP/3" > HTTP/3 is quite literally built for situations where you have many small requests, often in suboptimal situations. That is what Google markets it as, for sure. The rest of that sentence I could not parse.
- llm_nerd 2y ago
  >That is what Google markets it as, for sure. Can you point me to this Google "marketing"? Google doesn't particularly care if you use HTTP/3. They don't even build it into the tools they build like Go or Dart, at least not in a timely manner. There was a passing bit of technical notes for RFCs and as they added it in Chromium, but otherwise they've been remarkably silent about it. Yet they moved trillions of web requests to HTTP/3. Maybe they really don't know what they're doing. Cloudflare also clearly hasn't the slightest, right? Fools! >while the article we're in comments to decries HTTP/3 is complex to implement. Very complex. It's pretty simple to understand why it hasn't seen wide implementation in every random tool. And for many people HTTP/2 is fine, especially as you're probably just going to drop Cloudflare (which has HTTP/3) with caching in front of it anyways.