When "everyone" uses your software/websites, you can get away with this, much like Microsoft did back in the day. Internal Windows programs ran faster and seemed more stable than third party software written to run on Windows. It generally offered better "UX", to use today's lingo.
The thing that is totally ignored by the myopic focus is the value of not being part of the Borg. Putting small speed differences aside, that value is not insubstantial, though the Google communications department is not responsible for keeping users informed about anything more than the value of Google.
The fastest internet would be one without ads (not to mention the other benefits). Google will not inform anyone about that. It is not included in any tests.
I don't disagree with your sentiment. However, their biggest gains in terms of percentage points (as discussed in the article) are for YouTube. And YouTube wouldn't be significantly faster without ads in the way that browsing primarily textual websites is faster without ads. Getting buffering times down is actually a substantial improvement here esp. on flaky connections. (Though the article doesn't make it clear whether flaky connections specifically benefit from QUIC.)
All to show it will benefit everyone, of course.
What's the right way for Google to improve their internet-facing services at a protocol level?
An emperor can build trust by relinquishing power.
Now they're updating their own deployment, making it compatible with the updated standard.
Chrome/Android/google.com is literally changing what they do to match what the standard says.
Huh? They're reporting for their own products presumably because they have access to that information that is accurate, and they're a couple of the world's most popular, most visited sites.
But the speed improvements will come for everyone who uses the protocols, not just Google, of course. What is sickening about that?
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.
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-...
And 3% is still a lot if you're looking at global Internet traffic.
Ex: Why does clicking on a location link in google search load a big slow SPA to display a list of "cards" instead of just having a maps/web link in the search results?
Presumably if Search did link to Google Maps, other geographic information systems would have to be represented, just like various streaming platforms are represented in the video tab.
Nobody has moved over to HTTP2 yet, let alone HTTP3.
Myopic focus is exactly what the system rewards.
There also needs to be some adjustment to that valuation based on greater good delivered by the company. If they killed off a bunch of smaller businesses, that's a negative. If they emitted a bunch of carbon, that's a negative. If they caused injuries or deaths, that's a negative. If they contributed to open source products that enabled other companies to exist, that's a positive.
Carbon taxes are one step at capturing one very small aspect of this "greater good" factor, but there need to be other adjustments as well.
Another vague idea I've had is a hypothetical economic system in which the government doesn't print money (or isn't the only one printing money) but rather money is brought to existence by certain good deeds. Money can also be traded for goods and services, of course, in addition. So while you could make money by selling food or selling phones, you could also literally print your own money (translate: government hands it to you, in a controlled fashion) by sucking carbon out of the environment and proving that you did that to claim your money.
Their function is to raise money, whether they use the product or not (you don’t invest in something unless you believe it will provide value to some group of people) they’ve done their job and the company can continue to advance and adapt due to the capital. Further if you set what a company can be worth you’ve limited their resources and limited their innovation as a result.
You’ve also turned human labor into currency in an attempt to get rid of currency. You cannot get rid of the concept of money. Without it you must trade resources (like labor), which history has shown is a very bad idea. The idea of a government being able to print money is a very deliberate feature, not a bug. I cannot do this justice, but read up on why we have money in the first place.
it's three sentences you quoted.
imo this is a quite harsh & pointed take you have presented. you seem to focus on some very-nearby headline sentences that do focus on performance, where-as the real story is much more interesting & the tech much more promising.
> blatant exploitation that’s occurring as there is too much centralised ownership
what makes you think this is so lopsided? yes, the spdy drafts released in 2012 originated from google. and google spent enormous amounts of effort, time & money championing & supporting development of QUIC as it made it's way through the IETF, where other non-Google engineers also worked to improve HTTP and build a powerful new transport protocol that shows enormous progress & is opening doors.
where is the exploitation?
> The myopic internal focus. ‘Look we’ve made our new thing a standard and look it makes our products run faster’
actually they made two standards. this is much better than where we were. with http2, we had built a true monster of a specification, untame-able. for good reason! we wanted good things! but the http2 spec was trying to shoe-horn a bunch of streams inside tcp, a streaming transport protocol, and that never quite fit (head of line blocking problems resulted), but just as bad, it made http2 a massive work that was hard to evolve & grow & reuse & enhance.
they took an extremely broad view, & said, these pieces don't belong together. they delegated responsibility into component pieces. they made pieces re-usable.
the result is that there are now a couple dozen efforts related to improve the underlying QUIC transport for lots of interesting use cases. the QUIC working group lists a couple dozen efforts[1] & enhancements, such as multi-path, load-balancing tuning, multicast, ack controls, satcom capabilities, & webtransport, a potential radical simplification & rework of websockets in a more connection-friendly manner. this is all work being done outside of http, being done with quic, because of these advances by these very careful, considerate, thoughtful, aware engineers, & their willingness to work with other engineers & the IETF to figure out how best to improve things, how best to decouple http2's transport protocol from it's application protocols.
> In my opinion this is predatory behaviour packaged up as open source good for all
i would very much like to hear some of what you feel or think any of your numerous very heavy accusations are due or deserved. using acerbaic words like "most sickening sentence", "myopic internal focus", & "blatant explotation" are big big words, big angry moods, and it's really uncomfortable, really hard for me to process & deal with such emotional turmoil directed at something that seems so innocent & like such a natural refinement & progression over the very good solid ideas & improvement that were http2, as it tried to move on & progress beyond http1.1 pipelineing, which everyone wanted very much wanted & in many cases did give up on.
so why do you hold your opinion? it really hurt me to hear your opinion, stated so pointedly, at such a lot of work that so many engineers all over the industry have contributed to & worked hard on. is this new dissent you have? are there other anti-http3 anti-quic folks who have staked some of their problems & claims & issues, or who have other ways they want the community to work through standards & specifications to improve the internet? what are the issues here, what's wrong? i for one thank my lucky stars that there are corporate patrons paying engineers good money to improve the world with works like this, to do the logical & consistent task of breaking http2 into it's transport (quic) and application (http3) protocols, improving the speed & reliability of the net.
thank you Google & IETF for doing all sorts of good for us all, imo.
[1] https://datatracker.ietf.org/wg/quic/documents/
there's a lot here beyond performance. i encourage you to investigate a little further & to see what quic + http3 bring & how they emerged from http2. that there is some performance win is good, but don't let that one statement narrow down your own understanding of this important enhancement.
the best evidence i can point to is a quic look at the IETF work group's active & related documents[1]
I'm going to cut you some slack because it looks like your other comments since then have been good, but if you do it again we are going to have to ban you, so please review the rules and stick to them: https://news.ycombinator.com/newsguidelines.html.
This is the most sickening sentence for me. The myopic internal focus. ‘Look we’ve made our new thing a standard and look it makes our products run faster’. This is just blatant exploitation that’s occurring as there is too much centralised ownership. In my opinion this is predatory behaviour packaged up as open source good for all.