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!
Slashdot Valentines Beta Massacre: iT WORKED! The boycotts killed Beta!!
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!
At least from TFS.
But .... Google. I consider anything they touch to be tainted and untrustworthy. I can't point to specifics in this case, but their name alone is enough to cast a whole pile of doubt.
They were, after all, one of the companies actively cooperating with the NSA.
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.
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.
Using QUTor.
http://www.qscience.com/doi/abs/10.5339/qfarc.2016.ICTPP2961
They can serve ads directly bypassing many filter apps:
https://www.google.com/amp/s/amp.reddit.com/r/privacy/comments/67hhc4/google_is_using_quic_protocol_to_serve_ads_in/
I searched if this was possible while going through the RFC for QUIC and came across the part where it says HTTP3 will support extensions within individual connection requests.
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
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.
In the best circumstances, available bandwidth and speed are improving. In the worst circumstances, they aren't. And that's actually a big part of the problem.
One major reason for moving to binary protocols is that so much traffic these days lives the mobile world, where cellular networking (not to put too fine a point on it) sucks harder than a Hoover. In that world, packet loss is the main enemy of speed, not bandwidth. And every extra packet represents an additional opportunity to lose a packet, which triggers retransmit penalties that add up rather quickly.
When you're sending small amounts of data (which is extremely common these days, particularly in the JSON world), you can't make up for packet loss penalties through out-of-order delivery and resending preemptively if you don't get an ACK in a timely manner. Those approaches are great for reducing the retry penalty when you're delivering megabytes, but they don't do much good if the entire response fits in a couple of packets and you send the whole message in a fraction of the ACK window (high bandwidth, high latency).
By moving to a binary protocol that lets you maintain crypto state for a longer period of time and avoids extra handshake packets, you can dramatically reduce the packet count for short requests, which can produce a huge reduction in total latency even when you have a fairly good cellular signal. And when you have a mediocre cellular signal, the difference between a single packet response and a two-packet response can often make the difference between 200-milliseconds and several seconds.
In the mobile world, every packet counts.
Check out my sci-fi/humor trilogy at PatriotsBooks.
They're not reinventing for the sake of reinventing. They're reinventing to make people have GUIDs more permanent than IPs included in every packet.
Your ad here. Ask me how!
Why does it have to ride UDP? Certainly most middle boxes will forward 'protocol unknown' over IP at least if instructed to do so. Seems like at least 4 bytes worth of source and destination port in the UDP header that is basically no needed; given quick has connection ids.
I mean if we are going to both implementing a new transport layer; its going to be painful even if you do ride UDP. If we are doing this in the name of efficiency; we should at least do it right and not just burn 4 bytes per-packet b/c not doing tcp/udp is hard.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
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.