15 ms·

How QUIC is displacing TCP for speed

149 points by animesh371g 3y ago

dingi 3y ago
You either use TCP or re-implement TCP over UDP i.e. QUIC
- kccqzy 3y ago
  The whole point of QUIC is to re-implement TCP to be better than TCP.
- animesh371g 3y ago
  Yes, that is what QUIC has done.
- ajsnigrutin 3y ago
  Yep. And you need that, becuase your website, that cotains maybe 1kB of useful info (eg. news article), now needs to transfer tens of megabytes of random garbage, needs you to connect to 50 different external services, and where a simple even a basic share button, that could be implemented with an 'a href' pointing to "http: //twitter.com/share/?url=http....", now needs 3rd party cookies and external resources to track your users. So in a real-life example, this is like a movie-ticket seller optimizing the ball bearings in a shopping cart that you need to buy those tickets, because they want you to carry a bunch of flyers and gps trackers with you, while all you need is a small paper ticket.
  - rkagerer 3y ago
    This response is so on-point I might have to frame and hang it on the wall. Then in a few generations when the world comes back to its senses, some historian will find it and laugh at how dumb and broken our generation was.
TomSwirly 3y ago
Strong article so far, I'm still reading, but I found it rather jarring to have a cartoon in the middle with a white couple cherishing a baby and a black woman killing one...
- gsich 3y ago
  "killing"
  - jonathanstrange 3y ago
    It's a weird an uninformative illustration.
  - TomSwirly 3y ago
    If this were a photo, would you expect the infant launched high in the air like a basketball to survive?
    - code_sloth 3y ago
      Do you expect all memes and jokes to be absolutely harmless and 100% politically correct for every nation/culture/race/gender/<group>?
      - pasc1878 3y ago
        When doing technical or business work - YES If for entertainment then things can be unsettling or tuned to one group.
        pasc1878 3y ago
        I really do not want to work with the person(s) who downvoted this. These sort of 'jokes' are part of what makes a hostile work environment.
        kreetx 3y ago
rwmj 3y ago
TCP is also concerned with fairness (after Van Jacobson's famous paper[1]). We've long known that you can batter data through the network at speed if you don't care about other users. How does QUIC preserve fairness? [1] https://inst.eecs.berkeley.edu/~cs162/fa23/static/readings/jacobson-congestion.pdf https://inst.eecs.berkeley.edu/~cs162/fa23/static/readings/j...
- bheadmaster 3y ago
  According to this random document I found on the internet [0], in section 7., QUIC implements a congestion control system similar to TCP New Reno. [0] https://quicwg.org/base-drafts/rfc9002.html https://quicwg.org/base-drafts/rfc9002.html
  - hlandau 3y ago
    More precisely - it suggests one. Just like for TCP (see the myriad number of algorithms available for Linux's TCP stack) you can choose whatever congestion control strategy you want.
- Borg3 3y ago
  Fairness? It seems noone gives a shit about it. Most consumers want their data now. I have ETTH 100Mbit (with is very fast to my standards) and I can tell the difference between day, evening and weekend just by pinging my nodes. RTT is stable offhours, but in normal day jitter kicks in. It sad to see RTT jump from 9 to 90ms over major IX. Everything seems to be overbooked horribly. I know that Internet is best effort network (ATM, anyone remember it?) but Im sure I would preffer slower but more stable internet.
  - mort96 3y ago
    ISP overprovisioning is a completely different issue from fair congestion control algorithms... every device involved can be using totally fair congestion control algorithms and an overprovisioned network will still see degraded performance. I mean that's literally the point of fair congestion control algorithms, make it so that the overprovisioned network still works and everyone's performance degrades roughly evenly!
Slix 3y ago
I don't think this article is very well-written. It gets confused about whether QUIC has a handshake or not (it does). And it conflates zero round-trip time with combining the TCP/TLS handshakes together.
- animesh371g 3y ago
  QUIC doesn't have a handshake which is another reason for it being fast
  - dsr_ 3y ago
    The article says this repeatedly, but it's also wrong about that. QUIC doesn't use exactly the same three-way handshake at the beginning of the session -- but it uses a handshake that lasts at least 3 packets. https://quic.xargs.org/ https://quic.xargs.org/
- ktzar 3y ago
  I came to mention the same. Diagrams have redundant information, examples are badly picked, there's sentences with little to no value... I don't know if it's lack of care, the author not writing in his native language, or excess of GPT. > QUIC works on top of UDP. It overcomes the limitations of TCP by using UDP. It’s just a layer or wrapper on top of UDP. Makes me want to stop reading.
deleted 3y ago
[deleted]
tmikaeld 3y ago
QUIC is very exciting, after seeing what it did for latency in Cloudflare network and Cloudflare workers, I can't wait to finally see it in Deno 1.41[0]. [0] https://github.com/denoland/deno/pull/21942#issuecomment-1928479265 https://github.com/denoland/deno/pull/21942#issuecomment-192...
skerit 3y ago
It's weird that there's still no QUIC or HTTP3 in Node.js
- animesh371g 3y ago
  Best opportunity to contribute to a new NPM package for QUIC/HTTP3
- zilti 3y ago
  Node.js shouldn't be used in the first place, just like any server-side JS. But more importantly, put your hacky language-specific servers behind a webserver like nginx.
- 0x457 3y ago
  Not really. HTTP3 has little benefit (if any) when talking to a backend server, plus browsers only support QUIC with TLS and you probably don't want to waste CPU cycles terminating TLS on an application server and leave it load balancer (that isn't written in nodejs and supports HTTP3)
lini 3y ago
Is it just me or the graph at the end of the article is not really showing rising adoption in general. It basically shows a couple of spikes - each corresponding to some big company switching their edge servers to HTTP/3 like Alphabet, Meta, Cloudflare. There is no gradual increase. Furthermore, I don't see easy solutions yet for some problems with QUIC - for example browsers still try to establish a TCP connection first unless they know for sure the server supports QUIC. Proxy support for HTTP/3 is still in its infancy, but for many corporate envuronments it is a hard requirement. So outside of the biggest websites, which I admit also take up a large chunk of the network traffic, is QUIC really replacing TCP in the general Internet?
- animesh371g 3y ago
  The adoption would be gradual and few years down the line, it would be QUIC. The same was true for HTTP/1 and HTTP/2.
- gkbrk 3y ago
  Yep, and the graph looks like the HTTP 3 adoption spikes are taking from HTTP 2. It's basically one Google protocol replacing the previous one. And the original and simpler "real" HTTP 1.1 is still going strong.
  - marcosdumay 3y ago
    Anyway, the quicker we kill HTTP 2, the best. So, IMO, this is one of the best possible scenarios.
- danpalmer 3y ago
  > for example browsers still try to establish a TCP connection first unless they know for sure the server supports QUIC As you alluded to here, you can hint a networking implementation with QUIC supporting servers. This feels similar in practice to HSTS Preloading, most of the benefit of full HSTS comes from a small number O(100k? 1m?) of domains being pre-loaded as HSTS supporting, and that's just distributed with browsers now, a fairly straightforward solution. The same could probably be applied for QUIC. > which I admit also take up a large chunk of the network traffic, is QUIC really replacing TCP in the general Internet? I guess this depends on whether you're looking at aggregated traffic, or distinct traffic destinations. Neither of those is more important right! If YouTube/Netflix move to QUIC, that's a very significant amount of benefit for the internet and users. Equally if all wordpress sites on shared hosting disappeared because TCP was no longer supported, that would also be a very significant impact. I think the headline saying "QUIC is displacing TCP for speed" is very fair, but over-extrapolating from this would be going too far.
raffraffraff 3y ago
What happens when you tcpdump QUIC? Hmmm.. edit: "tcpdump -t quic", and I also see that it's supported (as expected) by Wireshark.
- freedomben 3y ago
  I got bit hard doing network troubleshooting with Wireshark. I was trying to debug connectivity issues and was filtering for HTTP packets, but that was excluding QUIC! Turns out my packets were QUICked through Cloudflare. Figuring that out when hair is on fire isn't my preferred time.
oaiey 3y ago
The chart at the bottom: So google switched it on, and then, let us guess, Facebook and Netflix. Afterwards no growth for a year. Displacing looks different to me. HTTP/2 is growing at cost of HTTP/1 ... so the only conclusion I can draw here, is that HTTP/3 adoption has halted. Do not read that negatively. The users who really needed it (like Google, Facebook, Netfix, ...) are using it and the rest, has it very low on the priority list if at all. I have my doubts that everyone needs HTTP/3, with UDP traffic has network device wise also its disadvantages and library availability and complexity should be lower for HTTP/1 and /2 for the foreseeable future.
- freedomben 3y ago
  Not disagreeing, but adding: Cloudflare also uses it between browser and proxy, which is a huge amount non-trivial amount of the small internet.
flumpcakes 3y ago
I don't think this article was very good and seems to be written by someone that doesn't really know what they're talking about, or by someone that does but "dumbed down" to a degree where it's conclusion inaccurate. I think HTTP3 is probably doomed for a IPv6 like existence for a long while. While everyone claims that TCP is apparently "too slow", the vast majority of corporate/enterprise settings will just block it. It seems like a technology built by the big players who want to shave a few cycles off each connection and save $millions rather than a practical standard. Do I want to use HTTP3 at home? Yeah, sounds cool. Will I be able to use it at work? Probably not for 5+ years.
- api 3y ago
  HTTP3 doesn't have the same chicken-or-egg problem as IPv6. It runs over UDP. IPv6 is a full protocol rev which takes a lot longer to accomplish. Once a large multi-vendor network is deployed revving the base protocol is really hard.
  - ronsor 3y ago
    Not to mention the companies backing it are so large and critical they can simply mandate it and enterprises will just have to deal with it, somehow.
    - londons_explore 3y ago
      so far, there is no reason to mandate http/3. There is barely any infrastructure cost to running a dual HTTP/1.1 and HTTP/3 setup. And the two are so similar to application developers that there is no reason to mandate anyone move over. However... It only takes one killer feature not compatible with HTTP/1.1 (eg. realtime VR with a stream per eye, and it turns out HTTP/1.1 can't do realtime bidirectional streams), and suddenly everyone will start turning off HTTP/1.1 services and replacing it with a page saying "please upgrade your web browser".
    - api 3y ago
      That part is great. It uses UDP, which means it helps prevent UDP from being sidelined or blocked by middleboxes. That in turn helps prevent the Internet from becoming a de-facto HTTP-only network, which was a trend that was kind of happening in the 20-teens and had me concerned.
nottorp 3y ago
"The big a-holes implemented it so you should use it too" ? That's what I get from the article. What are the advantages of that thing if you're not at Google/Facebook scale?
clbrmbr 3y ago
I’m a bit concerned that the ease of modifying the parameters will lead to Congestion Collapse. It’s been possible to cheat with TCP but most people don’t bother because it would require a kernel recompilation. Or did this ship sail a while ago with various other UDP-based reliable transports, streaming media, etc?
- londons_explore 3y ago
  If congestion collapse happens on the wider internet, I predict that it would take mere hours for sysadmins to come up with a temporary fix, and within months it'll become common for all core routers to have bloom filters of common src/dst IP pairs and de-prioritize anyone sending more than their fair share of traffic on a congested link.
- wmf 3y ago
  99% of QUIC traffic is coming from a handful of CDNs (Netflix, Google, Meta, etc.) and they have no incentive to collapse the Internet.
kd913 3y ago
I feel the main limitation over here is hardware optimisation support. With TCP you have the congestion control algo baked in hardware, tcp segment and checksum offload. You can pass things directly to the NIC for massive latency, bandwidth and offloading processing away from the cpu. A properly tuned system with a user space networking stack with ctpio, hardware offload and proper tuning beats the pants of QUIC for latency. It is possible to get some of the same benefits I guess with GSO. In any case, the slow hardware support here I suspect is a bottleneck. You may not get much benefit given more layers are binary/encrypted and not visible to hardware. The above is not relevant for hyperscalers like Google I imagine where they can make the hardware and the sheer amount of customers offer bandwidth benefits.
- jabart 3y ago
  The internet itself is not properly tuned and distance is an issue. On a local lan, sure a TCP tuned system will do amazing. On the public internet where who knows where your packet is going it's an optimal but not tuned system with latency TCP wasn't designed for. Also a modern CPU with SIMD/AVX can handle a lot of traffic in user space. UDP also has a checksum in it's packet header.
  - kd913 3y ago
    For hyperscalers in the cloud and low latency finance, tcp is likely still king. You do not want things running on CPU as that is compute that could be sold to someone else. This needs an easy way to offload to a specialised hardware accelerator.
    - jabart 3y ago
      https://aws.amazon.com/blogs/aws/new-http-3-support-for-amazon-cloudfront/ https://aws.amazon.com/blogs/aws/new-http-3-support-for-amaz... Seems AWS is doing just fine with it. They also have built their own custom chipsets though I don't see a mention of it offloading QUIC to those chips.
      - 3y ago
superkuh 3y ago
TCP also supports allowing people you've never met to connect to your IP without you getting the permission of a third party first and regularly. QUIC requires continued permission being allowed by some third party corporation. Baking the requirement for CA TLS into the protocol is fine for corporate uses but the internet is far more than just corporate uses. Sure QUIC may be faster, but only as long as you keep getting permission from your TLS CA. Once that stops it's very, very, slow. QUIC is fragile and like other CA TLS things: anything built with it will have a lifetime of only a few years without being updated. Do we really want to base our web protocol (and other things) on a system that will only allow machines updated in the last $fewyears to participate? Additionally, the claims of the use rate for the various HTTP versions is flawed in that it is not going per webserver or domain, but instead just counting traffic and of course the megacorp flows it knows about will dominate (they're not checking every webserver). Looking where the light is fallacy.
- brlewis 3y ago
  > Sure QUIC may be faster, but only as long as you keep getting permission from your TLS CA. Once that stops it's very, very, slow. QUIC is fragile and like other CA TLS things: anything built with it will have a lifetime of only a few years without being updated. For me, letsencrypt has been set-and-forget for at least 5 years. I use it with nginx, which is in front of several servers including a Jetty 5 server. Jetty 6 was released in 2006. You can configure which CAs you trust as well, so TLS isn't really any more of a centralization problem than DNS is.
  - superkuh 3y ago
    What did you do when acme1 was deprecated (for acme2) and stopped working with LetsEncrypt? That certainly required changes in your setup that would break otherwise. How did you handle the expiration of the LE root cert? Maybe can still access your TLS wrapped site but people using an RSS reader who's cert store was set up in 2019 can't. All these things, both on your side and the client side apply very, very broadly. It may work for you from your setup but I can assure you that isn't universal or even normal. I love LE and I think it's the least worst solution. But mandating CA TLS into a protocol is very bad for human use cases. HTTP+HTTPS prevents this fragility. HTTP/3 with it baked in is fragile. Also, you don't need DNS to communicate with an IP.
apitman 3y ago
I'm a fan of QUIC, but these articles are always heavy on explanations and light on data. I understand in theory how head-of-line blocking can cause serious issues on a lossy network, but by this point I would expect to see a ton of data backing that up in real-world usage from Google and Cloudflare. One specific question I've had is on a lossy network are there really that many situations where you would have packet loss on one QUIC stream but not most/all the others? I don't doubt that's true but I would love to see a breakdown. Also, what's the crossover point between opening multiple TCP streams and doing round robin across them? Maybe you only need 3-4 TCP connections to estimate the HOL advantages of QUIC. I will admit fewer RTT handshakes is a more obvious win.
- KMag 3y ago
  > One specific question I've had is on a lossy network are there really that many situations where you would have packet loss on one QUIC stream but not most/all the others? I don't doubt that's true but I would love to see a breakdown. If an intermediate router is using Randomized Early Detection (RED) and is congested within the randomized packed drop region, then you could easily see one random packet in the middle of a stream dropped, with other streams unaffected.
- adgjlsfhk1 3y ago
  > One specific question I've had is on a lossy network are there really that many situations where you would have packet loss on one QUIC stream but not most/all the others? This isn't the advantage. The advantage is that if you have 10 different streams and a low loss rate, the impact of each packet lost would be much smaller. Consider a voip call with an architecture where each person's audio is served as a separate stream from a central server. With head of line blocking, every packet lossed causes a slight stutter in the whole conversation because even if the lost packet is from someone not talking, you have to wait for that packet of silence before decoding the packet from the person speaking. With QUIC, the extra latency only affects the individual stream, so the conversation won't stutter when the person not talking wasn't the one who's packet got lost.
  - apitman 3y ago
Ragnarork 3y ago
It's a bit perplexing that an article that make some claims about QUIC speed over TCP has exactly zero benchmarks, numbers, anything to back that up besides theory. I could be inclined to believe it but I'd like to know by which factor, in which circumstances, with real examples and numbers.
- jeffbee 3y ago
  What would you want to compare? Google Quiche vs. Linux? Chrome vs. Windows TCP? What version of Linux, Windows, or Chrome? Under how much delay, loss, etc? There's a large parameter space to sweep.
  - unethical_ban 3y ago
    Uh, how about "something" vs. "nothing". Start with QUIC vs. TCP. Same OS, same client/server software. Edit: since the system says "I'm posting too quickly, slow down" despite not posting for an hour because they don't use accurate error messages here, let me say : I find it ironic that so many keystrokes below are used in a meta-discussion about the quality of comments here, when others are posed a legitimate question about the topic. Nevermind the article they seem to defend gets the order of a TCP 3 way handshake wrong. And since I can't respond to them, I can only d*wnv*te or fl*g them.
    - refulgentis 3y ago
      [flagged]
      - unethical_ban 3y ago
        I wasn't demanding it like the thread-starter was. I was pointing out that a benchmark would be like-for-like and that none of jeffbee's examples made sense.
        refulgentis 3y ago
0xbadcafebee 3y ago
Curl HTTP/3 performance (https://news.ycombinator.com/item?id=39163948 https://news.ycombinator.com/item?id=39163948) shows HTTP/3 is the slowest performer compared to HTTP2 and HTTP1.1 This paper from 2017 showed QUIC performance was poor: https://arxiv.org/pdf/2310.09423.pdf https://arxiv.org/pdf/2310.09423.pdf With no evidence to the opposite, the article's claim that QUIC is displacing TCP for speed is dubious at best.
- belthesar 3y ago
  The comments of that article cite a couple things: * The version of Caddy used for the test was missing several recent updates that significantly improve its performance. * Performance improvements for QUIC have always been about removing/recovering from dynamic network connections, and are about running connections at scale. Simple HTTP 1 requests in environments where there are far less shenanigans going on will always be fast. (lib)curl powered requests being single threaded requesting across the local network stack are not representative of the types of performance gains to expect in an HTTP/3 world.
- jeffbee 3y ago
  If localhost is your use case, these results are for you. Many others may be operating on real networks. Perfect, lossless, zero-delay networks are of no interest when evaluating protocols. Under those conditions literally any protocol can do the job. The exercise only becomes interesting in the real world where delay and loss exist.
hkgjjgjfjfjfjf 3y ago
[dead]
DarkmSparks 3y ago
most tcp work is done in the network hardware these days isnt it? how can a userpace protocol possibly hope to be faster than that?
- lxgr 3y ago
  "Fast" here means high throughput and/or low latency, not low on compute resources. If you're compute-bound (or using a userspace transport layer would make you compute-bound), this might not be a great choice, but many network-facing services aren't.
- wmf 3y ago
  No, TCP is not in hardware and Linux (the most popular server OS) has a policy to never allow full TCP offload.
  - DarkmSparks 3y ago
    Not convinced, but sounds like you know what you are talking about nginx has quic support now https://nginx.org/en/docs/quic.html https://nginx.org/en/docs/quic.html Do you fancy knocking up some benchmarks of typical server loads on accross some 100mbs/1gbs/10gbs connections and chrome headless?
    - wmf 3y ago
      As I said in another comment, I still expect TCP to use fewer cycles than QUIC due to kernel optimizations and partial NIC offload. IIRC people have done benchmarks showing this. Saturating 10G or even 100G with either protocol should be easy enough these days but if you want to do 400G or more from a single server then it matters.
spullara 3y ago
It is currently almost certainly not faster in all cases. https://github.com/icing/blog/blob/main/curl-h3-performance.md https://github.com/icing/blog/blob/main/curl-h3-performance....

149 points by animesh371g 3y ago

dingi 3y ago

You either use TCP or re-implement TCP over UDP i.e. QUIC

kccqzy 3y ago
The whole point of QUIC is to re-implement TCP to be better than TCP.
animesh371g 3y ago
Yes, that is what QUIC has done.
ajsnigrutin 3y ago
Yep. And you need that, becuase your website, that cotains maybe 1kB of useful info (eg. news article), now needs to transfer tens of megabytes of random garbage, needs you to connect to 50 different external services, and where a simple even a basic share button, that could be implemented with an 'a href' pointing to "http: //twitter.com/share/?url=http....", now needs 3rd party cookies and external resources to track your users. So in a real-life example, this is like a movie-ticket seller optimizing the ball bearings in a shopping cart that you need to buy those tickets, because they want you to carry a bunch of flyers and gps trackers with you, while all you need is a small paper ticket.
- rkagerer 3y ago
  This response is so on-point I might have to frame and hang it on the wall. Then in a few generations when the world comes back to its senses, some historian will find it and laugh at how dumb and broken our generation was.

TomSwirly 3y ago

Strong article so far, I'm still reading, but I found it rather jarring to have a cartoon in the middle with a white couple cherishing a baby and a black woman killing one...

gsich 3y ago
"killing"
- jonathanstrange 3y ago
  It's a weird an uninformative illustration.
- TomSwirly 3y ago
  If this were a photo, would you expect the infant launched high in the air like a basketball to survive?
  - code_sloth 3y ago
    Do you expect all memes and jokes to be absolutely harmless and 100% politically correct for every nation/culture/race/gender/<group>?
    - pasc1878 3y ago
      When doing technical or business work - YES If for entertainment then things can be unsettling or tuned to one group.
      - pasc1878 3y ago
        I really do not want to work with the person(s) who downvoted this. These sort of 'jokes' are part of what makes a hostile work environment.
        kreetx 3y ago

rwmj 3y ago

TCP is also concerned with fairness (after Van Jacobson's famous paper[1]). We've long known that you can batter data through the network at speed if you don't care about other users. How does QUIC preserve fairness? [1] https://inst.eecs.berkeley.edu/~cs162/fa23/static/readings/jacobson-congestion.pdf https://inst.eecs.berkeley.edu/~cs162/fa23/static/readings/j...

bheadmaster 3y ago
According to this random document I found on the internet [0], in section 7., QUIC implements a congestion control system similar to TCP New Reno. [0] https://quicwg.org/base-drafts/rfc9002.html https://quicwg.org/base-drafts/rfc9002.html
- hlandau 3y ago
  More precisely - it suggests one. Just like for TCP (see the myriad number of algorithms available for Linux's TCP stack) you can choose whatever congestion control strategy you want.
Borg3 3y ago
Fairness? It seems noone gives a shit about it. Most consumers want their data now. I have ETTH 100Mbit (with is very fast to my standards) and I can tell the difference between day, evening and weekend just by pinging my nodes. RTT is stable offhours, but in normal day jitter kicks in. It sad to see RTT jump from 9 to 90ms over major IX. Everything seems to be overbooked horribly. I know that Internet is best effort network (ATM, anyone remember it?) but Im sure I would preffer slower but more stable internet.
- mort96 3y ago
  ISP overprovisioning is a completely different issue from fair congestion control algorithms... every device involved can be using totally fair congestion control algorithms and an overprovisioned network will still see degraded performance. I mean that's literally the point of fair congestion control algorithms, make it so that the overprovisioned network still works and everyone's performance degrades roughly evenly!

Slix 3y ago

I don't think this article is very well-written. It gets confused about whether QUIC has a handshake or not (it does). And it conflates zero round-trip time with combining the TCP/TLS handshakes together.

animesh371g 3y ago
QUIC doesn't have a handshake which is another reason for it being fast
- dsr_ 3y ago
  The article says this repeatedly, but it's also wrong about that. QUIC doesn't use exactly the same three-way handshake at the beginning of the session -- but it uses a handshake that lasts at least 3 packets. https://quic.xargs.org/ https://quic.xargs.org/
ktzar 3y ago
I came to mention the same. Diagrams have redundant information, examples are badly picked, there's sentences with little to no value... I don't know if it's lack of care, the author not writing in his native language, or excess of GPT. > QUIC works on top of UDP. It overcomes the limitations of TCP by using UDP. It’s just a layer or wrapper on top of UDP. Makes me want to stop reading.

deleted 3y ago

[deleted]

tmikaeld 3y ago

QUIC is very exciting, after seeing what it did for latency in Cloudflare network and Cloudflare workers, I can't wait to finally see it in Deno 1.41[0]. [0] https://github.com/denoland/deno/pull/21942#issuecomment-1928479265 https://github.com/denoland/deno/pull/21942#issuecomment-192...

skerit 3y ago

It's weird that there's still no QUIC or HTTP3 in Node.js

animesh371g 3y ago
Best opportunity to contribute to a new NPM package for QUIC/HTTP3
zilti 3y ago
Node.js shouldn't be used in the first place, just like any server-side JS. But more importantly, put your hacky language-specific servers behind a webserver like nginx.
0x457 3y ago
Not really. HTTP3 has little benefit (if any) when talking to a backend server, plus browsers only support QUIC with TLS and you probably don't want to waste CPU cycles terminating TLS on an application server and leave it load balancer (that isn't written in nodejs and supports HTTP3)

lini 3y ago

Is it just me or the graph at the end of the article is not really showing rising adoption in general. It basically shows a couple of spikes - each corresponding to some big company switching their edge servers to HTTP/3 like Alphabet, Meta, Cloudflare. There is no gradual increase. Furthermore, I don't see easy solutions yet for some problems with QUIC - for example browsers still try to establish a TCP connection first unless they know for sure the server supports QUIC. Proxy support for HTTP/3 is still in its infancy, but for many corporate envuronments it is a hard requirement. So outside of the biggest websites, which I admit also take up a large chunk of the network traffic, is QUIC really replacing TCP in the general Internet?

animesh371g 3y ago
The adoption would be gradual and few years down the line, it would be QUIC. The same was true for HTTP/1 and HTTP/2.
gkbrk 3y ago
Yep, and the graph looks like the HTTP 3 adoption spikes are taking from HTTP 2. It's basically one Google protocol replacing the previous one. And the original and simpler "real" HTTP 1.1 is still going strong.
- marcosdumay 3y ago
  Anyway, the quicker we kill HTTP 2, the best. So, IMO, this is one of the best possible scenarios.
danpalmer 3y ago
> for example browsers still try to establish a TCP connection first unless they know for sure the server supports QUIC As you alluded to here, you can hint a networking implementation with QUIC supporting servers. This feels similar in practice to HSTS Preloading, most of the benefit of full HSTS comes from a small number O(100k? 1m?) of domains being pre-loaded as HSTS supporting, and that's just distributed with browsers now, a fairly straightforward solution. The same could probably be applied for QUIC. > which I admit also take up a large chunk of the network traffic, is QUIC really replacing TCP in the general Internet? I guess this depends on whether you're looking at aggregated traffic, or distinct traffic destinations. Neither of those is more important right! If YouTube/Netflix move to QUIC, that's a very significant amount of benefit for the internet and users. Equally if all wordpress sites on shared hosting disappeared because TCP was no longer supported, that would also be a very significant impact. I think the headline saying "QUIC is displacing TCP for speed" is very fair, but over-extrapolating from this would be going too far.

raffraffraff 3y ago

What happens when you tcpdump QUIC? Hmmm.. edit: "tcpdump -t quic", and I also see that it's supported (as expected) by Wireshark.

freedomben 3y ago
I got bit hard doing network troubleshooting with Wireshark. I was trying to debug connectivity issues and was filtering for HTTP packets, but that was excluding QUIC! Turns out my packets were QUICked through Cloudflare. Figuring that out when hair is on fire isn't my preferred time.

oaiey 3y ago

The chart at the bottom: So google switched it on, and then, let us guess, Facebook and Netflix. Afterwards no growth for a year. Displacing looks different to me. HTTP/2 is growing at cost of HTTP/1 ... so the only conclusion I can draw here, is that HTTP/3 adoption has halted. Do not read that negatively. The users who really needed it (like Google, Facebook, Netfix, ...) are using it and the rest, has it very low on the priority list if at all. I have my doubts that everyone needs HTTP/3, with UDP traffic has network device wise also its disadvantages and library availability and complexity should be lower for HTTP/1 and /2 for the foreseeable future.

freedomben 3y ago
Not disagreeing, but adding: Cloudflare also uses it between browser and proxy, which is a huge amount non-trivial amount of the small internet.

flumpcakes 3y ago

I don't think this article was very good and seems to be written by someone that doesn't really know what they're talking about, or by someone that does but "dumbed down" to a degree where it's conclusion inaccurate. I think HTTP3 is probably doomed for a IPv6 like existence for a long while. While everyone claims that TCP is apparently "too slow", the vast majority of corporate/enterprise settings will just block it. It seems like a technology built by the big players who want to shave a few cycles off each connection and save $millions rather than a practical standard. Do I want to use HTTP3 at home? Yeah, sounds cool. Will I be able to use it at work? Probably not for 5+ years.

api 3y ago
HTTP3 doesn't have the same chicken-or-egg problem as IPv6. It runs over UDP. IPv6 is a full protocol rev which takes a lot longer to accomplish. Once a large multi-vendor network is deployed revving the base protocol is really hard.
- ronsor 3y ago
  Not to mention the companies backing it are so large and critical they can simply mandate it and enterprises will just have to deal with it, somehow.
  - londons_explore 3y ago
    so far, there is no reason to mandate http/3. There is barely any infrastructure cost to running a dual HTTP/1.1 and HTTP/3 setup. And the two are so similar to application developers that there is no reason to mandate anyone move over. However... It only takes one killer feature not compatible with HTTP/1.1 (eg. realtime VR with a stream per eye, and it turns out HTTP/1.1 can't do realtime bidirectional streams), and suddenly everyone will start turning off HTTP/1.1 services and replacing it with a page saying "please upgrade your web browser".
  - api 3y ago
    That part is great. It uses UDP, which means it helps prevent UDP from being sidelined or blocked by middleboxes. That in turn helps prevent the Internet from becoming a de-facto HTTP-only network, which was a trend that was kind of happening in the 20-teens and had me concerned.

nottorp 3y ago

"The big a-holes implemented it so you should use it too" ? That's what I get from the article. What are the advantages of that thing if you're not at Google/Facebook scale?

clbrmbr 3y ago

I’m a bit concerned that the ease of modifying the parameters will lead to Congestion Collapse. It’s been possible to cheat with TCP but most people don’t bother because it would require a kernel recompilation. Or did this ship sail a while ago with various other UDP-based reliable transports, streaming media, etc?

londons_explore 3y ago
If congestion collapse happens on the wider internet, I predict that it would take mere hours for sysadmins to come up with a temporary fix, and within months it'll become common for all core routers to have bloom filters of common src/dst IP pairs and de-prioritize anyone sending more than their fair share of traffic on a congested link.
wmf 3y ago
99% of QUIC traffic is coming from a handful of CDNs (Netflix, Google, Meta, etc.) and they have no incentive to collapse the Internet.

kd913 3y ago

I feel the main limitation over here is hardware optimisation support. With TCP you have the congestion control algo baked in hardware, tcp segment and checksum offload. You can pass things directly to the NIC for massive latency, bandwidth and offloading processing away from the cpu. A properly tuned system with a user space networking stack with ctpio, hardware offload and proper tuning beats the pants of QUIC for latency. It is possible to get some of the same benefits I guess with GSO. In any case, the slow hardware support here I suspect is a bottleneck. You may not get much benefit given more layers are binary/encrypted and not visible to hardware. The above is not relevant for hyperscalers like Google I imagine where they can make the hardware and the sheer amount of customers offer bandwidth benefits.

jabart 3y ago
The internet itself is not properly tuned and distance is an issue. On a local lan, sure a TCP tuned system will do amazing. On the public internet where who knows where your packet is going it's an optimal but not tuned system with latency TCP wasn't designed for. Also a modern CPU with SIMD/AVX can handle a lot of traffic in user space. UDP also has a checksum in it's packet header.
- kd913 3y ago
  For hyperscalers in the cloud and low latency finance, tcp is likely still king. You do not want things running on CPU as that is compute that could be sold to someone else. This needs an easy way to offload to a specialised hardware accelerator.
  - jabart 3y ago
    https://aws.amazon.com/blogs/aws/new-http-3-support-for-amazon-cloudfront/ https://aws.amazon.com/blogs/aws/new-http-3-support-for-amaz... Seems AWS is doing just fine with it. They also have built their own custom chipsets though I don't see a mention of it offloading QUIC to those chips.
    - 3y ago

superkuh 3y ago

TCP also supports allowing people you've never met to connect to your IP without you getting the permission of a third party first and regularly. QUIC requires continued permission being allowed by some third party corporation. Baking the requirement for CA TLS into the protocol is fine for corporate uses but the internet is far more than just corporate uses. Sure QUIC may be faster, but only as long as you keep getting permission from your TLS CA. Once that stops it's very, very, slow. QUIC is fragile and like other CA TLS things: anything built with it will have a lifetime of only a few years without being updated. Do we really want to base our web protocol (and other things) on a system that will only allow machines updated in the last $fewyears to participate? Additionally, the claims of the use rate for the various HTTP versions is flawed in that it is not going per webserver or domain, but instead just counting traffic and of course the megacorp flows it knows about will dominate (they're not checking every webserver). Looking where the light is fallacy.

brlewis 3y ago
> Sure QUIC may be faster, but only as long as you keep getting permission from your TLS CA. Once that stops it's very, very, slow. QUIC is fragile and like other CA TLS things: anything built with it will have a lifetime of only a few years without being updated. For me, letsencrypt has been set-and-forget for at least 5 years. I use it with nginx, which is in front of several servers including a Jetty 5 server. Jetty 6 was released in 2006. You can configure which CAs you trust as well, so TLS isn't really any more of a centralization problem than DNS is.
- superkuh 3y ago
  What did you do when acme1 was deprecated (for acme2) and stopped working with LetsEncrypt? That certainly required changes in your setup that would break otherwise. How did you handle the expiration of the LE root cert? Maybe can still access your TLS wrapped site but people using an RSS reader who's cert store was set up in 2019 can't. All these things, both on your side and the client side apply very, very broadly. It may work for you from your setup but I can assure you that isn't universal or even normal. I love LE and I think it's the least worst solution. But mandating CA TLS into a protocol is very bad for human use cases. HTTP+HTTPS prevents this fragility. HTTP/3 with it baked in is fragile. Also, you don't need DNS to communicate with an IP.

apitman 3y ago

I'm a fan of QUIC, but these articles are always heavy on explanations and light on data. I understand in theory how head-of-line blocking can cause serious issues on a lossy network, but by this point I would expect to see a ton of data backing that up in real-world usage from Google and Cloudflare. One specific question I've had is on a lossy network are there really that many situations where you would have packet loss on one QUIC stream but not most/all the others? I don't doubt that's true but I would love to see a breakdown. Also, what's the crossover point between opening multiple TCP streams and doing round robin across them? Maybe you only need 3-4 TCP connections to estimate the HOL advantages of QUIC. I will admit fewer RTT handshakes is a more obvious win.

KMag 3y ago
> One specific question I've had is on a lossy network are there really that many situations where you would have packet loss on one QUIC stream but not most/all the others? I don't doubt that's true but I would love to see a breakdown. If an intermediate router is using Randomized Early Detection (RED) and is congested within the randomized packed drop region, then you could easily see one random packet in the middle of a stream dropped, with other streams unaffected.
adgjlsfhk1 3y ago
> One specific question I've had is on a lossy network are there really that many situations where you would have packet loss on one QUIC stream but not most/all the others? This isn't the advantage. The advantage is that if you have 10 different streams and a low loss rate, the impact of each packet lost would be much smaller. Consider a voip call with an architecture where each person's audio is served as a separate stream from a central server. With head of line blocking, every packet lossed causes a slight stutter in the whole conversation because even if the lost packet is from someone not talking, you have to wait for that packet of silence before decoding the packet from the person speaking. With QUIC, the extra latency only affects the individual stream, so the conversation won't stutter when the person not talking wasn't the one who's packet got lost.
- apitman 3y ago

Ragnarork 3y ago

It's a bit perplexing that an article that make some claims about QUIC speed over TCP has exactly zero benchmarks, numbers, anything to back that up besides theory. I could be inclined to believe it but I'd like to know by which factor, in which circumstances, with real examples and numbers.

jeffbee 3y ago
What would you want to compare? Google Quiche vs. Linux? Chrome vs. Windows TCP? What version of Linux, Windows, or Chrome? Under how much delay, loss, etc? There's a large parameter space to sweep.
- unethical_ban 3y ago
  Uh, how about "something" vs. "nothing". Start with QUIC vs. TCP. Same OS, same client/server software. Edit: since the system says "I'm posting too quickly, slow down" despite not posting for an hour because they don't use accurate error messages here, let me say : I find it ironic that so many keystrokes below are used in a meta-discussion about the quality of comments here, when others are posed a legitimate question about the topic. Nevermind the article they seem to defend gets the order of a TCP 3 way handshake wrong. And since I can't respond to them, I can only d*wnv*te or fl*g them.
  - refulgentis 3y ago
    [flagged]
    - unethical_ban 3y ago
      I wasn't demanding it like the thread-starter was. I was pointing out that a benchmark would be like-for-like and that none of jeffbee's examples made sense.
      - refulgentis 3y ago

0xbadcafebee 3y ago

Curl HTTP/3 performance (https://news.ycombinator.com/item?id=39163948 https://news.ycombinator.com/item?id=39163948) shows HTTP/3 is the slowest performer compared to HTTP2 and HTTP1.1 This paper from 2017 showed QUIC performance was poor: https://arxiv.org/pdf/2310.09423.pdf https://arxiv.org/pdf/2310.09423.pdf With no evidence to the opposite, the article's claim that QUIC is displacing TCP for speed is dubious at best.

belthesar 3y ago
The comments of that article cite a couple things: * The version of Caddy used for the test was missing several recent updates that significantly improve its performance. * Performance improvements for QUIC have always been about removing/recovering from dynamic network connections, and are about running connections at scale. Simple HTTP 1 requests in environments where there are far less shenanigans going on will always be fast. (lib)curl powered requests being single threaded requesting across the local network stack are not representative of the types of performance gains to expect in an HTTP/3 world.
jeffbee 3y ago
If localhost is your use case, these results are for you. Many others may be operating on real networks. Perfect, lossless, zero-delay networks are of no interest when evaluating protocols. Under those conditions literally any protocol can do the job. The exercise only becomes interesting in the real world where delay and loss exist.

hkgjjgjfjfjfjf 3y ago

[dead]

DarkmSparks 3y ago

most tcp work is done in the network hardware these days isnt it? how can a userpace protocol possibly hope to be faster than that?

lxgr 3y ago
"Fast" here means high throughput and/or low latency, not low on compute resources. If you're compute-bound (or using a userspace transport layer would make you compute-bound), this might not be a great choice, but many network-facing services aren't.
wmf 3y ago
No, TCP is not in hardware and Linux (the most popular server OS) has a policy to never allow full TCP offload.
- DarkmSparks 3y ago
  Not convinced, but sounds like you know what you are talking about nginx has quic support now https://nginx.org/en/docs/quic.html https://nginx.org/en/docs/quic.html Do you fancy knocking up some benchmarks of typical server loads on accross some 100mbs/1gbs/10gbs connections and chrome headless?
  - wmf 3y ago
    As I said in another comment, I still expect TCP to use fewer cycles than QUIC due to kernel optimizations and partial NIC offload. IIRC people have done benchmarks showing this. Saturating 10G or even 100G with either protocol should be easy enough these days but if you want to do 400G or more from a single server then it matters.

spullara 3y ago

It is currently almost certainly not faster in all cases. https://github.com/icing/blog/blob/main/curl-h3-performance.md https://github.com/icing/blog/blob/main/curl-h3-performance....