QUIC is a new reliable and secure transport protocol that is suitable low-level layer for a protocol like HTTP and that can address some of the known shortcomings of doing HTTP/2 over TCP and TLS. The logical next step in the web transport evolution.
QUIC is not limited to just transporting HTTP. The desire to make the web and data in general delivered faster to end users is probably the largest reason and push that initially triggered the creation of this new transport protocol. A new transport protocol built on top of UDP.
A background on HTTP/2
HTTP/2 addresses a whole slew of shortcomings in HTTP/1 and with the introduction of the second version of HTTP users can stop using a bunch of work-arounds. Some of which are pretty burdensome on web developers.
One of the primary features of HTTP/2 is that it makes use of multiplexing, so that many logical streams are sent over the same physical TCP connection. This makes a lot of things better and faster. It makes congestion control work much better, it lets users use TCP much better and thus properly saturate the bandwidth, makes the TCP connections more longlived, which is good so that they get up to full speed more frequently than before. Header compression makes it use less bandwidth.
With HTTP/2, browsers typically use one TCP connection to each host instead of the previous six. In fact, connection coalescing and "desharding" techniques used with HTTP/2 may actually even reduce the number of connections much more than so.
HTTP/2 fixed the HTTP head of line blocking problem, where clients had to wait for the first request in line to finish before the next one could go out.
Problem with HTTP/2 - TCP head of line blocking
HTTP/2 is done over TCP and with much fewer TCP connections than when using earlier HTTP versions. TCP is a protocol for reliable transfers and you can basically think of it as an imaginary chain between two machines. What is being put out on the network in one end will end up in the other end, in the same order - eventually. (Or the connection breaks.)
With HTTP/2, typical browsers do tens or hundreds of parallel transfers over a single TCP connection. If a single packet is dropped, or lost in the network somewhere between two endpoints that speak HTTP/2, it means the entire TCP connection is brought to a halt while the lost packet is re-transmitted and finds its way to the destination. Since TCP is this "chain", it means that if one link is suddenly missing, everything that would come after the lost link needs to wait.
It becomes a TCP-based head of line block!
As the packet loss rate increases, HTTP/2 performs less and less well. At 2% packet loss (which is a terrible network quality, mind you), tests have proven that HTTP/1 users are usually better off - because they typically have up to six TCP connections to distribute lost packets over. This means for every lost packet the other connections can still continue. Fixing this issue is not easy, if at all possible, with TCP.
Building on top of UDP
QUIC is a transfer protocol implemented on top of UDP. If you watch your network traffic casually, you will see QUIC appear as UDP packets. Based on UDP it also then uses UDP port numbers to identify specific network services on a given IP address.
All known QUIC implementations are currently in user-space, which allows for more rapid evolution than kernel-space implementations typically allow.
While UDP is not a reliable transport, QUIC adds a layer on top of UDP that introduces reliability. It offers re-transmissions of packets, congestion control, pacing and the other features otherwise present in TCP.
Data sent over QUIC from one end-point will appear in the other end sooner or later, as long as the connection is maintained.