The advantage is obvious for Google and the rest of us that run hobby search engines. For example: https://tools.ietf.org/html/draft-tsvwg-quic-protocol-00 htt

The advantage is obvious for Google and the rest of us that run hobby search engines. For example: https://tools.ietf.org/html/draft-tsvwg-quic-protocol-00 https://tools.ietf.org/html/draft-tsvwg-quic-protocol-00 Section 4.3 "A QUIC receiver advertises the absolute byte offset within each stream upto which the receiver is willing to receive data." This is saving the crawler bandwidth by a ton. Limit stuff to 64k and skip all non text data upfront in a very clear cut fashion. 6.2.1.2 prevents hosts spamming you with data after your decided to stop receiving from them. 6.3.2 makes this system fire and forget on a 10m limit and then decide what to do with the host that did or didn't respond with data from the request. 10. Properly download everything from the website (actual priority stuff, central to she protocol, aren't even written, it's a to-do :). All in all, great protocol to help whoever is running search engines. For the rest, won't be the default (they seem to be aware of this in this in 11.5) So trying to guess the future: push quic to Apache/nginx (because 11.5 bypass lots of deployment stuff too), hit websites once and determine who had latest code, cash in on bandwidth. Not bad for a company start. Do we need another protocol? Probably not. Will this see light of day? Probably yes since Google's money are pushing it.