QUIC (HTTP 3) is often referred to as the “next generation” in web communication. It operates on the fourth layer of the OSI model (transport) and used to stand for “Quick UDP Internet Connection” (the drafted specification now states that “QUIC” is the actual name of the protocol and it is not an acronym for anything else). It is also known as HTTP/3, which further cements its position as the successor to HTTP/2.
The most critical aspect of the QUIC protocol is the use of UDP for communication; this alone lowers latency between a client and server by foregoing the use of a traditional TCP-based arrangement (which requires any two parties to SYNchronise, followed by SYN-ACK and ACKnowledgement).
QUIC Protocol is still in its infancy — the protocol has only been deployed for roughly a decade. Having said that, the adoption rate for QUIC has been steadily increasing with a surge in traffic for streaming platforms. From Facebook to YouTube, its growing popularity along with support by major web browsers and web servers are indicators that it is here to stay — and that you’ve probably already visited a QUIC-enabled website.
The Quick UDP Internet Connection (QUIC) protocol operates over UDP-based connections. It inherits certain features from HTTP/2 (which itself was developed by Google), including non-blocking transmissions and resource prioritization. This means that the experimental protocol will eventually have significant speed and latency advantages with most web requests (QUIC’s infancy here means that some requests can still end up being slower than HTTP/2 requests).
One way QUIC should achieve better latency is with multiplexed (or multiple) connections. In theory, reliability will also be augmented with the specification’s new packet loss handling. Focusing on QUIC’s main advantage, which is QUIC-TLS (or “SSL”) connections, it can be seen that the multitude of handshakes required by TCP are gone. Encrypted traffic also gains compression for certificates, which will provide even more performance.
While QUIC Protocol has been added to most major browsers (Firefox, Safari, Chrome), its experimental nature (the specification, while achieving RFC status (RFC 9000), is still being implemented with routers, WAFs, etc.) means that certain browsers have not “flipped the switch” to enable the protocol. Safari, for example, has only recently gained support for the protocol (and can only be turned on through an “Experimental Features” menu). Firefox has, in the last few months, “flipped the switch,” enabling QUIC (it is indeed pronounced “QUICK”!) communication by default.
Furthermore, QUIC implements a new "Connection ID" system to identify connections between hosts and clients -- this means that along with more widespread support, software needs to be updated such that QUIC can be fully taken advantage of (i.e. new load balancers can potentially use this for maintaining states/sticky sessions). (again, due to the relative infancy of the protocol, it will take time for software to mature and enter production)
QUIC is slated to replace traditional TLS over TCP transmissions. With a lower overhead, clients with slower connections should receive noticeable benefits (the time before they begin to receive encrypted traffic will be lower). QUIC has been designed with security and performance in mind; packets can be multiplexed (or “pipelined”) to provide major efficiency gains (which further increases reliability in poor network conditions).
HTTP is a protocol used to connect to web servers by web browsers to request content to view. This is also used to transfer larger files, and is often used for software updates.
Compression involves running an algorithm to make a file/image/etc. smaller. There are two modes of compression: lossy and lossless.
A "Web Application Firewall."
QUIC is formerly known as the "Quick UDP Internet Connection" protocol, but it is an emerging web protocol slated to improve both performance and web security.