Leveling up Web Performance with HTTP/3

Hello, web. A digital frontier. I've tried to picture bundles of HTTP requests as they pass through the Internet. What do they look like? Fish? Other marine animals? I kept dreaming of some visualization I thought I would never see and then one day somebody made a tool called Firefox. Welcome to HTTP 3 Leveling up Web Performance with HTTP 3. Thank you for those who are joining me. Just after you joined me, we had a double bill. Excellent scheduling there from the team. I'm Lucas Pardue, in case you've forgotten. I'm an engineer at Cloudflare working on the protocols. So things related to TCP, TLS, WIC, HTTP 3, all that jazz. And today I'm joined by my special guest, Peter Wu, aka Lechenstein. You can correct me in a moment. But his appointed name is Peter and he's part of the research team here at Cloudflare. We do lots of cool stuff. If you've ever seen stuff like the crypto blog posts that we've had in the past. Clever things well beyond my mental capacity. But beyond that, in his other life, Peter also works on Wireshark, where he's a core developer working on the TLS and WIC features. So last week we had Robin Marks, a guest as well, talking about ways of analyzing protocols. And HTTP 2 and HTTP 3. So I wanted to give Peter an opportunity to come and talk about the OG tool for doing that, that many of us will be using. So enough from me. Let's go to Peter. See what you've got to say. Thanks for introducing me. Yeah, last week, Robin Marks did a great presentation on QFS and QLOG. That was really nice to see. QFS and QLOG are special tools built for analyzing WIC. So I guess it has some advantage on that front, given that that gate is specially built for WIC and optimized for that. Wireshark has been around for longer. It's a packet capture tool. It's quite easy to use. You install it, capture packets, and you can have a look at the stream of packets. That's the very quick overview of it. But in practice, people probably have no idea what they are doing. They install Wireshark on the web, and if they're like completely new to it, people probably say, like, ah, it's hard to use. So today I hope to show a bit how you can use this tool efficiently to, for example, look at the TLS or quick traffic. Awesome. Before we get into the deep stuff, you're a little bit quiet then. So if you could talk up a bit, that might just help. But yeah, like I use Wireshark here and there. But before we get into the technical stuff, I always wondered, you know, you and I, before I joined Cloudflare and before you joined us full time, you know, we interacted through the years. So, you know, mainly about quick stuff. How did you get into it? You know, being a core maintainer is quite a big thing, not just a patcher in there. Can you talk a bit about your background in that? Sure, definitely. So how I first got pulled into Wireshark, it actually started with the TLS dissection. So what I really like about Wireshark is that you basically have, if it's in the network, if it's communication, Wireshark will pick it up and will show it to you. And it understands a lot of protocols. So if you have DNS traffic, it will immediately show you, okay, this is DNS. If you have HTTP traffic, it will do that and also tell you there's a picture inside. When I started, I was just curious. I was interested in my VPN provider. They provided a web VNC console. So I figured like, well, VNC, Firefox probably doesn't understand that, but Wireshark probably does. So that's how I tried to start up Wireshark. Since it was using TLS, I had to try to decrypt it and try to understand it. That didn't exactly work out. I couldn't decrypt it for some reason. After digging for some error messages and so on, I figured there was a bug in the code. It needs a couple of fixes and then it would actually start decrypting. So that's how I got into Wireshark development in the first place and coincidentally, the TLS dissection as well. Apart from that, I made a patch and the community was very grateful, very nice. That's also where I got in touch with Alexis Lagut, another French Wireshark core developer. He was also very active on TLS and QUIC and so on. He's actually the guy who wrote the very first version of the QUIC dissection. If you look at the source code, you will actually find his name on top of the file. That's a good opportunity to give a shout out to Alexis as well, if you're watching or if anyone's not familiar. Alexis is someone else I've been interacting with over the years, trying to initially dissect Google QUIC. You hear about this protocol that's out there. What does it look like? How does it behave? What are the bytes on the wire? What do they break down to? A lot of the times, you'll have somebody's written a document to say these bytes mean these things, this is how they're laid out. But then actually find out the document is out of date with the code. I think some of my early interactions with the both of you, I remember being like, oh, this doesn't seem to reflect, like Wireshark isn't doing what the document says. And you'd say, well, now we can see the Google source code and the Google source code is the truth here. So it's quite funny. And I think that just reflects something like why having different ways of looking at the same stuff is quite important just to eliminate. Yeah, big thanks to Alexis and yourself. I know the community appreciate your efforts. As we iterate quite quickly, sometimes there's only weeks between versions where things change that break, not really break Wireshark. Maybe we can get into more about what that means in a sec without me getting, but, you know, and if someone can provide an example capture, you know, it's excellent work and it's very helpful to us. Yeah, exactly. So how I guess Alexis got started with Google Quick was as a network engineer, I had to back capture from their production network. I saw some like a UDP track which wasn't dissected by Wireshark. So that was a motivation for Alexis to actually look into it and try to build a dissector for it. And that's like quite some, like a couple of Wireshark code developers like that, they run into something unknown. I'm just very curious how does it exactly work? What is this traffic? Sometimes for like classic HP protocol, HP1 protocol, you can look at the like role TCP stream and it's all in text. So you can clearly see something like cats, something, something. It's a host header and so on. Yeah. And just by looking at the Wireshark traffic, you can see it's clearly HP. Unfortunately, as for encrypted protocols such as TLS and QUIC, it's all gibberish. So if you don't know with classic protocols, you could maybe look at TCP dump or you could take a hex editor and, well, if a hex editor worked for Wireshark, you could take that and have a look and guess it's HP, but that doesn't work for QUIC or TLS. And that's where further. I'll cover for Peter. So just in case anyone is tuning in and is like, I don't know what you're talking about, like what is taking a capture and things, you know, at the basic level, it's, it's a, you have a, say, piece of software that's talking on it. It is in charge of owning a connection in TCP, that'd be a real connection or UDP, it'd be sending datagrams to a socket that would go by the local network stack via the computer's software and ultimately onto the network card. And Wireshark somewhere hooks into that and is able to capture those things before they leave the machine. But also as they come back into the machine before your local software is able to maybe read them and get things wrong. So is that a good description or did I completely mess it up? I think the accurate description, yeah. I got just some feedback that my microphone is a bit crappy. Yeah. It's still pretty bad. I think, I think we might want to do the fallback here, just in case, before we get into juicy details. Okay. Especially if our audio levels are mixed. That's not, it's a kind of asking people to actively let's give you a test. Okay. Do you want me to switch it over? Yeah, let's go. Live TV people. No. Okay. Any better now? It's still pretty quiet. Okay. So I guess my phone's here. Yeah. If you could hold it even closer, I think. Okay. I guess. Yeah. Okay. Let's go over that hack. You're going to have to do a one handed demo now, Peter. Oh, okay. Where was I? Oh, okay. So, Wireshark and the patch process. Okay. Yeah. So as developers run into stuff they don't understand, they can like submit patches for that. And you also like experience, we had like quite a quite open community. If you run into something that you don't understand, you can submit a back capture and even better specifications so someone can have a look and validate it. With the quick development process, it's even better. Like everything is all in GitHub. So that also made it possible, especially for like new, the latest quick version. Quite like little changes in the draft because like you guys are trying to like stabilize the quick version and like release it. So that also means that sometimes we can even like release a new version of Wireshark with the quick support in like within a day or so. And this is it. Like, you know, they're nominally they're, I wouldn't say they're breaking changes. They're like backwards incompatible changes. And sometimes it just requires like a line of code and that's it. But then it's getting these things deployed, the harder thing. And even if the wire format stays the same or pretty similar, there can be other changes or people are taking a new version of the quick draft, say, okay, well, we'll basically deploy a new feature on or we need to update our infrastructure, be able to advertise these things. This is why the, you know, for instance, our deployment will track things quite closely, but sometimes there might be a delay just because of different impacts of changes that there can be and wanting to make sure that we're not just kind of rashly going, oh, it's the newest, let's deploy it. But actually we're taking measured approaches. The way that the draft, it's the pace that suits the draft. And ideally, that can match the implementers, but not always. Obviously, now that we're coming towards end of authorization, however long that might take. We're in the working group last call, which is a big milestone. There's a few minutes left on that, but ideally things are stable and that means that people start dedicating some resources into building out capability. Say, you know, there's some cases where you found like there's edge cases that can interrupt a section and that can make it look like nothing's happening, whereas actually you just didn't find them yet. More coverage, more testing. Exciting time. Yeah, exactly. Indeed, Quick is based on UDP. You can have no guarantee about ordering, whereas with GCP everything is a stream. So if an implementation didn't like it, they could just tear down the connection with Quick. You don't really have such a signal, at least for some errors. Implementation may signal it, but if implementation don't behave to the spec or if there's some other issue, they might not give such an explicit signal. And that's where things like application logs or a packet trace comes in, where that becomes very useful. Yeah, that's what I also like about Wireshark. It's all packet captures. It's basically a source of truth. It's all communication between two parties. So as long as you can hear what two parties are saying, you can pretty much follow what they had in mind. And there's some special encryption, then you need the key to understand that. I will get to that in a moment. What's the plan? Are you going to share something with us? Yeah, I was thinking about a couple of issues that were very visible in Wireshark. So as an example, there are many Quick implementations, as you may know. One of them was Quick Go, for example. These many implementations, they do interoperability tests, which help uncovering issues between the implementations. One of these bugs was that Quick Go, with certain ciphers, it wouldn't fail to do the connection. In the application logs, all you would see is something like an invalid packet or a decryption error or something like that. Using Wireshark, it was visible that, well, Wireshark also showed the same error. Well, there was some kind of decryption error, but by very carefully looking at the wire format, you could see that the sizes of the raw data didn't exactly match what was supposed to be sent. I should probably share a packet capture for easier understanding, because right now it's quite abstract. But that's a high level idea that there are a couple, some of these issues, they're only visible on the wire. They're not visible in the application, because the application implements what their idea is of the specification. Let me pull up the packet capture. Is the microphone disappearing now? Working? No? Oh, sorry. Sorry. I'm just, I was talking about my local end. You're absolutely fine. Okay. Okay. Let me share my screen. All right, you should be able to see something. Yeah. The terminal. Okay. It's a bit small. I don't know if you can Yeah, the text isn't important yet in this case, but yeah, I have run the latest version of Wireshark. It has the best support for the latest quick version, but nothing very interesting. I just started Wireshark. When you say latest, what do you mean? Is this like a binary download from Lightly's? Yeah, so I built it myself. I got the latest development version of Wireshark. I should point to a link where you can find additional versions. Just want to show you that, okay, when you start up, it just looks like this. So when you do packet capture involving TLS, HP2 over TLS, Quick, you have to start capturing the data before you actually open a connection to the server. The reason for that is In the very beginning of the connection, during the handshake, there's some essential information that's necessary for decryption, the TLS handshake, basically. So in this case, I'm going to capture data for blog.cloud.com. I specified filter because otherwise it will literally capture everything from my machine. It will be very noisy, especially given that I'm doing a video cast right now. Wireshark doesn't really like it when you do like megabytes, gigabytes of data. So that's one disadvantage compared to QFIS. It's not with things like QFIS-QLog, you can filter out your data, data frames, the very big data, while still keeping things like metadata such as headers. But with Wireshark, all of this information remains present in a packet capture. That's a weakness because your packet capture becomes very large. It makes it difficult to share, especially if it has confidential data. On the plus side, it literally contains everything and allows you to debug any potential issues if they exist. Just a clarification point here. One of the power features of Wireshark is all the filters and it's like different kinds, but right now this is a capture filter. So it will constrain what is actually captured by Wireshark. So although Wireshark or a packet capture could get everything and then you could filter that down to look at, this will focus on the TCP exchange with blog.cloud .com. Or would this capture the DNS as well? I've got this wrong in the past and sometimes it's bitten me. Very good point. So here I select an interface. So if you're on a VPN, for example, and your traffic to a site goes over the VPN, you have to select a different interface. For example, a U10 or a 1, for example. In this case, I'm not connected to a VPN. I'm just connected to Wi-Fi. So I have to select the Wi-Fi interface, which is currently selected by default. Usually Wireshark selects the right interface by default. This may be omitted, like I said, and it will capture everything. Or you can specify it, which means that when a packet comes in on the interface, this filter will determine, should I keep this packet for later analysis or not? In this case, a host something something means this name will actually be resolved to an IP address. And this filter will essentially mean every IP packet with the IP address belonging to this host name, be it IPv4 or IPv6, will be captured. So DNS packets will not be captured by this. That's interesting. Does Wireshark do its own name resolution then? Or does it use a system? Oh, yeah. So I'm going to write that down. So if you do a host flock to Cloudflare.com.x, there's no one who registered com.x. It will show up as red, a known host. I'm not sure if you can see it in the bottom, and I can probably not enlarge it. It's a bit small, but we can read it out for anyone. It just says, like a tooltip, a known host. So let's use a host that actually exists. So hosts, then I can press command E or capture and then start or just double click on this interface and then we'll start capturing. In this case, it looks a bit boring because literally nothing happens. Let me try to start up Firefox and actually go to flock to Cloudflare .com. So right now, there's a lot of traffic. Oh, actually, I should probably clear. That's another important thing to keep in mind. So right now I don't see a lot of traffic in here. You would probably expect a lot of data. The reason why you don't see the communication network right now is because the browser Firefox, it has some, I previously visited this website and has these resources already in cache. So if I want to actually see communication on the network, I have to delete the cache first. Then try again. Before doing so, let me show you the network tab. I can get that by command option, I think. Or you can go to tools, web developers, then a network. I closed again. So I just cleared my cache. I could use this option to have the same effect. If I refresh now. There's a lot of activity going on. If I look at Wireshark, this looks somewhat boring. Oh, it's encrypted. Right now, we're able to see the TCP messages coming back and forth. But as far as Wireshark is concerned, it's like calling up application. And it's just binary opaque stuff. You can't figure anything out. Whereas what you've got here is, you know, the TCP handshake by the look of it and then CLS 1.3 That's correct. So then go back one step of how you approach packet analysis. So what I do now. I actually have some plan in my head already. So I know exactly where to look for to To figure out whether it's a problem or not, or to demonstrate something. So, for example, I already put in a captive filter so I can limit the output so much more. I could apply additional like filters here. If I know I'm only interested in TLS traffic, I could put TLS there. If I want to look for DNS, I could do that, but it will show up as empty because I limited the capture If you, if you are just capturing acting or you don't know exactly what to look for. I'd usually suggest go to statistics and there's a protocol hierarchy view that shows for every layer. Like what kind of packets exist. Well, right now I captured Limit my capture to one host, so it will be pretty boring. But if you do it on a network without a filter, you'll probably see DNS OCSP maybe Email, what's not that will be visible in there. Yeah, if no one's ever taken a packet trace. I just encourage you to do it to see how much how chatty your computer is and the rest of the network with incoming and outcoming packets. It's pretty surprising and Yeah, if you're testing on lab networks where like in the past, a lot of my work has been and You don't kind of need those filters so much because there's nothing going on. But as soon as you're on an Internet or like a LAN with other machines. It's pretty noisy filter is your superpower. We're getting a bit of sun flashing on the side to distract you Yeah, no. Yeah, the weather. It was like JJ Abrahams doing his whole like tiny lights in the camera build suspense and mystery. Oh, it's the sun today, not raining in the Netherlands now. And another thing you could put into is enable name resolution. So right now I got a lot of IP addresses problem. No, but now that this kind of like a cloud flat peak for those who do not get enable name resolution. This could probably still not do a lot Okay, it results with my It resolved my local My computer name, the IP doesn't actually point to a Name. Let me Let me try to copy this IP address. Copy Copy the value So as you can see, it doesn't resolve. But if you pick one, one, one, for example, does have a name. And if you do one, one, one, one, and you see it resource back. So that's where the feature could become useful. All right, let me get back to the straight. So we know it's already to us. Let's have a look at what we can see. So this is someone what someone would see when they literally look at the wire. Let me double click it. So as you can see, there's a lot of gibberish. There's some text here. So if you want our cures. What it means you could click on it and then the whole tree point couldn't think of now, but The whole tree will basically expand and will highlight exactly what kind of field to this. It's also quite useful feature of wireshark Wireshark has a lot of protocol detectors, which allows you to narrow down this this sequence of bytes to particular field. I'm looking for the server name. It's perhaps it's encrypted. There's something unknown as well. Oh, encrypt the server name that explains it. So yeah, I was looking for the server name extension. The last extension, but it turns out that this connection uses is now which encrypts the server name. So it's also not visible on the wire. Yes. Now it's still a new thing that's developed that still developed by the idea of working group cloud class and implementation of it. And Firefox has an implementation of it. And that's why it's visible here. But basically, what I want to show you is there's a lot of data here. And basically, you can't make any sense of it unless you see something that I don't look us There's not much in there. So HP 1.1 What does that mean This HP 1.1, that's the ALPN field. Where was it There, I can click on it and it's highlight that right there. That's an application layer protocol negotiation abbreviated to ALPN. It's basically, it's used to inform The other side, the server or the client what project what protocol version will be used in the encrypted layer. So when people say the weapons encrypted. What they mean is there's still us which secured connection and there's an application layer inside it and that application layer inside the protocol used in there is Can be controlled using this field. So for classic HP one this extension didn't exist and the pair basically had to guess based on the port number that is need HP one or that something's indeed SMTP, for example, and it goes over port. 587 Doesn't matter, but For HP to since it's all in binary. They basically needed a mechanism to make clear that the application. Layer inside is not HP one but HP two. So that's why you see two options right there. It'd be two and it'd be one Yep. And like it's basically the problem of D multiplexing right so what they had And although the focus of this talk is on H three. It's important to understand like upgrade protocol versions like this. You make completely breaking changes or do you try and maintain as much as possible. So, so there was big in H two was The desire to avoid having to define a new team. So you wouldn't want to have to type like HP to colon slash slash thing you kind of wanted everything to seamlessly migrate, if it could, and if it didn't seamlessly fall back. And so LPN And it comes out from some other stuff called X protocol negotiation. There's an ability to reuse the port that we know and love for for three Negotiate stuff without having to build application negotiation at the application layer, which might not work so well because You'd have to update the applications. And if you could do that, then why do you need to negotiate them. It's kind of a circular argument. But what you don't see those HP three. And that's because in this case, it's this negotiation is happening on TLS for for for three and there's not really a way to like negotiate The application protocol of a completely different TLS handshake and even if someone tried one. I think that disaster. So that's, that's kind of why we need to hold there is stuff. But that's got nothing to do with this. Sorry, Peter. Well, it was very rapidly. Did you point out HP three cannot be used in there. Yeah, true. It's in white. You can clearly see the layering. This is TCP stream oriented protocol where HP three is over over you'd be so don't totally make sense in this context. So right now, you will probably be disappointed. I don't see HP three at all in this trace and what's going on. Like that this all encrypted to us. So we need a way to decrypt this and only when everything is done correctly when the server and client configured correctly, they will use a secure protocol such as George 1.3 And that means that only the server and the client should have the decryption keys to actually see what's inside this capture So in order to do that, I have to restart Firefox with a special option to them to secrets. Close that And let me close Firefox as well. I'd like to completely quit it. I cannot just close it. I have to completely close it in order to Do. Well, terminate the process. Otherwise, it would interfere. Otherwise, if I open a new Firefox instance will just open. Well, the open the old window in all process and for the option that I'm going to use. It's called SL kilo Paul Don't mind the SL his name. I know Jonathan and my colleague will like a shout at the name of this other thing. But this option will will instruct Firefox to dump secret to this file keys.txt Let me remove. Well, we can have a look at what I captured before because I did it before you will see a lot of like gibberish. SL kilo for this comment NSS is the library used by Firefox for us and NSS actually was the very first one to implement this extension where it could dump the secrets in order to encrypt enable decryption. This format is probably boring. But yeah, the very first field tells you what kind of line. Do I have the next one is an identifier to link The following secrets to a session. This is where you want to know this declined random. So if you want to verify whether whether a secret is present in this file. And whether matches to your session, you can look this up and try to match it with the client random in here. Let me try to open up We Client random this one. So it's called find random goes well. It's in the client. Hello. So also has to random, but it's not used for this book was of matching. So let me try to. Oh, oops. Let me try to open up Firefox. Now, so I checked. I don't have Firefox open I set this file. Let me remove the old one to demonstrate that's actually being created. Let me open up Firefox. And reminded me of an anecdote. I'll show at the end. Okay, so the file has been created Firefox open the talk to cloud. Let's come thing again and Right now it's already decrypting, but it's not entirely fair that the decrypting because I didn't show you how I can figure why shock to do decryption to do so right click on to ask layer protocol preferences and then go to the very last option. The secret log file name. And in there. Here you can like configure the path which you put in this SL key log faulting. Can't believe you just showed me that I've never done it that way. I've always had to do a really horrible way, which is like about three steps longer. Yeah, go down to TLS and then it's the same window, but you always have to Yeah, there are multiple ways to do things. This is probably useful as you haven't gotten a capture yet like this because this just lay open will only show up if you actually have to ask you trace so configuring via preferences also actually something I do if I can't if I don't have my trace configured yet. Yeah. Now you can actually see Oh, I added. So by default, the wire shock doesn't by default why shocks will probably look like this. There's a like a packet number. Like the time when it was captured since the start of the packet capture and a source and destination IP and protocol and so on. Usually what I also add is I go to TCP right click on stream index and then select apply as column. The reason I do that is because that way you can very easily identify which TCP or to us session, you're looking at. So as you can see, it's an increasing number. The previous session could not be decrypted because I didn't have the keys for those sessions and this session. I can actually decrypt. So what I can also do now is follow TCP stream. Like This is basically garbage. Well, it's not entirely garbage. This is this makes sense to the application that don't make entire sent to humans and encrypted. You can also like see the HP thing in there. It's the raw data of the TCP stream. So right now, the filter like the packet display is already limited to just this stream and usually what I do is either DP that length is larger than zero. I hope you can somewhat see it. By the way, I press Command Shift R to automatically resize the columns. Because when I zoomed in. The like things started getting hidden. So yeah, that's also an Excel spreadsheet. Yeah. So usually another thing I forgot to mention. Which shows a different way, which was a different than QFIS and Wireshark. QFIS is very like specific to the application Quake or HP3 or TLS or HP2 for example. Wireshark shows you all like layers shows you like the physical the link layer and IP, the network layer and so on. So while Wireshark does its best to like literally try to interpret as much as possible. The advantage of that is, well, if there's some information there, it will probably tell you about it. The downside of it is it makes a bit harder to focus on it. And that's where the display filter comes in useful. So in this case, for example, you're probably not interested in the empty packets, the like SYN packet for TCP connection setup is empty. So usually I select TCP packets, which are non-empty. Alternatively, I could say like, okay, I know it's TCP. Sorry, it's TLS. I can just use and TLS. TCP to stream equals 11 and TLS because this was my stream index, which I added before. Yeah. So now if you look at it. Okay, this is my client. Hello. It's the client. Hello. In TLS is still unencrypted. That's some, maybe, maybe it has some fields which are encrypted, but in general, the whole data is pretty much like visible on the wire. Similarly for the server hello. This was TLS 1.3 because the client hello has a supported first sender supported version field and server actually agreed to use this version. That's how Wireshark determined it's actually TLS 1.3. And in all the versions, this field would be used to negotiate the version, for example, 1 .1, 1.2. And this goes to really a point that if you if you start the trace too late, miss out on information like that. So to Wireshark is like tries its best. It has some heuristics, but some of this is stateful and if you miss the start. It's just possible. Unfortunately, Exactly. It's not a critique of the tool. It's just, I think it's That's just a fact of life. It's a useful limitation to be aware of it. Let me demonstrate example right now I have to find. Hello. And as you can see, this is all decrypted. If I ignore this, then you can see, oh, cannot make any sense of it anymore. Or I have to find it again. Look, I can do with the frame that ignored filter and now it's back. Okay. Very light debugging here. Yes. Well done. Okay, now somebody still missing for some reason. Did I correctly. Oh, Sure, it can Frame ignored because one Oh, Brad, that has something to do with me doing a live capture. So I re enabled the option, the packet. But for some reason, oh, it's back. So, Yes. So keep in mind that when you do a live capture, there may be some limitations versus when you take a capture file and save it for later use when it's doing live capture by shark will try to interpret as soon as things come up. But that also means it cannot do certain computations calculations. Because the data wasn't available yet in the first place. Yeah, that's one detail to be aware. So let me just conscious of time because I keep interrupting you and asking you stupid. Oh, yeah. So we're looking at h2 at the moment. Are we, are we able to do the same for HP three or four quick what's Yes, we are able to So essentially, the idea is the same. Okay, we have this handshake. And now we have this decrypt your step in there and to us. Normally you see this application layer data if you haven't configured the key. Is Making fun of my camera. In the Netherlands right now. Like expected Okay. Okay. So yeah, normally if you don't configure keys, you would see like application data. And now you can see there's actually some some decrypted data in there. In this case, it's HP to and what you would see is a couple of streams with a header frame. This is another like It's a feature that why shock shows a lot of like information, things like these will probably not make sense to most people, but for implementers who are doing like the latest 5g Protocol implementations or those who develop and like a web browser. So on this information can be very useful to see exactly what's on the very low wire contrasted to tools like Firefox. The web developer tools and Firefox or other process. Yeah, here you will see only like the application layer information HP three and sorry at HP headers and so on, which you also see here. But in addition to that, you see a lot of additional metadata. So this is the Dev tools are great. I just, I find that a bit oriented to web developers and sometimes in, you know, if we think of request and response is our lingua franca. And they try and shoehorn in like each two or three specific things into that model and it just doesn't quite fit you know here you've got things I can see like priority frames and Settings and window updates, which is like h2 level flow control. I mean, I was looking at just the other day in wire shock and other tooling. You don't, you don't get that necessarily in Sometimes as additional dialogues like I think I was showing chrome's net blog. The other day, but it's hard. Like it's it's fiddly to use and it doesn't. It's not as powerful as wire shock in my opinion. Yeah, the problem of tools like web developers and chrome five and so on is that's very specific to the application. So if you have A go go program or by the script which communicates with some API and you, you may not have as a like developer or user of that API, you may not have access to Like tooling on the server. So all information you need to get have to be available on the client and you buy the script, you probably don't have something as fancy as web developer tools. Or you could open up the URL that the your script is trying to open in the browser. It may have a result in Their behavioral differences, such as maybe there's some cookie missing. There's some header missing, but it could be some other side effects, even something as stupid as to use a header may have a side effect that you never realize Okay, so yeah, and this is just a to just to want to show you that. Okay. It's a bar chart shows you the very like low details of HP to Unfortunately, the like this level of detail for HP three and workshop is still very much in development. It hasn't been implemented yet. So I can show you how how quick currently looks like in the workshop. The goal is, is, is to show something like this late for HP three as well. But right now it will be somewhat more limited And don't be too unfair on yourselves like trying to show in my first session that actually the things like you've got here. Right. You've highlighted the window update frame. And in HP three, there isn't one because it's handled by the quick layer. So, so a lot of the frames are kind of pulled down into the transport and H3 is pretty thin on the ground. So yeah, get credit to yourselves of actually getting quick dissections and not just one version, but you support concurrently Google quick and the idea. Right. Yeah, Google quick is what is mostly driven by Alexi and like that, like, oh, he runs into something that shows up as unknown, then what tries to make someone more useful that make why should tell something more than unknown. Let me show you how HP three would look like So briefly talked about how, how does HP three get enabled. So, oh, this is if I refresh this you'll probably see it just HP two and Firefox. If you want to enable HP three, you have to go to about config. And search for HP three and this option network will be enabled. Now set to true So due to caching. I can disable cash this way and hopefully it works. By refresh my page. Now, maybe it shows up as a P three It doesn't. That could happen due to existing open connections. About Networking Oh, I don't have any connection over now. So let me try again. And so that's the thing with a P three. You need an existing channel to tell that the service actually support a P three So the very first request will most likely fail to tell you that a P three. Maybe if I go down the line. Maybe it's another request of it P three, not yet. So anyway, so right now, five. I should know that cloud blog.com support a P three. If I refresh it. Hopefully it then gets a resource of HP three. And Great. Let me clear the cache and hopefully it works again. And let me toggle Work offline such that every connection is terminated and definitely know there's no existing HP two connection. And then open up again. There may be a book somewhere. And it's worth reiterating at this stage that that this is a live demo, which always in folks that But, but that you know the protocols in development and that you know that there's experimental. This is why features like this behind like this is a nightly version of Firefox, which means it's getting update every night pulling in the Patches Friends over at Mozilla working on and sometimes it can be bugs. So that actually testing these things out helps catch them, you know, we, we would interact maybe and say, well, like we knew the blog page work yesterday didn't get a packet trace. This thing looks wrong. So actually, we're able to use these, not just for our own kind of why is my website not working, but to help debug each other. Okay, so that's interesting. So for some reason, this doesn't load but why I was able to capture the traffic. And as you can see, there was no information in the web developers. That's a prime example of why you would something you something like why shock the application doesn't show you the information and briefly. The web developer tools, for example, didn't implement web socket support and it showed you it's web socket, but didn't show you the contents of it. And that case, you can also use my shock. So here we have a very nice trace of quick Quick So what can you see here. Well, the stream TCP stream index don't exist because it's over UDP Wireshark instead maintains a special field called connection number. There's also a stream numbers in the UDP layer, similar to TCP but quick actually complicates things because quick support connection migration, meaning when you transition from your Wi Fi network to your mobile network, it will Continue it can continue to work without breaking your connection. That's called connection migration. So that's why there's a separate field here to track exactly that connection as it moves between networks. Wireshark here shows you. Okay, there's an initial packet here. In there, we should have a to ask client. Hello. So Wireshark. Sorry, not Wireshark to us. Sorry, not to us quick still uses to us. For its record for its encryption in there, you will see a LPN here. And Firefox says I support HP three draft 27 And so acknowledges After this like initial handshake. Is this all still the very same connection. Let me try to apply. It's all the very same connection. Oh, here you can also see like the draft version of those like Q log Q face will probably tell you it's the same information, but it shows you Whatever is visible in the wire, you can capture with Wireshark. You don't need specialized tools for it in order to Get now packet data. Actually, you need something like this Peter or some other tool that can get the data, but you don't have to modify the applications just quite a useful feature. Yeah, I mean, People like me who spend too much time on this stuff would be able to look at that version that you just had highlighted FF 001 B. Oh yeah, I know that's quick draft version 27 but that's the version of the quick transport layer. But, you know, if you're seeing those kind of screaming past your eyes like Yes, some people can read the matrix without without any help and assistance, but having something like this that actually turns that into textual helps you focus on the weirdness that kind of reduces that cognitive burden, at least for me anyway. So we're able to try and, you know, if you spend the next 15 minutes to say, well, why didn't this handshake work. But what was Firefox had a hiccup. Maybe there was some loss in the network that interrupted the flow. I don't know, like I'm speculating that With with some more time, we could probably figure this one out and probably need to feed this back anything that's But That's why if you're running the capture. What's great now is you could stop this say and send it over to me. Right. Yeah, I'd be able to take a look as well. And we can crowdsource the problem. Yeah, I'll save it later. For now, I probably start stopping capture right now. Oh. No, I didn't mean to maximize it. I mean, I'll be honest, it's usually me. He's crowdsourcing my problems back to people. It's a So why I guess an experimental feature called quick stream, which a lot of limitations, but it shows you what's inside. And this is probably all HP three stuff and why shotguns fortunately don't exactly does interpret It be tree. So currently your limb to this output. You can change it to hex temp if you want. If you know how to read a tree. Yeah. But what this feature does it's it takes all like package with a stream inside and it shows you the data inside. Usually it works, except when you have streams coalesced with Except if you have like multiple streams in a single quick packet, which is also possible for copy right now stream zero is the control stream, I believe, is this useful. It's a request. This is a single request. So five bucks for the same one and then Yeah, it's got a response. So in one of the views, you just had was some text saying grease is the word, which is a feature that pipe that use for greasing that to just for some weirdness in exercising extension point with some randomness. That to help maintain extensive, but that's a topic for another day. But yeah. Oh, a couple more minutes. So is there anything I delayed you in Talking about. Yes. So right now I'm just like scrolling. I was like trying to locate the QPAC stream. But yeah, why shock. There's a there's an experimental branch for a P3 support, but it hasn't like been completed yet. So right now, unfortunately, it will not tell you a lot of detail. Maybe I could like loaded up in a QPS and then it will try to dissect the details, but at the moment. All it tells you is information about the quick transport layer. So it's important to notice, you know, that HP three. It's an application layer. Protocol on top of a quick the transport layer. So what you basically see now is as useful as showing the TCP layer in all the protocols, except that quick is somewhat more complex. So you need specialized tools to understand that you cannot just look at a raw hex dumps. Yeah. Oh, so I think, you know, like we talked about before, basic for applications using quick they They use streams. That's the way that they communicate their important data. They use the other stuff like national oriented or flow control and stuff. But when it comes to exchanging the applications data. On stream. So even if you can't dissect exactly what's happening there you can you can look and you can see here that this thing. You could look for the offset being zero, for instance, and then you'd be able to trace the start of the stream. And kind of take it from there. Maybe you need to grab the hex the decoded hex out of Wireshark in this case and manually decode stuff, but maybe not. But I've got, I've got one question. Sure. Basically, so you know this this This segment is nominally called leveling up web performance. It's very click baity. You know, I think, yes, will will. It's very important. We talked about things like head of line blocking and how it can help But ultimately, you know, we're not talking about web performance right now as we demonstrated the most important thing is Being able to make a connection first place. And while this is still a bit, you know, while we're trying to finish stuff. Feels like this can help you there. But in any cases, oh, sorry. Before we get cut off. I just want to thank you everyone who tuned in today for your time, but like 10 seconds transfer in the next week as well. We'll be back on with another guest.