4 ms·

QUIC and HTTP/3: Too big to fail?

11 points by lladnar 8y ago

Matthias247 8y ago
Regarding the headline: I am pretty certain it won't fail, but that it will also take a long time to get rolled out and most likely won't see the usage rate (in applications, not worldwide requests/s) of TCP and HTTP/1.1. The same already happened with HTTP/2. Even though that one is available already for many years and yields noticeable benefits for some applications, there exists only a pretty low number of compliant implementations. Other applications/services are helping themselves by being behind HTTP/2 capable proxy servers. So I suspect the main areas where we would see HTTP/3 being used is Google services and some CDNs for a while. Implementing these low level networking protocols is hard, and most organizations won't invest in the time and effort of doing it (or doing it properly). I implemented HTTP/2 for .NET (https://github.com/Matthias247/http2dotnet https://github.com/Matthias247/http2dotnet), and it was for 2 years the only compliant implementation for that ecosystem. Nevertheless it saw not a lot of interest. I suspect something similar will happen for QUIC. And regarding the IoT section: The main challenge with constrained IoT devices is memory, and not necessarily computational power. This makes implementing lots of networking protocols which require higher buffer sizes super hard up to impossible. HTTP/2 would actually be a good protocol for IoT devices, since the permanent connection and logical streams e.g. decrease the cost for TLS establishment a lot compared to HTTP/1.1. And it's a lot easier to use for some use-cases than a message-based protocol like MQTT - e.g. for RPC, or large file downloads or uploads. However the memory requirements of HTTP/2 makes it hard to deploy it for those IoT scenarios - e.g. the default stream window size implies one should have 64kB of buffering per stream - which is immense on <= 300kB RAM CPUs. The other challenge is the lack of good libraries for these constrained devices. A normally dynamically allocating like nghttp2 might not work out there, and building a real embedded implementation is again a task that nobody wants to take on.
wahern 8y ago
A commenter on Ars, iAPX, put it best: > The problem is not HTTP over TCP, it is out-sourced Ads > and trackers. > > 67 requests, 1.0MB transferred, 1.48s with AdBlock Plus > and my own Tracker Blocking Chrome Extension. > 263 requests, 2.8MB transferred, 26.92s without any of > that. > This is the home page of Ars Technica as I write it (full > reload). > > Do you think that HTTP/3 will generate 4X less request, > will be 3X faster to transfer and will be 18X faster to > complete loading?!? > > This is not an HTTP problem, this a website design and > abuse of ads and tracker problem ;) > Google is trying to solve or hide a Google created > problem. -- https://arstechnica.com/gadgets/2018/11/the-next-version-of-http-wont-be-using-tcp/?comments=1&post=36350073 https://arstechnica.com/gadgets/2018/11/the-next-version-of-... Because those requests include many different domains, the benefit of QUIC is substantially blunted.
- dcbadacd 8y ago
  Anti-bloat has been peddled for a long time, it hasn't worked, it's time to mitigate those effects with adblockers, your wallet and new protocols.
  - wahern 8y ago
    Sure, simply admonishing developers and companies to reduce bloat won't do much to improve the situation. But neither will QUIC. That's the point. All QUIC effectively does is add more complexity to the technology stack, making real innovation more difficult by increasing the fixed costs.
OnlyRepliesToBS 8y ago
we're pushing it to production before you'll even know what the spec says!

11 points by lladnar 8y ago

Regarding the headline: I am pretty certain it won't fail, but that it will also take a long time to get rolled out and most likely won't see the usage rate (in applications, not worldwide requests/s) of TCP and HTTP/1.1. The same already happened with HTTP/2. Even though that one is available already for many years and yields noticeable benefits for some applications, there exists only a pretty low number of compliant implementations. Other applications/services are helping themselves by being behind HTTP/2 capable proxy servers. So I suspect the main areas where we would see HTTP/3 being used is Google services and some CDNs for a while. Implementing these low level networking protocols is hard, and most organizations won't invest in the time and effort of doing it (or doing it properly). I implemented HTTP/2 for .NET (https://github.com/Matthias247/http2dotnet https://github.com/Matthias247/http2dotnet), and it was for 2 years the only compliant implementation for that ecosystem. Nevertheless it saw not a lot of interest. I suspect something similar will happen for QUIC. And regarding the IoT section: The main challenge with constrained IoT devices is memory, and not necessarily computational power. This makes implementing lots of networking protocols which require higher buffer sizes super hard up to impossible. HTTP/2 would actually be a good protocol for IoT devices, since the permanent connection and logical streams e.g. decrease the cost for TLS establishment a lot compared to HTTP/1.1. And it's a lot easier to use for some use-cases than a message-based protocol like MQTT - e.g. for RPC, or large file downloads or uploads. However the memory requirements of HTTP/2 makes it hard to deploy it for those IoT scenarios - e.g. the default stream window size implies one should have 64kB of buffering per stream - which is immense on <= 300kB RAM CPUs. The other challenge is the lack of good libraries for these constrained devices. A normally dynamically allocating like nghttp2 might not work out there, and building a real embedded implementation is again a task that nobody wants to take on.

wahern 8y ago

A commenter on Ars, iAPX, put it best: > The problem is not HTTP over TCP, it is out-sourced Ads > and trackers. > > 67 requests, 1.0MB transferred, 1.48s with AdBlock Plus > and my own Tracker Blocking Chrome Extension. > 263 requests, 2.8MB transferred, 26.92s without any of > that. > This is the home page of Ars Technica as I write it (full > reload). > > Do you think that HTTP/3 will generate 4X less request, > will be 3X faster to transfer and will be 18X faster to > complete loading?!? > > This is not an HTTP problem, this a website design and > abuse of ads and tracker problem ;) > Google is trying to solve or hide a Google created > problem. -- https://arstechnica.com/gadgets/2018/11/the-next-version-of-http-wont-be-using-tcp/?comments=1&post=36350073 https://arstechnica.com/gadgets/2018/11/the-next-version-of-... Because those requests include many different domains, the benefit of QUIC is substantially blunted.

dcbadacd 8y ago
Anti-bloat has been peddled for a long time, it hasn't worked, it's time to mitigate those effects with adblockers, your wallet and new protocols.
- wahern 8y ago
  Sure, simply admonishing developers and companies to reduce bloat won't do much to improve the situation. But neither will QUIC. That's the point. All QUIC effectively does is add more complexity to the technology stack, making real innovation more difficult by increasing the fixed costs.

OnlyRepliesToBS 8y ago

we're pushing it to production before you'll even know what the spec says!