But no modern browsers actually use HTTP/1.1 pipelining. Interestingly, HTTP/1.1 pipelining works great for non-browser use. Most web servers enable it by default. After all, it works. For example requesting a series of pages from multi-page website, all under a single TCP connection. I have been using HTTP/1.1 pipeplining this way for decades. It is fast and reliable and enables the web to be used as a non-interactive, information retrieval source. It is also 100% ad-free. The user only gets what she requests, nothing more.
As for HTTP headers, privacy-conscious or minimalist users might not send many headers, only the minimum to retrieve the page. That's usually up to three extra lines of text per page for the request headers. (I rarely ever have to send a User-Agent header for HTTP/1.1 pipelining.)
GET /index.html HTTP/1.1
Host: example.com
Connection: keep-alive
Websites (IPs represented by domain names) to which users intentionally connect, i.e., the recognisable names that they type and click on, generally don't serve ads. The ads come from other domains, often other servers. Users generally do not intentionally try to connect to ad or tracking servers. HTTP/[01].x's automatic loading of resources, Javascript and other techniques may be used to make those requests, conveniently under the radar and outside the user's awareness.
Still, under HTTP/1.1, ads, nor Javascript files that trigger requests for ads, generally cannnot be delivered without the user's computer making a request first. Users can and do manage to exercise some control over their computers and they can prevent these non-interactive requests from being sent, from inside and outside the browser.
With HTTP/2 and HTTP/3, the necessity of a user-generated request disappears. As soon as the user "connects" (UDP) to the website's server, the server could for example send a Javascript file to the user's browser which can in turn trigger requests to other domains for ads or the purpose of tracking, all without any preceding request for the ad/tracking-related Javascript file. This is another feature of HTTP/[23] called "server push", but interestingly it is not the feature being used to sell HTTP/[23] to users (i.e., pipelining).
So, how does a user stop unwanted ads being "pushed" upon her in the stream (irrespective of the application, e.g., browser)? I generally don't use a "modern" browser, nor Javascript nor graphics. I like my pipelining outside the browser and free of advertising-related cruft.
It's worth considering that the motivation for speeding up websites via HTTP/[23] is solely for the purpose of speeding the delivery of more ads, more "stealthily", to users. This is a classic case of someone trying to sell you on a "solution" to a problem they themselves have created (or to which they are contributing).
Like an ISP trying to upsell customers to faster internet in order that websites bogged down with ads will "load" faster. When the ISP itself injects ads into pages of websites that are weighed down by ads.
And pushed content needs to be accepted by the browser, just sending someone ad bytes doesn't really do anything useful. It doesn't impact adblocking, and if a browser vendor wants to take the adblocking features away they can also just do that for the traditional model.
Most network stacks in major operating systems enable Nagle's algorithm[1] which was designed in the mid 80's to improve the efficiency of TCP/IP networks. John Nagle, the parent you're responding to, likely understands the HTTP/3 improvements at a level beyond what most of us can comprehend given his deep experience in this area[2].
As the author of two foundational RFCs (RFC896[3] and RFC970[4]), I think the parent also has a fairly good recognition of and experience working with IETF working groups.
[1] https://en.wikipedia.org/wiki/Nagle%27s_algorithm
[2] https://news.ycombinator.com/item?id=8381957
i'm still highly alarmed, both by John & the general level of discourse going on all throughout this thread. i posted replies to a number of others too. there is wild unsubstantiated & mean-spirited speculation running rampant through this, imo, good news. no one talks to how or why they think this is going to help spy on us, or reduce our ability to block ads, yet it's a very popular & trendy opinion. it seems widely assumed that this is all for bad, and everyone seems to want to believe that mis-information.
i find it distressing that the world would be so paranoid & crazy as this. after years of IETF hard work & discussion, after countless engineers work tirelessly to maximize privacy & security, after countless points are raised & tackled, the world greets what we think is a real & significant improvement with disdain, distrust, & belittling. this feels like the kind of easy-to-spread paranoia & madness that is part & parcel to the disinformation that has grown a threat to civil order, a threat to reason. it's too easy to knock things down[1], done so casually, & people seem to want to hear it too much. i realize i haven't been helping, haven't been waging an effective campaign to try to promote a healthier course for us, better discourse, but i want to. i want to not be overwhelmed & saddened by unsupported unreason.
touching back to @animats' post:
> The real motivation is probably to merge ads into the same stream as the content,
i don't see any potential for how this would impact ad-blocking or other security measures on the web. HTTP3 offers no new features or capabilities over HTTP2. existing extensions & tools ought be unaffected.
> All that effort to get a tiny improvement.
imo QUIC+HTTP3 is a straightforward & sensible simplification over what we had, & was a natural route to enhancing the existing systems.
http2 wanted to share a connection, allow out of order serving of requests in a better way than the obsolete & complicated/painful & largely removed http1.1 pipelineing, so servers could start working on upcoming work before finishing the current request.
quic has been an attempt to take a lot of the good work already done on http2, & to drive it further down the stack, enabling a) others to use the transport/session layers now distilled into quic for their own uses, and b) radically simplifying the http specification's responsibilities by separating out quic transport/session concerns from http.
beyond making http3 much simpler, there are other benefits. a capable replacement for WebSockets is forming via WebTransport[2], and a lot of people are hoping the complex SCTP-based WebRTC stack can be re-designed to use WebTransport/quic, once webtransport advances[3].
overall, the greatest proof that this is a simpler, better, more natural path than what we had comes from a quick look a the QUIC active & related documents[4], where we can see a number of different frontiers of innovation for other ways QUIC might be improved & enhanced, including topics such as multicast, load balancing, unreliable connections, & more: quic is a flexible, interesting, compelling extraction of really neat & interesting http2 technology, & decoupled from http, we are seeing amazing innovation take root & allow all sorts of good frontiers to open. quic is itself a big improvement to what was available for transport & session protocols, and it is throwing open the doors to colossal levels of innovation that were not conceivable before.
[1] https://en.wikipedia.org/wiki/Brandolini%27s_law
[2] https://w3c.github.io/webtransport/
I was thinking of Google-hosted content, with Google ads. About 25% of web traffic now comes from Google, although that includes YouTube. Google serves some (most?) ads from "doubleclick.com", which can be blocked at the domain level. But if they slip the ads into the same encrypted connection as the content, it's no longer possible to block them from outside the browser.
As for traffic issues, I've seen a few papers where people compare QUIC and TCP.[1][2] But nobody seems to be looking at what QUIC-type traffic is doing to other traffic on the same path. Not that I have, either. You can boost your throughput a bit by being more aggressive about sending packets. If the nodes in the middle are all FIFO queues (the cause of "bufferbloat"), the one who sends the most wins. This creates a perverse incentive and a way to game the results of such comparisons. Fair queuing can help.
Still, it's probably a win to speed up all the handshaking involved in setting up a TLS connection. The crypto setup is a big cost for small requests.
[1] https://blog.codavel.com/quic-vs-tcptls-and-why-quic-is-not-...
The real motivation is probably to merge ads into the same stream as the content, so they can't be blocked by anything outside the browser.