It missed being a recursive acronym by a single letter…
TCP is known for being the go-to protocol for stable connections over the internet. There are some things you can guarantee: you will not lose bits of data, packets will arrive in order, incorrect packets will be checked and redelivered, and both endpoints will be roughly metered to the least capacity. It is easy to develop applications around the TCP protocol, it does the hard problems for you.
Being meticulous also makes it slow, relatively speaking.
UDP, on the other hand, frees its packets in a fountain to hopefully land where it is intended. This protocol is fast, but a pain for applications that need some level of reliability. Quick UDP Internet Connections (QUIC), from Google, leverages UDP to create multiple independent, even encrypted connections. While TCP could be made faster, it is beyond the jurisdiction of web browsers; support is embedded into the operating system itself. This leaves building upon UDP, suffering with TCP, or not being compatible with about every network hardware installed just about anywhere.
This comes on the heels of SPDY, Google's other open protocol. SPDY is built around HTTP and both presume a reliable protocol underneath, where TCP is the usual candidate. A large advantage of SPDY allows assets to simultaneously stream over a single connection. TCP will, unfortunately, freeze the entire connection (and thus each stream) when a single stream drops a packet. QUIC, based upon UDP, can then be used to accelerate SPDY further by allowing truly independent multiplexing.
QUIC will be used for "a small percentage of Chrome dev and canary channel traffic to some Google server", for experimentation purposes. The code itself is licensed under BSD and, as such, could migrate to other browsers in due time.
