 All right, welcome everyone to this talk. My name is Robin and I'm a PhD student from Belgium And I spent the last couple of years getting to know these new internet protocols quite intimately I'm actually kind of it sad to say that I don't really know all that much about the droop out. I know terrible I'm sorry, so you might be wondering Robin. What are you doing at the droop on stage? Well, that's mostly because of this guy Women there's variable Drupal God. He is not only a very prolific Contributor he also used to be one of my classmates at university Wait back then he was already working on all things web performance and CDN integrations for Drupal and it was watching win with his projects that got me interested in this topic and I ended up doing a PhD in it When I kept in touch over the years and he said, you know quick talk at Drupal con would be interesting and Here we are. This means that if you like my talk, please come talk to me afterwards. And if you hate it, you can blame all of that Now I'm not gonna have too much about Drupal today, although I have a little bit yet I will focus mainly on the protocols themselves. I want to do that from a kind of a Devil's Advocate perspective a grumpy old man viewpoint if you will I want to do this because I see a lot of other talks and articles about these protocols And they make some very big claims. They say they're going to lead to massive improvements And while I think they're not necessarily very wrong I also think they often like a lot of nuance a lot of context that helps you really place where those claims are coming from So I want to make sure everybody stays with a feeling the ground today And knows what's happening underneath. I want to do this because I was there again Four years ago when HTTP 2 was announced and I read that kind of article and Upon deploying H2 was very disappointed if it doesn't if it but it didn't suddenly give me 50% faster improvement Magical, right? So I want to help prevent that this time around kind of manage expectations So we know we're getting ourselves The first thing you might have heard of these protocols is that quick was renamed HTTP 3 and they're actually the same thing You might also think that since two and three are quite different numbers These are obviously very different protocols and I would say two of their statements are absolutely not true The thing is we often look at HCPT in isolation, but that's not really correct on the modern Internet It's actually more like a protocol stack where HTTP runs on the application layer of the stack and beneath you have the transport layer With TCP for H2 and now quick for HTTP 3 so we can immediately see that quick in HB 3 or indeed Two completely different protocols running at different parts of the stack with different features Now, why do we need quick in the first place? What we really wanted was TCP 2.0 Because TCP is getting kind of old it has a lot of inefficiencies on modern networks We want to improve that the problem is TCP is also very popular There are billions of devices on the internet implementing if you want to change anything about that You have to wait until all those devices are also update We tried that for decades. Simply does not work The only viable way forward is to do something new you can't do something completely new because again the devices wouldn't understand it So quick is built on top of the only other well supported transport layer protocol called UDP This has led some people to say that quick also has the Features of UDP like unreliability that is completely false quick is very much an improvement on TCP with much of the same features only much better Now the original idea was to run HTTP 2.0 on quick as well as you can see here Because that's the main reason why we have this stack of different layers if you swap one layer out The rest should be relatively stable, right? That's in theory in practice, of course turns out HTTP 2 was a little bit too reliant on specific TCP stuff And we needed to change a few small things to make it quick compatible Not too much just a few couple of things and I would have called that HTTP 2.1 or HTTP 2 over quick It's more like the marketing department came in and they decided we're gonna call it HTTP 3 that sounds better But in practice the two protocols are really really similar. They have a very similar feature set We'll see later on that is actually a good thing That's not to say that if you use HP 3, you're not gonna see differences in behavior It's mainly that those come from the quick implementation melt from HP 3 itself So I'm gonna focus mostly on quick for the rest of the presentation And one of the things you might have heard about quick is that it's indeed better for security and privacy This is kind of true, but probably not in the way that you think It's not like quick is suddenly going to encrypt your passwords better or make your web page contents more secure You can already do that with normal HTTPS today The main thing that quick adds is it's going to start encrypting that transport layer as well There's a lot of extra stuff in there things like packet numbers and acknowledgments and read transmissions That are plain text visible for TCP that are now encrypted over quick Now in TCP they're being used by a lot of devices on the internet to implement some interesting features For example network operators use this to estimate how healthy their network is if you see a lot of retransmission going on That might mean that you have a problem Satellite internet providers can fake these fields to improve their performance over satellite internet And if you have a firewall some of the security features are also going to be looking at these TCP header fields Now with quick these are all encrypted you can no longer see them not necessarily for more security The reason for this is that quick wants to stay flexible. It wants to evolve in the future And the real reason we can't evolve TCP anymore is exactly because middle boxes are using these fields Right if you want to change anything about the public TCP header, you have to update all the things that do this So the idea is for quick if it's encrypted No one can read it. No one can use it. That's what we can very easily change it later on without breaking anything Right, this does have some nice security and privacy implications as well But that's not like intent. The main reason is to keep it Evolvable The problem is I think we can agree that the things on the left Quite useful, right? You might also want those for quick And the people doing that said that to the quick guys and they said it's good, you know, we're gonna help you We're gonna add something back in what they did was add a single bit One bit in the public quick header. It's called the spin bit And you can use it to kind of measure round trip times That's it and I always kind of imagine the quick people they felt a bit like this After they did this, right? They think one bit should be enough for anyone case closed. We can move on to the next feature Or I also think you can imagine what the network operators think about that You know, they suddenly have a very complex new protocol that they can't control and can't measure on the networks What are they gonna do? Right? Very high chance. They're simply gonna block it Right very easy to do because it runs on UDP. You can simply drop all of UDP People have looked into that turns out Three to five percent of networks were already doing that two years ago And I predict that this will rise as the amount of quick traffic increases Right? We've indeed seen in the past couple of months several firewall vendors have started issuing recommendations that people should be blocking quick Wholesale and also giving you tutorials on how to do that At least until they figure out how to add back some security features into that You think Robin that is never gonna happen, right? Because users would be angry They would say I can't load my favorite web page anymore because you're blocking quick That's not true because network operators have a secret weapon Right tcp fall back. You will always have networks blocking quick This means that you as a side provider always have to have a htp1 or htp2 server Next to your htp3 setup to provide for those users So websites will still keep on loading as normal. Those users will just not see any of the benefits of quick I always think this is quite ironic quick trying to be better in the long term Means that less users are actually able to use it, right? Now I said quick benefits and what you usually hear is always about performance performance performance, right? You might have thought quick and h3 are going to be so much faster than anything that we have right now When you talk about speed, it typically mean one of three things I'm going to talk about all of this all of those separately The first thing you might have heard is that quick is a very fast setup. It's connection. You might have heard the buzzword zero rgt To understand this you kind of have to know that I've told a half to myself not so long ago because there's actually another protocol in the stack It's called tls. It's a thing that adds the s in htp s It makes your stuff secure, right and it runs on top of tcp and is also embedded into quick to make encryption work Why am I telling you this because most of the articles are quick. They will show you these two diagrams And on the left you will see the tcp connection setup and they say it takes four round trip times four rgt's Back and forth between client and server to finally get some of the data back And two of those four are because of tls overhead And on the other side they place quick and then in quick magically all of that can happen in one round trip time And that doesn't sound newly impressive enough So they bring back in that marketing department and they call it a zero rgt as a new feature, right? But this is true quick can do this But it's not the normal way of establishing a quick connection that actually looks a bit more like this You can do the quick and the tls handshake in one rgt, but then you need a second one for the http level data But the thing is somewhere in that connection. You can also get what is called a new session ticket It's a tls 1.3 feature and the ticket basically contains an encryption key for your next connection So the first time you talk to a server that you don't know you do The center flow and then if you remember to take it and the server also remembers you Then the next connection the second one onward. You can start using the zero rgt feature. This is what's called tls 1.3 connection resumption, right? Now the interesting thing is this is not a quick specific feature. This is tls 1.3 That also works on tcp So the left side is actually kind of outdated what you can perfectly do in tcp is more like this The three rgt connection setup where you also get the new session ticket, which means you can also resume that Getting a two round trip time optimized setup with tcp as well You think maybe that's not good enough. That's still twice as much as quick But there is also a feature called tcp fast open That actually makes it behave almost exactly like what quick is doing The problem with tcp fast open is it's been around since 2012 It's a perfect example of how tcp is very slow to evolve It's only in about the last year that this has become kind of Usable on the wider internet and its support will continue to improve So that means that hopefully within one of two years You don't have to choose quick to get this zero rgt benefit. You can just use tcp as well So that's nice, but the real point I want to make here is that zero rgt is not really that interesting of a feature in most use cases And the reason for that is security And I got a nice example of that to explain it to you You might not notice But the Drupal con speakers, they're not actually getting paid. We are doing this voluntarily Now I said to him, look, I mean, Amsterdam is an expensive city. I have to come in by train You're gonna have to you're gonna have to give me something, right? And I badgered him for long enough and he agrees to send me a hundred bucks Right and he's gonna wire transfer this using a zero rgt post request to his bank because whim is cutting edge Right That was a big mistake when because I Am an elite hacker, right and I was in his network. I intercepted that message That zero rgt is fully encrypted. I can't read the message. I can't change the amount But what I can do is this It's called a replay attack This means if you want to do zero rgt, you can't just send anything in that You can't send anything that actually permanently changes back end state You can only do what they call item potent requests This means things like a normal get request for index or php will work quite well But if you want to do quick for internet of things appliances Or if you have a single page app that regularly posts backs and updates It's much more difficult to keep that secure And that's only the first stage the second problem comes when win whips out his phone checks his account balance and notices what I've done And he's going to get quite angry predictably So he's decides to take revenge What he's going to do is launch a denial of service attack against me The concept there is simple He wants to overload my internet with so much data that I can't do anything productive anymore Now he doesn't have enough bandwidth available to him to do that himself So he's going to try to have someone else do So he sends a zero rgt request to a web server for a very very large file The key thing there is that he's going to pretend this request comes from me You can do that on the internet using something called ip address spoofing Which is sadly still a thing that you can do If the web server agrees with this Wim has his intended effect and indeed I'm going to be drowned in all the bandwidth This is what's called a udp reflection or amplification attack Amplification because Wim only needs a very limited amount of bandwidth to have a very large output towards his target We've seen kind of these attacks the past few years. They're quite powerful and dangerous And quick has therefore decided to build in a protection against these attacks The way it does that is says whatever i'm getting in a zero rgt request I can only reply with that with three times as much data as I have received The amplification factor should be only three or less, right? Now because a normal rgt zero rgt request is just one or two packets in size This means the response is usually going to be less than 10 kilowatts That's not terribly. That's not terrible, but definitely not enough to fit your normal index of html Let alone anything else, right? So it's definitely interesting if you already have a well optimized website You can send your html head sooner and you can start discovering resources sooner But if you have a crap website, this is not going to do much at all The second performance thing you might have heard about quick is that it actually sends its data much faster in tcp When people say this, they're usually talking about something related to congestion control What is congestion? That is if your network is becoming overloaded. There's too much daytime Your devices can't keep up the the only thing they can do is start dropping packets that they can't process in time That's the way you typically get packet loss The only way to recover from packet loss in reliable protocols such as tcp And quick is typically to do a retransmission a new copy of the data The big problem there is that knowing that something was lost and then actually retransmitting it often takes a lot of time More than one round trip So everything you've gained with the previous optimization you can lose very easily if you have a lot of packet loss So you really want to prevent that from happening But how do you make sure you don't send too much? Right? Because we don't know how much bandwidth we have at the start This is what your congestion control algorithm is for The concept is very simple. You start off by sending just a little bit of data the bottom left Typically around 14 kilobytes If you get acknowledgments for that from the other side, you know, it's okay. I can send more 28 kilobytes You keep on growing your send rate until at some point you do see a packet loss That is typically a very clear signal that your network is becoming overloaded And indeed you have to back off. You have to limit your send rate again This gives the network time to recover And later you can start growing That's a basic way of doing congestion control. There are more complex algorithms out there, but that's a general concept And if everyone in the network does that That's a good thing. We get what we call fairness Here each individual cord line is a single connection And you see that over time they all tend to get about the same amount of bandwidth on the network. That's good behavior Now let's imagine that you have a bad actor in there somewhere that is not going to do this Instead when you see a packet loss They know that the rest is going to drop They know that there is going to be room on the network so they can happily keep growing Right increasing the send rate getting better performance for themselves At the expense of the rest This is when you get an unfair situation There have been tests, some quick implementations for example turnouts To take about two-thirds of all the available bandwidth Leaving just one-third for the tcp traffic The bottom one is even worse Where the green line is google's new bbr congestion control algorithm In this test at least drowning out almost all the other traffic that was there Now i am not saying that google is doing a left side of this slide right they're not trying to be nefarious But the fact is that they and other big companies have been experimenting with these kinds of new congestion control algorithms They're typically very complex It's not always well understood the kind of impact they have on other types of traffic on the same network There are even some critics who have said that because google is doing this They might have an unfair advantage for services like youtube for example because they're able to get better performance from that That is not what i'm saying That's what other people are saying of course what i'm saying is It's still possible for someone to do the left side And if someone actually starts doing that trying to be more aggressive We might end up with something like this A veritable arms race where someone deploys something more aggressive. The rest has no Option but to keep up not to be drowned out and if you keep on doing this long enough Keep on being more aggressive. You might not know what they call a congestion collapse of the internet right Some people think that might be a threat Others think that will not happen The latter group their main argument is You've been able to do this with tcp for decades, right? And there might have been companies that have been more aggressive with congestion control, but the internet is still here So how bad can it really be? That's kind of true But quick kind of changes things You see tcp is typically implemented in the operating system kernel Right highly privileged environment very difficult to program in if you want to change something about tcp You have to recompile your kernel. You have to deploy it on your machines It's definitely possible But it's definitely not something that many people in the world can just do like that, right Now quick is different Quick is implemented fully in user space Again, this is done to keep it flexible to keep make sure we can evolve and add new features easily What this also means is that any proverbial idiot with a keyboard Could start tweaking parameters of this congestion control start tweaking the behavior to get better performance for themselves But maybe those new people don't have enough Qualification or insight to know what these changes are doing to other people on the same network And the problems i've just described might actually start emerging Maybe maybe not Maybe thinking robin Mildly interesting, but why the hell are you telling us this we will never deal with this, right? The thing is i think you will I think you will see this kind of claim From certain companies down the road That they will start saying you know use our htp3 server because we are so much faster than the competition And here are some kind of bullshit benchmark results to prove that When somebody starts promising this You can't get magical performance like that, right? It usually means that they are cheating They're being unfair coders You decide if it's worth it or not, right? But I do think this kind of thing will happen now You know where those claims will probably be coming from The last performance optimization from quick comes that it's better in networks with a lot of packet loss And this is true These would be as that a long-standing deficiency in this kind of situation To understand that we need to know that on htp2 You can actually send multiple resources at the same time, right? You can have both the javascript and the css file In flight at the same time because htp2 multiplexes its resources Now we know this htp2 knows this But tcp it is not tcp is so general purpose that it doesn't know about these different resources It doesn't know if you're sending one file or 10 million files It just treats everything as a single big byte stream that it has to deliver exactly in the way it is being sent This means if even one of these packets gets dropped tcp has no choice, but to block everything after that Everything else has to be delayed even though it arrives at the destination until we get a retransmit for that one lost packet I said before retransmit can take quite a long time So this is very inefficient from tcp. And this is what called what is called the head of line blocking problem This is the main innovation of quick One of the main reasons we needed quick one of the main reasons we needed htp3 as well Is because of this problem and quick solve this quite simply actually It just knows at the transport layer that you have independent resources going on with it It doesn't know about javascript and css of course It just knows these are two independent resources. And if you have packet loss on one of them You can just keep on processing the other one, right? So that should be better for performance in theory In practice for the web browsing use case, it's not always that simple Firstly because this graphic actually makes little sense It kind of makes it seem like the two resources are being sent in parallel But that's not really true. You still only have one connection. You can send only one packet at a time So it kind of looks more like this You have a red packet first and then a green and then another red packet But it just explains still holds because if there's packet loss on a red packet You can still process the green ones as they come in The problem is this is not the only way that you can send data for a web page You could also potentially do this Right send all of the red first and then send all of the green Turns out that the bottom one is actually much better for normal web pages Because things like javascript and css You need to download them in full before you can actually execute them on the web page, right? You can't start processing them as they come in So if you do the top one the top option for normal web page loading Both the files will only be downloaded completely at the very end When in the bottom you get the red one And almost half the time And that's starting out to be much better for web performance So you see we kind of have a dilemma We really want a top option to profit from quick But we need the bottom option for web performance and the bottom option if you have a packet loss on red, right? You won't get any of the performance gains because there is no green to be processed in the meantime This is a problem that we haven't actually found a good solution for yet This is part of a very active ongoing research It's actually one of my main research topics right now And it's discussed in the context of htp3 prioritization if you want to know more about that So I think by now it's time that I start summarizing what we've seen We've looked at a lot of the features from quick the promises that they made and also how they might not always hold in normal web browsing use cases And I'm kind of afraid because I think that by now some people might start to think this What maybe I don't have to switch to htp3. Maybe it's not worth it That is exactly the opposite of the reaction that I wanted to get right I have very consciously taken The devil's advocate viewpoint to point out some of the problems That doesn't mean these protocols are not still very interesting I don't think they're going to give you a 50 performance improvement But I do think that the five or maybe 10 percent that you can get Might just be worth it for a lot of users in a lot of use cases Right, I think users on bad networks. For example speakers coming to amsterdam on high speed trains Are going to be very happy that quick has removed head of line blocking The same for users that are far away from your servers can profit from the zero rgt connection setup Right So I really think quick and htp3 are going to be worth it More so because everything I've talked about today And a lot of things I haven't gotten to are actually part of what we're calling quick version one This is the version that is slated to come out sometime next year But we're already planning a version two shortly after that And all the fancy new complex features have been postponed to version two Including things like multi parts Which would enable you to use your wi-fi and 4g or 5g modem at the same time Basically potentially doubling your bandwidth that you have available That might actually make a very big dent in your performance The second thing is forward error correction It's an alternative to that retransmission problem The basic idea is that you start adding copies of packets onto other packets So that if you have one packet that is lost you can just reconstruct it From the packets that you have received Obviating the need for a lot of retransmission It's that kind of feature that really has the potential to have a major performance impact that is coming down the road That means if you start investing in quick and hp3 now or next year You're better equipped to deal with these interesting things as they come out Well, I hope I have switched some of you back to the enthusiastic side Now you might be thinking well robin I want to try this out. You haven't told us how How can I do this in let's say our favorite cms, right? The thing is again, this is not ready for prime time yet. It's still very experimental You do have things like for example, cloudfarer has brought out a Nginx patch that you can use in front of your php server To have actual quick and hp3 for your drewbell. I've said right now You could also use a caddy server or light speed server And if you want to learn more about the protocols themselves, I can recommend the io quick implementation It's in python. I know But it's a very very well written well maintained library that you can learn how these things work Sadly the browsers are lagging a little bit behind at this point But you can use chrome and edge in the latest development canary versions if you have the correct command line flags To enable quick and hp3 I think this is going to change a lot in the next six months and by the end of next year We should be ready to stop deploying these things in production or at least trying to But you might think well, that's interesting But I'm not really someone who dabbles with experimental stuff, right? This is too cutting edge for me What can I do in the meantime? Luckily, I have the perfect solution for you. That's quite simple You can start optimizing for htp2 instead I said before that htp2 and htp3 are actually very very similar protocols And that's true. That means that the optimizations you do for h2 Will be more or less fully transferable to htp3 when it arrives So if you're not doing h2 yet, you're not doing much with it You can start looking into this How to do this? Well I could do a full new talk on that and many other people have done that Please try to find some things on youtube, but this is kind of a summary of the things that you should be doing um All the protocols work best now if you have less connections The browser typically opens one connection for each domain on your webpage So you should try to scale that on the amount of different domains that you use At least for htp2, right? For htp1 you would still need to use sharding Similarly for htp1, they always say try to bundle your resources as much as possible create a single very large javascript file single very large css file For h2 and h3, this is no longer needed. You can get away with much smaller files that are better in the cache Now I talked to him about this and he has added a htp version attribute to Drupal cache or is going to So they can cache different versions Of your assets depending on the htp version that it's actually being requested But then you can use something like the advanced aggregation plugin to actually drive the kind of files that are being generated What you can also do right now is start playing with new congestive controllers The very aggressive one that I showed at the beginning is actually in the Linux kernel And you can very easily enable that for your web page as well But you should I will leave that to you What you can also enable is tls 1.3 and zero rtt This is not functional on all servers and all browsers yet, but you can definitely start using this in production You might try to enable tcp file stop as well Experiences may vary, but I do think again in the next one or two years This is become this is going to become very viable as well I've talked a little bit about prioritization Right and then how if you send your resources Bit by bit interleaved that this might actually be more slow for your website And there are a couple of people that have looked at how this is happening in practice And they found that Over I think about 40 different cloud providers and cds Not even half does this correctly Right, there are very many implementation bugs on hp3 and this as well So go and take a look at that list and if you're in one of the areas that don't have a green check mark next to them Maybe it's time to switch or ask your provider to maybe update their software Because it could really make a very big dent Cloudfire has been working with this and they saw improvements of indeed 50 percent on safari The final thing is I haven't really talked about server push But it's a htp2 feature that is still in htp3 as well So you can definitely start experimenting with that right now And there's one of you called gabriel solace Who has made a very interesting Drupal integration for that that allows you to use server push with your json api request as well I think this is one of the most interesting and formed use cases for server push So you definitely should check that out if you have Something like a single page app or at least the front end that does a lot of rest api calls That's about all I had to say if you want to learn more about hp2 I can recommend the book htp2 in action by barry pollard is by far The best hp2 book that you can get at this point It talks a lot about all these performance improvements in practice as well That's all I had for you today. I would say remember the contribution events on thursday Remember to give us some feedback both on this session and the conference And then all of all that is left for me to say is in case I don't see you Good afternoon. Good evening and good night Thank you