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.
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
Using QUTor.
http://www.qscience.com/doi/abs/10.5339/qfarc.2016.ICTPP2961
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/
There is a draft RFC that specifically addresses this question; A Comparison between SCTP and QUIC.
Among the conclusions; QUIC provides better connection latency by eliminating handshake round trips. QUIC mandates encryption for everything in all phases including the initial handshake. QUIC has better compatibility with existing infrastructure because it rides on UDP and is therefore supported by nearly all "middleboxes," whereas SCTP is not universally supported. The connection ID concept allows QUIC connections to transparently survive IP address changes and NAT rebinding.
Another rationale for QUIC over SCTP appears here: QUIC: Design Document and Specification Rationale
Again, connection latency is cited. Also, "bandwidth efficiency;" basically QUIC has less overhead than SCTP+DTLS and achieves the same result.
Maw! Fire up the karma burner!
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.