[lispm]

> It can leave the connection open for re-use for very extended periods of time, so there's no need for that costly handshake that HTTP1 requires for every request.

HTTP1 supports pipelining requests.

> HTTP2 also uses compression, unlike HTTP1, and so the size of the request is significantly smaller - and thus faster.

'significantly'? How much is that?

> HTTP2 multiplexes; it can send and receive multiple things at the same time over one connection.

If that one connection stalls, multiple things won't be transferred.

Plus it introduces new protocol overhead.

[treve]

HTTP 1.1 supports pipelining requests but in reality it's disabled everywhere.

[currysausage]

> HTTP2 also uses compression, unlike HTTP1, and so the size of the request is significantly smaller - and thus faster.

Also, an HTTP/1.1 server, when configured properly, will use compression as well.

[jomohke]

It does support compression of the message body, but not of the headers.

They designed a new compression algorithm called HPACK specifically to compress headers in HTTP2: https://http2.github.io/http2-spec/compression.html

In small HTTP/1.1 requests the headers can be much larger than the content, which is part of the motivation for combining files into one request.

[Illniyar]

Considering the best practice for HTTP/1.1 is to create few very large files - why would compressing headers really make a difference?

[rakoo]

HTTP/2.0 does not only compress headers, it also keeps a context of headers that were already sent. So if you want to include a specific header with the same value in multiple requests (like, say, a cookie), it won't actually be re-sent on the wire. The other side will know that the value hasn't changed.

[sp332]

"Best practice" can take a lot of work and often doesn't happen in real life. HTTP/2 gets you this advantage for free.

[MichaelGG]

If the headers are big enough, then you may need multiple packets to transmit the request.

Also, some TCP stacks (or an extension option?) will allow data in the first packet, so you don't have to wait for the handshake. Perhaps this doesn't work if the data doesn't fit in a single packet?

[michaelmior]

Aside from the other responses to this comments, this goes towards making HTTP2 requests cheap which enables a lot of other optimizations that were antipatterns under HTTP/1.1

[fideloper]

The body, but not the headers, right?

Does http2 also compress headers?

[treve]

It does

[reissbaker]

> HTTP1 supports pipelining requests.

Head-of-line blocking makes the HTTP/1.1 pipelining perform poorly. Multiplexing is a more performant solution than pipelining.

Here's some worthwhile reading on the subject: http://http2.github.io/faq/#why-is-http2-multiplexed

> 'significantly'? How much is that?

Depends. In HTTP/1.1 request headers weren't compressed, and you generally have a ~1500 byte limit for a request to fit in a single packet. If you crossed that threshold, and if compression brings you back under (it certainly might), you could see 2x or better perf gains on time-to-first-byte depending on how many packets your initial request was being broken into.

> If that one connection stalls, multiple things won't be transferred.

While true, it's still often easier to optimize a single saturated connection than multiple ones for a variety of reasons (slow start, congestion, etc). More reading on the subject: http://http2.github.io/faq/#why-just-one-tcp-connection

Personally I'm really excited about HTTP2 being deployed. It makes the web fast by default — no need to concatenate or domain shard once it's widely deployed — and adds extra opportunities for performance (e.g. server push) that we haven't seen yet.

[sargun]

RE: The last one

QUIC is a solution for that - It's Google's answer to TCP, and dealing with multiplexed connections. I recommend taking a look.