
QUIC and HTTP/3: Too big to fail? - lladnar
https://calendar.perfplanet.com/2018/quic-and-http-3-too-big-to-fail/
======
Matthias247
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 not work out
there, and building a real embedded implementation is again a task that nobody
wants to take on.

------
wahern
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-...](https://arstechnica.com/gadgets/2018/11/the-next-version-of-http-wont-
be-using-tcp/?comments=1&post=36350073)

Because those requests include many different domains, the benefit of QUIC is
substantially blunted.

~~~
dcbadacd
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
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.

