HTTP/3 adoption is growing rapidly
&quot;Why TCP is not optimal for today&#x27;s web&quot;<p>Hmm, what is &quot;today&#x27;s web&quot;.  Surveillance and advertising.<p>Let&#x27;s be reasonable.  Not every web user is exactly the same.  Some might have diferent needs than others.  People might use the web in different ways.  What&#x27;s optimal for a so-called &quot;tech&quot; company or a CDN might not be &quot;optimal&quot; for every web user.  The respective interests of each do not always align on every issue.<p>&quot;Over time, there have been many efforts to update TCP and resolve some of its inefficiencies - TCP still loads webpages as if they were single files instead of a collection of hundreds of individual files.&quot;<p>To be fair, not all web pages are &quot;collections of hundreds of individual files&quot;, besides the file&#x2F;path that the web user actually requested, <i>that the web user actually wants to see</i>.  For example, I use TCP clients and a browser (HTML reader) and I only (down)load^1 a single file, using HTTP&#x2F;1.x.  This allows me to read the webpage.  Most of the time when I am using the web, that&#x27;s all I&#x27;m trying to do.  For example, I access all sites submitted to HN this way.  I can read them as text just the same as someone using HTTP&#x2F;3.  Hence I can discuss this blog post in this comment using HTTP&#x2F;1.1 and someone else can discuss the same blog post using HTTP&#x2F;3.  The text that we are discussing is contained in a single file.<p>So what are these &quot;collections of hundreds of individual files&quot;.  Well, they might come from other sites, i.e., other domains, other host IP addresses.  Chances are, they are being used for tracking, advertising or other commercial purposes.  And I am ignoring all the HTTP requests that do not retrieve files, e.g., behavioural tracking, telemetry, (incorrectly) detecting whether an internet connection exists, etc.  HTTP&#x2F;3 seems to downplay the concept of requests made by a web user, the idea of user agency.  It allows servers to send files to the web user that the web user never requested.  Surely these will only be files the user did not know they actually wanted.  For example, ads.  This is called something like &quot;server push&quot;.<p>IMHO, the best websites are not comprised of pages that each contain hundreds of individual files, sourced from servers to which I never indicated an intent to connect.  The best websites are, IMHO, ones with hundreds of pages where each is a single file containing only the information I am interested in, nothing else.  No tracking, no ads, no manipulative Javascripts, no annoying graphical layouts, no BS.  HTTP&#x2F;1.1 provides an elegant, efficient method to request those pages in sequence.  It&#x27;s called pipelining.  Multiple HTTP requests sent over a single TCP connection.  No multiplexing.  The files come from a single source, in the same order as they were requested.  Been using this for over 20 years.  (If the web user wants &quot;interactive&quot; webpages, filled with behavioural tracking and advertising, then this is not optimal.  But not every web user wants that.  For non-interactive, 100% user-controlled information retrieval HTTP&#x2F;1.1 is adequate.)<p>Not every web user is interested in a commercialised web where the protocols are optimised for tracking and programmatic advertising.  The early web had no such complexity nor annoyances.  HTTP&#x2F;3 can co-exist with other, simpler protocols, designed by academics not advertising service companies or CDNs.  The other protocols may or may not be as suitable for advertising and commercial use.<p>HN changed the title from &quot;Why HTTP&#x2F;3 is eating the world&quot; to &quot;HTTP&#x2F;3 adoption is growing rapidly&quot;.  Perhaps HTTP&#x2F;3 is being hyped.  If it is a protocol &quot;optimised&quot; for commercial uses that benefit the company who authored the specification, this would not be surprising.<p>Interestingly, the commentary in this thread mainly focuses not on HTTP&#x2F;3 but on QUIC.  QUIC reminds me of CurveCP, an earlier UDP-based TCP replacement.  I have run HTTP&#x2F;1.1 over CurveCP on the home network.  In theory shouldn&#x27;t it be possible to use any protocol with QUIC, via ALPN.  Something like<p><pre><code>   printf &#x27;GET &#x2F; HTTP&#x2F;1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n&#x27; \
   |openssl s_client -quic -alpn http&#x2F;1.1 -connect 93.184.216.34:443 -ign_eof
</code></pre>
1. The term &quot;load&quot; is interesting.  It&#x27;s more than downloading. It&#x27;s downloading code plus running it, automatically, without any user input.  There is no opportunity to pause after the download step to choose whether or not to run someoone else&#x27;s code.  That&#x27;s &quot;today&#x27;s web&quot;.  If one uses a &quot;modern&quot; web browser issued by an advertising-supported entity.  The browser I use is not issued by an advertising-supported company, AFAIK it&#x27;s originally written by university staff and students; it does not auto-load resources and it does not run Javascript.  There is no waiting for a site to &quot;load&quot;.