Slashdot Mirror
The Next Version of HTTP Won't Be Using TCP (zdnet.com)
"The HTTP-over-QUIC experimental protocol will be renamed to HTTP/3 and is expected to become the third official version of the HTTP protocol, officials at the Internet Engineering Task Force (IETF) have revealed," writes Catalin Cimpanu via ZDNet. "This will become the second Google-developed experimental technology to become an official HTTP protocol upgrade after Google's SPDY technology became the base of HTTP/2." From the report: HTTP-over-QUIC is a rewrite of the HTTP protocol that uses Google's QUIC instead of TCP (Transmission Control Protocol) as its base technology. QUIC stands for "Quick UDP Internet Connections" and is, itself, Google's attempt at rewriting the TCP protocol as an improved technology that combines HTTP/2, TCP, UDP, and TLS (for encryption), among many other things. Google wants QUIC to slowly replace both TCP and UDP as the new protocol of choice for moving binary data across the Internet, and for good reasons, as test have proven that QUIC is both faster and more secure because of its encrypted-by-default implementation (current HTTP-over-QUIC protocol draft uses the newly released TLS 1.3 protocol).
In a mailing list discussion last month, Mark Nottingham, Chair of the IETF HTTP and QUIC Working Group, made the official request to rename HTTP-over-QUIC as HTTP/3, and pass it's development from the QUIC Working Group to the HTTP Working Group. In the subsequent discussions that followed and stretched over several days, Nottingham's proposal was accepted by fellow IETF members, who gave their official seal of approval that HTTP-over-QUIC become HTTP/3, the next major iteration of the HTTP protocol, the technology that underpins today's World Wide Web.
In a mailing list discussion last month, Mark Nottingham, Chair of the IETF HTTP and QUIC Working Group, made the official request to rename HTTP-over-QUIC as HTTP/3, and pass it's development from the QUIC Working Group to the HTTP Working Group. In the subsequent discussions that followed and stretched over several days, Nottingham's proposal was accepted by fellow IETF members, who gave their official seal of approval that HTTP-over-QUIC become HTTP/3, the next major iteration of the HTTP protocol, the technology that underpins today's World Wide Web.
Those bay are guys... Why that compulsion to re-invent the Wheel? We'll never know.
SCTP is available now, is well understood, HTTP(S) already runs on it. Is more resilient than TCP, does not have Head-of-Line issues... What's not to like?
Oh, you can not write new papers on a protocol that already exists? Ah, and was Not-Invented-Here? Ok then...
*** Suerte a todos y Feliz dia!
How long has the IPv6 adoption been going on for now? 15 years? How's that been been going?
Yeah, that slowly.
Because, good enough for Google is good enough for everyone, right? And if it's not, they'll just do it anyway. Sure, I'm just old and grouchy, but I liked it when the IETF and the RFP process was a forum for very intense discussions with many researchers and industry leaders really working things out. Lately, it seems to be much more of a rubber stamp for big companies' technical ideas.
Also it appears they're spending a ridiculous amount of money solving something that isn't a problem with a solution that will definitely cause a massive amount of problems for everything and everyone it even comes close to touching.
If you don't serve your pages over QUIC your search rankings will go into the shitter, just like they did with AMP. You do like people being able to find your content, don't you? It'd be a shame if that didn't happen anymore.
The last thing we want is Google owning yet another layer of the Web stack!
It is a public open standard. Nobody "owns" it.
First, read this blog post from 2017: The world in which IPv6 was a good design. It's on the long-ish side, but you'll come out the other end somewhat smarter.
Toward the end, the author makes an off-handed reference to QUIC, a then-experimental protocol that actually solves many of the issues that IPv6 was supposed to solve. Right now, TCP connections are hard-bound to IP addresses. If your IP address changes (as is extremely likely to happen on your mobile phone), your connection is broken and you have to reconnect -- a huge pain in the ass for streaming applications and network operators trying to paper over that. QUIC's big win (assuming it wasn't lost during revisions) is that it allows your network connections to survive IP address changes, since the endpoints are identified not by an IP address/port tuple, but rather by a GUID/port tuple. Downside: You lose (some? all?) anonymity, as your GUID is long-lived.
So, no, this isn't some kluge Google chundered up last week. This has actually been under review by the IETF for a couple years.
Editor, A1-AAA AmeriCaptions
HTTP/2 shouldn't have bundled in TLS, and HTTP/3 shouldn't bundle in UDP. Keep the layers separate; interoperability depends on it.
...and the interoperability of IPX.
I really don't want to spend the money on a new firewall just to support web browsing.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
Also ATS (apache traffic server) has a branch dedicated to quic that developers who have been working on it at IETF have been implementing. The wire protocol works today, http-quic however is not implemented yet. But there are already at least partial implementations out there
They are already the IE 6 of this decade. Notice on Android phones when you switch apps from YOUTUBE you see the video playing in the background?
Well that is HTML 5.... err Google HTML 5 called Picture in Picture canvas. It is a proprietary Google CSS that web developers judge other browsers by. This is just one example well Google decides which standards are used and it makes Firefox and Edge look incompetent in comparison just like the PHB's viewed Firefox as incompetent because sites always worked in IE 6 so it must be the best browser.
http://saveie6.com/
yes and BOTH use UDP and you will see a LOT of problems with optimisations of links specifically sub sea fibre links
but google et al dont seem to care since they have plenty of transit they control and CDN like features...
good luck getting the telco's to use this and support it (they will just drop your packets) they make more by billing for the data and without control you wont know who is dropping your packets...
You could take five minutes to get a very basic idea of how QUIC works before you dismiss it. There is a connection, very similar most VPN connections.
Originally HTTP ran over plaintext, unencrypted TCP. There was a TCP session.
Then there was the option to tunnel an SSL session over the TCP connection, so you had a session within a session. You'd first establish a TCP connection, doing the whole handshake dance, then start the handshake dance over again for SSL. That's just as slow and inefficient as it sounds.
Now that we're moving to TLS on all web connections, setting up a TCP session just to then set up a TLS connection is wasteful and silly. Many protocols designed for encrypted connections, such as ipsec and openvpn, work better by just setting up the connection once. They just do one handshake, which sets up the encrypted connection, over UDP.
That's what QUIC does - the handshake sets up an encrypted TLS connection, over UDP. That's faster and more efficient. That's why openvpn, ipsec, quic, and most protocols originally designed for encrypted connections skip setting up two sessions, an unencrypted TCP session and then an encrypted session riding it. Just set up one encrypted session.
The last thing we want is Google owning yet another layer of the Web stack!
It is a public open standard. Nobody "owns" it.
No RFCs are like opinions, however instead of having a proper open debate about this, large companies like Google, Cloudflare or Mozilla will just stuff it down our throats. The process simply isn't democratic.
Considering that we probably have gotten most of the problematic TCP/TLS/HTTP bugs out, having a completely new stack will mean several new decades of new security problems. Secret services are probably rejoicing right now as more complexity will mean more bugs which will make the attack surface much bigger again.
Owning? If Google creates an open standard and it is accepted then it is an open standard, nothing owned by Google or anyone else.
Is this just another indication that the people here actually don't understand even the basics of the Internet (or even computing)? Scary.
I've had enough problems using Wireshark to find applications streaming data back to Microsoft and AWS. Last thing I need is have every network protocol multiplexed into an encrypted VPN so it's impossible to tell what is doing what. But that's Google.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
zidium screeched:
The last thing we want is Google owning yet another layer of the Web stack!
Exactly which part of the IETF process gives Google "ownership" of QUIC? The part where a working group composed of networking engineers who work for a whole bunch of different companies have spent months figuring out how to bolt this new protocol onto the existing IP stack, or the part where it's been kicked upstairs to the full HTTP working group with a recommendation that it be adopted as the basis of the next iteration of the protocol? Because neither of those decisions is anywhere close to final, yet, and the current version of QUIC - which Google actually uses internally - works well.
Or is it the fact that you're making shit up to trigger Google-haters's paranoia?
Further down in this discussion, ewhac provides the following link to a longish, quite intelligent discussion of what's wrong with TCP/IP in a ubiquitously-connected world (hint: the original design of the TCP protocol entirely failed to anticipate the mobile web - among many, many other shortcomings - and it now consists of a multi-layered kludge of, essentially, patches to enable it to function in an environment that is physically and logically completely unlike the bus-centric Ethernet networks it was developed to internetwork), and, just as importantly, an insightful discussion of why IPv6 has still not taken over the world, almost 30 years on, and probably never will:
The world in which IPv6 was a good design
Toward the end, the author talks about QUIC as a possible, elegant solution to the problem of creating a reliable, low-latency handover of session streams to enable a device whose IP address is constantly changing (i.e. - a mobile device that's, you know, in motion) to keep those data streams active in a much more elegant way than the current, provider-centric, dogshit-slow LTE protocol is capable of doing. And he goes to pains to point out that there are other possible solutions, as well, because that article is more than a year old, now, whereas the Mobile HTTP Working Group's recommendation that QUIC be the basis of the HTTP/3 standard is brand, spanking new.
(Just to be clear, it's not LTE itself that has the latency problem. It's the way LTE copes with constantly-changing IP addresses at the client end, as its signal gets handed off from one cell tower to the next.)
Mobile IP is a mess. Something has to be done about it. TCP is an increasingly-tottering kludge. Something has to be done about that, as well. IPv6 won't the panacea it's been advertised as, because its authors didn't anticipate the mobile Internet, either - and any fix is going to have to be a bolt-on, which is exactly the IPv4 problem IPv6 was supposed to eliminate.
Look, folks, internetworking has always been a moving target. As Niels Bohr phrased the old, Danish proverb, "Prediction is very difficult, especially about the future." That earlier generations of working network engineers failed to forsee the exact nature of the internetworked world we currently inhabit is profoundly unsurprising. But universal adoption of mobile, Internet nodes for personal communication is a reality with which the current crop of networking gurus must deal. Given that fact, we can either accept a hodgepodge of vendor-proprietary solutions, none of which is especially satisfactory, or tackle the problem as a general one that requires a universal, non-proprietary solution.
The Mobile HTTP Working Group consists of experts who have been studying the problem for a long time, and who are focused on trying to solve real-world issues the solutions to which are only going to become more urgent as time goes on. By contrast, most of the bleating on this forum is from users who have little familiarity with those problems and no meaningful technical expertise to infor
Check out my novel.