46 ms·

HTTP/3 Is Fast

445 points by SerCe 5y ago

bestest 5y ago
200ms faster than WHAT? Edit: Ok, apparently there are charts that are not being loaded due to the HN Effect. A clear example of how a blind reader would miss quite a bit of information when the data is only shown in images / other non A11Y compliant resources.
- avereveard 5y ago
  Comparing HTTP/2 and HTTP/3 protocol versions when loading pages from NY HTTP/3 is: 200ms faster for the Small Site 325ms faster for the Content Site 300ms faster for the Single Page Application it seems a text only extraction of the section in object remains perfectly intelligible
- ksec 5y ago
  >Edit: Ok, apparently there are charts that are not being loaded due to the HN Effect. No it doesn't work on Safari only. Turn on Lazy Image loading or use other browser.
phicoh 5y ago
It is nice to see the effect of 0-RTT in QUIC. In quite a few graphs the HTTP3 times for the small Site has one dot roughly at the same level as HTTP2. This probably the first connection. The rest gets 0-RTT.
sam_goody 5y ago
Full kudos to Caddy for being the first out the door with working HTTP/3 support. Are there downsides to HTTP/3? When HTTP/2 came out there was discussions about why not to enable.
- ardit33 5y ago
  We will know over time. HTTP/3 is fixing all shortcomings of HTTP/2, which was pretty flawed. It uses UDP though, and UDP itself can be blocked by many firewalls, and folks/companies have to update firewalls and routers for it to work properly. So, that's its major weakness (eg. some workplaces block all egress UDP packets). https://news.ycombinator.com/item?id=27402222 https://news.ycombinator.com/item?id=27402222 As the article says, HTTP3 is pretty fast when there are high latencies/high loss scenarios. It will be interesting to see how it performs in a mobile setting. 4G and 5G networks have their own/specific optimizations that are different than a desktop world. eg. http keep alives were never respected, etc. (connections would be closed if there was no continuous activity). But, given the test, it 'should' be much faster than http 1.1 One think is for sure: HTTP 1.1 is going to still be used, even 100 years from now. It is like FM Radio, which is both good enough for most cases, and very simple and convenient at the same time.
  - josefx 5y ago
    I can't wait for all the HTTP/3 -> HTTP/2 -> HTTP/1 tunneling and other exploits that will appear in all the rushed implementations. We already saw how that worked with HTTP/2 and people tried to rush OpenSSL into adopting an experimental implementation of QUIC while Google was still hashing out the spec. . I would suggest disabling HTTP/3 for the next 10 or so years and give everyone else the chance to burn through the exploits.
    - johncolanduoni 5y ago
      Thankfully HTTP/3 didn’t change request/header semantics much from HTTP/2, at least nowhere near the level of the HTTP/1 -> HTTP/2 changes.
  - ithkuil 5y ago
    Do you have a link at hand describing the main shortcomings of http/2 (that http/3 fixes)?
- Jleagle 5y ago
  I am using it with traefik too.
- jeroenhd 5y ago
  I know of at least one ISP that plain blocks outgoing UDP/443 or at least messes with the packets, so I wouldn't rely on its availability. I'm also hesitant about HTTP/2 and 3 because of their complexity, but if you trust the systems and libraries underlying your server I don't see any problem in activating either. Just watch out with features like 0-RTT that can have a security impact and you should be fine.
  - jillesvangurp 5y ago
    It will likely just fallback to http on networks like that. Shitty ISPs and corporate networks are why we need fallbacks like that. I would suggest using a VPN if you are on such a network. The only downside with HTTP 2 & 3 is software support. If you are in Google, you probably already use it just because the load balancer supports it. With self hosted, you are dependent on whatever you are using adding support. I remember playing with SPDY way back on nginx for example. It wasn't that hard to get going and it made a difference for our mobile users (who are on shitty networks by default). With anything self hosted, security is indeed a key concern; especially if you are using alpha versions of new functionality like this which is what you would be doing effectively.
- francislavoie 5y ago
  Caddy maintainer here - we still have it marked experimental, not turned on by default. There's still some bugs. The actual HTTP/3 implementation comes from https://github.com/lucas-clemente/quic-go https://github.com/lucas-clemente/quic-go which essentially just has one maintainer at the moment. I'm hoping the Go HTTP team throws some effort on HTTP/3 sooner rather than later.
- buro9 5y ago
  > Caddy Benefited from Lucas https://clemente.io/ https://clemente.io/ ... full credit to him, and the various people who worked on the IETF test implementations that then became various production implementations. I don't credit Caddy with this as they were downstream and just received the good work done. Not that Caddy is bad, but singling them out ignores those that did the hard work. > Are there downsides to HTTP/3? When HTTP/2 came out there was discussions about why not to enable 1. HTTP/1 and HTTP/2 were natural rate limiters to your application... can your app cope when all requests arrive in a much shorter time window? The traffic pattern goes from somewhat smooth, to somewhat bursty and spikey. If your assets come from a dynamic endpoint or you have authorization on your endpoint that results in database lookups... you'll want to load test real world scenarios. 2. There are amplification potentials when you pass HTTP/3 through layers that map to HTTP/2 and HTTP/1 (the optimisations in the small payload to H3 are "undone" and amplify through H2 and H1 protocols) 3. HTTP/3 combined the transport protocol benefits and the HTTP protocol benefits with TLS benefits... all good, but it is harder for DDoS protection as proxies and middle boxes can no longer differentiate as easily the good traffic from the bad, and may not have visibility over what constitues good at all. Largely though... worth enabling. And for a good while the last of my points is mitigated by disabling H3 as you'll degrade to H2 cleanly.
  - francislavoie 5y ago
    For sure, as a Caddy maintainer, all credit goes to the contributors of https://github.com/lucas-clemente/quic-go https://github.com/lucas-clemente/quic-go. Early on this was mostly Lucas Clemente, but Marten Seemann has been the primary maintainer for quite a while now, including the transition from QUIC to HTTP/3. https://github.com/lucas-clemente/quic-go/graphs/contributors https://github.com/lucas-clemente/quic-go/graphs/contributor...
beebeepka 5y ago
Is it fast enough for first person shooters in the browser? That would be both awesome. hosting dedicated servers in a browser hehe
- johncolanduoni 5y ago
  WebTransport (still in development unfortunately) lets you send unreliable datagrams over HTTP/3, but there’s no reason for it to be any faster (or slower) than WebRTC’s SCTP support. Probably somewhat easier to support once more HTTP/3 libraries are out there since it’s not part of a massive standard like WebRTC.
Mizza 5y ago
Has anybody done a comparison with Aspera yet?
- jerven 5y ago
  I would love to see this as well. Or even plain compared to plain downloading from an FTP site. Especially for large files 10GB plus in size.
cakoose 5y ago
These charts should have the y-axis start at zero. As they are now, I have to convert the bars into numbers, then mentally compare the numbers, which defeats the point of charting them graphically. Though I guess I can compare the confidence intervals visually :-P
- omegalulw 5y ago
  Whenever I see y axes not start from zero on a marketing slide or blog alarm bells go off in my head. Tbf, I think for this blog the narrower range does help the first chart as you can 1) easily compare bounds 2) on the full scale they would be nearly at the same spot.
- eric_trackjs 5y ago
  Author here. If I were to do it again I would pick a different visualization. The intent was not to "lie" with statistics as other commenters here seem to think, it was to fit the data side by side and have it be reasonably visible. Lots of room for improvement next time I think.
bestinterest 5y ago
Quick question, if I have a VPS with cloudflare in front of it where the VPS runs a HTTP1.1 server is cloudflare limited to 6 http connections/resources to my server at a time?
- CasperDern 5y ago
  I do not know about cloudflare's internals, but I believe the 6 connections limit is purely a browser thing. So it should be able to do as many connections as it's able to handle.
  - bestinterest 5y ago
    Ah okay thats good news. Is it worth upgrading to HTTP2 on the server side for cloudflare if they are the only consumers of my VPS? They already enable HTTP/3 for clients but I'm wondering if I'm somehow bottlenecking them by not matching my server with HTTP/2 or HTTP/3.
    - johncolanduoni 5y ago
      According to their docs Cloudflare won’t connect to your origin servers with HTTP/2 or HTTP/3 anyway: https://support.cloudflare.com/hc/en-us/articles/200168076-Understanding-Cloudflare-HTTP-2-and-HTTP-3-Support https://support.cloudflare.com/hc/en-us/articles/200168076-U... In general connections between CDNs/reverse proxies and origin servers don’t get much benefit from HTTP/2 or HTTP/3. CDNs don’t generally care about connection establishment speed or multiplexing to the origin (the main benefits of newer HTTP versions), since they can just create and maintain N long-lived connections if they want to be able to send N concurrent requests. They generally only bother with HTTP/2 to the origin if they need to support gRPC, which has some unusual connection semantics.
- slig 5y ago
  If you configure your static files caching correctly, they will be served directly by Cloudflare in the fastest way possible given the user has a modern browser. You can use http://webpagetest.org/ http://webpagetest.org/ (or Chrome Dev Tools) and look for `cf-cache-status: HIT` header on the content that should be served directly by CF.
wcoenen 5y ago
I am a little confused about the test methodology. The post clearly explains that the big advantage of HTTP/3 is that it deals much better with IP packet loss. But then the tests are done without inducing (or at least measuring) packet loss? I guess the measured performance improvements here are mostly for the zero round-trip stuff then. But unless you understand how to analyze the security vs performance trade-off (I for one don't), that probably shouldn't be enabled.
- nix23 5y ago
  Also: >TLS 1.2 was used for HTTP/1.1 and HTTP/2 >TLS 1.3 was used for HTTP/3.
  - tialaramex 5y ago
    The latter is obligatory. HTTP/3 is a way of spelling the HTTP protocol over QUIC, and QUIC is implicitly doing TLS 1.3 (or later) cryptography. So the fairer comparison might be TLS 1.3 under all three, but if you need to upgrade why not upgrade the whole HTTP stack?
    - tsimionescu 5y ago
      > HTTP/3 is a way of spelling the HTTP protocol over QUIC HTTP/3 could perhaps be described as HTTP/2 over QUIC. It's still a very different protocol from HTTP/1.1, even if you were to ignore the transport being used - the way connections are managed is entirely different.
      - tialaramex 5y ago
        It's just spelling. It certainly wouldn't be better to think of it as HTTP/2 over QUIC since it works quite differently because it doesn't have an in-order protocol underneath it. HTTP has a bunch of semantics independent of how it's spelled and HTTP/3 preserves those with a new spelling and better performance
    - nix23 5y ago
ohgodplsno 5y ago
>If a web page requires 10 javascript files, the web browser needs to retrieve those 10 files before the page can finish loading. The author is _this close_ to realizing the problem. But no, we need Google to save us and release HTTP versions at the same rythm as their chrome releases so they can keep pushing 4MB of Javascript to serve ads on a shitty full-js website that could have been static.
- rswail 5y ago
  Replace "javascript" with "img" and the same applies. Has nothing to do with your theory that this is all a secret plot by Google to sell ads. It's more about why is a TCP connection so "heavy" compared to a QUIC/UDP connection that is providing similar reliability guarantees?
  - johncolanduoni 5y ago
    To be fair, this is 100% part of a not-so-secret plot by Google to sell ads more efficiently by making web browser connections faster.
  - ohgodplsno 5y ago
    > Replace "javascript" with "img" and the same applies. Absolutely not, images can be completely loaded in an async manner. Sure, you might have some content jump (unless you do your job and specify the image size ahead of time), but your content is still there. >Has nothing to do with your theory that this is all a secret plot by Google to sell ads. It's everything but secret, in the same way that AMP was a plot by Google to sell ads. Everything Google does is in the interest of collecting data and selling ads. Not a single one of their products doesn't have this in mind.
    - Dylan16807 5y ago
      Images are part of content.
  - goodpoint 5y ago
    > secret plot by Google to sell ads Not secret at all. Google developed a whole technological stack including a browser to do that.
kaetemi 5y ago
Parallel requests are nice, but is there a standard way to request larger files sequentially (explicitly wanting nicely pipelined head-of-line-blocking delivery)? Think streaming media, where you want chunks to arrive one after the other, without the second chunk hogging bandwidth while the first one is still downloading too.
- johncolanduoni 5y ago
  AFAIK HTTP/3 doesn’t send data out-of-order within a single stream any more than TCP does. So if you want a large file to be streamed with head-of-line blocking you just don’t send multiple range requests for it.
  - kaetemi 5y ago
    What I want is multiple large files (chunks being individual files in a stream) to arrive one after the other, without re-request gap, and without multiple files hogging bandwidth. (i.e. HTTP/1.1 Pipelining) It's easy with streaming video, when you can just time the requests at a fixed rate. But for stuff like streaming game assets, you never know how long each download will take. Doing parallel requests will just slow down the time for the first asset to appear, and doesn't guarantee that you fill the bandwidth anyway if the latency is high enough...
thenoblesunfish 5y ago
Obviously the sample sizes are too small to be concluding much in this direction but for fun, it looks like the HTTP/3 numbers have more outliers than the HTTP/2 numbers. Is that to be expected due to the nature of the new protocol or the experiment?
- undecisive 5y ago
  That was my initial takeaway. I suspect that the outlier is the initial connection / handshake, and that all subsequent requests were much faster thanks to the QUIC / 0-RTT session ticket. But I can't see anywhere this is mentioned explicitly, and those outliers are a fair bit worse than HTTP/2.
ppg677 5y ago
QUIC needs a kernel implementation. At least in Linux, TCP/IP does a lot of its processing in soft interrupt handlers which is far cheaper and more responsive to pre-empt compared to UDP packet delivery and wakeup to an application thread. You don't want your transport acknowledgement packets to get delayed/lost because of app thread scheduling.
- fulafel 5y ago
  This argument would benefit from quantitavie evidence showing impact on end2end application performance or server load.
  - ppg677 5y ago
    It is way less CPU efficient, with poor tail latency for LAN environments.
- qalmakka 5y ago
  It would also be great to have a standard API to create QUIC sockets, like BSD sockets on POSIX. It would make easy to swap implementations and port applications using QUIC to other systems, avoiding balcanization. I can see OSes integrating QUIC in their system libraries, and it would be great to avoid dozens of #ifdefs or relying on third party libraries.
- Klasiaster 5y ago
  You have to consider that an in-kernel implementation also hinders innovation - for example, things like BBR instead of Cubic/NewReno can be rolled out easily in userspace through the application's QUIC library while it takes a while until all clients and servers a) use a recent kernel which has TCP BBR support and b) have it configured by default.
  - Klasiaster 5y ago
    … and another bonus is that your QUIC implementation can be in a memory safe language and doesn't have to use C ;)
baybal2 5y ago
HTTP/3 IS NOT FAST. Very likely, smartphones, or wimpier laptops will not be able to benefit from the speed because of lack of anything like hardware TCP offloading which benefits HTTP 1.1.
- jillesvangurp 5y ago
  This literally is an article presenting benchmarks that demonstrate the exact opposite of what you are claiming. If you have benchmarks to contradict the findings, maybe you can share them?
  - drewg123 5y ago
    The article goes into very little detail regarding the client hardware and software. From "No other applications were running on the computer", one can assume it was a laptop or desktop. If you assume that it was a developer's laptop, then its probably not the "wimpy" laptop GP talked about, and certainly not a smartphone.
    - jillesvangurp 5y ago
      Why are you assuming mobile is somehow a problem here? Basically we're talking unreliable, high latency mobile networks here. That's kind of the sweet spot for this as TCP acknowledgement can take hundreds of milliseconds to seconds. Additionally, Google has been experimenting with this on Android for years with the express purpose of helping that use case.
      - baybal2 5y ago
        Them experimenting with this never mean they got correct conclusions from it. Google's management gets sane massaged data if their engineers want to forcefully push their projects.
        jillesvangurp 5y ago
        You mean correct conclusions like "it's faster & works as advertised", like this and other benchmarks for this seem to suggest? I don't understand people trying to argue that it's not faster without presenting any evidence whatsoever.
mojuba 5y ago
So servers will now have to support HTTP/3, HTTP/2, HTTP/1.1, HTTP/1.0 and HTTP/0.9. Is added complexity worth it though?
- remus 5y ago
  It's not a requirement to support all of them, unless there's some radical change in the landscape of the web I imagine clients will continue to support HTTP/1.1 for a long time to come.
  - mojuba 5y ago
    At least HTTP/1.x is the default for command line testing and debugging. I'm a bit worried we'll lose testability of servers as we add more and more layers on top of 1.x. Say it works with `curl` for me, what are the guarantees it will work the same way over HTTP/2 and /3 multiplexers?
    - jrockway 5y ago
      curl already supports HTTP/2 and HTTP/3. It's true that you miss out on "telnet example.com 80" and typing "GET /", but that honestly hasn't been valid since HTTP/1.1 replaced HTTP/1.0. To some extent this all sounds to me like "I hate screws, they render my trusty hammer obsolete". That's true, but there are also great screw driving tools.
      - NoGravitas 5y ago
        You could still do valid HTTP/1.1 over nc or telnet, or 'openssl s_client' if you needed TLS; it was just a matter of you knowing the protocol, and the minimum required headers for your use-case. (That said, curl is generally a better choice.)
        Dylan16807 5y ago
        > or 'openssl s_client' if you needed TLS Which sites tend to need. I'm sure someone can make an equivalent to that. Maybe even just a wrapper around curl...
bsjks 5y ago
It's 2021 and 80% of the load time is spent generating the page because of slow backend languages such as Python and then 20% of the load time is spent compiling and executing the frontend Javascript. I am sceptical that these improvements will even move the needle.
- progx 5y ago
  In 2021 we use caches.
  - bsjks 5y ago
    “In 2021 we present outdated information because we can’t stop choosing bad backend languages”
    - futharkshill 5y ago
      alternative: In 2021 we still use C et al. for our backend server, and we get hacked every single day. If I am going to leave a wide open door to my house, I at least want confidence that the house is not made out of cardboard
      - bsjks 5y ago
        That’s disingenuous. There are languages like php or JavaScript that are much much faster than Python and that don’t require you to give up the keys to your house.
        Dylan16807 5y ago
        Is it any more of an exaggeration than your post? Also pypy is fast, and the speed of php also heavily depends on version. Not that backend speed even makes a difference that much of the time. 3ms vs 8ms won't matter.
    - interactivecode 5y ago
      So what language do you use for cranking out enterprise crud apps and getting actual work done?
littlecranky67 5y ago
The benchmarks are not suitable to reach the conclusion that HTTP/3 is fast (or faster than HTTP/2). When you run such benchmarks, you choose a very fixed parameter vector (bandwidth, latency, link conditions that impact packet loss, payload shapes etc.). Running the same benchmark against a differently chosen parameter vector may result in the complete opposite conclusion. Additionally, the Internet is not a static system but a dynamic one. To say something is "fast", means that it should be fast for most people in most conditions. Sinle-link benchmarks are not feasible. I.e. in a traffic jam I will be very fast when I use the turn-out/emergency lane. But only as long as I am the only one doing it.
zigzag312 5y ago
Heads-up: graphs have non-zero baselines. Still, gains are quite impressive.
illys 5y ago
I am always amazed by new stuff claiming to be faster when the old stuff has worked perfectly since computers and networks were hundreds of times less performant. It seems to me just like another excuse to add complexity and to create more bloated websites. The Google homepage is 1.8 MB at initial load for an image, a field and 3 links, all the other major web operators are not better. Seriously, would they do such pages if they cared for being fast? [EDIT] For those not liking my comment, I should have said that it is in line with the conclusion of the article: "In general, the more resources your site requires, the bigger the performance improvement you’ll see". I am just questioning the benefit to help the inflation of website traffic, in the end the service is not better, just always heavier (the Google example above is just an illustration).
- profmonocle 5y ago
  > It seems to me just like another excuse to add complexity and to create more bloated websites. Arguably it's the other way around. Web sites were already getting extremely complex and bloated, so new protocols are attempting to restore performance that we've lost. I.E. one of the problems HTTP/2 tries to solve is sending multiple files in parallel over the same connection, to avoid the pitfalls of opening lots of simultaneous TCP sockets. This only became a major concern as web sites added more and more assets. It's definitely a vicious cycle though. It's reminiscent of what happens with hardware. Better hardware incentivizes inefficient software development, to the point where a modern messaging app might not even be usable on a PC from 2003, despite not having much more functionality than similar apps from the era.
lil_dispaches 5y ago
Wait, it's not about a new HTTP, but about replacing TCP? Isn't that a big deal? When did OP's browser start supporting QUIC?
sidcool 5y ago
This is impressive. The only issue I have faced in the past with HTTP/2 is the supported servers and browsers. It's not very reliable, and migrations are painful. Hopefully HTTP/3 will be seamless.
knorker 5y ago
Grrr, graphs that are not anchored at y=0. Beware reading these graphs.
ainar-g 5y ago
Quite ironically, the link doesn't work for me. Archive link: https://web.archive.org/web/20211201172207/https://requestmetrics.com/web-performance/http3-is-fast https://web.archive.org/web/20211201172207/https://requestme....
usrbinbash 5y ago
This comment is not specifically about quic, which I believe is a solid idea and would love to see used and supported more, but about the topic of requiring super fast connections to do things that really shouldn't need them. Accessing a page where all useful information I am interested in is text, should not require a new protocol developed by genius engineers to work without delay. If I want to read an article that is 50kB of text, it's not unreasonable to expect that information to be here before my finger leaves the ENTER key, regardless of how its transmitted. Why isn't that the case? Because said article is not transmitted with a dollop of html to structure it, and a sprinkle of CSS and JS to make it look nice. It's delivered to me buried in a mountain of extraneous garbage, pulled in from god-knows-where, mostly to spy on me or trying to sell me crap I don't need. I am not saying "don't invent new protocols". But maybe think about why it was perfectly possible to have functional, fast, and reliable webpages and applications in the 90s and early 00s, despite the fact that our networks and computers were little more than painted bricks and paper-mache by todays standards. https://idlewords.com/talks/website_obesity.htm https://idlewords.com/talks/website_obesity.htm If we don't think about this, then neither QUIC, nor QUIC2 or REALLY_QUIC will save us from being wading through a pool of molasses slow crap. Because inevitably, following each techical improvement that could makes our stack faster, is an even bigger pile of bloat that drags it down again.
- delusional 5y ago
  You already know this, but the "mountains of extraneous garbage" is the content. The text you care about is just there to make you download and execute the rest. quic is not needed to give you the text you want. It's needed to deliver the actual content, the ads.
  - Nemi 5y ago
    I agree that it is a greek tragedy that it always comes to this, but this is just the market’s way of monetizing the medium. This is how it happens. We used to sit through 20 minutes(!) of commercials every hour for tv content. Now we download one or two magnitudes more data than is required so that the content we actually want is “free”. Efficient markets will always devolve to this unfortunately. At least this (compared to unskippable commercials of past) I can bypass looking at.
jeroenhd 5y ago
The comparison isn't entirely fair because there's no reason not to use TLS 1.3 on HTTP 1 or HTTP/2 connections. The 0-RTT advantage of QUIC is also available to those protocols, which is one of the things the article claims make HTTP/3 faster. The methodology section also doesn't say if 0-RTT was actually enabled during testing. I'd argue that any system or website with an admin interface or user account system should not enable 0-RTT without very strict evaluation of their application protection mechanisms, making it useless for many API servers and data sources. It's fine for static content and that can help a lot, but with the benefit of multiplexing I'm not sure how useful it really is.
- johncolanduoni 5y ago
  This is true, though it’s worth mentioning that 0-RTT on TLS 1.3 + HTTP/2 still has one more roundtrip (for the TCP connection) than 0-RTT HTTP/3. Plus even if you don’t enable 0-RTT on either there’s still a one roundtrip difference in favor of HTTP/3, since it combines the (equivalent of) the TCP establishment roundtrip and the TLS handshake roundtrip. That’s the real advantage in connection establishment.
- lemagedurage 5y ago
  Yes, TLS1.3 cuts out a RTT compared to TLS1.2, but QUIC cuts out another RTT by combining the TCP and TLS handshakes into one. For a full handshake: TCP + TLS1.2: 3 RTT TCP + TLS1.3: 2 RTT QUIC including TLS1.3: 1 RTT And for subsequent connections: TCP + TLS1.3: 1 RTT QUIC including TLS1.3: 0 RTT (but no replay attack protection)
favourable 5y ago
Anyone know if this breaks on legacy hardware running legacy browsers? Yes people largely use modern hardware, but there's always eccentric folk with old hardware who like to browse the web on old browsers (for whatever reason).
- lemagedurage 5y ago
  Chrome supports HTTP/3 since November 2020. https://caniuse.com/http3 https://caniuse.com/http3 Typically servers support multiple HTTP versions.
  - shakna 5y ago
    But not supported by default by any mobile browser except Android's Chrome, making this more of a bleeding edge type situation on the client side of things.
JackFr 5y ago
That improvements are given in milliseconds rather than percent and charts aren’t anchored at zero tells me all I need to know.
- akyoan 5y ago
  How to Lie with Charts 101
  - authed 5y ago
    s/Lie/deceive
    - tgv 5y ago
      It's a reference to this book: https://en.wikipedia.org/wiki/How_to_Lie_with_Statistics https://en.wikipedia.org/wiki/How_to_Lie_with_Statistics
- tester34 5y ago
  What do you mean, what's wrong with those charts? Would there be some better/more precise information shown if they were anchored at 0?
  - vlmutolo 5y ago
    See my comment here: https://news.ycombinator.com/item?id=29567067 https://news.ycombinator.com/item?id=29567067
- deleted 5y ago
  [deleted]
deleted 5y ago
[deleted]
anotherhue 5y ago
Just in time for Web3!
hutrdvnj 5y ago
How much packet loss does average internet traffic has on average?
tambourine_man 5y ago
What’s great about HTTP 1.1 is it’s simplicity. I mean, you can explain it to a complete newby and have that person write a functioning implementation in a few lines of shell script, all in one afternoon. In fact, you can probably figure it out by yourself just by looking at what goes across the wire. And yet, it runs the whole modern world. That’s beautiful. I think simplicity is underrated and it’s something I really value when choosing the tools I use.
- tambourine_man 5y ago
  I’m pretty sure I’ll never understand QUIC completely in my lifetime. I do know HTTP 1.1 through and through (it’s really easy). The fact that HTTP 1.1 speeds are even comparable, let alone faster in some situations, should at least tip the scale in its favor.
  - arpa 5y ago
    obscure standards mean less possibility that someone else without google-scale resources will implement their own client/server.
    - ocdtrekkie 5y ago
      And that is one of the key "benefits" of HTTP/3 if you're a Google-scale company.
    - bayesian_horse 5y ago
      Except there are already several such implementations and nobody is going to deprecate older HTTP versions.
      - giantrobot 5y ago
        Chrome has an overwhelming portion of the web browser installed base. It's full of dark patterns and scary warnings about "dangerous" things like unencrypted HTTP. I don't have a lot of faith that they're not going to disable older HTTP versions at some point.
beckerdo 5y ago
There are a few outliers in the HTTP/3 graphs that are slower than the HTTP/2 graphs. I might have missed it, but I don't think the outliers were explained.
bullen 5y ago
3x is nothing, 10x or 100x and we're talking. The only real bottleneck we're going to have is CPU, so they should compare that. Everytime humans make an improvement we scale up to fill that benefit: https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox
ch17z 5y ago
requestmetrics.com: Blocked by 1Hosts (Lite), AdGuard DNS filter, AdGuard Tracking Protection filter, EasyPrivacy and oisd.
- toddgardner 5y ago
  Request Metrics is not an advertiser, does not track individuals, and complies with the EFF dnt policy. Ad block lists are way too aggressive--all it takes is some random person to put you on the list and it's hard to get off of it.
eric_trackjs 5y ago
Author here. I am seeing a lot of comments about how the graphs are not anchored at 0. The intent with the graphs was not to "lie" or "mislead" but to fit the data in a way that was mostly readable side by side. The goal was to show the high level change, in a glanceable way, not to get in to individual millisecond comparisons. However, in the future I would pick a different visualization I think :) The benchmarking has also come under fire. My goal was to just to put the same site/assets on three different continents and retrieve them a bunch of times. No more, no less. I think the results are still interesting, personally. Clean room benchmarks are cool, but so are real world tests, imo. Finally, there was no agenda with this post to push HTTP/3 over HTTP/2. I was actually skeptical that HTTP/3 made any kind of difference based on my experience with 1.1 to 2. I expected to write a post about "HTTP/3 is not any better than HTTP/2" and was frankly surprised that it was so much faster in my tests.
- aquadrop 5y ago
  Thanks for the article. But the goal of the graphs should be to show level of change and let graph speak for itself, if it's high or low. If they were anchored at 0 it would actually allow to see visual difference and for me personally it would be "way that was mostly readable side by side".
- kzrdude 5y ago
  The missing part of the axis, down to 0, is just 1/9th of the current length, so I think it's absolutely the wrong trade-off to cut the y-axis.
- posix_me_less 5y ago
  Could it be simply because UDP packets may be treated with higher priority by all the middleman machines? UDP is used by IP phones, video conferences, etc.
  - digikata 5y ago
    Because of the use of UDP, I wonder the variation could end up being wider. There are some large outliers on the chart (though that could be an implementation maturity issue). Also I wonder if the routing environment will continue to be the same in terms of prioritization if http/3 becomes more common. There might be some motivation to slow down http/3 to prioritize traditional udp real-time uses.
markdog12 5y ago
Anyone interested in HTTP 3 that likes even-handed articles, Robin Marx has an excellent series on Smashing Magazine: https://www.smashingmagazine.com/author/robin-marx/ https://www.smashingmagazine.com/author/robin-marx/ The second article is about its performance.
mgaunard 5y ago
So I understand how multiplexing everything through a single TCP session is a bad idea. But what was the problem with using multiple TCP sessions like HTTP 1.1 does? Is it just the problem that there is a latency cost to establishing the connection (even though those sessions are reused later on)? How about extending TCP to establish multiple sessions at once instead?
- vlmutolo 5y ago
  I think it's just that hundreds of TCP connections per user can really bog down the servers. Individual TCP connections are much more expensive than QUIC streams. QUIC also handles things like transparent IP-address switching (on either side of the connection).
  - mgaunard 5y ago
    There is no difference in server overhead, the amount of state to maintain and data received/sent is the same. Also nothing prevents the server from implementing TCP in userland, apart from maybe security concerns, but then if you want low latency you have to discard those anyway.
    - deleted 5y ago
      [deleted]
- jayd16 5y ago
  Extending TCP is considered infeasible due to its pervasiveness and the calcification of it across the ecosystem. Implementing a new protocol is also considered infeasible for similar reasons. So they arrived at a new protocol over UDP to implement new features.
heftig 5y ago
I've deactivated HTTP/3 in Firefox as the bandwidth from CloudFlare to my provider (German Telecom) gets ridiculously bad (downloading a 6 MB file takes 25 s instead of 0.6 s) during peak times, and I only see this when using HTTP/3 over IPv4, all other combinations stay fast.
deleted 5y ago
[deleted]
aquadrop 5y ago
Regardless of the results, that is very disingenuous way of showing up charts, like floor being ~1000 and first result having 2500 score and second 1000, basically being on the floor, even though real difference is 2.5 times.
- deleted 5y ago
  [deleted]
amenod 5y ago
> The 0-RTT feature in QUIC allows a client to send application data before the handshake is complete. This is made possible by reusing negotiated parameters from a previous connection. To enable this, 0-RTT depends on the client remembering critical parameters and providing the server with a TLS session ticket that allows the server to recover the same information. Am I missing something, or is this yet another way to track clients across visits? If so, I'm sure Chrome will be faster than Firefox (because it will keep the sessions IDs live forever). Well played, Google.
- stusmall 5y ago
  There are features that go back a ways in TLS that someone could use for tracking. A while back I wrote a quick and dirty POC for using TLS 1.2 session resumption for sub-NAT user tracking[1]. While it is really effective at separating out multiple different users interacting with a server from behind a NAT, I'm not sure these features are usable for cross site tracking. I'm not familiar with 0-RTT but sessions resumption scoped tickets to a host so it wouldn't be useful there. While someone could use it for some tracking purposes it really is a huge performance boon. There are good intentions on why these features were put in even if they can be abused. 1. https://stuartsmall.com/tlsslides.odp https://stuartsmall.com/tlsslides.odp https://github.com/stusmall/rustls/commit/e8a88d87a74d5630227ea330cc4bf3fae8727b8e https://github.com/stusmall/rustls/commit/e8a88d87a74d563022...
  - youngtaff 5y ago
    Session resumption could be used for cross-site tracking As a mitigation Chrome (and FF?) have started to partition connections so a different connection would be used to a common 3rd party from different top level origins
fmiras 5y ago
Awesome post!
bawolff 5y ago
> TLS 1.2 was used for HTTP/1.1 and HTTP/2 > TLS 1.3 was used for HTTP/3. > 0-RTT was enabled for all HTTP/3 connections Ok then. No potential confounding variables there... none at all. [For reference its expected that tls1.3 with 0-rtt is going to be much faster than tls1.2 especially when fetching small documents from geographically far away places. To be clear, not doubting that http/3 gives performance improvements in some network conditions, this is just a really bad test and tls version is probably a good portion of the difference here]
est 5y ago
Is it possible to host a UDP only h3 site without the 443 tcp?
- heftig 5y ago
  Yes, I believe this is possible with the HTTPS DNS records defined in https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-08.html https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-...
AtlasBarfed 5y ago
I have seen SO MANY "reliable UDP" transports written instead of TCP over the decades. Off the top of my head: TIBCO, SaltStack, various games have bespoke UDP / TCP hybrids IIRC. Is TCP really that fundamentally slow? How could high-level repurposes of UDP be faster than presumably hardware optimized and heavily analyzed TCP stacks? The lies, damn lies, benchmarks seems a bit applicable too here. He's disabling caching? Really it is testing a specific transport situation, but caching IMO would mitigate a lot of the dramatic advantages? And what about cloudflare edge caching outside the browser? I think he was routing all resource requests through his single server that probably isn't cached properly. So with good caching will HTTP/3 produce the advantage for the everyman over HTTP/1.1 to justify the attention?
- Dylan16807 5y ago
  You can't control TCP very well, and you can't do anything about head-of-line blocking. So yes, for lots of circumstances it's easy to beat TCP. Importantly, a custom protocol over UDP can do things that are incompatible with 30 year old TCP implementations. And you don't need hardware optimization until you're getting into many gigabits per second.
ericls 5y ago
In practice, you'll have load balancers and reverse proxies some where in between your server and your client. Does HTTP/3 still make a difference in these cases?
KronisLV 5y ago
> It would be 18 more years before a new version of HTTP was released. In 2015, and with much fanfare, RFC 7540 would standardize HTTP/2 as the next major version of the protocol. Huh, this is interesting. So the current timescale is like: HTTP/1: 1996 (though HTTP/1.1 came out in 1997) HTTP/2: 2015 HTTP/3: 2021 (current draft) Should we expect HTTP/4 around 2022 or 2023, at this increasing rate of progress, then? Just a bit of extrapolation, since it seems like the rate of progress and new versions to deal with is increasing. Promising, but possibly worrying.
- azlen 5y ago
  From what I've read about it, one of the exciting things about QUIC and HTTP/3 is that they're much more extensible. Meaning anyone might be able to dabble and experiment with their own version of the protocol. So yes, I'd think the rate of progress may well increase. Not all will become standards, but I imagine we might see HTTP/3.1, 3.2, etc. long before we see an entirely new version like HTTP/4
Animats 5y ago
This is a bigger performance difference that Google reported. Is the packet loss rate being measured? That's the main cause of head-of-line blocking delays. Are both ends using persistent TCP connections? If you have to re-open and redo the TLS crypto handshake each time, that's a huge overhead. Does Caddy implement that? Is the CONTENT-LENGTH header set? If not, each asset is a fresh TCP connection.
twsted 5y ago
I don’t see any graph in Safari
ArchOversight 5y ago
Just as a heads up, if you are viewing the site in Safari, you will not see the graphs and images as lazy loading is not yet supported. https://caniuse.com/loading-lazy-attr https://caniuse.com/loading-lazy-attr You can manually enable it if you have Developer mode enabled with: Develop -> Experimental Features -> Lazy Image Loading
- ksec 5y ago
  12 Hours and 255 Comments, You can guess most on HN dont use Safari. Thanks for the tip.
  - galonk 5y ago
    I just assumed they were broken or that the image server was slashdotted.
  - chuckhoupt 5y ago
    I think this was a bug in the site, which appears to now been fixed.
- youngtaff 5y ago
  Guessing there must be some broken implementation of lazy loading on the site using JS etc. If they just used loading=lazy on the images Safari should ignore it and so all images should load
  - ArchOversight 5y ago
    They used data-src instead of just a src attribute on the image. So Safari parses it as: <img />
tiffanyh 5y ago
Cloudflare has interesting results as well. Though not as dramatic as this blog. > “ On average, with HTTP/3 we see the first byte appearing after 176ms. With HTTP/2 we see 201ms, meaning HTTP/3 is already performing 12.4% better!” https://blog.cloudflare.com/http-3-vs-http-2/ https://blog.cloudflare.com/http-3-vs-http-2/

445 points by SerCe 5y ago

200ms faster than WHAT? Edit: Ok, apparently there are charts that are not being loaded due to the HN Effect. A clear example of how a blind reader would miss quite a bit of information when the data is only shown in images / other non A11Y compliant resources.

avereveard 5y ago
Comparing HTTP/2 and HTTP/3 protocol versions when loading pages from NY HTTP/3 is: 200ms faster for the Small Site 325ms faster for the Content Site 300ms faster for the Single Page Application it seems a text only extraction of the section in object remains perfectly intelligible
ksec 5y ago
>Edit: Ok, apparently there are charts that are not being loaded due to the HN Effect. No it doesn't work on Safari only. Turn on Lazy Image loading or use other browser.

phicoh 5y ago

It is nice to see the effect of 0-RTT in QUIC. In quite a few graphs the HTTP3 times for the small Site has one dot roughly at the same level as HTTP2. This probably the first connection. The rest gets 0-RTT.

sam_goody 5y ago

Full kudos to Caddy for being the first out the door with working HTTP/3 support. Are there downsides to HTTP/3? When HTTP/2 came out there was discussions about why not to enable.

ardit33 5y ago
We will know over time. HTTP/3 is fixing all shortcomings of HTTP/2, which was pretty flawed. It uses UDP though, and UDP itself can be blocked by many firewalls, and folks/companies have to update firewalls and routers for it to work properly. So, that's its major weakness (eg. some workplaces block all egress UDP packets). https://news.ycombinator.com/item?id=27402222 https://news.ycombinator.com/item?id=27402222 As the article says, HTTP3 is pretty fast when there are high latencies/high loss scenarios. It will be interesting to see how it performs in a mobile setting. 4G and 5G networks have their own/specific optimizations that are different than a desktop world. eg. http keep alives were never respected, etc. (connections would be closed if there was no continuous activity). But, given the test, it 'should' be much faster than http 1.1 One think is for sure: HTTP 1.1 is going to still be used, even 100 years from now. It is like FM Radio, which is both good enough for most cases, and very simple and convenient at the same time.
- josefx 5y ago
  I can't wait for all the HTTP/3 -> HTTP/2 -> HTTP/1 tunneling and other exploits that will appear in all the rushed implementations. We already saw how that worked with HTTP/2 and people tried to rush OpenSSL into adopting an experimental implementation of QUIC while Google was still hashing out the spec. . I would suggest disabling HTTP/3 for the next 10 or so years and give everyone else the chance to burn through the exploits.
  - johncolanduoni 5y ago
    Thankfully HTTP/3 didn’t change request/header semantics much from HTTP/2, at least nowhere near the level of the HTTP/1 -> HTTP/2 changes.
- ithkuil 5y ago
  Do you have a link at hand describing the main shortcomings of http/2 (that http/3 fixes)?
Jleagle 5y ago
I am using it with traefik too.
jeroenhd 5y ago
I know of at least one ISP that plain blocks outgoing UDP/443 or at least messes with the packets, so I wouldn't rely on its availability. I'm also hesitant about HTTP/2 and 3 because of their complexity, but if you trust the systems and libraries underlying your server I don't see any problem in activating either. Just watch out with features like 0-RTT that can have a security impact and you should be fine.
- jillesvangurp 5y ago
  It will likely just fallback to http on networks like that. Shitty ISPs and corporate networks are why we need fallbacks like that. I would suggest using a VPN if you are on such a network. The only downside with HTTP 2 & 3 is software support. If you are in Google, you probably already use it just because the load balancer supports it. With self hosted, you are dependent on whatever you are using adding support. I remember playing with SPDY way back on nginx for example. It wasn't that hard to get going and it made a difference for our mobile users (who are on shitty networks by default). With anything self hosted, security is indeed a key concern; especially if you are using alpha versions of new functionality like this which is what you would be doing effectively.
francislavoie 5y ago
Caddy maintainer here - we still have it marked experimental, not turned on by default. There's still some bugs. The actual HTTP/3 implementation comes from https://github.com/lucas-clemente/quic-go https://github.com/lucas-clemente/quic-go which essentially just has one maintainer at the moment. I'm hoping the Go HTTP team throws some effort on HTTP/3 sooner rather than later.
buro9 5y ago
> Caddy Benefited from Lucas https://clemente.io/ https://clemente.io/ ... full credit to him, and the various people who worked on the IETF test implementations that then became various production implementations. I don't credit Caddy with this as they were downstream and just received the good work done. Not that Caddy is bad, but singling them out ignores those that did the hard work. > Are there downsides to HTTP/3? When HTTP/2 came out there was discussions about why not to enable 1. HTTP/1 and HTTP/2 were natural rate limiters to your application... can your app cope when all requests arrive in a much shorter time window? The traffic pattern goes from somewhat smooth, to somewhat bursty and spikey. If your assets come from a dynamic endpoint or you have authorization on your endpoint that results in database lookups... you'll want to load test real world scenarios. 2. There are amplification potentials when you pass HTTP/3 through layers that map to HTTP/2 and HTTP/1 (the optimisations in the small payload to H3 are "undone" and amplify through H2 and H1 protocols) 3. HTTP/3 combined the transport protocol benefits and the HTTP protocol benefits with TLS benefits... all good, but it is harder for DDoS protection as proxies and middle boxes can no longer differentiate as easily the good traffic from the bad, and may not have visibility over what constitues good at all. Largely though... worth enabling. And for a good while the last of my points is mitigated by disabling H3 as you'll degrade to H2 cleanly.
- francislavoie 5y ago
  For sure, as a Caddy maintainer, all credit goes to the contributors of https://github.com/lucas-clemente/quic-go https://github.com/lucas-clemente/quic-go. Early on this was mostly Lucas Clemente, but Marten Seemann has been the primary maintainer for quite a while now, including the transition from QUIC to HTTP/3. https://github.com/lucas-clemente/quic-go/graphs/contributors https://github.com/lucas-clemente/quic-go/graphs/contributor...

beebeepka 5y ago

Is it fast enough for first person shooters in the browser? That would be both awesome. hosting dedicated servers in a browser hehe

johncolanduoni 5y ago
WebTransport (still in development unfortunately) lets you send unreliable datagrams over HTTP/3, but there’s no reason for it to be any faster (or slower) than WebRTC’s SCTP support. Probably somewhat easier to support once more HTTP/3 libraries are out there since it’s not part of a massive standard like WebRTC.

Mizza 5y ago

Has anybody done a comparison with Aspera yet?

jerven 5y ago
I would love to see this as well. Or even plain compared to plain downloading from an FTP site. Especially for large files 10GB plus in size.

cakoose 5y ago

These charts should have the y-axis start at zero. As they are now, I have to convert the bars into numbers, then mentally compare the numbers, which defeats the point of charting them graphically. Though I guess I can compare the confidence intervals visually :-P

omegalulw 5y ago
Whenever I see y axes not start from zero on a marketing slide or blog alarm bells go off in my head. Tbf, I think for this blog the narrower range does help the first chart as you can 1) easily compare bounds 2) on the full scale they would be nearly at the same spot.
eric_trackjs 5y ago
Author here. If I were to do it again I would pick a different visualization. The intent was not to "lie" with statistics as other commenters here seem to think, it was to fit the data side by side and have it be reasonably visible. Lots of room for improvement next time I think.

bestinterest 5y ago

Quick question, if I have a VPS with cloudflare in front of it where the VPS runs a HTTP1.1 server is cloudflare limited to 6 http connections/resources to my server at a time?

CasperDern 5y ago
I do not know about cloudflare's internals, but I believe the 6 connections limit is purely a browser thing. So it should be able to do as many connections as it's able to handle.
- bestinterest 5y ago
  Ah okay thats good news. Is it worth upgrading to HTTP2 on the server side for cloudflare if they are the only consumers of my VPS? They already enable HTTP/3 for clients but I'm wondering if I'm somehow bottlenecking them by not matching my server with HTTP/2 or HTTP/3.
  - johncolanduoni 5y ago
    According to their docs Cloudflare won’t connect to your origin servers with HTTP/2 or HTTP/3 anyway: https://support.cloudflare.com/hc/en-us/articles/200168076-Understanding-Cloudflare-HTTP-2-and-HTTP-3-Support https://support.cloudflare.com/hc/en-us/articles/200168076-U... In general connections between CDNs/reverse proxies and origin servers don’t get much benefit from HTTP/2 or HTTP/3. CDNs don’t generally care about connection establishment speed or multiplexing to the origin (the main benefits of newer HTTP versions), since they can just create and maintain N long-lived connections if they want to be able to send N concurrent requests. They generally only bother with HTTP/2 to the origin if they need to support gRPC, which has some unusual connection semantics.
slig 5y ago
If you configure your static files caching correctly, they will be served directly by Cloudflare in the fastest way possible given the user has a modern browser. You can use http://webpagetest.org/ http://webpagetest.org/ (or Chrome Dev Tools) and look for `cf-cache-status: HIT` header on the content that should be served directly by CF.

wcoenen 5y ago

I am a little confused about the test methodology. The post clearly explains that the big advantage of HTTP/3 is that it deals much better with IP packet loss. But then the tests are done without inducing (or at least measuring) packet loss? I guess the measured performance improvements here are mostly for the zero round-trip stuff then. But unless you understand how to analyze the security vs performance trade-off (I for one don't), that probably shouldn't be enabled.

nix23 5y ago
Also: >TLS 1.2 was used for HTTP/1.1 and HTTP/2 >TLS 1.3 was used for HTTP/3.
- tialaramex 5y ago
  The latter is obligatory. HTTP/3 is a way of spelling the HTTP protocol over QUIC, and QUIC is implicitly doing TLS 1.3 (or later) cryptography. So the fairer comparison might be TLS 1.3 under all three, but if you need to upgrade why not upgrade the whole HTTP stack?
  - tsimionescu 5y ago
    > HTTP/3 is a way of spelling the HTTP protocol over QUIC HTTP/3 could perhaps be described as HTTP/2 over QUIC. It's still a very different protocol from HTTP/1.1, even if you were to ignore the transport being used - the way connections are managed is entirely different.
    - tialaramex 5y ago
      It's just spelling. It certainly wouldn't be better to think of it as HTTP/2 over QUIC since it works quite differently because it doesn't have an in-order protocol underneath it. HTTP has a bunch of semantics independent of how it's spelled and HTTP/3 preserves those with a new spelling and better performance
  - nix23 5y ago

ohgodplsno 5y ago

>If a web page requires 10 javascript files, the web browser needs to retrieve those 10 files before the page can finish loading. The author is _this close_ to realizing the problem. But no, we need Google to save us and release HTTP versions at the same rythm as their chrome releases so they can keep pushing 4MB of Javascript to serve ads on a shitty full-js website that could have been static.

rswail 5y ago
Replace "javascript" with "img" and the same applies. Has nothing to do with your theory that this is all a secret plot by Google to sell ads. It's more about why is a TCP connection so "heavy" compared to a QUIC/UDP connection that is providing similar reliability guarantees?
- johncolanduoni 5y ago
  To be fair, this is 100% part of a not-so-secret plot by Google to sell ads more efficiently by making web browser connections faster.
- ohgodplsno 5y ago
  > Replace "javascript" with "img" and the same applies. Absolutely not, images can be completely loaded in an async manner. Sure, you might have some content jump (unless you do your job and specify the image size ahead of time), but your content is still there. >Has nothing to do with your theory that this is all a secret plot by Google to sell ads. It's everything but secret, in the same way that AMP was a plot by Google to sell ads. Everything Google does is in the interest of collecting data and selling ads. Not a single one of their products doesn't have this in mind.
  - Dylan16807 5y ago
    Images are part of content.
- goodpoint 5y ago
  > secret plot by Google to sell ads Not secret at all. Google developed a whole technological stack including a browser to do that.

kaetemi 5y ago

Parallel requests are nice, but is there a standard way to request larger files sequentially (explicitly wanting nicely pipelined head-of-line-blocking delivery)? Think streaming media, where you want chunks to arrive one after the other, without the second chunk hogging bandwidth while the first one is still downloading too.

johncolanduoni 5y ago
AFAIK HTTP/3 doesn’t send data out-of-order within a single stream any more than TCP does. So if you want a large file to be streamed with head-of-line blocking you just don’t send multiple range requests for it.
- kaetemi 5y ago
  What I want is multiple large files (chunks being individual files in a stream) to arrive one after the other, without re-request gap, and without multiple files hogging bandwidth. (i.e. HTTP/1.1 Pipelining) It's easy with streaming video, when you can just time the requests at a fixed rate. But for stuff like streaming game assets, you never know how long each download will take. Doing parallel requests will just slow down the time for the first asset to appear, and doesn't guarantee that you fill the bandwidth anyway if the latency is high enough...

thenoblesunfish 5y ago

Obviously the sample sizes are too small to be concluding much in this direction but for fun, it looks like the HTTP/3 numbers have more outliers than the HTTP/2 numbers. Is that to be expected due to the nature of the new protocol or the experiment?

undecisive 5y ago
That was my initial takeaway. I suspect that the outlier is the initial connection / handshake, and that all subsequent requests were much faster thanks to the QUIC / 0-RTT session ticket. But I can't see anywhere this is mentioned explicitly, and those outliers are a fair bit worse than HTTP/2.

ppg677 5y ago

QUIC needs a kernel implementation. At least in Linux, TCP/IP does a lot of its processing in soft interrupt handlers which is far cheaper and more responsive to pre-empt compared to UDP packet delivery and wakeup to an application thread. You don't want your transport acknowledgement packets to get delayed/lost because of app thread scheduling.

fulafel 5y ago
This argument would benefit from quantitavie evidence showing impact on end2end application performance or server load.
- ppg677 5y ago
  It is way less CPU efficient, with poor tail latency for LAN environments.
qalmakka 5y ago
It would also be great to have a standard API to create QUIC sockets, like BSD sockets on POSIX. It would make easy to swap implementations and port applications using QUIC to other systems, avoiding balcanization. I can see OSes integrating QUIC in their system libraries, and it would be great to avoid dozens of #ifdefs or relying on third party libraries.
Klasiaster 5y ago
You have to consider that an in-kernel implementation also hinders innovation - for example, things like BBR instead of Cubic/NewReno can be rolled out easily in userspace through the application's QUIC library while it takes a while until all clients and servers a) use a recent kernel which has TCP BBR support and b) have it configured by default.
- Klasiaster 5y ago
  … and another bonus is that your QUIC implementation can be in a memory safe language and doesn't have to use C ;)

baybal2 5y ago

HTTP/3 IS NOT FAST. Very likely, smartphones, or wimpier laptops will not be able to benefit from the speed because of lack of anything like hardware TCP offloading which benefits HTTP 1.1.

jillesvangurp 5y ago
This literally is an article presenting benchmarks that demonstrate the exact opposite of what you are claiming. If you have benchmarks to contradict the findings, maybe you can share them?
- drewg123 5y ago
  The article goes into very little detail regarding the client hardware and software. From "No other applications were running on the computer", one can assume it was a laptop or desktop. If you assume that it was a developer's laptop, then its probably not the "wimpy" laptop GP talked about, and certainly not a smartphone.
  - jillesvangurp 5y ago
    Why are you assuming mobile is somehow a problem here? Basically we're talking unreliable, high latency mobile networks here. That's kind of the sweet spot for this as TCP acknowledgement can take hundreds of milliseconds to seconds. Additionally, Google has been experimenting with this on Android for years with the express purpose of helping that use case.
    - baybal2 5y ago
      Them experimenting with this never mean they got correct conclusions from it. Google's management gets sane massaged data if their engineers want to forcefully push their projects.
      - jillesvangurp 5y ago
        You mean correct conclusions like "it's faster & works as advertised", like this and other benchmarks for this seem to suggest? I don't understand people trying to argue that it's not faster without presenting any evidence whatsoever.

mojuba 5y ago

So servers will now have to support HTTP/3, HTTP/2, HTTP/1.1, HTTP/1.0 and HTTP/0.9. Is added complexity worth it though?

remus 5y ago
It's not a requirement to support all of them, unless there's some radical change in the landscape of the web I imagine clients will continue to support HTTP/1.1 for a long time to come.
- mojuba 5y ago
  At least HTTP/1.x is the default for command line testing and debugging. I'm a bit worried we'll lose testability of servers as we add more and more layers on top of 1.x. Say it works with `curl` for me, what are the guarantees it will work the same way over HTTP/2 and /3 multiplexers?
  - jrockway 5y ago
    curl already supports HTTP/2 and HTTP/3. It's true that you miss out on "telnet example.com 80" and typing "GET /", but that honestly hasn't been valid since HTTP/1.1 replaced HTTP/1.0. To some extent this all sounds to me like "I hate screws, they render my trusty hammer obsolete". That's true, but there are also great screw driving tools.
    - NoGravitas 5y ago
      You could still do valid HTTP/1.1 over nc or telnet, or 'openssl s_client' if you needed TLS; it was just a matter of you knowing the protocol, and the minimum required headers for your use-case. (That said, curl is generally a better choice.)
      - Dylan16807 5y ago
        > or 'openssl s_client' if you needed TLS Which sites tend to need. I'm sure someone can make an equivalent to that. Maybe even just a wrapper around curl...

bsjks 5y ago

It's 2021 and 80% of the load time is spent generating the page because of slow backend languages such as Python and then 20% of the load time is spent compiling and executing the frontend Javascript. I am sceptical that these improvements will even move the needle.

progx 5y ago
In 2021 we use caches.
- bsjks 5y ago
  “In 2021 we present outdated information because we can’t stop choosing bad backend languages”
  - futharkshill 5y ago
    alternative: In 2021 we still use C et al. for our backend server, and we get hacked every single day. If I am going to leave a wide open door to my house, I at least want confidence that the house is not made out of cardboard
    - bsjks 5y ago
      That’s disingenuous. There are languages like php or JavaScript that are much much faster than Python and that don’t require you to give up the keys to your house.
      - Dylan16807 5y ago
        Is it any more of an exaggeration than your post? Also pypy is fast, and the speed of php also heavily depends on version. Not that backend speed even makes a difference that much of the time. 3ms vs 8ms won't matter.
  - interactivecode 5y ago
    So what language do you use for cranking out enterprise crud apps and getting actual work done?

littlecranky67 5y ago

The benchmarks are not suitable to reach the conclusion that HTTP/3 is fast (or faster than HTTP/2). When you run such benchmarks, you choose a very fixed parameter vector (bandwidth, latency, link conditions that impact packet loss, payload shapes etc.). Running the same benchmark against a differently chosen parameter vector may result in the complete opposite conclusion. Additionally, the Internet is not a static system but a dynamic one. To say something is "fast", means that it should be fast for most people in most conditions. Sinle-link benchmarks are not feasible. I.e. in a traffic jam I will be very fast when I use the turn-out/emergency lane. But only as long as I am the only one doing it.

zigzag312 5y ago

Heads-up: graphs have non-zero baselines. Still, gains are quite impressive.

illys 5y ago

I am always amazed by new stuff claiming to be faster when the old stuff has worked perfectly since computers and networks were hundreds of times less performant. It seems to me just like another excuse to add complexity and to create more bloated websites. The Google homepage is 1.8 MB at initial load for an image, a field and 3 links, all the other major web operators are not better. Seriously, would they do such pages if they cared for being fast? [EDIT] For those not liking my comment, I should have said that it is in line with the conclusion of the article: "In general, the more resources your site requires, the bigger the performance improvement you’ll see". I am just questioning the benefit to help the inflation of website traffic, in the end the service is not better, just always heavier (the Google example above is just an illustration).

profmonocle 5y ago
> It seems to me just like another excuse to add complexity and to create more bloated websites. Arguably it's the other way around. Web sites were already getting extremely complex and bloated, so new protocols are attempting to restore performance that we've lost. I.E. one of the problems HTTP/2 tries to solve is sending multiple files in parallel over the same connection, to avoid the pitfalls of opening lots of simultaneous TCP sockets. This only became a major concern as web sites added more and more assets. It's definitely a vicious cycle though. It's reminiscent of what happens with hardware. Better hardware incentivizes inefficient software development, to the point where a modern messaging app might not even be usable on a PC from 2003, despite not having much more functionality than similar apps from the era.

lil_dispaches 5y ago

Wait, it's not about a new HTTP, but about replacing TCP? Isn't that a big deal? When did OP's browser start supporting QUIC?

sidcool 5y ago

This is impressive. The only issue I have faced in the past with HTTP/2 is the supported servers and browsers. It's not very reliable, and migrations are painful. Hopefully HTTP/3 will be seamless.

knorker 5y ago

Grrr, graphs that are not anchored at y=0. Beware reading these graphs.

ainar-g 5y ago

Quite ironically, the link doesn't work for me. Archive link: https://web.archive.org/web/20211201172207/https://requestmetrics.com/web-performance/http3-is-fast https://web.archive.org/web/20211201172207/https://requestme....

usrbinbash 5y ago

This comment is not specifically about quic, which I believe is a solid idea and would love to see used and supported more, but about the topic of requiring super fast connections to do things that really shouldn't need them. Accessing a page where all useful information I am interested in is text, should not require a new protocol developed by genius engineers to work without delay. If I want to read an article that is 50kB of text, it's not unreasonable to expect that information to be here before my finger leaves the ENTER key, regardless of how its transmitted. Why isn't that the case? Because said article is not transmitted with a dollop of html to structure it, and a sprinkle of CSS and JS to make it look nice. It's delivered to me buried in a mountain of extraneous garbage, pulled in from god-knows-where, mostly to spy on me or trying to sell me crap I don't need. I am not saying "don't invent new protocols". But maybe think about why it was perfectly possible to have functional, fast, and reliable webpages and applications in the 90s and early 00s, despite the fact that our networks and computers were little more than painted bricks and paper-mache by todays standards. https://idlewords.com/talks/website_obesity.htm https://idlewords.com/talks/website_obesity.htm If we don't think about this, then neither QUIC, nor QUIC2 or REALLY_QUIC will save us from being wading through a pool of molasses slow crap. Because inevitably, following each techical improvement that could makes our stack faster, is an even bigger pile of bloat that drags it down again.

delusional 5y ago
You already know this, but the "mountains of extraneous garbage" is the content. The text you care about is just there to make you download and execute the rest. quic is not needed to give you the text you want. It's needed to deliver the actual content, the ads.
- Nemi 5y ago
  I agree that it is a greek tragedy that it always comes to this, but this is just the market’s way of monetizing the medium. This is how it happens. We used to sit through 20 minutes(!) of commercials every hour for tv content. Now we download one or two magnitudes more data than is required so that the content we actually want is “free”. Efficient markets will always devolve to this unfortunately. At least this (compared to unskippable commercials of past) I can bypass looking at.

jeroenhd 5y ago

The comparison isn't entirely fair because there's no reason not to use TLS 1.3 on HTTP 1 or HTTP/2 connections. The 0-RTT advantage of QUIC is also available to those protocols, which is one of the things the article claims make HTTP/3 faster. The methodology section also doesn't say if 0-RTT was actually enabled during testing. I'd argue that any system or website with an admin interface or user account system should not enable 0-RTT without very strict evaluation of their application protection mechanisms, making it useless for many API servers and data sources. It's fine for static content and that can help a lot, but with the benefit of multiplexing I'm not sure how useful it really is.

johncolanduoni 5y ago
This is true, though it’s worth mentioning that 0-RTT on TLS 1.3 + HTTP/2 still has one more roundtrip (for the TCP connection) than 0-RTT HTTP/3. Plus even if you don’t enable 0-RTT on either there’s still a one roundtrip difference in favor of HTTP/3, since it combines the (equivalent of) the TCP establishment roundtrip and the TLS handshake roundtrip. That’s the real advantage in connection establishment.
lemagedurage 5y ago
Yes, TLS1.3 cuts out a RTT compared to TLS1.2, but QUIC cuts out another RTT by combining the TCP and TLS handshakes into one. For a full handshake: TCP + TLS1.2: 3 RTT TCP + TLS1.3: 2 RTT QUIC including TLS1.3: 1 RTT And for subsequent connections: TCP + TLS1.3: 1 RTT QUIC including TLS1.3: 0 RTT (but no replay attack protection)

favourable 5y ago

Anyone know if this breaks on legacy hardware running legacy browsers? Yes people largely use modern hardware, but there's always eccentric folk with old hardware who like to browse the web on old browsers (for whatever reason).

lemagedurage 5y ago
Chrome supports HTTP/3 since November 2020. https://caniuse.com/http3 https://caniuse.com/http3 Typically servers support multiple HTTP versions.
- shakna 5y ago
  But not supported by default by any mobile browser except Android's Chrome, making this more of a bleeding edge type situation on the client side of things.

JackFr 5y ago

That improvements are given in milliseconds rather than percent and charts aren’t anchored at zero tells me all I need to know.

akyoan 5y ago
How to Lie with Charts 101
- authed 5y ago
  s/Lie/deceive
  - tgv 5y ago
    It's a reference to this book: https://en.wikipedia.org/wiki/How_to_Lie_with_Statistics https://en.wikipedia.org/wiki/How_to_Lie_with_Statistics
tester34 5y ago
What do you mean, what's wrong with those charts? Would there be some better/more precise information shown if they were anchored at 0?
- vlmutolo 5y ago
  See my comment here: https://news.ycombinator.com/item?id=29567067 https://news.ycombinator.com/item?id=29567067
deleted 5y ago
[deleted]

deleted 5y ago

[deleted]

anotherhue 5y ago

Just in time for Web3!

hutrdvnj 5y ago

How much packet loss does average internet traffic has on average?

tambourine_man 5y ago

What’s great about HTTP 1.1 is it’s simplicity. I mean, you can explain it to a complete newby and have that person write a functioning implementation in a few lines of shell script, all in one afternoon. In fact, you can probably figure it out by yourself just by looking at what goes across the wire. And yet, it runs the whole modern world. That’s beautiful. I think simplicity is underrated and it’s something I really value when choosing the tools I use.

tambourine_man 5y ago
I’m pretty sure I’ll never understand QUIC completely in my lifetime. I do know HTTP 1.1 through and through (it’s really easy). The fact that HTTP 1.1 speeds are even comparable, let alone faster in some situations, should at least tip the scale in its favor.
- arpa 5y ago
  obscure standards mean less possibility that someone else without google-scale resources will implement their own client/server.
  - ocdtrekkie 5y ago
    And that is one of the key "benefits" of HTTP/3 if you're a Google-scale company.
  - bayesian_horse 5y ago
    Except there are already several such implementations and nobody is going to deprecate older HTTP versions.
    - giantrobot 5y ago
      Chrome has an overwhelming portion of the web browser installed base. It's full of dark patterns and scary warnings about "dangerous" things like unencrypted HTTP. I don't have a lot of faith that they're not going to disable older HTTP versions at some point.

beckerdo 5y ago

There are a few outliers in the HTTP/3 graphs that are slower than the HTTP/2 graphs. I might have missed it, but I don't think the outliers were explained.

bullen 5y ago

3x is nothing, 10x or 100x and we're talking. The only real bottleneck we're going to have is CPU, so they should compare that. Everytime humans make an improvement we scale up to fill that benefit: https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox

ch17z 5y ago

requestmetrics.com: Blocked by 1Hosts (Lite), AdGuard DNS filter, AdGuard Tracking Protection filter, EasyPrivacy and oisd.

toddgardner 5y ago
Request Metrics is not an advertiser, does not track individuals, and complies with the EFF dnt policy. Ad block lists are way too aggressive--all it takes is some random person to put you on the list and it's hard to get off of it.

eric_trackjs 5y ago

Author here. I am seeing a lot of comments about how the graphs are not anchored at 0. The intent with the graphs was not to "lie" or "mislead" but to fit the data in a way that was mostly readable side by side. The goal was to show the high level change, in a glanceable way, not to get in to individual millisecond comparisons. However, in the future I would pick a different visualization I think :) The benchmarking has also come under fire. My goal was to just to put the same site/assets on three different continents and retrieve them a bunch of times. No more, no less. I think the results are still interesting, personally. Clean room benchmarks are cool, but so are real world tests, imo. Finally, there was no agenda with this post to push HTTP/3 over HTTP/2. I was actually skeptical that HTTP/3 made any kind of difference based on my experience with 1.1 to 2. I expected to write a post about "HTTP/3 is not any better than HTTP/2" and was frankly surprised that it was so much faster in my tests.

aquadrop 5y ago
Thanks for the article. But the goal of the graphs should be to show level of change and let graph speak for itself, if it's high or low. If they were anchored at 0 it would actually allow to see visual difference and for me personally it would be "way that was mostly readable side by side".
kzrdude 5y ago
The missing part of the axis, down to 0, is just 1/9th of the current length, so I think it's absolutely the wrong trade-off to cut the y-axis.
posix_me_less 5y ago
Could it be simply because UDP packets may be treated with higher priority by all the middleman machines? UDP is used by IP phones, video conferences, etc.
- digikata 5y ago
  Because of the use of UDP, I wonder the variation could end up being wider. There are some large outliers on the chart (though that could be an implementation maturity issue). Also I wonder if the routing environment will continue to be the same in terms of prioritization if http/3 becomes more common. There might be some motivation to slow down http/3 to prioritize traditional udp real-time uses.

markdog12 5y ago

Anyone interested in HTTP 3 that likes even-handed articles, Robin Marx has an excellent series on Smashing Magazine: https://www.smashingmagazine.com/author/robin-marx/ https://www.smashingmagazine.com/author/robin-marx/ The second article is about its performance.

mgaunard 5y ago

So I understand how multiplexing everything through a single TCP session is a bad idea. But what was the problem with using multiple TCP sessions like HTTP 1.1 does? Is it just the problem that there is a latency cost to establishing the connection (even though those sessions are reused later on)? How about extending TCP to establish multiple sessions at once instead?

vlmutolo 5y ago
I think it's just that hundreds of TCP connections per user can really bog down the servers. Individual TCP connections are much more expensive than QUIC streams. QUIC also handles things like transparent IP-address switching (on either side of the connection).
- mgaunard 5y ago
  There is no difference in server overhead, the amount of state to maintain and data received/sent is the same. Also nothing prevents the server from implementing TCP in userland, apart from maybe security concerns, but then if you want low latency you have to discard those anyway.
  - deleted 5y ago
    [deleted]
jayd16 5y ago
Extending TCP is considered infeasible due to its pervasiveness and the calcification of it across the ecosystem. Implementing a new protocol is also considered infeasible for similar reasons. So they arrived at a new protocol over UDP to implement new features.

heftig 5y ago

I've deactivated HTTP/3 in Firefox as the bandwidth from CloudFlare to my provider (German Telecom) gets ridiculously bad (downloading a 6 MB file takes 25 s instead of 0.6 s) during peak times, and I only see this when using HTTP/3 over IPv4, all other combinations stay fast.

deleted 5y ago

[deleted]

aquadrop 5y ago

Regardless of the results, that is very disingenuous way of showing up charts, like floor being ~1000 and first result having 2500 score and second 1000, basically being on the floor, even though real difference is 2.5 times.

deleted 5y ago
[deleted]

amenod 5y ago

> The 0-RTT feature in QUIC allows a client to send application data before the handshake is complete. This is made possible by reusing negotiated parameters from a previous connection. To enable this, 0-RTT depends on the client remembering critical parameters and providing the server with a TLS session ticket that allows the server to recover the same information. Am I missing something, or is this yet another way to track clients across visits? If so, I'm sure Chrome will be faster than Firefox (because it will keep the sessions IDs live forever). Well played, Google.

stusmall 5y ago
There are features that go back a ways in TLS that someone could use for tracking. A while back I wrote a quick and dirty POC for using TLS 1.2 session resumption for sub-NAT user tracking[1]. While it is really effective at separating out multiple different users interacting with a server from behind a NAT, I'm not sure these features are usable for cross site tracking. I'm not familiar with 0-RTT but sessions resumption scoped tickets to a host so it wouldn't be useful there. While someone could use it for some tracking purposes it really is a huge performance boon. There are good intentions on why these features were put in even if they can be abused. 1. https://stuartsmall.com/tlsslides.odp https://stuartsmall.com/tlsslides.odp https://github.com/stusmall/rustls/commit/e8a88d87a74d5630227ea330cc4bf3fae8727b8e https://github.com/stusmall/rustls/commit/e8a88d87a74d563022...
- youngtaff 5y ago
  Session resumption could be used for cross-site tracking As a mitigation Chrome (and FF?) have started to partition connections so a different connection would be used to a common 3rd party from different top level origins

fmiras 5y ago

Awesome post!

bawolff 5y ago

> TLS 1.2 was used for HTTP/1.1 and HTTP/2 > TLS 1.3 was used for HTTP/3. > 0-RTT was enabled for all HTTP/3 connections Ok then. No potential confounding variables there... none at all. [For reference its expected that tls1.3 with 0-rtt is going to be much faster than tls1.2 especially when fetching small documents from geographically far away places. To be clear, not doubting that http/3 gives performance improvements in some network conditions, this is just a really bad test and tls version is probably a good portion of the difference here]

est 5y ago

Is it possible to host a UDP only h3 site without the 443 tcp?

heftig 5y ago
Yes, I believe this is possible with the HTTPS DNS records defined in https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-08.html https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-...

AtlasBarfed 5y ago

I have seen SO MANY "reliable UDP" transports written instead of TCP over the decades. Off the top of my head: TIBCO, SaltStack, various games have bespoke UDP / TCP hybrids IIRC. Is TCP really that fundamentally slow? How could high-level repurposes of UDP be faster than presumably hardware optimized and heavily analyzed TCP stacks? The lies, damn lies, benchmarks seems a bit applicable too here. He's disabling caching? Really it is testing a specific transport situation, but caching IMO would mitigate a lot of the dramatic advantages? And what about cloudflare edge caching outside the browser? I think he was routing all resource requests through his single server that probably isn't cached properly. So with good caching will HTTP/3 produce the advantage for the everyman over HTTP/1.1 to justify the attention?

Dylan16807 5y ago
You can't control TCP very well, and you can't do anything about head-of-line blocking. So yes, for lots of circumstances it's easy to beat TCP. Importantly, a custom protocol over UDP can do things that are incompatible with 30 year old TCP implementations. And you don't need hardware optimization until you're getting into many gigabits per second.

ericls 5y ago

In practice, you'll have load balancers and reverse proxies some where in between your server and your client. Does HTTP/3 still make a difference in these cases?

KronisLV 5y ago

> It would be 18 more years before a new version of HTTP was released. In 2015, and with much fanfare, RFC 7540 would standardize HTTP/2 as the next major version of the protocol. Huh, this is interesting. So the current timescale is like: HTTP/1: 1996 (though HTTP/1.1 came out in 1997) HTTP/2: 2015 HTTP/3: 2021 (current draft) Should we expect HTTP/4 around 2022 or 2023, at this increasing rate of progress, then? Just a bit of extrapolation, since it seems like the rate of progress and new versions to deal with is increasing. Promising, but possibly worrying.

azlen 5y ago
From what I've read about it, one of the exciting things about QUIC and HTTP/3 is that they're much more extensible. Meaning anyone might be able to dabble and experiment with their own version of the protocol. So yes, I'd think the rate of progress may well increase. Not all will become standards, but I imagine we might see HTTP/3.1, 3.2, etc. long before we see an entirely new version like HTTP/4

Animats 5y ago

This is a bigger performance difference that Google reported. Is the packet loss rate being measured? That's the main cause of head-of-line blocking delays. Are both ends using persistent TCP connections? If you have to re-open and redo the TLS crypto handshake each time, that's a huge overhead. Does Caddy implement that? Is the CONTENT-LENGTH header set? If not, each asset is a fresh TCP connection.

twsted 5y ago

I don’t see any graph in Safari

ArchOversight 5y ago

Just as a heads up, if you are viewing the site in Safari, you will not see the graphs and images as lazy loading is not yet supported. https://caniuse.com/loading-lazy-attr https://caniuse.com/loading-lazy-attr You can manually enable it if you have Developer mode enabled with: Develop -> Experimental Features -> Lazy Image Loading

ksec 5y ago
12 Hours and 255 Comments, You can guess most on HN dont use Safari. Thanks for the tip.
- galonk 5y ago
  I just assumed they were broken or that the image server was slashdotted.
- chuckhoupt 5y ago
  I think this was a bug in the site, which appears to now been fixed.
youngtaff 5y ago
Guessing there must be some broken implementation of lazy loading on the site using JS etc. If they just used loading=lazy on the images Safari should ignore it and so all images should load
- ArchOversight 5y ago
  They used data-src instead of just a src attribute on the image. So Safari parses it as: <img />

tiffanyh 5y ago

Cloudflare has interesting results as well. Though not as dramatic as this blog. > “ On average, with HTTP/3 we see the first byte appearing after 176ms. With HTTP/2 we see 201ms, meaning HTTP/3 is already performing 12.4% better!” https://blog.cloudflare.com/http-3-vs-http-2/ https://blog.cloudflare.com/http-3-vs-http-2/