46 ms·

HTTP/3 adoption is growing rapidly

632 points by skilled 3y ago

bullen 3y ago
I don't understand the arguments. 1) TCP needs to establish a connection. That is ZERO problem. 2) Encryption is needed in the bottom stack! WHY? Idiots are eating the world.
- userbinator 3y ago
  Look at the ones pushing this stuff, who they work for, and what interests they have. It's easy to see why a lot of things are the way they are, when you realise their true purpose.
- adgjlsfhk1 3y ago
  The reason to put encryption at the bottom of the stack is that it helps with Hyrum's Law. Part of the reason TLS is so hard to change is that everyone can see all the data and therefore anyone on the path your package takes might make decisions based on the data. This code will break if you try to update anything (even if the thing they are observing is something that they shouldn't have been observing). By encrypting everything possible, you remove the ability for everyone in the middle to see or depend on any details of the higher layers.
  - bullen 3y ago
    Enjoy debugging things when everything is encrypted... and then your certificate provider goes down (or removes you because they don't like you) and you can't even connect...
- cryptonector 3y ago
  > 2) Encryption is needed in the bottom stack! WHY? One reason is that hardware (NICs) can offload encryption more easily when it's closer to the lowest end-to-end layer (i.e., no lower than IP). So IPsec and QUIC are easy to offload, but TLS-over-TCP less so. It especially helps that there is no need to buffer up part of the TCP stream so as to get whole TLS records to decrypt.
  - bullen 3y ago
    You don't need hardware encryption if you don't need encryption. You are solving 1% of the problems with 99% of the energy.
1vuio0pswjnm7 3y ago
"Why TCP is not optimal for today's web" Hmm, what is "today's web". Surveillance and advertising. Let's be reasonable. Not every web user is exactly the same. Some might have diferent needs than others. People might use the web in different ways. What's optimal for a so-called "tech" company or a CDN might not be "optimal" for every web user. The respective interests of each do not always align on every issue. "Over time, there have been many efforts to update TCP and resolve some of its inefficiencies - TCP still loads webpages as if they were single files instead of a collection of hundreds of individual files." To be fair, not all web pages are "collections of hundreds of individual files", besides the file/path that the web user actually requested, that the web user actually wants to see. For example, I use TCP clients and a browser (HTML reader) and I only (down)load^1 a single file, using HTTP/1.x. This allows me to read the webpage. Most of the time when I am using the web, that's all I'm trying to do. For example, I access all sites submitted to HN this way. I can read them as text just the same as someone using HTTP/3. Hence I can discuss this blog post in this comment using HTTP/1.1 and someone else can discuss the same blog post using HTTP/3. The text that we are discussing is contained in a single file. So what are these "collections of hundreds of individual files". Well, they might come from other sites, i.e., other domains, other host IP addresses. Chances are, they are being used for tracking, advertising or other commercial purposes. And I am ignoring all the HTTP requests that do not retrieve files, e.g., behavioural tracking, telemetry, (incorrectly) detecting whether an internet connection exists, etc. HTTP/3 seems to downplay the concept of requests made by a web user, the idea of user agency. It allows servers to send files to the web user that the web user never requested. Surely these will only be files the user did not know they actually wanted. For example, ads. This is called something like "server push". IMHO, the best websites are not comprised of pages that each contain hundreds of individual files, sourced from servers to which I never indicated an intent to connect. The best websites are, IMHO, ones with hundreds of pages where each is a single file containing only the information I am interested in, nothing else. No tracking, no ads, no manipulative Javascripts, no annoying graphical layouts, no BS. HTTP/1.1 provides an elegant, efficient method to request those pages in sequence. It's called pipelining. Multiple HTTP requests sent over a single TCP connection. No multiplexing. The files come from a single source, in the same order as they were requested. Been using this for over 20 years. (If the web user wants "interactive" webpages, filled with behavioural tracking and advertising, then this is not optimal. But not every web user wants that. For non-interactive, 100% user-controlled information retrieval HTTP/1.1 is adequate.) Not every web user is interested in a commercialised web where the protocols are optimised for tracking and programmatic advertising. The early web had no such complexity nor annoyances. HTTP/3 can co-exist with other, simpler protocols, designed by academics not advertising service companies or CDNs. The other protocols may or may not be as suitable for advertising and commercial use. HN changed the title from "Why HTTP/3 is eating the world" to "HTTP/3 adoption is growing rapidly". Perhaps HTTP/3 is being hyped. If it is a protocol "optimised" for commercial uses that benefit the company who authored the specification, this would not be surprising. Interestingly, the commentary in this thread mainly focuses not on HTTP/3 but on QUIC. QUIC reminds me of CurveCP, an earlier UDP-based TCP replacement. I have run HTTP/1.1 over CurveCP on the home network. In theory shouldn't it be possible to use any protocol with QUIC, via ALPN. Something like printf 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n' \ |openssl s_client -quic -alpn http/1.1 -connect 93.184.216.34:443 -ign_eof 1. The term "load" is interesting. It's more than downloading. It's downloading code plus running it, automatically, without any user input. There is no opportunity to pause after the download step to choose whether or not to run someoone else's code. That's "today's web". If one uses a "modern" web browser issued by an advertising-supported entity. The browser I use is not issued by an advertising-supported company, AFAIK it's originally written by university staff and students; it does not auto-load resources and it does not run Javascript. There is no waiting for a site to "load".
deleted 3y ago
[deleted]
weird-eye-issue 3y ago
"In fact, the blog post you’re reading right now was probably loaded over HTTP/3!" It actually isn't. But some of the 3rd party resources like a captcha script are loaded over HTTP3
- diggan 3y ago
  Seeing the same thing both in Firefox and Chrome, every response from blog.apnic.net comes over HTTP/2, none of the HTTP/3 ones are from any apnic.net requests. Strange that a registry, who should have really good idea about what kind of infrastructure they run, would get which protocol they're using wrong.
- krichprollsch 3y ago
  The original blog post is served hover http/3 as far as I can see. https://pulse.internetsociety.org/blog/why-http-3-is-eating-the-world https://pulse.internetsociety.org/blog/why-http-3-is-eating-...
- dgb23 3y ago
  Looks like they forgot that we are hitting a cache that isn't configured the same way.
  - weird-eye-issue 3y ago
    Appears to be Cloudflare's APO cache. I wonder why they haven't toggled HTTP/3 on in their Cloudflare dashboard (Just confirmed my sites with APO are being served with HTTP/3)
- ReactiveJelly 3y ago
  And I can't use HTTP/3 over Tor cause Tor only forwards TCP lol We'll get there
WJW 3y ago
Growing from 0 to ~27% of traffic in 2 years is great, but the graph from TFA shows that it was not a gradual increase but rather two big jumps in adoption: - One in mid 2021, to ~20%. - A second one in July 2022, to ~29%. Since then the traffic share has been pretty flat. I don't think that counts as "eating the world" at all tbh.
- sph 3y ago
  Is the graph showing the number of requests served by HTTP/3, or the number of individual hosts that support it? I believe it's the former, and it's explainable by the fact that most people these days visit only the same handful of siloes: Google, Amazon, Facebook, Twitter and Youtube probably make 90+% of all anonymised requests seen by Mozilla. But I doubt even 20% of global webservers are HTTP/2 ready, let alone HTTP/3. So HTTP/3 is eating the world, if by world you only count FAANG websites, which sadly seems to be the case. Remains to be seen how many websites are hidden behind tech's favorite MITM, Cloudflare, which might make figures a little harder to discern.
- buro9 3y ago
  Right, and those big jumps are more to do with large Cloud providers or proxy providers switching it on, and less to do with web applications themselves switching it on. It's great that the upgrade path for the end clients is so easy, but it doesn't reflect that the environment for web application developers has shifted towards HTTP/3
- taf2 3y ago
  July 2022 maybe linked to cloudfront supporting it 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...
- dchftcs 3y ago
  There's a cookie I took out of a package for a nibble. You could say I'm eating that pack of cookies. Not justifying the sensationalist title though.
- ascar 3y ago
  Intetestingly (or rather not surprising at all?) http3 is eating away the http2 traffic, while http1 just stays on a very slow decline. Since http1 webservers are usually stuck there for a (more or less) good reason, they won't be converting to http3 anytime soon, while already more modern webservers are easier to upgrade from http2 to 3.
tomalaci 3y ago
Will the spread of QUIC improve low latency services such as video game servers? Last I checked they were using either gRPC or homecooked protocol over UDP.
- tuetuopay 3y ago
  Not really. Video game servers definitely don't want session oriented protocols, and don't really care about dropped packet. Lost the packet with the player position? It comes at a regular interval, so we'll get it anyways, and more up to date! All they care about is the best latency possible. As for the non-time sensitive stuff in games (scoreboard, nicknames, etc), there is no real benefit there either. It's not time sensitive, the connection get opened once at the start and that's it. Where QUIC really shines if for fast connections and many streams, ie the web where a page will need 500 resources spread across 100 hosts. In this case session establishment speed and parallel streams are paramount.
- deleted 3y ago
  [deleted]
- KingMob 3y ago
  Not a whole lot, but the connection identifier will probably make it much more seamless when your phone switches from wifi to mobile networks. Right now, that's somewhat disruptive; with QUIC, you might not even notice.
- plopz 3y ago
  For games running on the browser absolutely yes. They are all currently on tcp and being able to switch to udp is huge.
sschueller 3y ago
What? I just updated my nginx config to HTTP/2. V3 still seems to be experimental in nginx: https://nginx.org/en/docs/http/ngx_http_v3_module.html https://nginx.org/en/docs/http/ngx_http_v3_module.html
- olavgg 3y ago
  Anything which involves more work than dnf/apt install nginx isn't worth wasting time on. So http2 for now.
- yakubin 3y ago
  It’s enabled by default in Caddy.
- oblio 3y ago
  And Apache? Edit: https://stackoverflow.com/questions/60324166/is-there-any-way-to-implement-http-3-quic-in-apache-http-server https://stackoverflow.com/questions/60324166/is-there-any-wa... No plans as of right now.
- lost_tourist 3y ago
  You'll be fine, there will be http2 for the next couple of decades at least. By then you'll be saying "Siri set up nginx for reverse proxying my new email server and open-facebook federated instance, oh and turn on the coffee maker, i'm gonna grab another 15 minutes of sleepy time"
- claar 3y ago
  Yeah, and not available in nginx stable yet (currently nginx v1.24) - only available in nginx mainline (v1.25+). More info at https://quic.nginx.org/ https://quic.nginx.org/
ThePhysicist 3y ago
QUIC is a really nice protocol as well, I find. It basically gives you an end-to-end encrypted & authenticated channel over which you can transport multiple streams in parallel, as well as datagrams. A lost packet in a given stream won't block other streams, and the overhead is quite low. Both ends of the connection can open streams as well, so it's really easy to build bidirectional communication over QUIC. You can also do things like building a VPN tunnel using the datagram mechanism, there are protocols like MASQUE that aim to standardize this. Apple is using a custom MASQUE implementation for their private relay, for example. HTTP/3 is a protocol on top of QUIC that adds a few more really interesting things, like qpack header compression. If you e.g. send a "Content-type: text/html" header it will compress to 2 bytes as the protocol has a Huffman table with the most commonly used header values. I found that quite confusing when testing connections as I thought "It's impossible that I only get 2 bytes, I sent a long header string..." until I found out about this.
- promiseofbeans 3y ago
  Woah that's actually pretty neat about header compression. Thanks for sharing!
  - ithkuil 3y ago
    it builds on the experience gathered with the HTTP/2 HPACK header compression.
- culebron21 3y ago
  That makes sense -- if a packet is lost, and it affected just one asset, but you're on TCP, then everything has to wait till the packet is re-requested and resent.
  - afiori 3y ago
    I wonder why the OS does not let the application peek at upcoming incomplete data.
    - 3y ago
culebron21 3y ago
Read up until author is confusing HTTP/1 with TCP, claiming that it's TCP's fault that we must make multiple connections to load a website. Actually, TCP allows continuous connection and sending as much stuff as you want -- in other words, stateful protocol. It was HTTP/1 that was decidedly stateless. Sessions in web sites are direct consequence of the need to keep state somewhere.
- fidotron 3y ago
  The whole HTTP request/response cycle has led to a generation of developers that cannot conceive of how to handle continuous data streams, it's extraordinary. I have seen teams of experienced seniors using websockets and then just sending requests/responses over them as every architecture choice and design pattern they were familiar with required this. Then people project out from their view of the world and assume the problem is not with what they are doing but in the other parts of the stack they don't understand, such as blaming TCP for the problems with HTTP.
  - culebron21 3y ago
    I switched from web dev to data science some years ago, and surprisingly couldn't find a streaming parallelizer for Python -- every package assumes you loaded the whole dataset in memory. Had to write my own.
    - elashri 3y ago
      There are many packages that can do that, like Vax [1] and Dask [2]. I don't know exactly your workflow. But the concurrency in python is limited to multiprocessing, which is much expensive than threads which usually a typical streaming parallelizer will use outside python world. [1] https://vaex.io/docs/index.html https://vaex.io/docs/index.html [2] https://docs.dask.org/en/latest/ https://docs.dask.org/en/latest/
    - bboygravity 3y ago
      Just curious: why would you not load the entire dataset "into memory" ("into memory" from a Python perspective)? On an average desktop/server system the OS would automatically take care of putting whatever fits in RAM and the rest on disk. Or are the datasets large enough to fit on neither?
ta1243 3y ago
I have a corporate laptop which funnels all traffic through zscaler. I was somewhat surprised when I was getting a different IP address on ipinfo.io (my home IP) compared with whatsmyip.org (a zscaler datacentre IP) Curlling ipinfo.io though came back with the zscaler address. Turns out they don't funnel UDP via zscaler, only TCP. Looking into zscaler, https://help.zscaler.com/zia/managing-quic-protocol https://help.zscaler.com/zia/managing-quic-protocol > Zscaler best practice is to block QUIC. When it's blocked, QUIC has a failsafe to fall back to TCP. This enables SSL inspection without negatively impacting user experience. Seems corporate IT is resurging after a decade of defeat
- wkat4242 3y ago
  Zscaler is pure crap, we use it at work too. It's especially hard to configure docker containers for its proxy settings and ssl certificate. When I test something new in our lab I spend 10 minutes installing it and half a day configuring the proxy.
  - fein 3y ago
    It causes minor annoyances with ssl + maven as well, which can be fixed by -Dmaven.wagon.http.ssl.insecure=true. Well, at least they tried I guess.
    - ta1243 3y ago
      No, setting any variable including the line "http.ssl.insecure=true" Is not a fix under any circumstance.
      - Thiez 3y ago
        Sure it is. The org insists on making your life difficult, and you just want to get your work done. If they really cared about security they would prioritise fixing stuff like this, but they don't, so you know they don't really care, it's just for show and a need for control. And if they don't really care about security, why should you?
wkat4242 3y ago
I'm extremely sceptical of anything proposed by Google especially because they are building some truly evil stuff lately (like FLoC/Topics and WEI). I really view them as the enemy of the free internet now. But QUIC doesn't really seem to have their dirtbag shadow hanging over it. Perhaps I should try to turn it on.
- mixmastamyk 3y ago
  Agree, but topics sounded like an improvement to me.
- jiggawatts 3y ago
  Google just ignored anything Windows needed in HTTP and included everything they needed — to the point that the compression in HTTP/3 is basically tuned for www.google.com and no one else.
kondro 3y ago
I miss when diagnosing server issues meant opening telnet and typing English. But I guess I also appreciate why that couldn’t last.
- KingMob 3y ago
  "When ah was yur age, we had to push our bits 10 miles to tha nearest router in the snow... and it was uphill...both ways!!!"
- mnw21cam 3y ago
  Most servers should still be able to service HTTP/1.0 requests (although you're right they'll probably just reply with a redirect to the HTTPS site).
nmstoker 3y ago
I get that major participants have switched but what's the developer experience like? It's a while since I read up on this but previously it seems relatively hard to get set up for any local usage of http3 - has that changed recently?
MrThoughtful 3y ago
the blog post you’re reading right now was probably loaded over HTTP/3! This made me curious. In the Firefox console, when I enable "raw" for the request headers, I see: GET /2023/09/25/why-http-3-is-eating-the-world/ HTTP/2 So I guess it was not?
243423443 3y ago
Frankly, I am a bit disappointed with the article. I fail to follow the argument that an encrypted header makes it easier to adopt HTTP/3 & QUIC because middleboxes cannot see the header. With HTTP/1.1 & TCP, the middleboxes should not be changing the TCP packets anyway, no? Also, the author does not point out that QUIC builds on UDP instead of directly building on IP like TCP does.
- lemagedurage 3y ago
  Even though they arguably shouldn't, some middleboxes assume that protocols don't change. They have made it hard for protocols such as TCP and TLS to evolve without breaking things. Similarly, middleboxes have made it unviable to deploy protocols that aren't TCP or UDP based. https://en.wikipedia.org/wiki/Protocol_ossification https://en.wikipedia.org/wiki/Protocol_ossification
  - 243423443 3y ago
    I did not know that protocol ossification was a such a thing. Thanks for the link, it's an interesting article. It says that middleboxes near the edge are more likely to be the cause of ossification. Are there any stats about that? Such as some manufacturers or software companies "infringing" on the end-to-end principle more often than others?
    - Karrot_Kream 3y ago
      Not sure about stats but if you hang out in networking forums, you'll see netops complaining about bad implementations of protocols in their networking gear forever. This has been a huge problem in several protocols, everything from SCTP to IPSec to UDP RTSP.
ishanjain28 3y ago
I looked at netflow data for the last 10 days from my router. 75% of the HTTP traffic is HTTP3, 23% HTTP1.1/HTTP2(over TLS) and 2% is plain HTTP.
jalino23 3y ago
I just recently found out that even if browser supports up to http3, it still up to the browsers to decide which protocol to use even if the browser supports http3 too, this was dishearten to find out that you don't have control of forcing the browser to use http2 or 3 specially if you have features that only worked on http3 and was broken on http2, I guess I should have just fixed the implementation on http2
- sassy_quat 3y ago
  [dead]
- scrpl 3y ago
  You don't have control because browser might not support of http3 at all. It's up to browser developers to decide when their support levels are mature enough to use by default. There's no other way of doing it.
SanderNL 3y ago
Imagine you are holding a 200 requests/page bag of excrement and it’s generating too much load on all systems involved. What do we do? Empty the bag? No, we do not. That doesn’t scale. We create the most elaborate, over the top efficient bag-of-excrement-conveyer-belt you ever came across. We’ll move these babies in no time flat. Don’t worry about side-loading 24 fonts in 3 formats and whatnot. Especially do not worry about having to load three different trackers to “map” your “customer journeys”. No sir, your customer journeys are fully mapped, enterprise-ready and surely to be ignored by everyone. We got you covered with QUIC. Reimagining “data transport”, for your benefit. Edit: Of course I didn’t read the article, but now I did and it’s somehow worse than I thought. “Why TCP is not optimal for today’s web”: no answers. There are literally no answers here. Other than, TCP is old. Old things are difficult.
- miohtama 3y ago
  If you do not know the answer yet,as it sounds like you do, but there is a ting of rant there, let me expand what was said in the article: TCP/IP was build for 80s/90s when - Amount of data transferred was low - Data access patterns were different - Most TCP/IP was in university networks - There were no consumer users - Everyone on Internet could be trusted Today we have - 3B more people using Internet - 5B people living in authoritative regimes where the government wants to jail them for saying wrong thing on Internet - Mobile users - Wireless users (subject to different packet loss conditions) - You can stream 4k movies in your pocket - You can search and find any piece of information online under one second To get the low latencies and high bandwidths for mobile links TCP/IP can do it, but QUIC and HTTP/3 does it much better. Plus it's always encrypted, making all kind of middlebox attacks harder.
  - peoplefromibiza 3y ago
    > - 5B people living in authoritative regimes it's actually 1.9B > where the government wants to jail them for saying wrong thing on Internet that happens across all the spectrum of types of systems of government
    - 3y ago
scrpl 3y ago
Few years ago I wrote an article on HTTP/3 that was briefly featured on HN as well: https://news.ycombinator.com/item?id=24834767 https://news.ycombinator.com/item?id=24834767 I can't agree with author about it eating the world though. It seems like only internet giants can afford implementing and supporting protocol this complex, and they're the only ones who will get a measurable benefit from it. It is an upgrade for sure, but an expensive one.
- lemagedurage 3y ago
  It's not all bad, you can start using Caddy for your new project and serve http3 right now.
  - CharlieDigital 3y ago
    ASP.NET also has support: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel/http3?view=aspnetcore-7.0 https://learn.microsoft.com/en-us/aspnet/core/fundamentals/s... (minus macOS)
Andrew018 3y ago
[dead]
JakaJancar 3y ago
One thing where the semantics are not the same between HTTP/1.1 and HTTP/2/3(?) is the `Host` header, which is often (always?) gone in the latter in favor off the `:authority` pseudo-header. Apps/scripts may rely on `Host`, but the underlying HTTP/2 server software might not normalize/expose it in a backwards-compatible way (e.g. Hyper in Rust). Technically I guess it’s the browsers fault it doesn’t set it. I would be curious to know if there are other such discrepancies that apps migh run into when enabling HTTP/2/3.
- jiggawatts 3y ago
  We saw authentication errors in some very old ASP.NET apps that forced us to roll back to HTTP 1.1 after an attempt to upgrade to HTTP/2. Google is the main driver of HTTP 2 and 3, so they just didn’t bother to include features used primarily by Windows.
deleted 3y ago
[deleted]
goalieca 3y ago
I always thought GRPC would be an interesting candidate for http/3 but there's been no real movement in that direction. https://github.com/grpc/proposal/blob/master/G2-http3-protocol.md https://github.com/grpc/proposal/blob/master/G2-http3-protoc...
djha-skin 3y ago
I hate QUIC. I don't like that now there's an implementation of TCP in user space, and I find binary protocols nauseating, particularly when 90% of their value can be achieved using gzip over the wire. Not to mention corporate firewalls generally block UDP by default. UDP? Really? The design makes a lot of sense if you're talking about a remote client because now you can update the TCP stack without regard to when the user updates Android or whatever, but like GraphQL I feel like it's a technology that bends over backwards for the client. Maybe that's necessary and I get that, but whenever possible for other services that don't need to be sensitive to rural users I prefer to use things that make sense. REST and HTTP 1.1 over TCP continue to make sense.
FuriouslyAdrift 3y ago
Yeah... that's an unsecured VPN. Blocked.
- BitPirate 3y ago
  With this line of reasoning, you will have to block TCP as well.
anilshanbhag 3y ago
You can enable HTTP/3 with one click in Cloudflare. Just enabled it after reading this for Dictanote.
superkuh 3y ago
HTTP/3 is becoming more popular because Microsoft and Google white-washed google's QUIC through the IETF. It's popular because what they call "HTTP/3" is perfectly designed for meeting the needs of a multi-national corporation serving web content to millions of people. But it's only megacorps using it for their walled gardens. It's a terrible protocol for the human person web. You can't even host a visitable website for people who use HTTP/3 without getting the permission of a third party corporation to temporarily lend you an TLS cert. Once Chrome drops HTTP/1.1 support say goodbye to just hosting a website as a person free from any chains to corporate ass-covering. While LetsEncrypt is benign now, it won't always stay that way as more and more people use it. Just like with dot Org it'll go bad and there'll be nowhere to run. TLS only HTTP/3 is just as bad for individual autonomy as web attestation in it's own way.
- lost_tourist 3y ago
  Can't you sign your own certificates? I honestly haven't done any work with http/3 so it's a sincere question.
  - superkuh 3y ago
    I could. But that wouldn't help make my website visitable for anyone. I'm not trying to access my own hosted site. I want a random person on the other side of the world who I've never met and will never meet to be able to visit my website. That's the point of public websites. Generating my own root cert and using it does not help with this at all since no one else will have it installed nor install it unless I'm already good friends with them. Installing a root cert in the various trust stores is no simple task either. The easier self-sign with no root cert also doesn't help because every current implementation of HTTP/3 does not support self-signed certs.
    - lost_tourist 3y ago
      I mean you have to do that with https now if you don't go with one of the big guys? How is that any more dangerous to the end user than just going to an http site that they don't know personally? The risks are the same as far as malware.
akmittal 3y ago
Just saw Hacker news uses http/1.1 and its plenty fast. I wonder if they explored moving to http2/3
- jefftk 3y ago
  I wouldn't expect HN to gain much by moving to HTTP/2 or HTTP/3. Loading this page with a cold cache is just 60kB, divided as 54kB of HTML, 2kB of CSS, and 2kB of JS, plus three tiny images. And on follow-up pageviews you only need new HTML. If the whole web was like this then we wouldn't need new versions of HTTP, but of course it isn't.
  - netol 3y ago
    But would it gain something? I'm wondering if HTTP/3 could be enabled in one of my websites, which is even much smaller, and which has no blocking requests. I don't mind if the gains are small, as long as the impact is not negative for most visitors. I'm mostly concerned about some of my visitors visiting the website through an unreliable connection (mobile).
    - jefftk 3y ago
      It should gain a small amount; it is a more efficient protocol, with better compression and including 0-RTT for repeat visitors. But I doubt it would be noticeable on such a light site.
  - adgjlsfhk1 3y ago
    The main thing it would get is 2x faster loading on high latency networks (because the TLS handshake happens with the same packets as the QUIC handshake).
  - qingcharles 3y ago
    Yes, I use this site as the paragon of page weight. When other sites I visit are routinely throwing 200MB (MB!) pages at me, this site is throwing 60KB, of which 54KB is content! It's the benchmark I measure all my design against.
xg15 3y ago
> This means that metadata, such as [...] connection-close signals, which were visible to [...] all middleboxes in TCP, are now only available to the client and server in QUIC. Do I understand that correctly, that middelboxes are not supposed to know whether or not a connection still exists? Then how exactly is NAT going to work?
- Vecr 3y ago
  Works the same way it works with UDP (because it is UDP), with a timeout.
  - xg15 3y ago
    But then the "close signal" is in practical terms not encrypted at all: You close a connection by not sending data for 30 seconds. That's a signal that's plainly visible to network intermediaries. So then why not eliminate one risk of bad middlebox heuristics and expose the actual flag?
    - Vecr 3y ago
      Not sending an explicit signal prevents certain injection attacks, but I'm not sure how much that would matter in practice. They would have to be some sort of off-path attack so the attacker can't just end the connection by blocking it.
bdd8f1df777b 3y ago
As a Chinese user who regularly breaches the GFW, QUIC is a god send. Tunneling traffic over a QUIC instead of TLS to breach the GFW has much lower latency and higher throughput (if you change the congestion control). In addition, for those foreign websites not blocked by GFW, the latency difference between QUIC and TCP based protocol is also visible to the naked eye, as the RTT from China to the rest of the world is often high.
- meowtimemania 3y ago
  RTT?
  - Dylan16807 3y ago
    Round-trip time.
  - deleted 3y ago
    [deleted]
- svara 3y ago
  What do you need to change for congestion control?
  - bdd8f1df777b 3y ago
    The default congestion control is CUBIC, which is very slow for connections between China and the rest of the world. Google's BBR is a great improvement, and sometimes I use "brutal" congestion control, which is basically a constant speed.
- girishso 3y ago
  Any specific tool you can recommend?
  - bdd8f1df777b 3y ago
    hysteria and tuic. Both are based on QUIC. But you need a server outside China though.
iamcalledrob 3y ago
QUIC's promise is fantastic, and latency-wise it's great. And probably that's what matters the most for the web. However I have run into issues with it for high-throughput use-cases. Since QUIC is UDP based and runs in user-space, it ends up being more CPU bound than TCP, where processing often ends up being done in the kernel, or even hardware. In testing in a CPU constrained environment, QUIC (and other UDP-based protocols like tsunami) capped out at ~400Mbps, CPU pegged at 100%. Whereas TCP+TLS on the same hardware could push 3+Gbps. It'll be interesting to see how it plays out, since a goal of QUIC is to be an evolving spec that doesn't get frozen in time, yet baking in to the kernel/hardware might negate that.
- wofo 3y ago
  Luckily, there are ways to reduce syscalls (like Generic Segmentation Offload and other tricks[1]). But I agree that not having things run in the kernel makes it more challenging for high-throughput scenarios. [1] https://blog.cloudflare.com/accelerating-udp-packet-transmission-for-quic/ https://blog.cloudflare.com/accelerating-udp-packet-transmis...
- Karrot_Kream 3y ago
  Is this mostly syscall overhead? Could io_uring and friends solve some of this?
antirez 3y ago
It's incredible that we need to assist to this farce where it is pretended that thanks to the tech giants the web is becoming faster. The average web latency is terrible, and this because of the many useless framework/tracking layers imposed by such tech giants. And HTTP/3 is a terrible protocol: for minor improvements that are interesting only for the narrow-data-driven mentality of somebody in some Google office, the web lost its openness and simplicity. Google ruined the Internet piece by piece, with Adsense and AD-driven SERP results, with complexity, buying and destroying protocols one after the other, providing abandonware-alike free services stopping any potential competition and improvement.
- ReactiveJelly 3y ago
  Google didn't force anyone to put ads on their blogspam sites.
c7DJTLrn 3y ago
Simple HTTP/1.1 would've been perfectly adequate if the web wasn't collapsing under its own weight made up of megabytes of JavaScript firing off tens of requests a second.
- y04nn 3y ago
  I'm not sure about that. I noticed that some websites (even simple blogs) felt instantaneous when loading (after pressing enter or clicking a link), way much faster than other websites. So I opened the dev tools, and the first request was HTTP/3. But all resources were still loaded with HTTP/2! HTTP/3 really brings something not negligible. Those accumulating TCP/TLS handshakes (+WIFI high latency) are really a burden and degrade the user experience when you have a fast internet connection.
tomohawk 3y ago
Since QUIC is UDP based, there are performance issues that become apparent at higher rates. In TCP, a single write can write a large amount of data. You can even use sendfile to directly send the contents of a file to a TCP socket, all in kernel space. In UDP, you need to write out data in chunks, and you need to be aware of the link MTU as IP fragments can be very bad news at higher rates. This means an app needs to context switch with the kernel multiple times to send a large amount of data, whereas only a single context switch is required for TCP. There are newish system calls such as sendmmsg which alleviate the strain a bit, but they are not as simple as a stream oriented interface. The QUIC implementations are primarily in user space, so you end up with multiple QUIC implementations in whatever language on any given system. Hopefully Linux will add a QUIC kernel implementation that will bypass and overcome the traditional UDP shortcomings in the current stack.
- BitPirate 3y ago
  Isn't the syscall overhead solved by GSO and GRO?
  - tomohawk 3y ago
    Not necessarily. With GSO, you can send near 64K datagrams, which will then get split into MTU sized datagrams in the driver or on the card. But if you're sending a 1G file, that's a lot of 64K writes. And then you have to consider what is seen on the other end. Is GRO configured on all the endpoints these datagrams are going to? They won't necessarily see those near 64K datagrams, but lots of smaller ones.
rc_mob 3y ago
Why does this article read like propaganda. Its pretty technical and I don't understand all of it and it still reads like propaganda.
- kzrdude 3y ago
  I was thinking the same thing. One item I thought about was "H/3 Adoption Grows Rapidly" is paired with a graph that shows that adoption is absolutely flat over the last year.
imetatroll 3y ago
This made me realize that I don't really understand basic concepts. For instance, when connecting to a webserver on a given port, is it up to the kernel to take packets of data and assemble them into ... streams (? - not sure about the correct term here) that the server can then read and process? For some time I had the incorrect idea that a connection to a webserver would ultimately get its own port on the server side. In reality the only port that is randomly assigned is on the client side (from what I understand). Based on the above, when a server does not use threading to process multiple incoming streams (?), the kernel is, I guess, buffering up data from multiple clients while waiting for the server process to read and process the one stream the kernel has assembled for it? Or I am still completely a dunce about how this works and the above is still wildly incorrect. I would like to better understand but honestly I don't know where to start. On a very low level even on a threaded server that can receive and process multiple HTTP requests how exactly is the incoming data on the single server socket turned into something that each thread uses for a particular client? Especially in the context of something like http smuggling... I just don't understand the fundamental mechanism of multiple tcp connects on a single server port are turned into individual http requests... With http smuggling it makes it sound like all of the data is actually just a single stream. But if that is the case, how does threaded processing of http requests even happen?
- thethimble 3y ago
  I’d strongly recommend Beej’s guide to network programming. It’s very approachable and will clear these concepts up for you. https://beej.us/guide/bgnet/html/split/ https://beej.us/guide/bgnet/html/split/
- jiggawatts 3y ago
  This “depends” on a lot of factors. Under Windows, the HTTP stream is decoded by the kernel! Even when this feature is turned off, there’s still a system service for enabling port sharing so that multiple services can listen on the same port (but different binding paths). The opposite end of the spectrum is “user mode networking” where the kernel is completely bypassed and the server process accepts data directly from the NIC. This is rare but used in high performance systems that need to process hundreds of gigabits.
cchance 3y ago
Realistically, http/3 growth is likely largely thanks to a epic ton of the web being delivered from cloudflare for the last mile and when they enabled http3... ya... thats a lot of sites suddenly being served on quic.
est 3y ago
Does QUIC offer MP-TCP like capabilities? e.g. multiplexing connections to different IPs.
jessi_lia 3y ago
It looks bizarre to me to see ppl complaining "if there's no Google services my phone's gonna be a brick when traveling in China", while in so many posts in HN, people are digging substitutes for evil Google. (Yeah I know they might not be the same group of people)

632 points by skilled 3y ago

I don't understand the arguments. 1) TCP needs to establish a connection. That is ZERO problem. 2) Encryption is needed in the bottom stack! WHY? Idiots are eating the world.

userbinator 3y ago
Look at the ones pushing this stuff, who they work for, and what interests they have. It's easy to see why a lot of things are the way they are, when you realise their true purpose.
adgjlsfhk1 3y ago
The reason to put encryption at the bottom of the stack is that it helps with Hyrum's Law. Part of the reason TLS is so hard to change is that everyone can see all the data and therefore anyone on the path your package takes might make decisions based on the data. This code will break if you try to update anything (even if the thing they are observing is something that they shouldn't have been observing). By encrypting everything possible, you remove the ability for everyone in the middle to see or depend on any details of the higher layers.
- bullen 3y ago
  Enjoy debugging things when everything is encrypted... and then your certificate provider goes down (or removes you because they don't like you) and you can't even connect...
cryptonector 3y ago
> 2) Encryption is needed in the bottom stack! WHY? One reason is that hardware (NICs) can offload encryption more easily when it's closer to the lowest end-to-end layer (i.e., no lower than IP). So IPsec and QUIC are easy to offload, but TLS-over-TCP less so. It especially helps that there is no need to buffer up part of the TCP stream so as to get whole TLS records to decrypt.
- bullen 3y ago
  You don't need hardware encryption if you don't need encryption. You are solving 1% of the problems with 99% of the energy.

1vuio0pswjnm7 3y ago

"Why TCP is not optimal for today's web" Hmm, what is "today's web". Surveillance and advertising. Let's be reasonable. Not every web user is exactly the same. Some might have diferent needs than others. People might use the web in different ways. What's optimal for a so-called "tech" company or a CDN might not be "optimal" for every web user. The respective interests of each do not always align on every issue. "Over time, there have been many efforts to update TCP and resolve some of its inefficiencies - TCP still loads webpages as if they were single files instead of a collection of hundreds of individual files." To be fair, not all web pages are "collections of hundreds of individual files", besides the file/path that the web user actually requested, that the web user actually wants to see. For example, I use TCP clients and a browser (HTML reader) and I only (down)load^1 a single file, using HTTP/1.x. This allows me to read the webpage. Most of the time when I am using the web, that's all I'm trying to do. For example, I access all sites submitted to HN this way. I can read them as text just the same as someone using HTTP/3. Hence I can discuss this blog post in this comment using HTTP/1.1 and someone else can discuss the same blog post using HTTP/3. The text that we are discussing is contained in a single file. So what are these "collections of hundreds of individual files". Well, they might come from other sites, i.e., other domains, other host IP addresses. Chances are, they are being used for tracking, advertising or other commercial purposes. And I am ignoring all the HTTP requests that do not retrieve files, e.g., behavioural tracking, telemetry, (incorrectly) detecting whether an internet connection exists, etc. HTTP/3 seems to downplay the concept of requests made by a web user, the idea of user agency. It allows servers to send files to the web user that the web user never requested. Surely these will only be files the user did not know they actually wanted. For example, ads. This is called something like "server push". IMHO, the best websites are not comprised of pages that each contain hundreds of individual files, sourced from servers to which I never indicated an intent to connect. The best websites are, IMHO, ones with hundreds of pages where each is a single file containing only the information I am interested in, nothing else. No tracking, no ads, no manipulative Javascripts, no annoying graphical layouts, no BS. HTTP/1.1 provides an elegant, efficient method to request those pages in sequence. It's called pipelining. Multiple HTTP requests sent over a single TCP connection. No multiplexing. The files come from a single source, in the same order as they were requested. Been using this for over 20 years. (If the web user wants "interactive" webpages, filled with behavioural tracking and advertising, then this is not optimal. But not every web user wants that. For non-interactive, 100% user-controlled information retrieval HTTP/1.1 is adequate.) Not every web user is interested in a commercialised web where the protocols are optimised for tracking and programmatic advertising. The early web had no such complexity nor annoyances. HTTP/3 can co-exist with other, simpler protocols, designed by academics not advertising service companies or CDNs. The other protocols may or may not be as suitable for advertising and commercial use. HN changed the title from "Why HTTP/3 is eating the world" to "HTTP/3 adoption is growing rapidly". Perhaps HTTP/3 is being hyped. If it is a protocol "optimised" for commercial uses that benefit the company who authored the specification, this would not be surprising. Interestingly, the commentary in this thread mainly focuses not on HTTP/3 but on QUIC. QUIC reminds me of CurveCP, an earlier UDP-based TCP replacement. I have run HTTP/1.1 over CurveCP on the home network. In theory shouldn't it be possible to use any protocol with QUIC, via ALPN. Something like printf 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n' \ |openssl s_client -quic -alpn http/1.1 -connect 93.184.216.34:443 -ign_eof 1. The term "load" is interesting. It's more than downloading. It's downloading code plus running it, automatically, without any user input. There is no opportunity to pause after the download step to choose whether or not to run someoone else's code. That's "today's web". If one uses a "modern" web browser issued by an advertising-supported entity. The browser I use is not issued by an advertising-supported company, AFAIK it's originally written by university staff and students; it does not auto-load resources and it does not run Javascript. There is no waiting for a site to "load".

deleted 3y ago

[deleted]

weird-eye-issue 3y ago

"In fact, the blog post you’re reading right now was probably loaded over HTTP/3!" It actually isn't. But some of the 3rd party resources like a captcha script are loaded over HTTP3

diggan 3y ago
Seeing the same thing both in Firefox and Chrome, every response from blog.apnic.net comes over HTTP/2, none of the HTTP/3 ones are from any apnic.net requests. Strange that a registry, who should have really good idea about what kind of infrastructure they run, would get which protocol they're using wrong.
krichprollsch 3y ago
The original blog post is served hover http/3 as far as I can see. https://pulse.internetsociety.org/blog/why-http-3-is-eating-the-world https://pulse.internetsociety.org/blog/why-http-3-is-eating-...
dgb23 3y ago
Looks like they forgot that we are hitting a cache that isn't configured the same way.
- weird-eye-issue 3y ago
  Appears to be Cloudflare's APO cache. I wonder why they haven't toggled HTTP/3 on in their Cloudflare dashboard (Just confirmed my sites with APO are being served with HTTP/3)
ReactiveJelly 3y ago
And I can't use HTTP/3 over Tor cause Tor only forwards TCP lol We'll get there

WJW 3y ago

Growing from 0 to ~27% of traffic in 2 years is great, but the graph from TFA shows that it was not a gradual increase but rather two big jumps in adoption: - One in mid 2021, to ~20%. - A second one in July 2022, to ~29%. Since then the traffic share has been pretty flat. I don't think that counts as "eating the world" at all tbh.

sph 3y ago
Is the graph showing the number of requests served by HTTP/3, or the number of individual hosts that support it? I believe it's the former, and it's explainable by the fact that most people these days visit only the same handful of siloes: Google, Amazon, Facebook, Twitter and Youtube probably make 90+% of all anonymised requests seen by Mozilla. But I doubt even 20% of global webservers are HTTP/2 ready, let alone HTTP/3. So HTTP/3 is eating the world, if by world you only count FAANG websites, which sadly seems to be the case. Remains to be seen how many websites are hidden behind tech's favorite MITM, Cloudflare, which might make figures a little harder to discern.
buro9 3y ago
Right, and those big jumps are more to do with large Cloud providers or proxy providers switching it on, and less to do with web applications themselves switching it on. It's great that the upgrade path for the end clients is so easy, but it doesn't reflect that the environment for web application developers has shifted towards HTTP/3
taf2 3y ago
July 2022 maybe linked to cloudfront supporting it 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...
dchftcs 3y ago
There's a cookie I took out of a package for a nibble. You could say I'm eating that pack of cookies. Not justifying the sensationalist title though.
ascar 3y ago
Intetestingly (or rather not surprising at all?) http3 is eating away the http2 traffic, while http1 just stays on a very slow decline. Since http1 webservers are usually stuck there for a (more or less) good reason, they won't be converting to http3 anytime soon, while already more modern webservers are easier to upgrade from http2 to 3.

tomalaci 3y ago

Will the spread of QUIC improve low latency services such as video game servers? Last I checked they were using either gRPC or homecooked protocol over UDP.

tuetuopay 3y ago
Not really. Video game servers definitely don't want session oriented protocols, and don't really care about dropped packet. Lost the packet with the player position? It comes at a regular interval, so we'll get it anyways, and more up to date! All they care about is the best latency possible. As for the non-time sensitive stuff in games (scoreboard, nicknames, etc), there is no real benefit there either. It's not time sensitive, the connection get opened once at the start and that's it. Where QUIC really shines if for fast connections and many streams, ie the web where a page will need 500 resources spread across 100 hosts. In this case session establishment speed and parallel streams are paramount.
deleted 3y ago
[deleted]
KingMob 3y ago
Not a whole lot, but the connection identifier will probably make it much more seamless when your phone switches from wifi to mobile networks. Right now, that's somewhat disruptive; with QUIC, you might not even notice.
plopz 3y ago
For games running on the browser absolutely yes. They are all currently on tcp and being able to switch to udp is huge.

sschueller 3y ago

What? I just updated my nginx config to HTTP/2. V3 still seems to be experimental in nginx: https://nginx.org/en/docs/http/ngx_http_v3_module.html https://nginx.org/en/docs/http/ngx_http_v3_module.html

olavgg 3y ago
Anything which involves more work than dnf/apt install nginx isn't worth wasting time on. So http2 for now.
yakubin 3y ago
It’s enabled by default in Caddy.
oblio 3y ago
And Apache? Edit: https://stackoverflow.com/questions/60324166/is-there-any-way-to-implement-http-3-quic-in-apache-http-server https://stackoverflow.com/questions/60324166/is-there-any-wa... No plans as of right now.
lost_tourist 3y ago
You'll be fine, there will be http2 for the next couple of decades at least. By then you'll be saying "Siri set up nginx for reverse proxying my new email server and open-facebook federated instance, oh and turn on the coffee maker, i'm gonna grab another 15 minutes of sleepy time"
claar 3y ago
Yeah, and not available in nginx stable yet (currently nginx v1.24) - only available in nginx mainline (v1.25+). More info at https://quic.nginx.org/ https://quic.nginx.org/

ThePhysicist 3y ago

QUIC is a really nice protocol as well, I find. It basically gives you an end-to-end encrypted & authenticated channel over which you can transport multiple streams in parallel, as well as datagrams. A lost packet in a given stream won't block other streams, and the overhead is quite low. Both ends of the connection can open streams as well, so it's really easy to build bidirectional communication over QUIC. You can also do things like building a VPN tunnel using the datagram mechanism, there are protocols like MASQUE that aim to standardize this. Apple is using a custom MASQUE implementation for their private relay, for example. HTTP/3 is a protocol on top of QUIC that adds a few more really interesting things, like qpack header compression. If you e.g. send a "Content-type: text/html" header it will compress to 2 bytes as the protocol has a Huffman table with the most commonly used header values. I found that quite confusing when testing connections as I thought "It's impossible that I only get 2 bytes, I sent a long header string..." until I found out about this.

promiseofbeans 3y ago
Woah that's actually pretty neat about header compression. Thanks for sharing!
- ithkuil 3y ago
  it builds on the experience gathered with the HTTP/2 HPACK header compression.
culebron21 3y ago
That makes sense -- if a packet is lost, and it affected just one asset, but you're on TCP, then everything has to wait till the packet is re-requested and resent.
- afiori 3y ago
  I wonder why the OS does not let the application peek at upcoming incomplete data.
  - 3y ago

culebron21 3y ago

Read up until author is confusing HTTP/1 with TCP, claiming that it's TCP's fault that we must make multiple connections to load a website. Actually, TCP allows continuous connection and sending as much stuff as you want -- in other words, stateful protocol. It was HTTP/1 that was decidedly stateless. Sessions in web sites are direct consequence of the need to keep state somewhere.

fidotron 3y ago
The whole HTTP request/response cycle has led to a generation of developers that cannot conceive of how to handle continuous data streams, it's extraordinary. I have seen teams of experienced seniors using websockets and then just sending requests/responses over them as every architecture choice and design pattern they were familiar with required this. Then people project out from their view of the world and assume the problem is not with what they are doing but in the other parts of the stack they don't understand, such as blaming TCP for the problems with HTTP.
- culebron21 3y ago
  I switched from web dev to data science some years ago, and surprisingly couldn't find a streaming parallelizer for Python -- every package assumes you loaded the whole dataset in memory. Had to write my own.
  - elashri 3y ago
    There are many packages that can do that, like Vax [1] and Dask [2]. I don't know exactly your workflow. But the concurrency in python is limited to multiprocessing, which is much expensive than threads which usually a typical streaming parallelizer will use outside python world. [1] https://vaex.io/docs/index.html https://vaex.io/docs/index.html [2] https://docs.dask.org/en/latest/ https://docs.dask.org/en/latest/
  - bboygravity 3y ago
    Just curious: why would you not load the entire dataset "into memory" ("into memory" from a Python perspective)? On an average desktop/server system the OS would automatically take care of putting whatever fits in RAM and the rest on disk. Or are the datasets large enough to fit on neither?

ta1243 3y ago

I have a corporate laptop which funnels all traffic through zscaler. I was somewhat surprised when I was getting a different IP address on ipinfo.io (my home IP) compared with whatsmyip.org (a zscaler datacentre IP) Curlling ipinfo.io though came back with the zscaler address. Turns out they don't funnel UDP via zscaler, only TCP. Looking into zscaler, https://help.zscaler.com/zia/managing-quic-protocol https://help.zscaler.com/zia/managing-quic-protocol > Zscaler best practice is to block QUIC. When it's blocked, QUIC has a failsafe to fall back to TCP. This enables SSL inspection without negatively impacting user experience. Seems corporate IT is resurging after a decade of defeat

wkat4242 3y ago
Zscaler is pure crap, we use it at work too. It's especially hard to configure docker containers for its proxy settings and ssl certificate. When I test something new in our lab I spend 10 minutes installing it and half a day configuring the proxy.
- fein 3y ago
  It causes minor annoyances with ssl + maven as well, which can be fixed by -Dmaven.wagon.http.ssl.insecure=true. Well, at least they tried I guess.
  - ta1243 3y ago
    No, setting any variable including the line "http.ssl.insecure=true" Is not a fix under any circumstance.
    - Thiez 3y ago
      Sure it is. The org insists on making your life difficult, and you just want to get your work done. If they really cared about security they would prioritise fixing stuff like this, but they don't, so you know they don't really care, it's just for show and a need for control. And if they don't really care about security, why should you?

wkat4242 3y ago

I'm extremely sceptical of anything proposed by Google especially because they are building some truly evil stuff lately (like FLoC/Topics and WEI). I really view them as the enemy of the free internet now. But QUIC doesn't really seem to have their dirtbag shadow hanging over it. Perhaps I should try to turn it on.

mixmastamyk 3y ago
Agree, but topics sounded like an improvement to me.
jiggawatts 3y ago
Google just ignored anything Windows needed in HTTP and included everything they needed — to the point that the compression in HTTP/3 is basically tuned for www.google.com and no one else.

kondro 3y ago

I miss when diagnosing server issues meant opening telnet and typing English. But I guess I also appreciate why that couldn’t last.

KingMob 3y ago
"When ah was yur age, we had to push our bits 10 miles to tha nearest router in the snow... and it was uphill...both ways!!!"
mnw21cam 3y ago
Most servers should still be able to service HTTP/1.0 requests (although you're right they'll probably just reply with a redirect to the HTTPS site).

nmstoker 3y ago

I get that major participants have switched but what's the developer experience like? It's a while since I read up on this but previously it seems relatively hard to get set up for any local usage of http3 - has that changed recently?

MrThoughtful 3y ago

the blog post you’re reading right now was probably loaded over HTTP/3! This made me curious. In the Firefox console, when I enable "raw" for the request headers, I see: GET /2023/09/25/why-http-3-is-eating-the-world/ HTTP/2 So I guess it was not?

243423443 3y ago

Frankly, I am a bit disappointed with the article. I fail to follow the argument that an encrypted header makes it easier to adopt HTTP/3 & QUIC because middleboxes cannot see the header. With HTTP/1.1 & TCP, the middleboxes should not be changing the TCP packets anyway, no? Also, the author does not point out that QUIC builds on UDP instead of directly building on IP like TCP does.

lemagedurage 3y ago
Even though they arguably shouldn't, some middleboxes assume that protocols don't change. They have made it hard for protocols such as TCP and TLS to evolve without breaking things. Similarly, middleboxes have made it unviable to deploy protocols that aren't TCP or UDP based. https://en.wikipedia.org/wiki/Protocol_ossification https://en.wikipedia.org/wiki/Protocol_ossification
- 243423443 3y ago
  I did not know that protocol ossification was a such a thing. Thanks for the link, it's an interesting article. It says that middleboxes near the edge are more likely to be the cause of ossification. Are there any stats about that? Such as some manufacturers or software companies "infringing" on the end-to-end principle more often than others?
  - Karrot_Kream 3y ago
    Not sure about stats but if you hang out in networking forums, you'll see netops complaining about bad implementations of protocols in their networking gear forever. This has been a huge problem in several protocols, everything from SCTP to IPSec to UDP RTSP.

ishanjain28 3y ago

I looked at netflow data for the last 10 days from my router. 75% of the HTTP traffic is HTTP3, 23% HTTP1.1/HTTP2(over TLS) and 2% is plain HTTP.

jalino23 3y ago

I just recently found out that even if browser supports up to http3, it still up to the browsers to decide which protocol to use even if the browser supports http3 too, this was dishearten to find out that you don't have control of forcing the browser to use http2 or 3 specially if you have features that only worked on http3 and was broken on http2, I guess I should have just fixed the implementation on http2

sassy_quat 3y ago
[dead]
scrpl 3y ago
You don't have control because browser might not support of http3 at all. It's up to browser developers to decide when their support levels are mature enough to use by default. There's no other way of doing it.

SanderNL 3y ago

Imagine you are holding a 200 requests/page bag of excrement and it’s generating too much load on all systems involved. What do we do? Empty the bag? No, we do not. That doesn’t scale. We create the most elaborate, over the top efficient bag-of-excrement-conveyer-belt you ever came across. We’ll move these babies in no time flat. Don’t worry about side-loading 24 fonts in 3 formats and whatnot. Especially do not worry about having to load three different trackers to “map” your “customer journeys”. No sir, your customer journeys are fully mapped, enterprise-ready and surely to be ignored by everyone. We got you covered with QUIC. Reimagining “data transport”, for your benefit. Edit: Of course I didn’t read the article, but now I did and it’s somehow worse than I thought. “Why TCP is not optimal for today’s web”: no answers. There are literally no answers here. Other than, TCP is old. Old things are difficult.

miohtama 3y ago
If you do not know the answer yet,as it sounds like you do, but there is a ting of rant there, let me expand what was said in the article: TCP/IP was build for 80s/90s when - Amount of data transferred was low - Data access patterns were different - Most TCP/IP was in university networks - There were no consumer users - Everyone on Internet could be trusted Today we have - 3B more people using Internet - 5B people living in authoritative regimes where the government wants to jail them for saying wrong thing on Internet - Mobile users - Wireless users (subject to different packet loss conditions) - You can stream 4k movies in your pocket - You can search and find any piece of information online under one second To get the low latencies and high bandwidths for mobile links TCP/IP can do it, but QUIC and HTTP/3 does it much better. Plus it's always encrypted, making all kind of middlebox attacks harder.
- peoplefromibiza 3y ago
  > - 5B people living in authoritative regimes it's actually 1.9B > where the government wants to jail them for saying wrong thing on Internet that happens across all the spectrum of types of systems of government
  - 3y ago

scrpl 3y ago

Few years ago I wrote an article on HTTP/3 that was briefly featured on HN as well: https://news.ycombinator.com/item?id=24834767 https://news.ycombinator.com/item?id=24834767 I can't agree with author about it eating the world though. It seems like only internet giants can afford implementing and supporting protocol this complex, and they're the only ones who will get a measurable benefit from it. It is an upgrade for sure, but an expensive one.

lemagedurage 3y ago
It's not all bad, you can start using Caddy for your new project and serve http3 right now.
- CharlieDigital 3y ago
  ASP.NET also has support: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel/http3?view=aspnetcore-7.0 https://learn.microsoft.com/en-us/aspnet/core/fundamentals/s... (minus macOS)

Andrew018 3y ago

[dead]

JakaJancar 3y ago

One thing where the semantics are not the same between HTTP/1.1 and HTTP/2/3(?) is the `Host` header, which is often (always?) gone in the latter in favor off the `:authority` pseudo-header. Apps/scripts may rely on `Host`, but the underlying HTTP/2 server software might not normalize/expose it in a backwards-compatible way (e.g. Hyper in Rust). Technically I guess it’s the browsers fault it doesn’t set it. I would be curious to know if there are other such discrepancies that apps migh run into when enabling HTTP/2/3.

jiggawatts 3y ago
We saw authentication errors in some very old ASP.NET apps that forced us to roll back to HTTP 1.1 after an attempt to upgrade to HTTP/2. Google is the main driver of HTTP 2 and 3, so they just didn’t bother to include features used primarily by Windows.

deleted 3y ago

[deleted]

goalieca 3y ago

I always thought GRPC would be an interesting candidate for http/3 but there's been no real movement in that direction. https://github.com/grpc/proposal/blob/master/G2-http3-protocol.md https://github.com/grpc/proposal/blob/master/G2-http3-protoc...

djha-skin 3y ago

I hate QUIC. I don't like that now there's an implementation of TCP in user space, and I find binary protocols nauseating, particularly when 90% of their value can be achieved using gzip over the wire. Not to mention corporate firewalls generally block UDP by default. UDP? Really? The design makes a lot of sense if you're talking about a remote client because now you can update the TCP stack without regard to when the user updates Android or whatever, but like GraphQL I feel like it's a technology that bends over backwards for the client. Maybe that's necessary and I get that, but whenever possible for other services that don't need to be sensitive to rural users I prefer to use things that make sense. REST and HTTP 1.1 over TCP continue to make sense.

FuriouslyAdrift 3y ago

Yeah... that's an unsecured VPN. Blocked.

BitPirate 3y ago
With this line of reasoning, you will have to block TCP as well.

anilshanbhag 3y ago

You can enable HTTP/3 with one click in Cloudflare. Just enabled it after reading this for Dictanote.

superkuh 3y ago

HTTP/3 is becoming more popular because Microsoft and Google white-washed google's QUIC through the IETF. It's popular because what they call "HTTP/3" is perfectly designed for meeting the needs of a multi-national corporation serving web content to millions of people. But it's only megacorps using it for their walled gardens. It's a terrible protocol for the human person web. You can't even host a visitable website for people who use HTTP/3 without getting the permission of a third party corporation to temporarily lend you an TLS cert. Once Chrome drops HTTP/1.1 support say goodbye to just hosting a website as a person free from any chains to corporate ass-covering. While LetsEncrypt is benign now, it won't always stay that way as more and more people use it. Just like with dot Org it'll go bad and there'll be nowhere to run. TLS only HTTP/3 is just as bad for individual autonomy as web attestation in it's own way.

lost_tourist 3y ago
Can't you sign your own certificates? I honestly haven't done any work with http/3 so it's a sincere question.
- superkuh 3y ago
  I could. But that wouldn't help make my website visitable for anyone. I'm not trying to access my own hosted site. I want a random person on the other side of the world who I've never met and will never meet to be able to visit my website. That's the point of public websites. Generating my own root cert and using it does not help with this at all since no one else will have it installed nor install it unless I'm already good friends with them. Installing a root cert in the various trust stores is no simple task either. The easier self-sign with no root cert also doesn't help because every current implementation of HTTP/3 does not support self-signed certs.
  - lost_tourist 3y ago
    I mean you have to do that with https now if you don't go with one of the big guys? How is that any more dangerous to the end user than just going to an http site that they don't know personally? The risks are the same as far as malware.

akmittal 3y ago

Just saw Hacker news uses http/1.1 and its plenty fast. I wonder if they explored moving to http2/3

jefftk 3y ago
I wouldn't expect HN to gain much by moving to HTTP/2 or HTTP/3. Loading this page with a cold cache is just 60kB, divided as 54kB of HTML, 2kB of CSS, and 2kB of JS, plus three tiny images. And on follow-up pageviews you only need new HTML. If the whole web was like this then we wouldn't need new versions of HTTP, but of course it isn't.
- netol 3y ago
  But would it gain something? I'm wondering if HTTP/3 could be enabled in one of my websites, which is even much smaller, and which has no blocking requests. I don't mind if the gains are small, as long as the impact is not negative for most visitors. I'm mostly concerned about some of my visitors visiting the website through an unreliable connection (mobile).
  - jefftk 3y ago
    It should gain a small amount; it is a more efficient protocol, with better compression and including 0-RTT for repeat visitors. But I doubt it would be noticeable on such a light site.
- adgjlsfhk1 3y ago
  The main thing it would get is 2x faster loading on high latency networks (because the TLS handshake happens with the same packets as the QUIC handshake).
- qingcharles 3y ago
  Yes, I use this site as the paragon of page weight. When other sites I visit are routinely throwing 200MB (MB!) pages at me, this site is throwing 60KB, of which 54KB is content! It's the benchmark I measure all my design against.

xg15 3y ago

> This means that metadata, such as [...] connection-close signals, which were visible to [...] all middleboxes in TCP, are now only available to the client and server in QUIC. Do I understand that correctly, that middelboxes are not supposed to know whether or not a connection still exists? Then how exactly is NAT going to work?

Vecr 3y ago
Works the same way it works with UDP (because it is UDP), with a timeout.
- xg15 3y ago
  But then the "close signal" is in practical terms not encrypted at all: You close a connection by not sending data for 30 seconds. That's a signal that's plainly visible to network intermediaries. So then why not eliminate one risk of bad middlebox heuristics and expose the actual flag?
  - Vecr 3y ago
    Not sending an explicit signal prevents certain injection attacks, but I'm not sure how much that would matter in practice. They would have to be some sort of off-path attack so the attacker can't just end the connection by blocking it.

bdd8f1df777b 3y ago

As a Chinese user who regularly breaches the GFW, QUIC is a god send. Tunneling traffic over a QUIC instead of TLS to breach the GFW has much lower latency and higher throughput (if you change the congestion control). In addition, for those foreign websites not blocked by GFW, the latency difference between QUIC and TCP based protocol is also visible to the naked eye, as the RTT from China to the rest of the world is often high.

meowtimemania 3y ago
RTT?
- Dylan16807 3y ago
  Round-trip time.
- deleted 3y ago
  [deleted]
svara 3y ago
What do you need to change for congestion control?
- bdd8f1df777b 3y ago
  The default congestion control is CUBIC, which is very slow for connections between China and the rest of the world. Google's BBR is a great improvement, and sometimes I use "brutal" congestion control, which is basically a constant speed.
girishso 3y ago
Any specific tool you can recommend?
- bdd8f1df777b 3y ago
  hysteria and tuic. Both are based on QUIC. But you need a server outside China though.

iamcalledrob 3y ago

QUIC's promise is fantastic, and latency-wise it's great. And probably that's what matters the most for the web. However I have run into issues with it for high-throughput use-cases. Since QUIC is UDP based and runs in user-space, it ends up being more CPU bound than TCP, where processing often ends up being done in the kernel, or even hardware. In testing in a CPU constrained environment, QUIC (and other UDP-based protocols like tsunami) capped out at ~400Mbps, CPU pegged at 100%. Whereas TCP+TLS on the same hardware could push 3+Gbps. It'll be interesting to see how it plays out, since a goal of QUIC is to be an evolving spec that doesn't get frozen in time, yet baking in to the kernel/hardware might negate that.

wofo 3y ago
Luckily, there are ways to reduce syscalls (like Generic Segmentation Offload and other tricks[1]). But I agree that not having things run in the kernel makes it more challenging for high-throughput scenarios. [1] https://blog.cloudflare.com/accelerating-udp-packet-transmission-for-quic/ https://blog.cloudflare.com/accelerating-udp-packet-transmis...
Karrot_Kream 3y ago
Is this mostly syscall overhead? Could io_uring and friends solve some of this?

antirez 3y ago

It's incredible that we need to assist to this farce where it is pretended that thanks to the tech giants the web is becoming faster. The average web latency is terrible, and this because of the many useless framework/tracking layers imposed by such tech giants. And HTTP/3 is a terrible protocol: for minor improvements that are interesting only for the narrow-data-driven mentality of somebody in some Google office, the web lost its openness and simplicity. Google ruined the Internet piece by piece, with Adsense and AD-driven SERP results, with complexity, buying and destroying protocols one after the other, providing abandonware-alike free services stopping any potential competition and improvement.

ReactiveJelly 3y ago
Google didn't force anyone to put ads on their blogspam sites.

c7DJTLrn 3y ago

Simple HTTP/1.1 would've been perfectly adequate if the web wasn't collapsing under its own weight made up of megabytes of JavaScript firing off tens of requests a second.

y04nn 3y ago
I'm not sure about that. I noticed that some websites (even simple blogs) felt instantaneous when loading (after pressing enter or clicking a link), way much faster than other websites. So I opened the dev tools, and the first request was HTTP/3. But all resources were still loaded with HTTP/2! HTTP/3 really brings something not negligible. Those accumulating TCP/TLS handshakes (+WIFI high latency) are really a burden and degrade the user experience when you have a fast internet connection.

tomohawk 3y ago

Since QUIC is UDP based, there are performance issues that become apparent at higher rates. In TCP, a single write can write a large amount of data. You can even use sendfile to directly send the contents of a file to a TCP socket, all in kernel space. In UDP, you need to write out data in chunks, and you need to be aware of the link MTU as IP fragments can be very bad news at higher rates. This means an app needs to context switch with the kernel multiple times to send a large amount of data, whereas only a single context switch is required for TCP. There are newish system calls such as sendmmsg which alleviate the strain a bit, but they are not as simple as a stream oriented interface. The QUIC implementations are primarily in user space, so you end up with multiple QUIC implementations in whatever language on any given system. Hopefully Linux will add a QUIC kernel implementation that will bypass and overcome the traditional UDP shortcomings in the current stack.

BitPirate 3y ago
Isn't the syscall overhead solved by GSO and GRO?
- tomohawk 3y ago
  Not necessarily. With GSO, you can send near 64K datagrams, which will then get split into MTU sized datagrams in the driver or on the card. But if you're sending a 1G file, that's a lot of 64K writes. And then you have to consider what is seen on the other end. Is GRO configured on all the endpoints these datagrams are going to? They won't necessarily see those near 64K datagrams, but lots of smaller ones.

rc_mob 3y ago

Why does this article read like propaganda. Its pretty technical and I don't understand all of it and it still reads like propaganda.

kzrdude 3y ago
I was thinking the same thing. One item I thought about was "H/3 Adoption Grows Rapidly" is paired with a graph that shows that adoption is absolutely flat over the last year.

imetatroll 3y ago

This made me realize that I don't really understand basic concepts. For instance, when connecting to a webserver on a given port, is it up to the kernel to take packets of data and assemble them into ... streams (? - not sure about the correct term here) that the server can then read and process? For some time I had the incorrect idea that a connection to a webserver would ultimately get its own port on the server side. In reality the only port that is randomly assigned is on the client side (from what I understand). Based on the above, when a server does not use threading to process multiple incoming streams (?), the kernel is, I guess, buffering up data from multiple clients while waiting for the server process to read and process the one stream the kernel has assembled for it? Or I am still completely a dunce about how this works and the above is still wildly incorrect. I would like to better understand but honestly I don't know where to start. On a very low level even on a threaded server that can receive and process multiple HTTP requests how exactly is the incoming data on the single server socket turned into something that each thread uses for a particular client? Especially in the context of something like http smuggling... I just don't understand the fundamental mechanism of multiple tcp connects on a single server port are turned into individual http requests... With http smuggling it makes it sound like all of the data is actually just a single stream. But if that is the case, how does threaded processing of http requests even happen?

thethimble 3y ago
I’d strongly recommend Beej’s guide to network programming. It’s very approachable and will clear these concepts up for you. https://beej.us/guide/bgnet/html/split/ https://beej.us/guide/bgnet/html/split/
jiggawatts 3y ago
This “depends” on a lot of factors. Under Windows, the HTTP stream is decoded by the kernel! Even when this feature is turned off, there’s still a system service for enabling port sharing so that multiple services can listen on the same port (but different binding paths). The opposite end of the spectrum is “user mode networking” where the kernel is completely bypassed and the server process accepts data directly from the NIC. This is rare but used in high performance systems that need to process hundreds of gigabits.

cchance 3y ago

Realistically, http/3 growth is likely largely thanks to a epic ton of the web being delivered from cloudflare for the last mile and when they enabled http3... ya... thats a lot of sites suddenly being served on quic.

est 3y ago

Does QUIC offer MP-TCP like capabilities? e.g. multiplexing connections to different IPs.

jessi_lia 3y ago

It looks bizarre to me to see ppl complaining "if there's no Google services my phone's gonna be a brick when traveling in China", while in so many posts in HN, people are digging substitutes for evil Google. (Yeah I know they might not be the same group of people)