Networking/Computing Tips/Tricks

Rate this content:
5 of 5 - 4 votes
Thank you for rating this article.

Have you noticed a lot of QUIC protocol in your packet captures?  I certainly have, and we had better talk about what this is. Image source: google.com

What is QUIC (now more recently called gQUIC)?

QUIC is a new protocol created by the fine folks at Google.  It stands for Google Quick UDP Internet Connections.  It is an experimental protocol that was introduced back in 2012 on the Chrome and Chromium platforms, and is getting broader use by the day as users continue to flee from Microsoft's Internet Explorer and Edge.  Google calls it a transport layer protocol (which would be Layer 4) but it actually runs over UDP which is at Layer 4 - so we see it as a new Layer between 4 and 5.

Note: Google originally called this protocol "QUIC" as you can tell by the original logo, but now that original version is referred to as gQUIC, whereas the IETF has chosen to call the newer version they are working on as "QUIC" - confusing - yes - so when I saw QUIC here I am referring to Googles original QUIC protocol.

The target of QUIC, although Google soft shoes this point, is to essentially replace TCP.  TCP has been around a long time, and while it has received many updates to improve function, speed, and scalability, due TCP's dependency on round-trip exchanges and acknowlegements (ACK's), many believe it is becomming outdated based on today's higher speed demands of the Internet.  By high speed demands, what we mean is that in the original web pages of the Internet, life was simple, it took one TCP session to send the page.  Today, it can take dozens of TCP connections to load all the elements on a single web page.  These multiple connections take time and have to be processed in order.  TCP has no ability to multiplex these connections.2021 10 19 13 22 37

In fact, one of the problems that can occur is that let's say the first of several dozen TCP connections is slow or ties up the resources of the receiver.  Other processes won't even start!  So that first process essentially blocks other processes from even starting.  Google calls this 'head of the line blocking'.

One attempt to improve this multiplexing was a protocol that Google called SPDY ('speedy').  This was done above the transport layer, and SPDY eventually became what we now call HTTP/2.  But SPDY did not fix all the problems.  You can read more on SPDY here.

Let's get back to QUIC.  QUIC supports a set of multiplexed connections between two endpoints over UDP, and was designed to provide security protection equivalent to TLS/SSL.  So along with reduced connection and transport latency, and bandwidth estimation in each direction to avoid congestion, QUIC's achieves its main goal to improve perceived performance of connection-oriented web applications that are currently using TCP.

Now - as mentioned above, the IETF has picked up on Google's development and the original QUIC protocol is now referred to as GQUIC.  The IETF is busy reasserting this design under the new-not new name QUIC and there are approximately 30 internet draft specifications dealing with the new version of QUIC.  You can find those drafts here.

Google's Own Explanation of what QUIC is

You can also view Google's own explanation about QUIC in the following video:

 

 Examining GQUIC on Your Computer

***NOTE – below does not work after v71 of Chrome!

One of the cool things that Google does for us is it allows us to view QUIC performance within Chrome.  So if you have Chrome installed, open a new tab and enter the following:

 chrome://net-internals/#quic

You will something like this:

QUIC1

 You can see the number of events, the QUIC version that you are running, and Connection ID's.  This screen will update as connections come and go.  

If you click on one of your connection ID's, and then on the next page, click on the Source Type field, you will get something that looks like this:

QUIC2

To the right, you will see the actual packet process that QUIC is using as all the protocol processes are dissected (well, without the data).  This is a live screen, and it will continue to update if there is data going in the session.

Wireshark does have the ability to dissect QUIC processes as well (ofcourse it cannot decrypt the data), and we will discuss this in another article.

Scanning through the packet information you will see interesting information like packet numbers, missing packet information, acknowleged packet information and much more.

We hope this article has helped you to understand what QUIC is at an introductory level.  Look for more details to come by simply clicking on the QUIC tag below.

Comments?  Questions?

I hope you find this article and its content helpful. If you would like to see more articles like this, please support us by clicking the patron link where you will receive free bonus access to courses and more, or simply buying us a cup of coffee!, and all comments are welcome!

Did you learn something?
Did I save you time? 

Buy me a coffeeBuy me a coffee!

Find by Tag

5G Networks 6LoWLAN 6LoWPAN 802.11 802.11ah 802.11ax 802.11ay 802.11az ACL Addressing Analysis Ansible Architecture ARP Assessment AToM Backup Bandwidth BGP Biography Bloom's Taxonomy Briefings CBRS CellStream Cellular Central Office Cheat Sheet Chrome Cisco Clock Cloud Computer Consulting CPI Data Center Data Networking Decryption DHCPv4 DHCPv6 Display Filter DNS Documentation ECMP EIGRP Ethernet Ethics Flipping the Certification Model Follow Me Fragmentation Git GNS3 Google GQUIC Hands-On History Home Network HTTPS ICMP ICMPv6 IEEE 802.11p IEEE 802.15.4 In A Day Internet IOS Classic IoT IPv4 IPv6 IS-IS L2 Switch L2VPN L3VPN LDP Learning Services Linux LLN Logging LoL M-BGP MAC MAC OSx Macro Microsoft mininet Monitoring Monitor Mode MPLS Multicast Name Resolution Netflow NetMon netsh Networking Network Science nmap Npcap nslookup Online Learning Online School OpenFlow OSPF OSPFv2 OSPFv3 OSX Parrot PIM Ping Policy POTS POTS to Pipes PPP Profile Profiles Programming Project Management PW3E Python QoS QUIC Requirements RIP Routing RPL RSVP Rural SAS SDN Security Self Certification Service Provider Services Sharepoint Small Business Smartport SONET Speed SSH SSL Subnetting T-Shark TCP TCP/IP Telco Telecom 101 Telecommunications Telephone Telnet Terminal TLS Tools Traceroute Traffic Analysis Traffic Engineering Training Travel Tunnel Utility Video Virtualbox Virtualization Voice VoIP VRF VXLAN Webex Wi-Fi Wi-Fi 6 Wi-Fi 6/6E Windows Wireless Wireless 5G Wireshark Wireshark Tip WLAN ZigBee Zoom

Twitter Feed