Let me know when the modules for programming languages are out of alpha state. The benefits are so infinitesimal compared to just loading less crap that it's not worth the lift to beta-test a...
Most programming languages don’t support HTTP/3 because QUIC presents a vastly different way to communicate. Without kernel support or widely supported bindings, adding QUIC to a language is a bit like re-implementing TCP in the language. TCP is usually relatively easy to add because OS kernels typically implement TCP for you and provide bindings. As far as I know, that isn’t the case for QUIC.
Let me know when the modules for programming languages are out of alpha state. The benefits are so infinitesimal compared to just loading less crap that it's not worth the lift to beta-test a protocol.
Indeed, language support is absolutely abysmal in all but a few, which is why I find the usage statistics incredible. Browser makers, cloud providers and load balancers truly said "we don't need...
Indeed, language support is absolutely abysmal in all but a few, which is why I find the usage statistics incredible. Browser makers, cloud providers and load balancers truly said "we don't need you!" to most software engineers.
Mostly I've been blocking quic because it seems mostly to be used by apps that don't want to honor things like my DNS policies. I've got nothing against the technical aspects, but as a former...
Mostly I've been blocking quic because it seems mostly to be used by apps that don't want to honor things like my DNS policies. I've got nothing against the technical aspects, but as a former engineering director including operating a large WAN, I'm not sure it's the revolutionary protocol the article makes it to be. If it was, people wouldn't be sleeping on it.
The biggest players don't want you to use your DNS, it makes it harder for them to monitor what you're doing and easier for you to block their crap. As best I can tell, there's no way for me to...
apps that don't want to honor things like my DNS policies
The biggest players don't want you to use your DNS, it makes it harder for them to monitor what you're doing and easier for you to block their crap.
As best I can tell, there's no way for me to prevent my Samsung Galaxy S21 from injecting 8.8.8.8 for all DHCP connections.
I have a S21 but it is a work device so I can't really test, but on my other Androids I've been able to set a private DNS entry using my specified DNS over https target from Adguard DNS. You...
I have a S21 but it is a work device so I can't really test, but on my other Androids I've been able to set a private DNS entry using my specified DNS over https target from Adguard DNS. You sometimes have to toggle it to use a public Wi-Fi since those sometimes rely on local DNS resolution for capture portals before giving you outbound Internet.
Alternatively, I run an OpenDNS service on my firewall and use dynamic DNS, so you could always full tunnel to your home Internet, v block all but your DNS provider and overwrite unencrypted DNS calls.
QUIC is awesome. While not as huge of a performance improvement as HTTP/2 was over HTTP/1.1, it offers a lot of stability for unreliable networks which are common in rural areas, and with phone...
QUIC is awesome. While not as huge of a performance improvement as HTTP/2 was over HTTP/1.1, it offers a lot of stability for unreliable networks which are common in rural areas, and with phone connections (tower handoffs, etc). It also makes deep packet inspection a lot more difficult. Corporate networks and residential ISPs are probably unhappy about that, but it should offer a lot more privacy for regular users. It also makes it harder for governments to unilaterally block content, ala the Chinese GFW.
At first I thought HTTP/3 was meant to replace QUIC in the same way HTTP/2 replaced SPDY, but it's actually just one layer of the protocol. It leans heavily on the work done in HTTP/2, so it's not a total reinvention so much as addressing the inefficiencies at a different step.
Though a few years old now, this series on Smashing Magazine offered some great technical details on QUIC in an accessible way. At the time the biggest hold up to adoption was middleboxes, and I'd guess that's still the case today. Anything involving physical hardware will take substantially longer than what a software update can accomplish (see IPv6). But as the article above shows, support is growing by the day.
I’m wondering what happens when it’s used only part of the way. For example, on Cloudflare, it seems to be a toggle, and they terminate the TLS connection anyway. Does it matter what happens on...
I’m wondering what happens when it’s used only part of the way. For example, on Cloudflare, it seems to be a toggle, and they terminate the TLS connection anyway. Does it matter what happens on the back end?
Similarly for a web app that has an http server in front of it, like Apache or Nginx. And you might be serving static content with a CDN.
Traffic from Cloudflare to the backend is usually either HTTP/1.1 or HTTP/2 (this one is also a toggle). Getting HTTP/3 all the way to app servers is really out of reach at the moment. I suspect...
Traffic from Cloudflare to the backend is usually either HTTP/1.1 or HTTP/2 (this one is also a toggle). Getting HTTP/3 all the way to app servers is really out of reach at the moment. I suspect it will become common when and if language support is figured out. HTTP/2 is reaching a decade since it was introduced and HTTP/3 is only has two years. It has some growing up to do, especially since it's replacing TCP, with its 44 years of optimizations.
I'm not sure I answered all your questions but hopefully that helped.
HTTP 2 and 3's performance improvements will help whichever parts of the connection they're used for, and it's fine if a single request is proxied through multiple HTTP versions on its way to the...
HTTP 2 and 3's performance improvements will help whichever parts of the connection they're used for, and it's fine if a single request is proxied through multiple HTTP versions on its way to the backend server (as long as some currently-uncommon features that require a specific HTTP version aren't used, like the WebTransport API which requires HTTP 3 the whole way through). An end-user's browser can open a single HTTP 2 or 3 connection with Cloudflare (or your load balancer etc) and make multiple requests within it, and then Cloudflare can translate each request into a separate HTTP 1.1 connection with your backend server if that's all it supports. In the likely situation that many of your users have a less reliable connection to the internet than your backend servers have to Cloudflare, then it's much more important that the hop between the users and Cloudflare supports HTTP 2 or 3 than it is that the hop between Cloudflare and your backend server does, though it generally would still help for that connection to use a newer version too.
Let me know when the modules for programming languages are out of alpha state. The benefits are so infinitesimal compared to just loading less crap that it's not worth the lift to beta-test a protocol.
Indeed, language support is absolutely abysmal in all but a few, which is why I find the usage statistics incredible. Browser makers, cloud providers and load balancers truly said "we don't need you!" to most software engineers.
Mostly I've been blocking quic because it seems mostly to be used by apps that don't want to honor things like my DNS policies. I've got nothing against the technical aspects, but as a former engineering director including operating a large WAN, I'm not sure it's the revolutionary protocol the article makes it to be. If it was, people wouldn't be sleeping on it.
The biggest players don't want you to use your DNS, it makes it harder for them to monitor what you're doing and easier for you to block their crap.
As best I can tell, there's no way for me to prevent my Samsung Galaxy S21 from injecting 8.8.8.8 for all DHCP connections.
I have a S21 but it is a work device so I can't really test, but on my other Androids I've been able to set a private DNS entry using my specified DNS over https target from Adguard DNS. You sometimes have to toggle it to use a public Wi-Fi since those sometimes rely on local DNS resolution for capture portals before giving you outbound Internet.
Alternatively, I run an OpenDNS service on my firewall and use dynamic DNS, so you could always full tunnel to your home Internet, v block all but your DNS provider and overwrite unencrypted DNS calls.
QUIC is awesome. While not as huge of a performance improvement as HTTP/2 was over HTTP/1.1, it offers a lot of stability for unreliable networks which are common in rural areas, and with phone connections (tower handoffs, etc). It also makes deep packet inspection a lot more difficult. Corporate networks and residential ISPs are probably unhappy about that, but it should offer a lot more privacy for regular users. It also makes it harder for governments to unilaterally block content, ala the Chinese GFW.
At first I thought HTTP/3 was meant to replace QUIC in the same way HTTP/2 replaced SPDY, but it's actually just one layer of the protocol. It leans heavily on the work done in HTTP/2, so it's not a total reinvention so much as addressing the inefficiencies at a different step.
Though a few years old now, this series on Smashing Magazine offered some great technical details on QUIC in an accessible way. At the time the biggest hold up to adoption was middleboxes, and I'd guess that's still the case today. Anything involving physical hardware will take substantially longer than what a software update can accomplish (see IPv6). But as the article above shows, support is growing by the day.
I'm old -- before reading the next phrase in parenthesis I was thinking "modem" (POTS modem) when I read "phone connections".
I’m wondering what happens when it’s used only part of the way. For example, on Cloudflare, it seems to be a toggle, and they terminate the TLS connection anyway. Does it matter what happens on the back end?
Similarly for a web app that has an http server in front of it, like Apache or Nginx. And you might be serving static content with a CDN.
Traffic from Cloudflare to the backend is usually either HTTP/1.1 or HTTP/2 (this one is also a toggle). Getting HTTP/3 all the way to app servers is really out of reach at the moment. I suspect it will become common when and if language support is figured out. HTTP/2 is reaching a decade since it was introduced and HTTP/3 is only has two years. It has some growing up to do, especially since it's replacing TCP, with its 44 years of optimizations.
I'm not sure I answered all your questions but hopefully that helped.
HTTP 2 and 3's performance improvements will help whichever parts of the connection they're used for, and it's fine if a single request is proxied through multiple HTTP versions on its way to the backend server (as long as some currently-uncommon features that require a specific HTTP version aren't used, like the WebTransport API which requires HTTP 3 the whole way through). An end-user's browser can open a single HTTP 2 or 3 connection with Cloudflare (or your load balancer etc) and make multiple requests within it, and then Cloudflare can translate each request into a separate HTTP 1.1 connection with your backend server if that's all it supports. In the likely situation that many of your users have a less reliable connection to the internet than your backend servers have to Cloudflare, then it's much more important that the hop between the users and Cloudflare supports HTTP 2 or 3 than it is that the hop between Cloudflare and your backend server does, though it generally would still help for that connection to use a newer version too.