31–40 of 123 posts
I hate to be a curmudgeon, but I can't help but think that designing a new service over UDP isn't the best idea. DNS has been fighting off wave after wave of attack vectors, some that realistically cannot even be fixed. Making it immune to these vectors is going to look a lot like a slapped together TCP over UDP...
Because QIC is UDP based, Chrome first runs a race with TCP just in case you're sitting behind some device that blocks UDP. I wonder how much bandwidth this will waste globally.
Isn't that like any device behind NAT?
Because QIC is UDP based, Chrome first runs a race with TCP just in case you're sitting behind some device that blocks UDP. I wonder how much bandwidth this will waste globally.
One or two packets? A handful of bytes per initial connection. The Connection ID mechanism and QPACK are likely to save a lot more data than is lost on initial TCP races.
Why are they calling it HTTP/3 and not just keeping the QUIC name?
Seems more verbose than https://caniuse.com/#feat=http3 TLDR - No browsers support it (without flag / config changes) yet.
In the age of evergreen browsers, it's possible to go from 0% to 85% in just a few weeks time. Upgrading web servers will be the real bottleneck.
All this is only a win mostly if you have a huge number of little assets from different sources. Ads, trackers, icon buttons, malware, etc. If it's all coming from one source, HTTP/2 is good enough. If it's mostly one big file, HTTP/1 is good enough.
I hate to be a curmudgeon, but I can't help but think that designing a new service over UDP isn't the best idea. DNS has been fighting off wave after wave of attack vectors, some that realistically cannot even be fixed. Making it immune to these vectors is going to look a lot like a slapped together TCP over UDP...
Too bad no major internet company wants to implement a new version of TCP. We can’t even get IPv6 done after 15 years.
Changing transport protocol is far harder then changing IP protocol or layer 2 medium.
Yeah I'm not deploying this, pretty much ever. I'll gladly eat the overhead of TCP to be able to avoid the reflection and spoofing issues of UDP.
Earlier quoted context omitted.
Isn't that like any device behind NAT?
No. Most NATs handle UDP sessions trivially as long as one end of the connection is not behind a NAT itself. Tricks like UDP hole punching are necessary only between two endpoints that are both behind NATs.
I hate to be a curmudgeon, but I can't help but think that designing a new service over UDP isn't the best idea. DNS has been fighting off wave after wave of attack vectors, some that realistically cannot even be fixed. Making it immune to these vectors is going to look a lot like a slapped together TCP over UDP...
Forget the narrow waist of the internet; this is the spaghetti ball of the internet. It violates all of the encapsulation and decoupling principles you learned about as a CS undergrad. If you have a better transport layer, fine. Make a better transport layer. But rolling the whole thing is the best way to ensure nothing will ever get done. HTTP/3 is the new IPv6.
I mean, it's not like encapsulation and decoupling ever worked with the networking stack. For example, let's pause a minute and think about which layer does TLS or NAT sit in.
To quote @tptacek[0]: There is no such thing as a layering violation. You should be immediately suspicious of anyone who claims that there are such things.
> HTTP/3 is the new IPv6.
Funny you mentioned IPv6. The famous article [The world in which IPv6 was a good design][1] actually gives some good context on why QUIC is needed, and believe it or not, layering violation was explicitly mentioned.