The Next Version of HTTP Won't Be Using TCP (zdnet.com) 258
"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.
NOOOOOO! (Score:3, Insightful)
The last thing we want is Google owning yet another layer of the Web stack!
Re:NOOOOOO! (Score:4, Interesting)
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.
Re: (Score:2)
http://stereotypeoftheday.blog... [blogspot.com]
Re:NOOOOOO! (Score:5, Informative)
The last thing we want is Google owning yet another layer of the Web stack!
It is a public open standard. Nobody "owns" it.
Re: (Score:2, Interesting)
As with any other technology, it's owned by the people who make the largest contributions and have the largest amount of political influence over the standards bodies that approve the standard.
These days, "open public standard" is as meaningful as "open source". The politics are always a problem, and we all know how well Google is faring in that department.
Re:NOOOOOO! (Score:5, Insightful)
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.
Re: (Score:2)
The same argument could be made about any new protocol that is selected for HTTP/3.
And we do need something new. The current tech is widely abused to improve performance by subverting the TCP bandwidth estimation that slowly ramps up, making sites load slowly.
QUIC makes a real difference, especially on mobile connections. Since it's based on UDP and other existing standards most of the security stuff has been resolved already. And it's optional, HTTP/2 and TCP are not going to go away for a very long time.
Re: (Score:3)
Web sites don't load badly because of some problems of TCP, but because
a) existing features of HTTP/HTML are not used (like request pipeliuning)
b) Web design has evolved into utter crap with layers upon layers of needless waste.
Re: NOOOOOO! (Score:5, Informative)
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
Re:NOOOOOO! (Score:5, Informative)
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.
Re: (Score:3)
Hardly. It's an Android feature that only works in Android and Google happen to call out in their own browser on their own website and that's about it.
If you're going to call out an example of IE6ness then pick something like Accellerated Mobile Pages. That is something that affects multiple services across multiple devices and is not a standard in any form.
Re: (Score:2)
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.
Embrace, extend, and extinguish ... Google is learning.
Re:NOOOOOO! (Score:5, Insightful)
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.
Re:NOOOOOO! (Score:5, Interesting)
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.
Re: NOOOOOO! (Score:2)
I would think you already knew not to do your private stuff on somebody else's network.
Re: (Score:3)
The internet is someone else's network. Fortunately we have ways of doing stuff privately without having to trust the network.
Re: Knee-jerk FUD from Google-haters (Score:5, Interesting)
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 [slashdot.org], 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 [apenwarr.ca]
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
SCTP (Score:5, Interesting)
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...
Re:SCTP (Score:5, Interesting)
Re: (Score:2)
Re:SCTP (Score:5, Informative)
There is a draft RFC that specifically addresses this question; A Comparison between SCTP and QUIC [ietf.org].
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 [google.com]
Again, connection latency is cited. Also, "bandwidth efficiency;" basically QUIC has less overhead than SCTP+DTLS and achieves the same result.
problems with SCTP and QUIC (Score:5, Interesting)
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...
Re: (Score:2)
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)
So you think the telcos are going to compete with Google's long haul links by offering a worse service ?
Re: (Score:3)
Comcast 2016: "Google Fiber! Shiver me timbers!!"
Comcast 2018: "Yawn... here's another price increase."
Re: (Score:2)
but google et al dont seem to care
Why should they? It's not their job to optimise infrastructure someone else runs, just like it's no the job of car manufacturers to install traffic lights at intersections when they introduced something that actually moves faster than a horse.
Re: (Score:2)
If we just assumed that everything will stay exactly the same no matter what we would not make much progress.
It seems very likely that once adopted the internet backbone and transit providers will make an effort to properly support it, being an IETF standard and all.
Re: (Score:3)
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...
The primary driver for change is round trip reduction. You can achieve QUIC parity in that regard using TCP TFO in conjunction with TLS features (session tickets). This is really nice because you can resume a "session" with no round trips before transmitting request to a server without requiring server side state be maintained.
With these two used in conjunction HTTP 1.0 works just as well as HTTP 3.0 given you can send any number of requests any time you want without any inter-request HOL with no RTT over
Re: (Score:2)
There is no such thing as HTTP 3.0. This is HTTP/3 being discussed, which is HTTP (some version) over QUIC. It is not a change to the HTTP protocol.
This is not true. This is not just a simple layering of an existing transport agnostic application protocol on top of a new stream transport.
It is perfectly possible to achieve this outcome via QUIC but it's not what's being specified in the draft and is not what is actually being deployed.
The HTTP protocol has in fact been modified:
Re: (Score:2)
This isn't a reinvention.
Re: (Score:3)
Why that compulsion to re-invent the Wheel?
What you really need is one of these: https://www.snydersantiqueauto... [snydersantiqueauto.com] I mean why bother changing any part of the wheel design. That one spins right? So it is clear that there is no possible way it can be improved...
It sounds OK technically.... (Score:2, Insightful)
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.
Re:It sounds OK technically.... (Score:4, Insightful)
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.
Re: (Score:2, Funny)
5 years from now: Google Announces End of Support for QUIP, End of Internet
Re: It sounds OK technically.... (Score:5, Informative)
Re: It sounds OK technically.... (Score:2)
Re: It sounds OK technically.... (Score:2)
I won't hold my breath.... (Score:5, Insightful)
How long has the IPv6 adoption been going on for now? 15 years? How's that been been going?
Yeah, that slowly.
Re: I won't hold my breath.... (Score:3)
This is a fuck of a lot simpler than IPV6.
Re: I won't hold my breath.... (Score:3)
Yes.
Re: (Score:2)
Oh come on, HTTP1 and 2 aren't going away and would be likely supported side-by-side...
Re: (Score:2)
Simpler? Updating EVERY running web server?
Anecdote: One day in 2015 I woke up to find my webserver supported TLS 1.2
I did need to restart the running instances, but yes updating EVERY running web server is simpler.
Re: (Score:2)
Anecdote: One day in 2015 I woke up to find my webserver supported TLS 1.2
I did need to restart the running instances, but yes updating EVERY running web server is simpler.
This often happens to Internet users. They wake up one day and all their computers have IPv6 addresses and more than half of their traffic is IPv6. Not only did they not do anything to make it happen they don't even know what IPv6 is.
Re: (Score:2)
They wake up one day and all their computers have IPv6 addresses and more than half of their traffic is IPv6. Not only did they not do anything to make it happen they don't even know what IPv6 is.
Not at all. They may wake up one day to hear about this IPv6 thing only to find that their modem doesn't support it, their switches doesn't support it and even if it did, their ISP doesn't provide them with a publically routable IP address.
Comparing IPv6 to what is being proposed here is idiotic to the highest order and serves only to show an incredible lack of critical thinking skills.
On the other hand expect users to have exactly the reaction you described to QUIC
Re: (Score:2)
Not at all. They may wake up one day to hear about this IPv6 thing only to find that their modem doesn't support it, their switches doesn't support it and even if it did, their ISP doesn't provide them with a publically routable IP address.
Everything I said is factually correct and has in fact already happened to countless millions of customers on eyeball networks across the world.
For years modems and routers sold that don't support IPv6 today are an endangered species. Only managed switches which most consumers don't have in the first place need to "support" IPv6. I'm unaware of any ISP handing out non-routable IPv6 prefixes. I'm sure someone somewhere is doing it yet the behavior is quite rare and counterproductive. The entire reason yo
Re: (Score:2)
Everything I said is factually correct and has in fact already happened to countless millions of customers on eyeball networks across the world.
And out of the actual billion people in the world lots of people will require hardware upgrades. Anyway pat yourself on the back. It's only taken you 15+ years to get I tend to agree with the conclusions but not the supporting detail about I woke up one day and my web server supported TLS or QUIC or whatever.
Except you're missing the obvious difference between a software update and a hardware upgrade, and yes I deliberately used two different verbs to describe what was going on. Comparing the two is assini
Re: (Score:2)
I haven't dug into this protocol. I support everything is encrypted but I do have concerns about whether government and corporations, including one's own employer, can snoop the traffic.
Fuck everything (Score:2)
Fuck everything, let's do IPV8!
Re: (Score:2)
Let's do IP W16, instead !
We love complicated things !
Re: (Score:3)
Introducing a new protocol that works with existing infrastructure is completely different than introducing a new protocol that can ride on existing routeable packets using existing hardware and a customised software stack.
TLS was adopted quickly
HSTS was adopted quickly
AMP for worse (not better) was adopted quickly
Re: (Score:2)
Let's rush that through... (Score:5, Insightful)
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.
Re: (Score:2, Insightful)
So if you click the RFC and read the end :
The original authors of this specification were Robbie Shade and Mike
Warres.
A substantial portion of Mike's contribution was supported by
Microsoft during his employment there.
Author's Address
Mike Bishop (editor)
Akamai
So you got Microsoft, Akamai and Google.
Feel free also to see you submitted idea / feedbacks : https://github.com/quicwg/
Re: (Score:2)
Because, good enough for Google is good enough for everyone, right? And if it's not, they'll just do it anyway.
Not to worry, this is from Google. What are the chances it ever makes it out of Beta and into actual use. :-)
A layer (Score:2)
There's More to QUIC Than You Think (Score:5, Informative)
First, read this blog post from 2017: The world in which IPv6 was a good design [apenwarr.ca]. 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 [ietf.org] for a couple years.
Re:There's More to QUIC Than You Think (Score:5, Interesting)
Downside: You lose (some? all?) anonymity, as your GUID is long-lived.
That's a hell of a downside. Is there any way to protect your anonymity in such a system?
There's More to Tor Than You Think. (Score:2, Informative)
Using QUTor.
http://www.qscience.com/doi/abs/10.5339/qfarc.2016.ICTPP2961
Re: (Score:2)
QUIC is apparently user-side, so not buried in your OS. I don't know how this will work in practice, but I'd imagine each process you run will have a different GUID. Further, I'd imagine it's possible to (say) tell your browser to quiesce all network activity, change GUIDs and start networks again. Any GUID-based sessions would have to re-authenticate, but you'd be on a new GUID.
This aspect of QUIC does need some thinking about in implementations. You want the client to rotate GUIDs quite often, but I'll be
Re: (Score:3)
It's not really long lived. You can have one GUID per server, and can select how long you want it to persist for. The longer the lower the overhead when you request more data from that server, because the connection is already active and doesn't need to be re-started. This is similar to how HTTP/2 allows very long lived sessions.
But you can also change it as often as you like (with small overhead), use different ones for different servers, that sort of thing.
IPv6 is a similar issues, the usual solution to b
Re: (Score:2)
It will eliminate hate speech from the internet as we can finally identify and permanently ban all of the perpetrators.
Funny thing about "hate speech" is that most people define it as "speech I don't agree with". Most anything which speaks favorably of Republicans is falsely labeled as sexist, racist, or bigoted. I want a forum where I can post statements which are factually correct, even though politically incorrect, without getting threats in real life. I'm tired of living in a world where "all animals are created equal, but some animals are more equal than others."
Re:There's More to QUIC Than You Think (Score:5, Insightful)
QUIC's big win ... 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.
Hmm... I can't imagine why Google would want to develop a network protocol where devices/people could be persistently tracked by unique, persistent identifiers that would allow identification regardless of the applications used ...
Re: (Score:2)
Hmm... I can't imagine why Google would want to develop a network protocol where devices/people could be persistently tracked by unique, persistent identifiers that would allow identification regardless of the applications used ...
Good point. Considering how good Google is at tracking people, making it absurdly easy to track people would be a huge boost to their competitors while only improving their own abilities a tiny bit.
Also, couldn't the device be setup to change its GUID frequently if the user wanted to?
Re: (Score:2)
Seems to me you could change the GUID on every connect to every port, or anytime a connection is idle you could close/reopen with a different GUID. Seems to me you could change it more often (and more easily) than your IP address.
Re: (Score:2, Insightful)
I'd rather lose my connection than my anonymity.
Re:There's More to QUIC Than You Think (Score:4, Interesting)
Re: (Score:2)
What happens when your TCP/HTTPS connection is stolen or spoofed, you just know it will happen.
Yeah, it doesn't really make sense. TCP packets can be spoofed which is why HTTPS mitigates that possibility.
Re: (Score:2)
Downside: You lose (some? all?) anonymity, as your GUID is long-lived.
Many IP addresses are long-lived anyway. And my home IP address links a dozen different devices.
I haven't read the protocol, but wouldn't it be possible to cycle your GUID regularly? That seems like (slightly) better anonymity than IP addresses... not that either approach is designed for that purpose.
this is a huge downside (Score:2)
Re: (Score:2)
You know, for changing IP addresses, I just use mosh and tunnel over it. I think Google is solving the wrong problem here.
Re: (Score:2)
Downside: You lose (some? all?) anonymity, as your GUID is long-lived.
On second thought, refreshing my browser was not that bad.
Re: (Score:2)
Kind of entertaining so far, but here's the first stupid:
Do you really want your routing table full of hard addresses like 11:22:33:44:55
Re: (Score:2)
Actually, that was all really good, but the author failed to notice that management functions were being overlaid on what he called a mere human abstraction.
He probably has a good idea of how this management function could be done more elegantly in this alternate world, and maybe I could figure it for myself with more time and another read through.
But it shouldn't have been neglected in the original narrative, because the view from elegance is not a first language for the reader until the reader has read an
Re: (Score:2)
On the other hand, what happens if I generate a unique GUID (or Ipv6 address) for each session/browser window/etc? What if my browser supports a fixed ID/address for trusted sessions (like to my bank or stock broker) but then randomizes these when I'm doing searches, watching porn, etc?
Re: There's More to QUIC Than You Think (Score:5, Informative)
Actually, if I understand correctly, the client should be using different IDs at a much finer granularity than per-session or per-window. The connection ID (no longer called GUID) is assigned for each connection to the server, similar to the way each TCP connection has a source port and source IP. The connection ID typically persists for the duration of the connection, whether that's one second or a few minutes. If you have multiple connections (e.g. to download multiple resources in parallel), each would have its own ID. And clients can change them at any time — even in the middle of a connection.
Connection IDs are intended to make it possible for stateful NAT firewalls to route packets to the correct machines behind them. They would be useless for tracking, because they are too transient.
The Quic Transport [quicwg.org] RFC draft gives a lot more info than the protocol RFC.
Re: (Score:2)
A much simpler solution would be to always use static IP addresses. Using dynamic IP addresses is a hangover from dialup days and IPv4 limitations. You device has an identity so it can also have a fixed IP address. That is exactly why we have IPv6.
Actually, the switch to IPv6 was because there are more internet-connected devices than IPv4 addresses; static IP for every device was never the driving force behind IPv6. DHCP still exists for IPv6.
Yet more inappropriate layer-mixing (Score:5, Insightful)
HTTP/2 shouldn't have bundled in TLS, and HTTP/3 shouldn't bundle in UDP. Keep the layers separate; interoperability depends on it.
Re: (Score:2)
Seeing that requires experience. I begin to think Google engineering is lacking that.
Um, what? (Score:2)
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.
Re:Um, what? (Score:5, Funny)
...and the interoperability of IPX.
Oh good HTTP version next (Score:2)
I need to know how much of a QUIC packet has been set aside for ADs and/or trackers? /s
Re: (Score:2)
I think it's 28 bytes. It's a long lived, device specific, application independent QUIC. You don't need any other trackers using QUIC.
Re: (Score:2)
Oops, I meant "a long lived, device specific, application independent GUID".
Google already using this to serve ads (Score:2, Interesting)
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/ [google.com]
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.
What will that do to my firewall rules? (Score:5, Insightful)
Re: (Score:2)
I really don't want to spend the money on a new firewall just to support web browsing.
Nothing, which is kind of the point of this protocol.
Who needs congestion control? (Score:2)
Who needs congestion control? The network will be just fine when this is deployed large-scale...
Please stop breaking things that work (Score:2)
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.
Re: (Score:2)
Excessive use of UDP breaks TCP. Has been known for 20 years or so...
Why UDP (Score:3)
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.
Re: (Score:2)
Most "middle boxes" won't forward unknown protocols. They're too paranoid about security. Sure, they're willing to transmit absolutely anything over port 443. But an unknown IP type might be a HACKER! Oh noes!
Not only that, lots of them break unknown TCP options. Or TCP windows. I remember years when TCP ECN and window sizes wouldn't work on random internet sites because of their short-sighted, STUPID firewall boxes.
That's why QUIC is completely encrypted. Random hardware and software providers have proven
What are you talking about connectionless? (Score:5, Informative)
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.
Re:What are you talking about connectionless? (Score:4)
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.
By definition a tunnel is a transport protocol within a transport protocol. SSL is NOT a transport protocol. SSL is a security layer. SSL is transport agnostic requiring an ordered reliable stream over which to operate. TCP is but one of many protocols SSL operates over.
The reality is only advantage QUIC has over TFO + tickets is one additional RTT on initial connection. From there new HTTPS requests can be 0-RTT over TCP just like their QUIC counterparts.
The idea you are selling layering is bad and necessarily inefficient is not true.
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.
Not that it matters WRT topic at hand but not everyone wants to use TLS.
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 reason VPN transport avoid the use of TCP has nothing to do with inefficient evils of layering. It has everything to do with the fact VPNs are tunneling PACKETS not STREAMS.
What do you think TLS might stand for? (Score:2)
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.
Re: (Score:2)
> The connection comes first, then the security.
Yep, that's what you get when you take a 1970s protocol and try to duct tape security on it. With modern protocols, you just establish a secure connection in the first place. No need to establish an insecure one first, then start talking about switching over to a secure one.
> One can't get a postcard from an unknown address using unknown cypher and understand the message.
And sending back and forth postcards saying "may I send you a postcard?", "Yes you m
Re:What are you talking about connectionless? (Score:4, Interesting)
Lets look a little deeper though.
First you setup a TCP connection. Gotta have some kind of transport. That takes care of all the reliability and a lot of the recovery you need.
Next you start setting up the TLS connection on top of that plain text TCP channel. Okay - part of that is plain text you need to negotiate a cipher suite; do authentication, perhaps mutual authentication. You need to exchange symmetric keys etc.
All things you'd still need to do even if you crammed everything into one big fat protocol.
The only advantage I see in quic at all is sessions being separate from network addresses so they can survive address changes. That is kind of cool; I men your mobile could do from wifi to cellular without breaking a single transfer. There are other solutions to that like byte range requests though; that we have today. Improving support and reliability of those features might be easier frankly than upending the protocol stack
Re: (Score:2)
TLS on top of TCP:
C: hello I'm 1.2.3.4 and I'd like to talk to port 443
S: Okay, you can talk to port 443 if you really want to
C: Yes, I really want to talk to port 443
C: Can we use ECC encryption?
S: yes we can use ECC
C: Okay let's use ECC
S: Cool, ECC it is
QUIC:
C: hello I'm 1.2.3.4 and I'd like to talk to port 443 using ECC
S: You are now talking to port 443 using ECC
That's an advantage of QUIC over TCP, yes (Score:2)
> 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
Re: (Score:3)
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 hard
Re: (Score:2)
When LEO becomes a thing, this will help as well.
Not reinventing (Score:3)
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.