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!!
The next version of HTTP will break millions of routers. Good job!
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!
What license is this thing under? Unless it's fully open, it's garbage.
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.
... google protocol because google's http 2.0 was such a roaring success already.
Also the W3C are competent and they sure know what they're doing.
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.
More proprietary shit from a company that keeps trying to reinvent the fundamentals of the internet instead of providing useful services on it. HI GOOGLE NO YOU AREN'T THE FUCKING W3C AND AS SHIT AS THEY ARE AT THEIR JOB IT IS STILL THEIR JOB WAS DASH NOT A CLEAR ENOUGH FAILURE
"Made up/misattributed quote that makes me look smart. I am on
to better connect the user with big brand ads.
Domestic spying is now "Benign Information Gathering"
There are many smart people behind Slashdot, why don't they implement some way of blocking this annoying little piece of shit?
This will allow even easier DDOS attacks to web servers
All the smart people left a looong time ago.
Sure. On paper it looks that way....
WTF *IS* all this massive faggotry shitting up my screen? Can't someone ban these assholes, or go to their houses and smash their computers or something? NOBODY needs to be subjected to this bullshit.
HTTP/2 was a retarded shitshow. Let's hope this one is a little less that.
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
So browsers will have to support three levels of protocol , basically forever? How much bloat does that add? And the people at Apache. Mozilla and Microsoft all have nothing better to do?
Or is this at the network layer, thus the OS and router people are going to be impacted?
I do not see this happening. Let’s all reflect on the mess called android and reflect. HTTP is critical infrastructure. Google is not up to the task. They are media people. They have ties to the communists in China. The banks will never never never never rewrite their apps. Never.
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.
We should be implementing RFC 1149 with the RFC 2549 amendment.
I get it now, you are the real idiot, the other one was impersonating you.
Why would you let this scumbag corporation replace a simple, easy standard with a massive, convoluted pile of shit? This is a travesty.
The WHOLE PURPOSE is to overcomplicate it, then change it *constantly* - so that they are only ones who can keep up. Total de facto control.
They did same exact thing with web browsers. Jesus Christ. Do NOT switch to QUIC *EVER* unless you want your privacy fucked forever.
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
Seriously, cut it out. Google should be the last company on planet Earth to have any say in anything. They would sell you your own nutsack for twice what you earn in a month ...
A binary protocol is a step backwards. Saving a few bytes and making it all faster is totally at odds with what has been improving recently - available bandwidth and speed. Besides, any speed degradation has been caused by hundreds of advertisers all linking to the same page. Google could easily reduce that factor without reinventing the wheel (with a more broken one).
ZIP tell us why you twice minusmod hid APK exposing you for the trash you are here https://news.slashdot.org/comm... ? Ashamed? You should be.
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...
We'll stop impersonating you when you stop making posts in support of yourself, (where you're doing a very poor job of) pretending to be someone else.
You really don't think we can tell?
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!
Sorry to burst the bubble of your narrative, but IPv6 deployment stands at around 25% now, averaged across the world. That's specific to Google users, but they constitute a very broad and representative demographic. Looking at countries individually, IPv6 adoption among nations leading the charge is of course substantially higher:
- Belgium 56.42%
- India 45.98%
- USA 43.79%
- Germany 38.85%
These are huge percentages already despite your allegations of slow adoption. In any case, your cited time interval is incorrect.
World IPv6 Launch day was on June 6, 2012, so the transition has been ongoing for 6 years, not 15 or more. Backdating it to the start of IPv6 design and development only makes sense to those trying to fabricate some kind of anti-IPv6 point out of thin air, and isn't rational. Transitioning your company to a new protocol stack before it is officially launched for production is not what a professional engineer would do.
Considering the large costs in equipment and manpower involved in IPv6 deployment, 25% world and 56% leading national deployments in just 6 years is pretty damn amazing.
And in the nick of time too, as IPv4 is on the edge of a precipice. And just to make the growth of new enterprises looking for IPv4 addresses even less attractive, the market price of IPv4 addresses is now around $18 each, and rising.
Your narrative is falling apart. IPv6 is arriving much faster than anyone reasonably expected.
Yeah, WTF is this? APK? Hosts file engine? WTF!!!!
It's good stuff though. I wholeheartedly recommend a pint of excellent hosts file engine security.
You know that everyone is just godeing You for fun right? Every time you react they get a little emotional kick because the have power to easily control you.
Just move on and enjoy your life. That will be the best way to make you happy and will stop everyone else from revelling in all the hate.
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
I think this story might be an old festering regugitated dupe
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.
Seem to totally blast right threw my ISP's traffic shaping..
Funnily enough QUIC is already in chrome (but off by default)
Some sites owned by google are already QUIC enabled, eg youtube.
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
I love you APK.
Google's getting good at standards nobody wants or uses. HTTP/1 forever.
See my subject: Blame those impersonating me. I only post on hosts IF they stop threats OR to speed you up. I don't off topic.
I've got my own "psycho fanclub" IMPERSONATING me & spamming + lying about MY work (I don't post about it unless it applies to STOP THREATS or SPEED YOU UP).
They also STALK ME constantly by UNIDENTIFIABLE anonymous posts like whackos!
* They're a pack of BUTTHURT little wannabes & psychos I've torn to shreds before & this is their "effete 'revenge'" & "ReTaLiAtiOn" lol apparently!
Especially GOOFS like c6gunner CAUGHT IMPERSONATING ME https://linux.slashdot.org/com...
(His name's on that post link as the SUBMITTER yet signing "APK" as I do while he ALTERED users words of praise of my work (since he tried INSULTING me & I simply issued a FAIR CHALLENGE to him that HE SHOW HE CAN DO BETTER - he hasn't to date & NEVER will (wannabe))).
ZIP is another I've had to PUBLICLY SHAME & he tried HIDING facts that show he's a FOOL & A LIAR here, twice https://news.slashdot.org/comm...
APK
P.S.=> Jackass WEAKLING LOSERS abound (ZIP & c6gunner are PRIME EXAMPLES)... apk
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're caught impersonating me c6gunner (your name's the submitter signing "APK") https://linux.slashdot.org/com... & you ALTERED /.ers PRAISE of my work (not yours you don't even HAVE).
(Don't throw stones if you live in a glass house vs. me: RIGHT ZIP? https://yro.slashdot.org/comme... )
LIAR ZIP says he has no account "I don't have an account, so I don't have mod points" https://news.slashdot.org/comm...
Yet LIAR ZIP says he downmods my posts (IMPOSSIBLE MINUS AN ACCOUNT on /.): "I down-modded a few of your post on other threads" - by Anonymous Coward "ZIP" on Thursday October 11, 2018 @11:31AM (#57461058) FROM https://yro.slashdot.org/comme...
APK
P.S.=> Hosts can stop portsmash (blocking downloads of it) https://it.slashdot.org/commen... not Spectre/Meltdown AFAIK - & U FAIL a PORTFILTERING TEST https://yro.slashdot.org/comme... ... apk
0.0.0.0 test1.com:53
0.0.0.0 test2.com:53
0.0.0.0 jowie.com
0.0.0.0 jealous.com
0.0.0.0 jowie.com
0.0.0.0 test3.com
0.0.0.0 borlnd.com
0.0.0.0 tester.com
* RUN THAT DATASET THRU MY PROGRAM & WHAT RESULTS COME OUT THAT HAVE A "PORT FILTER" ATTACHED?
NONE!
Only borlnd.com, tester.com, test3.com, jealous.com & jowie.com (last 2 are for YOU, lol) REMAIN (no filters on them)
MY PROGRAM EVEN PREVENTS THAT MISTAKE!
APK
P.S.=> THIS PROVES MY PROGRAM'S OUTPUT DOES NOT ALLOW "PORT FILTERING" ENTRIES IN HOSTS as I said!
ALL DESPITE you IMPERSONATING ME & LYING (for YEARS now) saying hosts do + STALKING ME via UNIDENTIFIABLE ANONYMOUS too (loser weezil).
It's LONG PROVEN YOU DO THAT c6gunner https://linux.slashdot.org/com...
+ your LIES saying I have a MacOS model (I don't YET) OR that hosts cure Spectre/Meltdown (hosts don't but you LIE impersonating ME saying they do - FILTERS in hosts too!) ... apk
> 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.
But I'm still.. ohhh.....
You forgot to tell everyone that you're an employee of Google, a manager/engineer of some kind IIRC. In that light, your argument looks very different. SHILL HARDER.
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