21–30 of 123 posts
This article omits that Caddy has had long-running experimental support for HTTP/3 for a couple of years now: https://caddyserver.com/docs/json/apps/http/servers/experime...
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...
I am afraid that businesses that will host HTTP/3 will be less secure in terms of availavility.
I'll gladly eat the overhead of TCP to be able to avoid the reflection and spoofing issues of UDP.
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...
Don't think of it being UDP as anything more than "it happens to go through existing infrastructure without any or much work"
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.
Isn't that like any device behind NAT?
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...
Totally agree with you. Many big corporations totally block UDP at ISP level because there is no easy/magic solutions against amplified DDoS. They usually use some internal backend for DNS, Ntp, routed through other ISP. I am afraid that businesses that will host HTTP/3 will be less secure in terms of availavility.
For people who have reasonably configured UDP, it offers a benefit; the fact that some people have broken UDP is neither here nor there. HTTP/2 continues to be an option for TCP-only networks.
This article omits that Caddy has had long-running experimental support for HTTP/3 for a couple of years now: https://caddyserver.com/docs/json/apps/http/servers/experime...
Caddy's strange official binary licencing did them no favours. The licensing makes more sense now but they are off people's radar.
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...
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...
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.