What is QUIC?
ฝัง
- เผยแพร่เมื่อ 31 ก.ค. 2024
- QUIC is the Quick UDP Internet Connections protocol, developed by Google and currently in IETF workgroups for further development. It is being considered for replacing TCP as a transport protocol for HTTP/3. Join Jason in this Lightboard Lesson as he gives an overview of the protocol in light of a transition from TCP.
- วิทยาศาสตร์และเทคโนโลยี
Nice and QUIC presentation! Please bring this guy to give whole presentation on the topic!
Appreciate the comment!
Thank you for the presentation. It was a very good introduction to QUIC.
Excellent presentation, as always, by the F5 Team......appreciated.
Great video! Thank you Jason! Super smart and likable guy.
I love this guy! Informative video. Thank you so much mr
A good short explanation about QUIC!
Thank you! Everything I wanted to know happened in just 8 minutes. Magic! Before watching this video I tried understand that proto reading docs and it didn't work out.
its a great presentation related to QUIC!. new generation of protocols is comming...
Thanks for very informative episode
it is awesome video to understand how QUIC works.
Great explanation, thanks.
i love lightboard lessons
Beautiful quic
Great video!
I enjoyed the explanation of QUIC and it sounds great. After watching the video I think that QUIC might still have its drawbacks if you are really into security (if I'm understanding it correctly). If anyone could add more to the security part I would greatly appreciate it! It sounds like the future, but as of 2021 it still might not be as secure as TCP & TLS
Thanks for sharing
thanks sir , great exlaination
Now tell me how to write like this.
He says in the start, lightboard
In reverse?
@@KangJangkrik record the video and flip it
@@IshamMohamedIqbal That suggests that they have shirts with mirror logos. That's pretty nifty.
Mirror image. Took me a while to figure out. Ring finger gave him up.
The shirt has the logo printed backwards right? How could he possibly write everything flipped so naturally?
This is how we create these :-) : th-cam.com/video/U7E_L4wCPTc/w-d-xo.html
What does it mean exactly that TCP/UDP is in kernel space and TLS/HTTP and QUIC are in userspace? And why is it that it takes longer to make changes to kernel space than user space?
So, does Big-IP fully support termination of QUIC sessions? If so, can you utilize it on the client-side, with a typical TCP/HTTP back-end connection? I'm thinking of the benefit gained by maintaining the connection UUID across changing networks more than any performance boost?
QUIC is out in the wild, but not yet a standard. (see datatracker.ietf.org/wg/quic/about/) I think any first step will probably follow your thoughts there with client-side support and typical TCP/HTTP on back-end, but that's speculation at this point.
@@devcentral Thanks for the reply. So, not really supported for termination, yet. Looking thru F5s docs, it really only comes up in the SSL Intercept stuff. I assume Big-IP can properly parse it to send to and IDS/IPS and other auditing services?
@@TobyGarcia currently you could classify applications based on the SNI in the first packet of a Google QUIC connection, but that's about it.
@Toby Garcia, as of version 15.1.0.1 BIG-IP supports draft-24 of QUIC and HTTP/3 on the clientside with and HTTP/1 or 2 backend. Further maintenance releases are keeping up with versions of QUIC as they emerge.
What would happen if I cloned a connection UUID? Does the mean I could resume the session of another person regardless of the local device used?
yes but QUIC header is almost totally encrypted before it sent to end point. So, you can sniff entire packet and send exactly same one again and again.
No it uses TLS 1.3, you would have to know the shared secret agreed during the handshake, which would require knowing both private keys of client and server plus the random number sent during the exchange. The connection id is just metadata.
please allow me the very stupid question: How did you do this video? But then you have to do mirror writing? Is it done that way? Or did you mirror the video afterwards? (your shirt appeas laterally reversed, so this would be my guess.)
Our write-up on the magic is here: devcentral.f5.com/articles/lightboard-lessons-behind-the-scenes.
So, the two takeaways that I see are 1) QUIC is going to use a non ip:port id (Amazing!) and 2) QUIC won't suffer the head of line blocking problem occurring with TCP.
How does it sends acknowledgement especially for lost packets?
QUIC manages the transport reliability in lieu of TCP. Details in sections 3 and 4 here: quicwg.org/base-drafts/draft-ietf-quic-recovery.html
with using Quic is there any risk of packet loss ?
Is QUIC an application layer protocol? What about packet loss? will QUIC resend lost packets? Or UDP will?
Kashif Riaz more session layer, incorporating reliability components from TCP. End state is still in development, but can resend, or function like raid and spread packet data as overhead on other packets so lost packets can be reconstructed by the receiver. UDP is unreliable, and will not handle any of that.
Jason Rahm much appreciate it buddy
@Blood Sausage you can't make me!
I never thought about it but is normal server is limited to 65536 connections (assuming they dont have NAT) because they allocate a port for each connection where google can handle unlimited connections with the UUID
servers can use the same port for multiple connections, actually :)
@@ascensionblade Like using the packet number for identification?
@@gaydolfhitler6310 I'm not sure how servers currently do it specifically under the hood. I believe the concept is called "multiplexing" if you wish to research it further :)
what will happen with websockets
Tcp and tls use port 443. Quic us faster, because it stacks on top of udp.
Is quic using UDP as the underlying protocol ?
yes
If it's located on userspace, what if there is a malware patch QUIC binary and easily exploit the system? That's nightmare!
if there's malware in userspace, quic isn't making it any worse
FYI: QUIC as used by the IETF is no longer an acronym.
1. Developed by google
2. Why does QUIC matters?
a. solves head of line blocking issue for layer 4 with application layer. With TCP+TLS we were solving only for application layer
b. TCP has 2 trips and TLS has 4 trips which makes the total as 6 trips for connection but with Quic it takes 1-2 trips per connection max. This is big deal if you have create connections for all request
c. Improved loss control and congestion feedback
d. TLS 1.3 is used with QUIC
e. Only particular stream of package is resent unlike TCP+ TLS as udp doesnot care much on order unlike TCP
f. For tcp we use ip:port for client and server however quip use conn uid. Benefit is now you can switch from mobile to wifi to wired etc but you will not lose information
g. Quic is developed by google and google owns clients like chrome with which they can do real world testing. In chrome you can enable quic in browser setting as well
3. Other Learnings
a. TCP UDP lives in kernel space so it is very hard to make any change at protocol level but since quic is in user space it is easier to make changes
the online games are doing this about decades ago
you mean DTLS and custom equivalents
developed by Googs......faaaarkk
Hes not a lefty is he? Good vid though 🇧🇩🇧🇩🥰🥰
No, but both my parents are. Does that count? ;)
I hope google realizes that hackers can also now do a lot of testing...then expecting us to open udp 443 outbound...yes, what could possibly go wrong (oh I know how about dlp?)...
The dos protection for udp is indeed a challenge.
Tcp syn cookie mechanism protects upper layer from tcp session creation brute force.
We need to see how quic protects againts session creation brute force
fix ur mic dude
He needs to lose weight.
Indeed. It's been a journey with ups and downs, injuries, illnesses, and plenty of excuses along the way.