A couple reasons.  Look at these as something HTTP&#x2F;2 does well, but maybe not the best:<p>Head of line blocking is mostly solved.  You can interleave sending big messages with small ones.  You can send control messages (like &quot;Hey, I&#x27;m shutting down soon, don&#x27;t send any more traffic this way&quot;) along with other messages.  The alternative would be using multiple connections, or reimplementing your own version on top of HTTP&#x2F;2.<p>The above is much more useful in the presence of streaming.  H2 has first class support for bidirectional streaming.   It is now feasible to do a stock ticker, or chat room, or whatever over a normal H2 connection, and not have a whole extra protocol or browser work-arounds.  Web sockets work, and hanging GET request work, but they are extra burden.  It would be great if the standard protocol supported it out of the box.<p>TCP Keep alive is not good enough, especially in the presence of Proxies.  TCP Keep alive only goes over the first hop.  It is possible to work around this, but wouldn&#x27;t it be nice if this was part of the spec?  Also, for what it&#x27;s worth, TCP Keep alive only works over TCP.  In the case of not using TCP (like Unix Sockets), what do you send to check round trip time?  What about over shared memory?  Other transports?<p>H2 Header support is pretty useful too.  Sending repetitive headers (like user agent, referrer, auth tokens) is wasteful in H1.1.  Huffman encoding allows you get get back the size of base64 encoded strings pretty easily, so the penalty for having to only use safe characters in your headers.<p>Some people have mentioned that this protocol was designed for making advertising faster.  While this is possibly true, Google is planning on using HTTP&#x2F;2 as its new intra&#x2F;inter-Datacenter RPC transport (See gRPC).  The protocol is good enough to support browsers, mobile, and servers without having to transliterate between protocols.