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.
I want my pr0n delivered with HTTPS-over-THICC - the booty is bigger and bouncier
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.
to better connect the user with big brand ads.
Domestic spying is now "Benign Information Gathering"
I don't think you understand the definition or proprietary...
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.
QUIC stands for "Quick UDP Internet Connections" and is ... Google's attempt at rewriting the TCP protocol as an improved technology that combines HTTP/2, TCP, UDP, ...
QUIC -- All the reliability of TCP with the unreliability of UDP.
It must have been something you assimilated. . . .
I need to know how much of a QUIC packet has been set aside for ADs and/or trackers? /s
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.
Who needs congestion control? The network will be just fine when this is deployed large-scale...
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!
So quic is the corporation advertiser wet dream, you can be folllowed all over the web...?
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
Fuck everything, let's do IPV8!
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
from Draft: The IP addresses and ports can change in the middle of a connection. ad/js/css blocking will be much more difficult, as browser probably dont have proper API for plugins to kill those. blocking will probably need to move to some proxy (which need to be done from scratch) also browser should be put in separate linux namespace to avoid ability to go-around proxy. iptables support for this protocol woud be much more complicated as there is now mixing of data/tranasport/security features ...
IMHO .. garbage (just to gain few ms in latency)
This is really stupid. Google is changing and endangering working internet standards, just so they can safe a few bucks on connectivity. This should be resisted decisively.
I think the problem here is both that Google has stopped caring about anything than themselves (if they ever did) and that they actually lack experience. They may just come with yet another new protocol in a few years, because this one did not do what they want after all. This is not good at all.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
It's not that much legacy code. What is that? 100KB? Do you what how many web APIs browsers support nowadays? The list is huuuuuuge.
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
There was only one World IPv6 Launch day, on June 6, 2012, after which the nodes were officially left running. The previous events were "IPv6 Days" organized to test out operation with large audiences, but without the expectation of nodes being left running afterwards.
IPv6 has no significant problems at all, it runs totally sweetly and is powering many countries right now, including all the newest mobile networks which run exclusively over IPv6. Its design by committee worked out perfectly, courtesy of the IETF, who did a very competent job.
Its firewalling works flawlessly, so it seems that you're simply incompetent or trolling, probably the latter. Fortunately you can simply be ignored, since the near-exponential growth in IPv6 deployment worldwide makes your denialism completely irrelevant. The world moves on, everyone with technical understanding is moving to IPv6, and you'll end up stuck on a dying network costing you an arm and a leg in costly IPv4 addresses and with no room to grow.
Have fun. :P
Application layer protocols such as http operate on top of the transport layer. Application layer can be on top of TCP, because TCP is transport layer. Application layer like HTTP can also be on top of TLS, Transport Layer Security, because Transport Layer Security is - transport layer.
There is no "security layer" in either the OSI model or the TCP/IP model. Please review chapter 2 of Networking for Dummies.
> you think DDOS is going to obey any of the rules? that's so naive
> It just makes a connection, first stage , not a full connections, this is enough to tie up resources on the server
That's true of TCP, you can DOS with a syn flood.
Since that's a big problem, people duct-taped on a workaround called syn cookies. Since TCP wasn't designed to use sun cookies, they cause other problems. Notably it hurts performance because the syn cookie doesn't leave room for important TCP options. Things like selective ACKs and TCP Window Scaling won't work if you turn on SYN Cookies, even if your server isn't currently under attack.
QUIC, on the other hand, has stateless sessions similar in concept to syn cookies designed in, so everything works. You don't have to give up anything to avoid DOS with QUIC since it was designed with that protection in mind.
The thing with standardisation is that you write down how it's done, then do it. So everybody else can do it too.
This "living standard" and other moving target bullshit is the reverse: You keep on figuring new ways and things you might do, do them, and maybe write them down too. But what if you forget to write it down? No skin off your nose, you have the (only) working implementation. But your competition doesn't...
Sneaky, huh? But it seems to be effective enough. It does mean that HTML5, SPDY/"HTTP/2" and now QUICC/"HTTP/3" are all google trying to sneakily own the entire "web"-space, so everyone else will have to pay admittance of some sort to them. This is how you fuck up "open standards" deliberately. Just look at google doing it.
(Eerily similarly, this is what poettering is doing to linux for red hat, except without some sort of standards committee in the mix. It's also what microsoft tried to do by raping standardisation processes to shuffle their thoroughly broken answer to ooxml through. Even if that was only an answer to a battle they already essentially lost. This all does show that ECMA, ISO, the W3C, the IETF, and the linux community can all be played like fiddles. Just look at it happening.)
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.
When LEO becomes a thing, this will help as well.
Shai Schticks:"You don't make peace with friends, you make peace with enemies"
I'm assuming you mean low earth orbit satellites, but it wasn't obvious from context. My first thought was "How does this have anything to do with law enforcement officers?" :-)
I would expect LEO constellations to do handoffs between two satellites that are both relaying data to the same ground station, i.e. you shouldn't be switching IPs all the time. I could be wrong, though. But cellular phone networks can be a mess, and this might help with that.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Those are funny
We could have used all this work back when internet was SLOW! Now we really do not need all these changes that only matter to a massive company; create more technical headaches, developer work, upgrades and the expected phase out of old fully functional HTTP 1. Not everything requires encryption.
NOTE: google needs tracking and do not expect privacy to improve simply because they added encryption. Roaming IP addresses would be a nice feature but it'll make it easier for them to track everybody.
Democracy Now! - uncensored, anti-establishment news