QUIC is FINALLY a Standard. RIP TCP?

after eight years of continuous evolution quick is finally a standard it's a proof it has a number and all it has an rfc number get this it's a sexy number nine thousand give me an rfc that has like the beautiful number like this none it's final standard let's discuss welcome to the backend engineering show with your host hussein nasser and quick which i don't think it's an acronym for anything right but but people try it's the protocol that google has invented to solve limitations of http 2 and obviously there's no long video enough to talk about the history about all the stuff i made many many videos about the history about this i talked about http i talked about http 100 i talked about hdb11 hdb2 i'm gonna link up the playlist for check it out if you want to learn more the history the history is very very critical because guess what we don't solve problems for the sake of solving problems we don't invent stuff for the sake of inventing stuff we solve problems that exist right and that's what quick was for and eight years google came up with a quick protocol which is an implementation of this multiplexed way when the client needs to send so many requests and a single tcp connection cannot be used as its raw form to multiplex stuff we tried with http 2 we failed http 2 locks up heads offline blocking and then there's an additional stuff that we don't really uh we can't get our get our with the j which is the tcp handshake itself and then we have to secure the tls and there is the the protocification boxes in the middle started messing with our packets when hdb2 so it's a mess it's a mess so we wanted a way to be more efficient that's what google invented and given the the quick protocol right it was their own version cloud freight could to contribute microsoft chipped in everybody chipped in to make the protocol better there was like so many facebook is now i think a completely unquick on their back and i talked about that if you want to check out the video facebook completely moved too quick internally right they have seen they seem good improvement not not great good there was so many drafts google started to do their own thing the the ietf started to do their own thing and they finally converged into one final version right now you can turn on http 3 which is running on top of quick if you want to and uh you can enjoy this new protocol how about we jump into this article and discuss all right let's read this from the register tcp alternative quick reaches ietf standards track after eight years of evolution google spawned it cloudflare backed it microsoft made its own cut and both ends worry it didn't improve privacy well let's let's check all right let's read this blurb and then discuss a little bit more quick udp internet connections is that what it stands for i don't think because google did say that it doesn't stand for anything it's just quick right uh have uh graduated to internet engineering tests for standard track the quick spec we're gonna open it up in a minute rfc 9000 appeared on may 27th so a few days ago making the end of the beginning for a story that started in 2013 when google revealed it was playing with quick which it then described as an early stage network protocol we are experimenting with which runs a stream multiplexing protocol over the new flavor of transport layer security on top of udp the beauty here is we only had the concept of tcp for reliable connection and we have the other option of a layer 4 transport which is udp which is not reliable so people stop building stuff on top of tcp but guess what when you are at the application level you want to you have your own rules you have your own guarantees and tcp started getting in the way of this because because it just deals at the packet by packet basis and it has its own handshake and now on top of that we hope we have to secure things because we're on the encrypted world we don't want any on anyone to snoop so we invented tls so we have to do the handshake so three-way handshake of tcp and then on top of that we always had to do this tls right so ts 1.2 we had uh almost two round trips to exchange the symmetric key and then ts 1.3 we made it into one we even cut it down into zero round trip zero rtt with tls 1.3 improved edition uh with this idea of having a send the data if i did talk to you before the pre shared key concept but even then there is so much stuff that we have to do to get to sharing the actual content quick what google built originally they said okay how about if i moved the guarantees of the tcp handshake and the connection reliability and the packet delivery up at the application level not really application just higher level and use udp so i'm gonna do a handshake to to establish the sequences the number of sequences and and the packet numbering and all that stuff and in the same virtual handshake not logical handshake that i'm building on top of udp i'm gonna do tls so two in one beautiful beautiful how this is just genius right and that just the idea of that really solves a lot of time so let's continue reading quick's best trick is to allow a client and server to exchange data with the list overhead as i discussed it earlier cutting off the extra round trip established to needed to establish the tcp link means less traffic and faster connection so you don't need to to do the tcp handshake while you're doing a handshake well quick but were moving to handshake in one the encryption and the actual tcp handling that's especially welcome on wireless network yeah less overhead which are nearly always shared and see contention for resources just in case you haven't noticed there are three billion wireless devices okay okay we know connection connectivity greasing company cloudflare link quick so much it's offered it as a service we know uh cloudflare has been pushing quick for a very long time i've been covering these news on my channel here quick has been really a pioneer right when it comes to quick they just did so much stuff with quick google already back quick into the chrome browser long time ago i mean i've showed in my my uh my analysis videos that when we go through devtools we see this q3 uh protocol there's a google owned version of draft right now they are hopefully they get a move to the actual standard rfc version but quick has not been widely adopted elsewhere a cloudframe post celebrating quick ascension to the standards he says it can detect around twelve percent of the internet using quick with hdb3 and if you go if you're using iphone that's if you're going out and you go to safari option settings you're going to see that http 3 is turned off by default i don't know so people are still skeptical they want it maybe they want things to be standardized before because you know the bugs that comes from the http 3 and all that stuff they want they want things to be stable before moving all right so guys so this is the actual rfc rfc 9000 request for comment 9000 as you can see and one one thing that is really a sell point for quick uh there's been a lot of people talking about is the ability for seamless underlining connection media switching so that means if you're using quick theoretically again if you are on a wireless network on your home and you drive out for your garage because that happens to me all the time and then all of a sudden you switch to a 4g network what happens here is obviously your ip address change your local port change your destination still doesn't change because you're connected to the same server technically right well not technically because you're through load balancers and all stuff you might hit another server but now that you have to retry that connection again right we don't need to see we don't need to see the rfc anymore so because i'm going to discuss this and end the video but yeah if you drive our garage you're going to change your ip address you're going to change your ports and as a result the connection is being dropped right you have to you your old connection the server eventually is going to give up because oh there's no uh there is no pings coming from that connection must be have been disconnected so i'm gonna send the reset and now you're coming in through a brand new connection here with a new ip address and now trying to establish a new connection so that you have to take the hit in their older design with tcp you have to take the head to do the handshake again to do the tls again with quick they have like a bit in the packets itself it's called connection id which keeps track of that connection so the there is a logical connection that is keep being keep track so it's still stateful thing but it's being sent with every packet so now if you want to re-establish as a smart client that as a smart quick client you can re-establish reconnect with the 4g connection on on that connection id so asking the server to re just just hey you know me i'm still saying oh gee but i've been low key let's connect again let's not do this stupid handshake you know me all right so now the if the server receives that connection id renegotiation whatever it's called it will just resume where it will pick up where it is left off that's even so powerful but what people miss here is that is not easy to implement right because like think about it connection id is where where do you store this connection id the implementation it has to be stateful you start in the server memory so if i came in into a 4g connection within different ipas and and i did send a connection id first of all what is the guarantee that the load balancer will eventually funnel my packets all the way to that server that has my connection id there are no guarantees so you are responsible to build the guarantees so you can build a sticky session all the way to that server if based on the connection id and here's the thing i don't know is that connection id bit encrypted i'm gonna say absolutely i think yes if it's not encrypted then i can do this solution if it is encrypted there is no way unless you terminate the quick tls encryption in the load balancer and look at the connection id right you can't do it so there is other ways like okay the rfc i read the rfc a bit that way so you know what let's share the rfc uh again reading through that because that's that's part so yeah i was interested in that part so i searched connection id and behold someone essentially people those people are smart so they thought about this and look at this consideration for simple load balancers because like how does that work how do you do connection migration in in load balancers that's very very interesting right so i started reading through this thing and i don't know if i'm convinced with these solutions to be honest one solution says okay a server could use an out-of-bound mechanism to forward packets to the correct server so if that if another server receives that connection migration with the connection id another server that server is responsible to send it to the actual server so you need to have an out of bound like a database to store the connection id on the server which is i don't know about that you can you can do that it's not it's not difficult i guess but then the service has to talk to each other things that you don't normally have to do i mean you can have a message queue in the middle to talk to a broker something like that the other solution is that if the server can use a dedicated server ip port address or port other than the one that the client initially connects to they can use the preferred address transport parameter to request that the client move connections to that dedicated address so you have a dedicated address and make sure that assuming that dedicated is not a load balancer or an api gateway that just funnels you randomly to another server right it has this this other bullet i believe is a way to do okay let's make let's make a way a sticky session kind of a solution where make sure hey always connect to me right all right guys but this is i'm so excited i am so pumped for this news this is excellent news i hope people start moving their implementation to to quick and see what's wrong with that right obviously uh people are concerned with security and i understand that as well because this this idea of connection migration is scary imagine someone just sending a connection migration without any credentials or anything and that you can just resume a connection if i can guess a connection id can i be able to resume it right if i can guess maybe an ip address or a port if i know this information can i just resume it from somewhere else i i'm pretty sure people thought about it the smart people are a quick and the enter internationing task force thought about it but i'm just interested about this stuff what do you guys think about this news i'm gonna see you in the next one you guys awesome good bio disco

Channel: Hussein Nasser

Views: 19,185

Keywords: hussein nasser, backend engineering, quic, quic google, http/3, http vs quic, quic rfc9000, rfc 9000, quic system, connection id quic, QUIC is a FINALLY a Standard. RIP TCP?

Id: vfShdjlyRGg

Length: 14min 46sec (886 seconds)

Published: Thu Jun 03 2021