Great explanation! A way more convenient way of learning this without reading 3 RFCs, distilling the highlights, capturing packets, dissecting them myself and correlating them back to the RFCs. As a lazy engineer, I really appreciate this video!
Very nyc videos. Easy, clean & understandable language used. Thanks to Greer for posting videos on ever complex protocol. By watching these videos, now tcp seems easy & help to tshoot the issue in better way. Thanks Chris. Cheers 🤟
Thanks for the easy to understand delivery. I'm studying at Deakin University in Australia and your videos are much better than the rubbish that they deliver.
Regarding the QUIC connection number and it's ability to change with changing devices/environments how does that interfere with our ability to trace packetry across a QUIC (session?) With more than one connection? Is it possible to do that without tracing somewhere at the upstream of each connections Internet provider?
Hey, in the first video you had mentioned that in 2 rounds of network cycle, QUIC can establish a connection. First is TLS handshake and then it can directly communicate using HTTP3 , but here in Wireshark, it doesn't seem to match what you have said earlier. Like I could see INITIAL packets before HANDSHAKE, can you please explain this part?
Thank you for the great content Chris! I'm thinking google can track us with the destination connection id correct? advertising companies can pay google for this information, or am I being to paranoid here?
What kind of security implications are there for the connection ID working with different 4 touples? Is there more authentication done at a higher layer to make that session secure? Could it be possible to randomly select destination connection IDs and get an existing session?
Hey, that is a great question. RFC 9000 covers it in the gory detail, but to keep it short, there are a few ways. Let's just say that the QUIC masters definitely considered that when creating the protocol. 8.1 of the RFC mentions a token that is constructed on a connection basis. This secure token is validated by the server upon connection resumption. Another method that I have read about (I haven't seen it in practice yet) is the ability for QUIC to use more than one connection ID. So the two endpoints can securely exchange connection ID info for rebind if the connection migrates. Check out the RFC here for more info - datatracker.ietf.org/doc/html/rfc9000#section-8
I have seen it in CDNs and in supporting mobile apps like UBER. It will probably grow from there. Hard to say at this point to what extent it will be brought in house.
Thanks for the video! It seems like TLS is mandatory for QUIC. Without TLS, there would be no connection management or flow control. I assume then, that a QUIC server won't accept unencrypted HTTP, meaning there wouldn't be a HTTP 301 redirect from HTTP to HTTPS? If so, RTTs are saved.
Thanks Chris, your videos are always interesting. I follow your posts not just about quic but others as well. One thing came into my mind. Maybe it would be nice to explain how client side gets to know to use quic protocol instead of tcp. If I know it well the initial packets then handshake communicate on tcp/443 when reach website that supports quic.
Hey and thanks for the comment. I do mention this in my How QUIC Works - Intro to QUIC video. The client at this point typically will reach out over TCP, which the server (if it supports QUIC) can suggest an alt-svc of QUIC. The client can then initiate communications over QUIC. Thanks!
Again thanjs for your videos and effort.I don't know might explain it better.I have a question too,that might sound stupid specially from person who thinks knows networking.I actually thought I know networking until I opened wireshark and seen many things on there that I have no idea.Thanks for you I got most them but there is a thing that still don't get.When we look through statistics in wireshark,then protocol hyerarchy we see tcp and udp.Then we see as example http,https under TCP.That makes sense because they are TCP protocols.But since QUIC taking place of TCP I see most of my capturing as QUIC on protocol columun.So when there is TCP I see http or https or anything else.I see TCP on handshake.But with QUIC I don't see http or https in protocol column.I know QUIC build kver UDP but somehow we interact with http and https.Why I don't see them?Where they are?
At 03:25 when discussing those Quic parameters like initial_max_data and max_udp_payload_size... Are those values in bytes? Or what value are they measured in? Edit: also is the max UDP payload size the same as the max QUIC frame size? Any correlation there?
Great video Chris. Loved it. My query is how did you decrypted the TLS 1.3 packets to see the http3 application data? I downloaded the wireshark capture but it's encrypted.
There are well documented websites and videos that mention how to capture encrypted HTTP data. Chris does a video with David Bombal on this very topic.
Chris, thanks a lot for another great video... lots of great stuff uploaded in this channel. May i ask you something? On 7:40 you refer to unidirectional and bidirectional streams. How come unidirectional and bidirectional streams of frame 6, are both 131072 bytes ? Shouldn't bidirectional stream be double the size of the unidirectional ?
That's a great question! From what I have seen so far, bi-directional streams are not always a doubled value. I think it is because there are so many unidirectional streams for many applications. In most cases, you don't use a stream-based transfer bidirectionally. It will definitely be interesting to study that aspect of QUIC as the protocol develops. Thanks for the comment!
I've been using Wireshark for many years and find the QUIC is very fascinating. I've often wondered why UDP has not been used before. You mentioned in this video "stream" and I'm wondering in part has this been developed to enhance streaming of video for the broadcast industry that is now coming on strongly. Seems interesting that Google has developed it and they have become a big player in the whole streaming industry. Love the explanations of Wireshark. Takes some of the jumble out of the mass of data coming across a connection.
Hey Robert, thanks for the comment. Yeah it is quite possible that the two are connected like you mentioned. Either way, I agree that it was time to bring the smarts of TCP up half a layer and run it over UDP so it wouldn't be so picky about each byte. See you around the channel!
I once had a national database with a load balancer feeding sql servers and a home grown software application accessed by doctors, hospitals and law enforcement. Understanding where the slowness was coming from was monumental. Wireshark was the only application that I could use to see what was going on. The network guy in the middle (me) had to tell the programmers/medical people or law enforcement it was their issue not the network (With a smile on my face most of the time)...
I don't get the hype... after delving for days into quic it all comes to reducing round-trips by increasing packet size, everything else has its negative counterpart. Solving congestion by eating your bandwidth/throughput.
Thanks for the comment. So QUIC is not at all about increasing packet size. And I will have to hard-disagree that all other aspects of quic have negative counterparts. The way quic addresses head of line blocking via streams at the transport layer has tremendous upsides, as well as future improvements in performance for applications. They won’t have to introduce streaming into the application the way H2 did. This is just one benefit of quic. I could go on.
Great explanation! A way more convenient way of learning this without reading 3 RFCs, distilling the highlights, capturing packets, dissecting them myself and correlating them back to the RFCs. As a lazy engineer, I really appreciate this video!
Thanks for the comment, glad it helped!
Soo true
Very nyc videos. Easy, clean & understandable language used. Thanks to Greer for posting videos on ever complex protocol. By watching these videos, now tcp seems easy & help to tshoot the issue in better way.
Thanks Chris.
Cheers 🤟
It's my pleasure!
Thanks for the easy to understand delivery. I'm studying at Deakin University in Australia and your videos are much better than the rubbish that they deliver.
Wow, thank you!
Regarding the QUIC connection number and it's ability to change with changing devices/environments how does that interfere with our ability to trace packetry across a QUIC (session?) With more than one connection? Is it possible to do that without tracing somewhere at the upstream of each connections Internet provider?
Hey, in the first video you had mentioned that in 2 rounds of network cycle, QUIC can establish a connection. First is TLS handshake and then it can directly communicate using HTTP3 , but here in Wireshark, it doesn't seem to match what you have said earlier. Like I could see INITIAL packets before HANDSHAKE, can you please explain this part?
thanks Sir ...you explain so easy and clear.......have question can we get wpa2 password if we get handshake.cap of wifi using wireshark ???
Thank you for the great content Chris! I'm thinking google can track us with the destination connection id correct? advertising companies can pay google for this information, or am I being to paranoid here?
What kind of security implications are there for the connection ID working with different 4 touples? Is there more authentication done at a higher layer to make that session secure? Could it be possible to randomly select destination connection IDs and get an existing session?
Hey, that is a great question. RFC 9000 covers it in the gory detail, but to keep it short, there are a few ways. Let's just say that the QUIC masters definitely considered that when creating the protocol. 8.1 of the RFC mentions a token that is constructed on a connection basis. This secure token is validated by the server upon connection resumption. Another method that I have read about (I haven't seen it in practice yet) is the ability for QUIC to use more than one connection ID. So the two endpoints can securely exchange connection ID info for rebind if the connection migrates.
Check out the RFC here for more info - datatracker.ietf.org/doc/html/rfc9000#section-8
Thanks Chris. What I heard is only the CDNs implemented this at this point and not any enterprises.
I have seen it in CDNs and in supporting mobile apps like UBER. It will probably grow from there. Hard to say at this point to what extent it will be brought in house.
Thanks for the video! It seems like TLS is mandatory for QUIC. Without TLS, there would be no connection management or flow control. I assume then, that a QUIC server won't accept unencrypted HTTP, meaning there wouldn't be a HTTP 301 redirect from HTTP to HTTPS? If so, RTTs are saved.
Hey Yasser - you guessed it. TLS is built-in to QUIC. I don't know if there is any plan to do an unencrypted version.
Great video!
Thanks Chris, your videos are always interesting. I follow your posts not just about quic but others as well. One thing came into my mind. Maybe it would be nice to explain how client side gets to know to use quic protocol instead of tcp. If I know it well the initial packets then handshake
communicate on tcp/443 when reach website that supports quic.
Hey and thanks for the comment. I do mention this in my How QUIC Works - Intro to QUIC video. The client at this point typically will reach out over TCP, which the server (if it supports QUIC) can suggest an alt-svc of QUIC. The client can then initiate communications over QUIC. Thanks!
Again thanjs for your videos and effort.I don't know might explain it better.I have a question too,that might sound stupid specially from person who thinks knows networking.I actually thought I know networking until I opened wireshark and seen many things on there that I have no idea.Thanks for you I got most them but there is a thing that still don't get.When we look through statistics in wireshark,then protocol hyerarchy we see tcp and udp.Then we see as example http,https under TCP.That makes sense because they are TCP protocols.But since QUIC taking place of TCP I see most of my capturing as QUIC on protocol columun.So when there is TCP I see http or https or anything else.I see TCP on handshake.But with QUIC I don't see http or https in protocol column.I know QUIC build kver UDP but somehow we interact with http and https.Why I don't see them?Where they are?
At 03:25 when discussing those Quic parameters like initial_max_data and max_udp_payload_size... Are those values in bytes? Or what value are they measured in?
Edit: also is the max UDP payload size the same as the max QUIC frame size? Any correlation there?
does the client side can embed the ip address of the destination server under encryption, if so mean, it can by pass most dns firewalls?
Interesting. Thanks, Chris.
You bet
Great video Chris. Loved it. My query is how did you decrypted the TLS 1.3 packets to see the http3 application data? I downloaded the wireshark capture but it's encrypted.
There are well documented websites and videos that mention how to capture encrypted HTTP data. Chris does a video with David Bombal on this very topic.
Chris, thanks a lot for another great video... lots of great stuff uploaded in this channel.
May i ask you something? On 7:40 you refer to unidirectional and bidirectional streams. How come unidirectional and bidirectional streams of frame 6, are both 131072 bytes ? Shouldn't bidirectional stream be double the size of the unidirectional ?
That's a great question! From what I have seen so far, bi-directional streams are not always a doubled value. I think it is because there are so many unidirectional streams for many applications. In most cases, you don't use a stream-based transfer bidirectionally. It will definitely be interesting to study that aspect of QUIC as the protocol develops. Thanks for the comment!
I heard of quic, using adguard.
I've been using Wireshark for many years and find the QUIC is very fascinating. I've often wondered why UDP has not been used before. You mentioned in this video "stream" and I'm wondering in part has this been developed to enhance streaming of video for the broadcast industry that is now coming on strongly. Seems interesting that Google has developed it and they have become a big player in the whole streaming industry. Love the explanations of Wireshark. Takes some of the jumble out of the mass of data coming across a connection.
Hey Robert, thanks for the comment. Yeah it is quite possible that the two are connected like you mentioned. Either way, I agree that it was time to bring the smarts of TCP up half a layer and run it over UDP so it wouldn't be so picky about each byte. See you around the channel!
I once had a national database with a load balancer feeding sql servers and a home grown software application accessed by doctors, hospitals and law enforcement. Understanding where the slowness was coming from was monumental. Wireshark was the only application that I could use to see what was going on. The network guy in the middle (me) had to tell the programmers/medical people or law enforcement it was their issue not the network (With a smile on my face most of the time)...
Thanks for sharing....
Thanks for watching!
So QUIC basically is reliable UDP?
You could put it that way, yes. It’s all the stuff that makes TCP reliable and efficient, with TLS tied in, but on top of UDP.
Hopefully QUIC is not mucking around with DNS or is it?
Nope, not yet anyway. DNS is still a separate service over UDP (Or HTTPS if you are using DoH)
Dns, crypt is fast
I like you Chris
Chris pls reply
Hey!
I don't get the hype... after delving for days into quic it all comes to reducing round-trips by increasing packet size, everything else has its negative counterpart. Solving congestion by eating your bandwidth/throughput.
Thanks for the comment. So QUIC is not at all about increasing packet size.
And I will have to hard-disagree that all other aspects of quic have negative counterparts. The way quic addresses head of line blocking via streams at the transport layer has tremendous upsides, as well as future improvements in performance for applications. They won’t have to introduce streaming into the application the way H2 did.
This is just one benefit of quic. I could go on.
Do you really think this QUIC thing is going to fly ?
You probably watched this video over quic....