 So we're going to talk real quick about the quick protocol, there seems to be a lot of questions I've run into about this because I talk a lot about firewalls, but the data traveling through the firewall, it matters what data it is, because it matters how the firewall sees it, how it perceives it and whether or not you can filter certain aspects of it. So this is a really game changing protocol that the internet has as a whole much of the transport layer of the internet is moving towards this. And I say as a whole, which kind of means Google's moving towards it and lots of other companies are following suit because it's more efficient way to send data. This protocol is used by many of the big internet companies that does include Facebook, YouTube, Google, lots of companies that have moved to this for the efficiency of it. First let's talk about a quick fundamental, TCP versus UDP transmission control protocol versus user data user datagram protocol. Now when you have a TCP connection, it is a connection that's suited for high reliability. So every time you send a TCP packet, there's a verification SINAC as it's called, so the ACSINAC which is the shorthand for TCP going through and acknowledging each piece of data that was received. I sent this data, did you get the data? Great, I don't need to send it again, so the acknowledgement back and forth. As you can probably perceive here, this means there's a lot of data going back and forth to verify each one. UDP on the other hand, a request for the data comes, UDP streams the data back without verifying that it even all got there. This is great for streaming protocols because you've now eliminated a big section of the data where you have to constantly check back and forth. Did you get the packet? Okay, I'm going to send the next one. Did you get the packet? Okay, I'm going to send the next one. That is the overhead that quick eliminates. And this protocol started a long time ago, so the quick protocol is a multiplex protocol stream transport over UDP. And the early days it was just referred to as the G-quick protocol. And Google, starting back in 2012 is when they started slowly working on this project. They kind of have a heavy hand on the internet because of their ubiquitous nature of Google. Their service is very popular and people using a Chrome browser. So they had access and this is started in the Chromium project itself, them having so much market share and they could try things out and try using this quick protocol. Now the way quick protocol works is it can fall back if for some reason it's not working. So it wants to use quick, it favors quick when you're using a Chrome browser and actually other browsers support this as well now, but it can fall back to standard TCP connections when quick protocol is blocked or for some reason the firewall doesn't understand it or for whatever reason it's unavailable through the browser even though the server is supporting it. So quick has that easy fall back, they both work over port 443. Just one uses 443 over TCP, the other one uses 443 over UDP. Now I really like this write up that is over at Cloudflare. Cloudflare is a content delivery network that helps websites be faster and they're embracing a quick protocol as well because well making websites faster is what happens with quick. So they have a good breakdown of how this works and some of the interesting pieces up in here's a visual of what I was talking about for the HTTP request for TCP plus TLS. So there's TCP and then TLS for transport layer security that adds another layer that is a security layer that we've pretty much come to know in the last couple of years where the internet has moved more towards encryption. So instead of the protocols working over unencrypted protocols, everything warms over TLS. That's great for security, that's bad for sending more and more packets because especially when you're first assigning a request, it has to get the transport layer security embedded. So now there's even more of these back and forth SINAC responses. And here's what the quick protocol looks like. Quick doesn't have an unencrypted version. So because it's a new protocol and was designed with security first, it encrypts always, it doesn't have a fallback of unencrypted or an unencrypted layer that you have or encryption layer that you have to add as you had with TCP because TCP is an unencrypted protocol that encryption can be added to. So this just makes for a very short response and each one of the responses represents packets that go back and forth. So as these packets go back and forth, like I said, they add overhead and that's where you get a lot of the speed. The other advantage of quick versus here is it's a multiplexing protocol. So this is an example where they say, here's a jQuery file that was asked for example.css image.png. So you ask for some JavaScripting, some CSS for the website and some images. There are three separate streams. Now inside each of these streams is going to be all that bouncing back and forth that you've seen with the TCP protocol, the verifications. So there's three TCP connections, which is also taxing everything in between because now it's got a every system in between as I keep track of all three of those TCP connections with HTTP to slash quick protocol. The ratified version that is being rolled out and it's more or less official now, the quick protocol is a single TCP with UDP streaming going on. So there's only a single TCP connection to request the data. Then all the data is multiplexed back via UDP and reassemble. And if the browser decides that there's a piece missing, it can send one more connection and get it back because UDP doesn't verify it just streams and sends. And as long as all the data got there, your browser reassembles the data with a checksum and goes, yep, this is the data, reassembles it in a way we go, but it's much less overhead and much less taxing on thing. I'll leave links to this so you can read on here. There's some challenges. If you have a really old net router where it does not understand, it can lose some of the sessions. There are some challenges that can come with older firewalls. But as I said, the way the protocol works and still just working over port 443, if for some reason the data doesn't work over quick in UDP, it can switch it back over to TCP and you just lose the speed benefits. Google has also added this from a load balancing standpoint. So this is a server side and they have cool little animation. And it's just showing the same thing again, showing how the back and forth and how many milliseconds it takes versus running the same thing over a quick. So you look 200 milliseconds to do the transport, 300 milliseconds for the first time handshake to add the TLS layer, zero milliseconds to 100 milliseconds, it's literally one half or even one third the speed, depending on whether that's a new connection or not. So you can see that this is just a much faster protocol. But then let's suck over on the security side. Now, from the end user standpoint, it's very secure. From the people who want to watch what your data is doing, it is a problem. And I bring up Cisco, but Palo Alto, SquidCache, you name it. If you want to watch people's internet data, you're going to have to block quick. Here in 2019, to my knowledge, no one has built anything that can truly see into quick very well at all. This is why people like Cisco and whatnot, they just say block it. You have to not use TLS 1.3. You cannot use quick protocol because by using these things, they blind these security devices. They have a hard time figuring out. Now, they still are able to see the IP addresses you're going to. So they're still able to block because of a known bad IP address so they know a bad website. In general, they can block this. Because it still requires DNS to get to the connection for that website. But the protocol itself, what's going on inside that layer, blinds these type of firewalls and devices, which is why they just suggest to block it. That's from the Meraki blog, the Cisco blog, the Palo Alto. Even in SquidCache, because this has come up many times with people who want to cache and make the internet faster. Well, that's not a great idea. I have a video ranking about that I can leave a link to. But the other side is, the quick protocol, simply by blocking it, you're making the internet slower for your users. Now, this is very common. I know quick protocols blocked in a lot of commercial installs, especially when you have companies that want to filter what their employees are doing and they install certificates and have IN filtering system to put a lot of restriction. They just blocked the quick protocol, which for now works because it's not like it's being forced to use quick in most sites such as YouTube and Google and Facebook that use quick protocol by default also can fall back to your standard TCP connections. Now, if you want to block it yourself, all of any of this is really telling you to do is block, implicitly block UDP over port 443 as opposed to TCP. So quick uses UDP over ports 80 and 443 according to this. I thought it only used 443, but I noticed an documentation here. But this is how you would do is you would block the UDP traffic and that's going to force things on there and maybe you want to do that because of security. If you're using something like the Cisco Marocchies, it's an option to check even on Palo Alto. You check your different firewall, they just have a option. Yeah, okay, it does use both port 80, my bad and 443, but this is how you would get rid of it. You just block it and a lot of the different firewall companies have an option. Like I said, you're going to make the internet slower, but it gains back some of that visibility that you might be looking for inside of the traffic with different IDS systems and filtering systems versus the blanket. It's a quick protocol to this IP address we know is owned by Google. So we'll assume it's doing this. So this is my little overview of quick because this comes up so many times when people have problems figuring out what traffic's going on across their network. This protocol is not going anywhere. It's becoming the standard for the newer versions of the internet. We're going to see more and more usage of it. It's very efficient. It's faster from an end user standpoint. It's secure and solid from I want to filter your internet standpoint of for example, ISPs or businesses or governments that want to filter what traffic goes on. It can be problematic because it can blind a firewall and I'll leave links to all these things so you can do your own further reading on this and thanks. Thanks for watching. If you liked this video, give it a thumbs up. If you want to subscribe to this channel to see more content, hit that subscribe button and the bell icon and maybe YouTube will send you a notice when we post. If you want to hire us for a project that you've seen or discussed in this video, head over to laurancesystems.com where we offer both business IT services and consulting services and are excited to help you with whatever project you want to throw at us. Also, if you want to carry on the discussion further, head over to forums.laurancesystems.com where we can keep the conversation going and if you want to help the channel out in other ways, we offer affiliate links below which offer discounts for you and a small cut for us that does help fund this channel. And once again, thanks again for watching this video and see you next time.