While, again, this is a fun spin on TCP - QUIC rides on UDP. Interestingly enough I pulled the stats from my home network for the past 30 days and I had roughly 300MB and 9k QUIC sessions (Chrome defaults to QUIC for the majority of Google services) via my firewall. If you want to see QUIC in action pop this into your Chrome bar with a Google endpoint open: chrome://net-internals/#quic
Compared to HTTP things like QUIC make perfect sense - especially when you consider all the RTT wasted on pipelined connections to the same site. You're only opening all those sockets because they're not multiplexed in any manner - your browser wants a JPG, grab the JPG. Your browser wants another, do it again...
So while this is light hearted, there's some validity to next gen web protocols that are more adapted to how the data is consumed.
You should read the design document and specicifaction rationale, it has more details than a blog post. Considering on the first page, in bold font it describes QUIC as "Multiplexed Stream Transport over UDP" it should only be compared to TCP+TLS in operation - but it helps to solve the multiplexing problem for anything that decides to take advantage of it directly. The majority of applications using TCP+TLS as a transport today have the same problem and open many sockets during operation.
Agreed SPDY and HTTP/2 have multiplexing built in - but so does QUIC.
"This is a working document, for group discussion and editing, which we expect to evolve into a somewhat fleshed out design document. The expectation is that we will flesh out a design for a tunneling protocol, running atop UDP, which can multiplex a large number of streams between two endpoints (a client, which initiates the overall connection, and a server). Each stream may, for example, be nearly equivalent to an independent TCP connection."
Edit:
And this...
"Pairs of IP addresses and sockets are finite resources. Today, too many distinct connections are routinely made between clients and servers, utilizing a multitude of sockets, and often carrying redundant information. A multiplexed transport has the potential for unifying the traffic and reducing the port utilization count. A multiplexed transport can unify reporting and responses to channel characteristics (packet loss, etc.), and also allow higher level application protocols (such as SPDY) to reduce or compress redundant data transmissions (such as headers). In the presence of layer-3 load-balancers, a multiplexed transport has the potential to allow the different data flows, coming and going to a client, to be served on a single server."
Compared to HTTP things like QUIC make perfect sense - especially when you consider all the RTT wasted on pipelined connections to the same site. You're only opening all those sockets because they're not multiplexed in any manner - your browser wants a JPG, grab the JPG. Your browser wants another, do it again...
So while this is light hearted, there's some validity to next gen web protocols that are more adapted to how the data is consumed.