Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
devNews12226y
-
Great, one more protocol to remember. As if they didn't have enough already.
Levity aside, this is actually really cool. -
Thank you DevNews!
what's the expected real life benefit of this for the average joe? -
-vim-31256y@heyheni Faster loading times overall, and I guess less traffic, which is great when you have things that communicate lots of small files I guess.
-
Skayo85686y<@gitpush>
Couldn't find any info about the release date. Sorry. But as mentioned I'm sure we will still have to wait a bit for version 3. -
@irene HTTP that shoves the resources you need at you before you can parse the document to identify the next requests you'd need to make.
-
matste6416yWhat could possibly go wrong by abandoning tcp - a protocol with tens of years of testing and tooling?
-
@matste Yeah. I suspect we're going to see a rehash of the TLS1.3 problems unfolding at the moment, but on a much larger scale.
-
Internet Enginieer Task Force sounds like something that only Trump would be capaible of creating...
Of course... just move it from tcp to udp! Well that isnt creation of a new protocol, just messing thing around!
Yep udp with relaibility of tcp... sounds like bullshit... propably is going to become a async hell.
And that was my amateur opinion on the matter.
Bullshit-o-meter reading: blockchain*cloud / 10 -
@matste @AlmondSauce @Gregozor2121 every request to google sites from any google browser already used quic for the past 5 years
-
@succcubbus
Oh so they somehow managed to pull that off... Im curioua how they managed to change the protocol.
It is the time to test it against the old solution! -
@irene this is reasonably thorough: https://ma.ttias.be/googles-quic-pr...
The usage info starts a bit down the page after the 'The QUIC protocol in action' heading -
Especially: "since Chrome 52, everyone has QUIC enabled by default, even to non-whitelisted domains"
-
GeaRSiX6426ySo is HTTP/3 going to exist alongside HTTP/2 or replace it?
I'm kinda excited for HTTP/2's features and I've only just seen it start to get implemented anywhere.
Related Rants
-
devoutpost14HTTP response code cheat sheet (From /r/Programmer humor)
-
alexjamesbrown17Status code: 200 Content-Type: application/json Body: {"error": true, "responseCode":400 }
-
arturgrigio13You see a web, I see: CLIENT: TCP SYN SERVER: TCP SYN ACK CLIENT: HTTP Get SERVER: HTTP Response ... CLIENT...
--- HTTP/3 is coming! And it won't use TCP! ---
A recent announcement reveals that HTTP - the protocol used by browsers to communicate with web servers - will get a major change in version 3!
Before, the HTTP protocols (version 1.0, 1.1 and 2.2) were all layered on top of TCP (Transmission Control Protocol).
TCP provides reliable, ordered, and error-checked delivery of data over an IP network.
It can handle hardware failures, timeouts, etc. and makes sure the data is received in the order it was transmitted in.
Also you can easily detect if any corruption during transmission has occurred.
All these features are necessary for a protocol such as HTTP, but TCP wasn't originally designed for HTTP!
It's a "one-size-fits-all" solution, suitable for *any* application that needs this kind of reliability.
TCP does a lot of round trips between the client and the server to make sure everybody receives their data. Especially if you're using SSL. This results in a high network latency.
So if we had a protocol which is basically designed for HTTP, it could help a lot at fixing all these problems.
This is the idea behind "QUIC", an experimental network protocol, originally created by Google, using UDP.
Now we all know how unreliable UDP is: You don't know if the data you sent was received nor does the receiver know if there is anything missing. Also, data is unordered, so if anything takes longer to send, it will most likely mix up with the other pieces of data. The only good part of UDP is its simplicity.
So why use this crappy thing for such an important protocol as HTTP?
Well, QUIC fixes all these problems UDP has, and provides the reliability of TCP but without introducing lots of round trips and a high latency! (How cool is that?)
The Internet Engineering Task Force (IETF) has been working (or is still working) on a standardized version of QUIC, although it's very different from Google's original proposal.
The IETF also wants to create a version of HTTP that uses QUIC, previously referred to as HTTP-over-QUIC. HTTP-over-QUIC isn't, however, HTTP/2 over QUIC.
It's a new, updated version of HTTP built for QUIC.
Now, the chairman of both the HTTP working group and the QUIC working group for IETF, Mark Nottingham, wanted to rename HTTP-over-QUIC to HTTP/3, and it seems like his proposal got accepted!
So version 3 of HTTP will have QUIC as an essential, integral feature, and we can expect that it no longer uses TCP as its network protocol.
We will see how it turns out in the end, but I'm sure we will have to wait a couple more years for HTTP/3, when it has been thoroughly tested and integrated.
Thank you for reading!
random
http-over-quic
quic
http/3
http