41–50 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...
Earlier quoted context omitted.
Too bad no major internet company wants to implement a new version of TCP. We can’t even get IPv6 done after 15 years.
implementing a new version of TCP would be nearly impossible because of all the equipment out in the field already. Changing transport protocol is far harder then changing IP protocol or layer 2 medium.
Earlier quoted context omitted.
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.
nginx will get H3 this year, so I think we'll see a massive uptick in adoption.
Earlier quoted context omitted.
implementing a new version of TCP would be nearly impossible because of all the equipment out in the field already. Changing transport protocol is far harder then changing IP protocol or layer 2 medium.
Why doesn't the IP protocol require new hardware if it's a lower layer?
Transmission Control Protocol - TCP - is baked into the firmware of every client network interface card, and I would suppose in almost all of the switches and routers of business infrastructure.
I have no idea what data centers use. Infiniband and similar things aren't TCP, I think.
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 is basically TCP 2.0 implemented on top of UDP. What concerns do you have with this?
The biggest red flag to me is that it is trivial to make the server send sizable packets to clients who didn't ask for them nor want them. Spoofing is not a solved problem, no matter how many times people scream at providers to block it before it gets out. Why isn't there a minimal ACK process up front? I mean, this thing is designed such that it's vulnerable to reflection attacks on -day 1-.
How would one make the decision, what factors would influence it? What are some of the best books/essays arguing either direction?
I believe in maintaining best practices even if you can get away with sloppiness on a specific project, to be good and fast at doing things the right way, but I honestly can't tell where the new protocols fall.
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.
Presumably most HTTP/3 implementations will gracefully fall back to HTTP/2 (or 1.1) if UDP is filtered. Chrome's existing QUIC implementation already does this.
Every Google property has had QUIC enabled for quite a while now (at least 4-5 years), so if UDP blocking would cause availability issues, affected businesses would've noticed by now.
For the builder of small to medium (say, 10k to 1 million monthly users, some media but not the primarily focus) websites, apps, APIs, etc, is it time to begin deploying HTTP/2 or even 3? How would one make the decision, what factors would influence it? What are some of the best books/essays arguing either direction? I believe in maintaining best practices even if you can get away with sloppiness on a specific projec…
HTTP/3? Meh. We've started into the realm of solving google scale problems in HTTP standards that have marginal if any benefit to the 99%
All this to support more ads per page. 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'm also very afraid of the future of Web Assembly.
Both of these technologies i'm afraid aren't going to make things better, faster and more lightweight. They are just going to allow the bloat of the web to become worse without noticeable symptoms.
All this to support more ads per page. 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.
(Any introduction on QUIC will explain you these if you are interest.)