Before you move to HTTP/3 ...

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
it's been over a year since HTTP 3 has became an official standard and uh the adoption has Sky arched since then let's discuss so this comes from AP nick.net titled why htb3 is eating the ward it's very interesting and uh I'm going to link the article below for you guys because I I want to give full credit to to the author of course I can't just read everything but essentially I want to focus on the charts here because it's a really good article the article explains essentially how htb3 has gained popularity over the three years since his was started to become popular and this particular chart that we're looking at here is comes from Mozilla and specifically was captured since January 2021 and my guess this is is where uh Mozilla or Firefox started experiment exp menting or enable experimented support for htb3 that's why it starts with zero almost like 0.1 and then when it became a little bit popular you can see that it started to increase and increase the usage for htb3 so this tells me that both the client side and servers and backends started to enable light up htb3 and then you can see that http1 is gradually decreasing but not as steep if you notice right it's still cuz people still love this and I'm going to talk about why this article goes through the good thing about hb3 but it never mentions of course the disadvantage it's all like like everything in the in in new technologies nobody talks about the bad things right the the things that we never know or the things like Hush Hush right 3b3 has some potential disadvantages and we don't talk about these because it's the hype right we never talk about bad things when it's it's hype right so we're going to talk about this when the same thing want htb2 mid 2015 or even before that it was the perfect thing right then few years later the disadvantage of htb2 start showing up I expect htb3 in in three years from now two years from now you would start seeing as people started adopting it you will start seeing some problems with that nothing is perfect right so htb2 had like severe drops right here and another drop right here but it's a it's almost like a mirror from htb3 everyone who almost everyone who had htb2 switched to htb3 right of course it is it's not they are like disabled htb2 right it's still supported but they enabled the htb3 end point and it has you have to support both because because not all clients know quick right they don't know how to talk in the quick NH htb3 language so you have to have this Duality here but essentially what I want to talk about here is is it would be really cool to see the corresponding CPU and memory usage uh for these servers right because if I if you enable if you had htb1 and you enable htb2 you would see as slight increase in the CPU usage right compared to uh compared to htv1 and then htv3 to htv2 you wouldn't see much because it's almost the same computationally and why I why do I say that and the reason is because of this beautiful chart you know this is a fantastic chart so this is a fantastic uh diagram so in the top we're seeing the T TCP on top of TLS on top of TCP and it doesn't really mention if this is htp1 or htb2 if it's htb1 then this as is the encrypted content you simply copy it into your user space user process space decrypted and then immediately start working with the data so the cost you're taking is the cost of encryption of decryption like I'm talking about the back end here right so that's in htb1 one that's it you immediately once you decrypted you'll take you'll see the headers plain and simple right you'll see the headers yeah of course you might assemble need to assemble one more one or more packets so you can see the whole request right in this case because we were in the back end that's it so you decrypt and you immediately work with the data that's hb11 so it's straightforward and simple so the cost is just copying right the data from the kernel into the user space then apply the SSL crypto to decrypt it right using the symmetric key that was exchanged in HTP 2 there are additional work that needs to happen copying the data and decrypting is just the first step you are not ready to to to work with the data yet and this additional data the additional cycles that you need to spin is is parsing the streams because now we have the concept of streams right and when you work with streams you have to know oh what is this now oh is this what what this data is is this stream one stream s is this a header frame is this a data frame is this a setting frame so you have more parsing the protocol requires more parsing and parsing equals CPU and CPU basically your your CPU will go high right up and of course if you're talking about few packets it wouldn't matter but the higher throughput you have at least per connection the more you'll see your CPU Cycles you know usage goes up right and as a result because of this just proportionally your memory also will go up because you still need to move data around right so that's that's the htp1 and http2 in the quick it's almost the same right because now in quick it's actually maybe it's actually worse in quick let me explain in TCP the konel takes care of all this stuff yeah so it's optimized to learn and to understand about the sequence the ordering you know the packets and all of that stuff it's all there right the konel reorder the packets and has its own receive cue and send Q and and won't even send you the data that is not in order that's the basically the problem with gtp2 right uh we receed data from earlier newer streams but we can't deliver into the app because they are not in order and that's the problem the head of line of blocking but in quick quick is the transport protocol and guess what quick is not implemented in the kernel it's a user application it's a completely user space thing the kernel part guess what it's the UDP so the konel take takes these UDP packets and says all right here's a UDP datagram and it's not ordered so it will just put it in the receive queue and the app which is whoever runs the backend server that supports quick there is a quick library that is shared essentially with all other processes so it's like there's like a specific shared memory with this's library and that code runs and start parsing the entire UDP packet so now instead of the colonel doing it efficiently now the app your process is doing all the you know the quick transport things so anything related to connection the concept of a connections C of sequencing all of this is happening in your user space so you're doing more work so that just transfer translates to more CPU usage of course right I know the engineers at Google and and Cloud flare and people who is working on this spec are improving and lowering and lowering and lowering the cost of CPU I think I read a paper about this uh several months ago uh another feature of because everything is encrypted one of the most important problem with TCP is you cannot uh improve this protocol at all right right TCP because in the middle boxes in the middle they they look at this stuff the sequence number all of this is incorrupted in quick sequence number act and they accept this to be there and so if they are not there or there's a new field that you added it will just it will just block it and that's the problem why it's called protocol oifc it was it was never improved because of this reason but in quick because if everything is encrypted you don't have this problem right these middle boxes they look at this as just a dumb UDP packet just a UDP packet like all right whatever you have there as long as these don't change you're fine but this that's the structure of quick you can completely upgrade the protocol you can improve it you can remove ad field and the middle boxes will not be a problem as long as the server and the client agree on the version you should be good to go but of course while this there is a nice features that we talked about right of course that other features like oh zero RT and the TLs is actually mushed with the TCP connection right with the connection establishment sorry and that because quick literally is a transport work right and we did so we doing all of this at once but that is one of the Fantastic thing here the cost it would be really interesting to see all the cost associated with this right so I'm just uh I'm just interested I want to see like give it a few years and see how people you know what is the side effects of implemenation htb3 maybe people says no what are you talking about we have beefy server we never noticed it say all right maybe that's said right but um it's just that it's just interesting to know what happens behind the scenes because we take this for granted right see it's like all right yeah but understanding what the colonel does versus what the user space does it would be interesting right in the future what I what what I would expect will happen is the colonel will natively Implement quick and will do it much much much much much efficiently right in the future I think right but I don't know how long that's going to take to be honest right there is no talk about that at all in the community right all right guys catch you in the next one
Info
Channel: Hussein Nasser
Views: 15,117
Rating: undefined out of 5
Keywords: hussein nasser, backend engineering
Id: DWC0ELc6oIE
Channel Id: undefined
Length: 11min 31sec (691 seconds)
Published: Fri Oct 06 2023
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.