I upgraded HAproxy on my server a few months ago, then enabled HTTP3. I haven't noticed any changes in performance, but the improvements in initial connection RTT seems worth it.
I wish programming languages were better supported, could jump on this stuff fast & make it available. There's one dude whose been painstakingly trying to bring the underlying QUIC to node for years. There's a variety of rust options but almost no framework adoption for devs to use this.
Sure, a lot of times just turning it on at the load balanced is all you need. But I feel like getting devs excited & using this stuff, putting it in their world, is a precondition for actual excitement and change. And it just takes so so long now.
One example that has me excited, the Iggy message steaming platform, which uses QUIC (not http3) (using Quinn for quic).
a domain is a big ask for some p2p applications. Not only does it cost money, but you have to interact with a (central) domain registry, which defeats the purpose.
There really ought to be a system (like .onion services or eepsites but without the mixnet/anonyminity) where you can just register a domain by a public key and have a signed pointer to your address on the internet as DHT. Sort of like IPNS or GNS but more common so you can just point someone to a domain like "0x1234[...]ABCD.ed25519.pubkey" and they can get a secure connection to you at whatever address you have.
Whereas the problem that Namecoin, ENS, and others (presumably namebase as well?) are trying to solve is squaring the whole triangle with a petname system that sacrifices security for human-meaningful names. They are what's referred to as a petname system.
There is not. You could compile the HTTP/3 libs with the flag enabled and the link that library when you compile your browser with the appropriate flags (but there's no sure thing this will be possible). And for 99.9999% of the people on the web their browser/user-agent will be unable to establish a connection to an HTTP/3 listening server that does not have a CA TLS cert.
It's the worst aspect of HTTP/3. It makes all web things require CA TLS and means that if something in the TLS breaks (as it does every couple years with root cert expirations, version obsolecence, acme version obsolecence, etc) then the website is not accessible. Because there's no such thing as HTTP+HTTPS HTTP/3. There is only HTTPS. It's designed entirely around corporate/institutional needs and is a terrible protocol for human people. HTTP+HTTPS websites can last decades without admin work. HTTP/3 websites can only last a few years at most.
My work blocks http/3 due to zfailer usage. I’m not sure enabling http/3 for our end users when no one from engineering is able to use/test it would be very responsible.
This article links to an nginx documentation page which warns that their QUIC and HTTP/3 support is still experimental. They're not kidding either, their last six CVEs were all related to their HTTP/3 implementation.
Http/3 is great. No need for third party cookies or local storage for user tracking when the server can supply the client connection ID at the protocol level.
From https://quic.xargs.org/#server-handshake-packet/annotated
"The destination connection ID is given. This field allows packets for a connection to be recognized by recipients even if the sender's network address or NAT translation has changed, making it more resilient than the underlying network connection. "
17 comments
[ 3.8 ms ] story [ 60.2 ms ] threadI wish programming languages were better supported, could jump on this stuff fast & make it available. There's one dude whose been painstakingly trying to bring the underlying QUIC to node for years. There's a variety of rust options but almost no framework adoption for devs to use this.
Sure, a lot of times just turning it on at the load balanced is all you need. But I feel like getting devs excited & using this stuff, putting it in their world, is a precondition for actual excitement and change. And it just takes so so long now.
One example that has me excited, the Iggy message steaming platform, which uses QUIC (not http3) (using Quinn for quic).
I've toyed with the idea of generating DNS names for static IP addresses with an * cert. Does anyone know if such a thing exist?
There really ought to be a system (like .onion services or eepsites but without the mixnet/anonyminity) where you can just register a domain by a public key and have a signed pointer to your address on the internet as DHT. Sort of like IPNS or GNS but more common so you can just point someone to a domain like "0x1234[...]ABCD.ed25519.pubkey" and they can get a secure connection to you at whatever address you have.
Whereas the problem that Namecoin, ENS, and others (presumably namebase as well?) are trying to solve is squaring the whole triangle with a petname system that sacrifices security for human-meaningful names. They are what's referred to as a petname system.
It's the worst aspect of HTTP/3. It makes all web things require CA TLS and means that if something in the TLS breaks (as it does every couple years with root cert expirations, version obsolecence, acme version obsolecence, etc) then the website is not accessible. Because there's no such thing as HTTP+HTTPS HTTP/3. There is only HTTPS. It's designed entirely around corporate/institutional needs and is a terrible protocol for human people. HTTP+HTTPS websites can last decades without admin work. HTTP/3 websites can only last a few years at most.
Maybe there's still a way to go yet.
I’m a bit lost. Under what circumstances do people even switch WiFi networks while using video chat and how common is this?
And previously I had issues that when my phone roamed from AP1 -> AP2 that the call had a hickup.
I fixed it by getting some more expensive equipment that supports fast roaming so I don't have the issue anymore.
Maybe the author is describing when switching from Network A to Network B, or from Wi-Fi to cellular.
From https://quic.xargs.org/#server-handshake-packet/annotated "The destination connection ID is given. This field allows packets for a connection to be recognized by recipients even if the sender's network address or NAT translation has changed, making it more resilient than the underlying network connection. "