QUIC is here! The RFC just dropped. Let's learn about this new protocol that stands ready to take on some of the TCP workload over the web. Check out my new Protocol Deep Dive: QUIC course on Pluralsight. You can watch it for free with a 10 day trial: www.bit.ly/wiresharkquic Please smash the like button to let me know if you dig this content!
You are a natural teacher, friend. Just starting to go deeper into IT, networking, cyber sec, etc. And even though I have limited knowledge, I felt like I could follow everything you were covering. Instantly Subbed. Thank you!
Hi Joe! Yes sir I have. It's tough though because I already have content on Pluralsight so I've chosen to go that route for now. Thank you for the comment though - I appreciate the idea.
Chris, I love the way you explain things. So easy to follow. I'm hoping to do some of your courses once I'm done with my current studies next month. Cheers Wayne
Chris, good presentation. I noticed one error made. Perhaps it was a slip of the tongue. If QUIC runs on top of UDP it cannot be as stated another or new transport protocol. Both TCP and UDP are OSI transport layer protocols. This would make QUIC an OSI sessions layer protocol.
Check out RFC 9000 - datatracker.ietf.org/doc/html/rfc9000. The first sentence is “This document defines the core of the QUIC transport protocol.” QUIC covers aspects of the transport layer, so it is a transport protocol. I can totally understand the confusion though - until now we have largely only had TCP/UDP at that layer. Think of QUIC as layer 4.5. 😁 trust me it helps!
@@ChrisGreer curious. After posting that also occurred to me as well. Perhaps QUIC falls somewhere in as a layer 4.5 protocol. Or maybe the reference is to the TCP/IP layer stack rather than the OSI layer stack I'm referencing. Anyways, thanks for link; I will dive through it.
hiii chris, i have a issue, in my chrome, quic allowed policy is set to false and i am not having avast or avg antivirus installed, i have windows security, due to this chrome is showing your browser is managed by organization which is annoying, i want to know about quicallowed policy being set to false is good for me or not. i mean its ok or not.
Thanks, great Video. But i have one question: When I lock in a Wireshark capture. Before Quick is established, a normal TCP handshake is done first. Only then QUICK is used. The advantage of QUICK is lost, isn't it?
Not all advantages are lost. Just the initial QUIC connection time. But all other QUIC features (streams, built-in TLS, no head of line blocking) are still there, even if the browser first knocks on the server door using TCP. Since QUIC is so new, it's common to see non-chrome browsers do that first.
@@ChrisGreer Thanks for the answer. I have another question: As I understand it, firewalls can no longer do any content filtering due to the encryption of QUIC. Is this true or is there a way to look into a QUIC traffic?
hi Chris, i am capturing youtube traffic, there is mixing protocol of QUIC and GQUIC inside the captured file. What is the relation between QUIC and GQUIC ? and how to correlate QUIC and GQUIC in that youtube file ?
Hi Chris, I have one video request for you. Can you make a video on MPTCP. Although many videos are available but the way you explain makes me understand things better. Looking forward for MPTCP video soon!!
What about ddos attack? UDP is favorite one for hackers to attack network; a simple port scan, see what udp port are open, and done, deliver a big ddos attack; how handle this with QUIC?
Hey, got a question, protocols like UDP, TCP and IP are implemented into the kernel right ?? So why would it be hard to rollout QUIC if its based on top of IP instead of UDP, as both IP and UDP are present in the kernel ???
Because you would have to update every kernel in the planet to support QUIC/IP. Where if you put it on top of UDP, the system will just treat it like an application and send it up the stack
So how does quick handle packetloss? how does it utilize max bandwidth without overcongestion? is global synchronization an issue with quic? How does quic determine the MSS along a path?
Hey Mario - Great questions. QUIC acks on a per-packet basis. Note: not an IP packet, but a QUIC packet. The UDP payload can carry more than one. When one goes missing, only those streams within the QUIC packet are impacted. QUIC only retransmits data for the affected stream. Within each stream, and with the connection as a whole, congestion algorithms very similar to the ones used with TCP are implemented. Not sure what you mean about global synchronization. QUIC starts out with the largest packet payload first which, if there are MTU problems, will reveal that before the connection kicks off.
Hi Chris, thanks for your sharing. I am wondering somethings. Can we say that quic will die the tcp? Also, does quic protocol need more bandwith than tcp?
TCP will still be around for awhile, but QUIC will take on some of it's workload for web based apps. QUIC doesn't need more bandwidth, as the data is generally the same. It's just carried differently.
Any chance that the QUIC videos will be put on something like Udemy so they can be purchased. I am trying not to sign up for another monthly subscription service if I can help it. I would rather give you $30 for the videos than sign up for a month... I have already used my free trial on Pluralsight and also trying not to set up another gmail account for a free trial ;)
If blocked the keyword in firewall then in chromium browser tha blocked website is able to acces in packet captures we observed instead of TCP there is QUIC
I didn't have any plans to cover MPTCP yet - I just haven't seen it enough in the wild yet to master it. But if I do, the video will definitely follow.
At 6:37, why do we compare UDP to IP, instead of asking "why is quic built on top of UDP instead of TCP". I am confused because IP is a network layer protocol, so obviously it makes more sense to build quic on top of UDP. What do i miss here?
I think his point was think if we built something new at the same level as UDP/TCP (i.e. "on top of IP") then it would be a brand new thing that low-level network software would need to understand whereas with this approach we're leveraging an existing, known protocol (UDP) and just building on top of that. So we get backwards compatibility while still being able to create a new protocol.
It seems so obvious? I'm guessing it was advancements in crunching the TLS into the UDP first step or why wouldn't this have been in place initially and TCP avoided all together. Just named it UDPS and UDP, UDPS for secure? I'm learning Networking + now and am guessing I'll eventually know this answer come the time.
Hey Adam, thanks for watching! So QUIC doesn't crunch TLS into UDP. Instead TLS was crunched into QUIC. Since QUIC is a brand new transport layer protocol (Think of it almost like layer 4.5) it couldn't be put right on top of IP because it would take forever for every device in the world to support it. By using UDP/IP as the carrier, QUIC is almost turnkey. UDP is not any more secure than it ever was - it's still just an 8 byte protocol header. Two ports, a length, and a checksum. No bells and whistles at that layer. The smarts and security is all built into QUIC.
Where does it sit in the OSI Layer? Is it at layer 4 or closer to layer 7? If it is higher wouldn't this potentially cause more overhead for the computers at either edge that TCP would?
Like the RFC mentions, QUIC is a transport protocol. That said however, it also dips a bit into the application layer with the way that it sets up streams, which used to be handled just by HTTP/2. So to me, it's a transport protocol with a toe into the application layer.
@@ChrisGreer So what's the CPU hit for this? Does it cause processor overhead on just the two ends, or is it so little that we don't even need to worry about it?
For the time being, I'm guessing it will be more intensive on the CPU, or at least until OS's and apps start to optimize it. Here is a report about it - conferences.sigcomm.org/sigcomm/2020/files/slides/epiq/0%20QUIC%20and%20HTTP_3%20CPU%20Performance.pdf
How does quick traverse homenet [ and corporate ] firewalls given there is no client side initiated tcp connection to support the server sent download and stream payloads?
The client initiates the QUIC connection, much like it initiates a TCP connection. Since the firewall sees the Initial packet going out, it allows the reply back through - just like with TCP.
Dear Chris, good day sir! Let's say we would be interested in acquiring consultation services from you, Is there a way we may do so ? We're a finance company located in Malaysia, Zoom intermittent quality and performances has baffled us for the past 2 years, Hoping you'd undertake the singular and interesting subject and even more so the opportunity to be ale to work with you :D
I don't understand why it'd be a problem if quic sat atop of IP as he put it. Would really like to hear someone's explanation on this one as it sounds wrong to me. I always understood IP as being its own thing that other protocols used. Great example is how tcp is generally reffed to as TCP/IP.
That is a good question. If QUIC sat right on top of IP, every device in the world (network infrastructure, end user devices, phones, tablets, printers, IoT devices, etc, etc) would need a specific upgrade to the kernel stack in order to use QUIC. That would have a very long implementation cycle. QUIC sits on UDP because all those devices already support UDP. QUIC can be passed up to the sub-application layer immediately without the device getting stuck
@@ChrisGreer so quic leverages UDPs access to the IP stack then? Why can't the network drivers just be extended to allow quic to work natively with IP? Or is that the issue at hand? I don't understand drivers inside the network stack well enough to speak intelligently on them. I just assume that if something needs to use existing protocols it simply makes the calls to them.
h2 is like old generation people, who first get to know each other, make sure they are on the same page, then they date, and the new gen QUIC people, well they jump straight in.
Can they abuse rights easier with this protocol in future? and force routing into blockk chains etc...? Are they setting up a world where there wont be free reign to travel online sorta speak
Hey - QUIC embeds TLS 1.3 - so they can't abuse rights any more with QUIC than they already can with TLS over TCP, which is used by most servers on the internet.
![BRASIL vs. PERÚ [4-0] | RESUMEN | ELIMINATORIAS SUDAMERICANAS | FECHA 10](http://i.ytimg.com/vi/tbyOJKXfQnI/mqdefault.jpg)
QUIC is here! The RFC just dropped. Let's learn about this new protocol that stands ready to take on some of the TCP workload over the web.
Check out my new Protocol Deep Dive: QUIC course on Pluralsight. You can watch it for free with a 10 day trial: www.bit.ly/wiresharkquic
Please smash the like button to let me know if you dig this content!
Will it replace the TCP?
Just found your channel and I'm already a fan. Many thanks, Chris!
@@ileonardor Thanks for the comment!
You are a natural teacher, friend. Just starting to go deeper into IT, networking, cyber sec, etc. And even though I have limited knowledge, I felt like I could follow everything you were covering. Instantly Subbed. Thank you!
Wow, thank you!
We havw a RFC! Great short summary of QUIC. Thanks, Chris!
Chris, your videos helped me crack interviews. Thanks for all the work you are doing. keep it up
Thanks for the comment, glad to hear it!
By far one of the best tutorials I've watched in a long time!! Thanks a lot!
Thanks for the comment!
Thanks for explaining it so nicely and concisely. Appreciate your effort !!
Glad it was helpful!
I love the way you teach it’s so understandable
Chris, Thanks for posting. Have you ever considered putting your videos on Udemy?
Hi Joe! Yes sir I have. It's tough though because I already have content on Pluralsight so I've chosen to go that route for now. Thank you for the comment though - I appreciate the idea.
Chris, I love the way you explain things. So easy to follow. I'm hoping to do some of your courses once I'm done with my current studies next month. Cheers Wayne
I learned about your channel because of a video you made with David Bombal. Thanks for your videos.
Thanks for the insights into QUIC
Great overview Chris! Hope you'll have a course / lab on this at Sharkfest next year. Really enjoyed your presentations last year.
Actually I will! I'll be speaking on QUIC at Sharkfest Europe next week, then again at the US conference in September. Stay tuned!
Great vid! Very concise!! Would love to see one for MASQUE..
Thanks for explaining in quic and concise manner ;)
Good stuff Chris. You're a phenomenal instructor.
Thanks for the comment!
make a video on how QUIC is going to help solana avoid spam transactions on the blockchain please
Thanks for doing a video on QUIC. Have you ever considered doing a video on SCTP?
Great summary! Thank you very much for sharing.
Chris great channel. I made it here through David Bombal and I’m glad he’s had you on. Definitely subbing
Glad to have you! Thanks for the comment and welcome.
Great Overview !
Really appreciated. Superb video. BTW, I am learning new things every single day by watching your videos. Go on like this 👍👍👍
Clear and great explanation. Waiting for many more videos and learning from you. Thank you Chris.
Awesome, thank you!
explanation is clear and concise. appreciate it!
Thank you!
That was really quick Quic 😁 loved your video
Thanks!
Chris, good presentation. I noticed one error made. Perhaps it was a slip of the tongue. If QUIC runs on top of UDP it cannot be as stated another or new transport protocol. Both TCP and UDP are OSI transport layer protocols. This would make QUIC an OSI sessions layer protocol.
Check out RFC 9000 - datatracker.ietf.org/doc/html/rfc9000. The first sentence is “This document defines the core of the QUIC transport protocol.” QUIC covers aspects of the transport layer, so it is a transport protocol. I can totally understand the confusion though - until now we have largely only had TCP/UDP at that layer. Think of QUIC as layer 4.5. 😁 trust me it helps!
@@ChrisGreer curious. After posting that also occurred to me as well. Perhaps QUIC falls somewhere in as a layer 4.5 protocol. Or maybe the reference is to the TCP/IP layer stack rather than the OSI layer stack I'm referencing. Anyways, thanks for link; I will dive through it.
How is QUIC used at the client and server app layer? Is there a new library which does all the QUIC before it hits the network stack?
hiii chris, i have a issue, in my chrome, quic allowed policy is set to false and i am not having avast or avg antivirus installed, i have windows security, due to this chrome is showing your browser is managed by organization which is annoying, i want to know about quicallowed policy being set to false is good for me or not. i mean its ok or not.
Thanks, great Video.
But i have one question: When I lock in a Wireshark capture. Before Quick is established, a normal TCP handshake is done first. Only then QUICK is used. The advantage of QUICK is lost, isn't it?
Not all advantages are lost. Just the initial QUIC connection time. But all other QUIC features (streams, built-in TLS, no head of line blocking) are still there, even if the browser first knocks on the server door using TCP. Since QUIC is so new, it's common to see non-chrome browsers do that first.
@@ChrisGreer Thanks for the answer. I have another question: As I understand it, firewalls can no longer do any content filtering due to the encryption of QUIC. Is this true or is there a way to look into a QUIC traffic?
Thank you for this super concise explanation, Chris! :)
Glad it was helpful!
I am learning from you! Thank you!!!
Thanks , for your wonderful Explanation.
You are welcome!
hi Chris, i am capturing youtube traffic, there is mixing protocol of QUIC and GQUIC inside the captured file. What is the relation between QUIC and GQUIC ? and how to correlate QUIC and GQUIC in that youtube file ?
Thanks for this video Chris !!
Hi Chris,
I have one video request for you.
Can you make a video on MPTCP. Although many videos are available but the way you explain makes me understand things better.
Looking forward for MPTCP video soon!!
It’s very good explanation, thank you very much!
You are welcome!
What about ddos attack? UDP is favorite one for hackers to attack network; a simple port scan, see what udp port are open, and done, deliver a big ddos attack; how handle this with QUIC?
Brilliant Explanation 👏👏
Glad you liked it
I am un able to make payment to access that quic drive course ..it does not accept credit card.Any other solution for this
Hey, got a question, protocols like UDP, TCP and IP are implemented into the kernel right ?? So why would it be hard to rollout QUIC if its based on top of IP instead of UDP, as both IP and UDP are present in the kernel ???
Because you would have to update every kernel in the planet to support QUIC/IP. Where if you put it on top of UDP, the system will just treat it like an application and send it up the stack
@@ChrisGreer oooh, got it, thanks for the prompt reply, really appreciate it 🍻
So how does quick handle packetloss? how does it utilize max bandwidth without overcongestion? is global synchronization an issue with quic? How does quic determine the MSS along a path?
Hey Mario - Great questions. QUIC acks on a per-packet basis. Note: not an IP packet, but a QUIC packet. The UDP payload can carry more than one. When one goes missing, only those streams within the QUIC packet are impacted. QUIC only retransmits data for the affected stream. Within each stream, and with the connection as a whole, congestion algorithms very similar to the ones used with TCP are implemented. Not sure what you mean about global synchronization. QUIC starts out with the largest packet payload first which, if there are MTU problems, will reveal that before the connection kicks off.
Hi Chris, thanks for your sharing. I am wondering somethings. Can we say that quic will die the tcp? Also, does quic protocol need more bandwith than tcp?
TCP will still be around for awhile, but QUIC will take on some of it's workload for web based apps. QUIC doesn't need more bandwidth, as the data is generally the same. It's just carried differently.
Today I learn many things.
Any chance that the QUIC videos will be put on something like Udemy so they can be purchased. I am trying not to sign up for another monthly subscription service if I can help it. I would rather give you $30 for the videos than sign up for a month... I have already used my free trial on Pluralsight and also trying not to set up another gmail account for a free trial ;)
Oh gotcha. It's something I could consider. Thanks for the comment and the productive suggestion.
If blocked the keyword in firewall then in chromium browser tha blocked website is able to acces in packet captures we observed instead of TCP there is QUIC
Any intro on MPTCP any time soon? Kudos for your trainings BTW, top quality!
I didn't have any plans to cover MPTCP yet - I just haven't seen it enough in the wild yet to master it. But if I do, the video will definitely follow.
@@ChrisGreer Thanks for the answer. Siri, Apple Maps and Apple Music are supposed to use it I believe.
Thank you
At 6:37, why do we compare UDP to IP, instead of asking "why is quic built on top of UDP instead of TCP". I am confused because IP is a network layer protocol, so obviously it makes more sense to build quic on top of UDP. What do i miss here?
I think his point was think if we built something new at the same level as UDP/TCP (i.e. "on top of IP") then it would be a brand new thing that low-level network software would need to understand whereas with this approach we're leveraging an existing, known protocol (UDP) and just building on top of that. So we get backwards compatibility while still being able to create a new protocol.
Nice explanation
Thanks for liking
Btw Nginx already providing binaries with quic support though still preview :)
u very good teacher thank you
Fab overview!
Thank you!
where can I get a packet head cap?
Which one is better QUIC or TCP?
It seems so obvious? I'm guessing it was advancements in crunching the TLS into the UDP first step or why wouldn't this have been in place initially and TCP avoided all together. Just named it UDPS and UDP, UDPS for secure? I'm learning Networking + now and am guessing I'll eventually know this answer come the time.
Also, thanks for the video!
Hey Adam, thanks for watching! So QUIC doesn't crunch TLS into UDP. Instead TLS was crunched into QUIC. Since QUIC is a brand new transport layer protocol (Think of it almost like layer 4.5) it couldn't be put right on top of IP because it would take forever for every device in the world to support it. By using UDP/IP as the carrier, QUIC is almost turnkey. UDP is not any more secure than it ever was - it's still just an 8 byte protocol header. Two ports, a length, and a checksum. No bells and whistles at that layer. The smarts and security is all built into QUIC.
Thanks :)
After cleaning of cache memory then the website is able to blocking
Where does it sit in the OSI Layer? Is it at layer 4 or closer to layer 7?
If it is higher wouldn't this potentially cause more overhead for the computers at either edge that TCP would?
Like the RFC mentions, QUIC is a transport protocol. That said however, it also dips a bit into the application layer with the way that it sets up streams, which used to be handled just by HTTP/2. So to me, it's a transport protocol with a toe into the application layer.
@@ChrisGreer So what's the CPU hit for this? Does it cause processor overhead on just the two ends, or is it so little that we don't even need to worry about it?
For the time being, I'm guessing it will be more intensive on the CPU, or at least until OS's and apps start to optimize it. Here is a report about it - conferences.sigcomm.org/sigcomm/2020/files/slides/epiq/0%20QUIC%20and%20HTTP_3%20CPU%20Performance.pdf
How does quick traverse homenet [ and corporate ] firewalls given there is no client side initiated tcp connection to support the server sent download and stream payloads?
The client initiates the QUIC connection, much like it initiates a TCP connection. Since the firewall sees the Initial packet going out, it allows the reply back through - just like with TCP.
Awesome!
Thanks!
Dear Chris, good day sir!
Let's say we would be interested in acquiring consultation services from you,
Is there a way we may do so ?
We're a finance company located in Malaysia, Zoom intermittent quality and performances has baffled us for the past 2 years,
Hoping you'd undertake the singular and interesting subject and even more so the opportunity to be ale to work with you :D
Does it have an ErC-20 token? I know some idiots that will likely trade it.
Hello guys , does anyone have a working simple client/server protocol in any programming language ?
tcp udp and quic?
Why it happens?
QUIC is an acronym for Quick UDP Internet Connections.
RFC 9000 Section 1.2: QUIC: The transport protocol described by this document. QUIC is a name, not an acronym. datatracker.ietf.org/doc/html/rfc9000
I don't understand why it'd be a problem if quic sat atop of IP as he put it. Would really like to hear someone's explanation on this one as it sounds wrong to me. I always understood IP as being its own thing that other protocols used. Great example is how tcp is generally reffed to as TCP/IP.
That is a good question. If QUIC sat right on top of IP, every device in the world (network infrastructure, end user devices, phones, tablets, printers, IoT devices, etc, etc) would need a specific upgrade to the kernel stack in order to use QUIC. That would have a very long implementation cycle. QUIC sits on UDP because all those devices already support UDP. QUIC can be passed up to the sub-application layer immediately without the device getting stuck
@@ChrisGreer so quic leverages UDPs access to the IP stack then? Why can't the network drivers just be extended to allow quic to work natively with IP? Or is that the issue at hand? I don't understand drivers inside the network stack well enough to speak intelligently on them. I just assume that if something needs to use existing protocols it simply makes the calls to them.
-QUIC is on top of UDP
-Possibility of 0-RTT
-TLS1.3 built in the protocol not separated
h2 is like old generation people, who first get to know each other, make sure they are on the same page, then they date, and the new gen QUIC people, well they jump straight in.
3:11 QUIC = Quick UDP Internet Connection
RFC 9000 Section 1.2 - QUIC:The transport protocol described by this document. QUIC is a name, not an acronym. 😉
Just a tip: Don't use the letter S to represent two different things at the same time.
LOL. yea UDP is so well supported that a lot of firewalls and ISPs just block them right away.
Well, that was QUIC...
Love it!
QUIC is an acronym for "Quick UDP Internet Connections"
Can they abuse rights easier with this protocol in future? and force routing into blockk chains etc...? Are they setting up a world where there wont be free reign to travel online sorta speak
Hey - QUIC embeds TLS 1.3 - so they can't abuse rights any more with QUIC than they already can with TLS over TCP, which is used by most servers on the internet.
QUIC QUic Is not an aCronym. See ..its not.
Its not over 9000