The IETF community had a number of goals when it chartered work on QUIC. Much of the motivation for this work comes from HTTP, and in particular what we've learned from HTTP/2.

One of the key goals for HTTP/2 was to avoid head-of-line blocking–when an outstanding request blocks subsequent requests. HTTP/2 solved that problem by allowing multiplexing on top of TCP; many HTTP requests and responses can be in flight at the same time, with no blocking from the application protocol.

However, fixing head-of-line blocking in HTTP exposed it down in the transport layer. When a packet is lost, TCP buffers any subsequent packets until it is successfully retransmitted, even when the application (like HTTP with multiplexing) might be able to use some of that buffered data. For example, some deployments of HTTP/2 have seen reduced performance on lossy connections–especially for video–because of this.

QUIC takes the stream model of HTTP/2 and embeds it in the transport layer, so that a single connection can make progress on a stream even if packets containing data from other streams are lost–thereby mitigating the head-of-line blocking problem in the transport as well as the application layer.

Many have noted that SCTP already offers multiplexing in a transport protocol. However, it's difficult to deploy SCTP on the open Internet, because many networks block it. As a result, QUIC is built on top of UDP.

That brings up another important feature of QUIC: protection against ossification. Because TCP exposes things like acknowledgements and retransmissions to networks, devices on the network sometimes try to "help" by changing unprotected information, or by inferring things from it.

Unfortunately, this makes evolving the protocol more difficult, because any changes can have unpredictable results. TCP is now so ossified that introducing any changes to its basic operation have to be done very carefully; this harms the ability of the protocol to meet the needs of its users.

QUIC hides much of this state from observers, ensuring that it remains a flexible, end-to-end protocol. Even where QUIC's state is exposed to the network, it is protected from on-path tampering, including QUIC's handshake as well as signals intended for on-path devices like the connection ID and the spin bit, should it be adopted.

QUIC does that by being encrypted by default. Internet protocols have been moving towards always-on encryption for a while now, because of concerns about ossification as well as pervasive monitoring. As an always-encrypted protocol, QUIC helps achieve this, and as a bonus, is able to offer better performance, thanks to its tighter integration between things like the transport and cryptographic handshakes.