4 ms·

> 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 requ

by lispm 12y ago

> 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.

currysausage 12y ago
> 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 12y ago
  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 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 12y ago
    Considering the best practice for HTTP/1.1 is to create few very large files - why would compressing headers really make a difference?
    - sp332 12y ago
      "Best practice" can take a lot of work and often doesn't happen in real life. HTTP/2 gets you this advantage for free.
    - rakoo 12y ago
      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.
    - MichaelGG 12y ago
      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 12y ago
      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 12y ago
  The body, but not the headers, right? Does http2 also compress headers?
  - treve 12y ago
    It does
sargun 12y ago
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.
treve 12y ago
HTTP 1.1 supports pipelining requests but in reality it's disabled everywhere.
reissbaker 12y ago
> 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 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 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.

by lispm 12y ago

currysausage 12y ago

> 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 12y ago
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 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 12y ago
  Considering the best practice for HTTP/1.1 is to create few very large files - why would compressing headers really make a difference?
  - sp332 12y ago
    "Best practice" can take a lot of work and often doesn't happen in real life. HTTP/2 gets you this advantage for free.
  - rakoo 12y ago
    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.
  - MichaelGG 12y ago
    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 12y ago
    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 12y ago
The body, but not the headers, right? Does http2 also compress headers?
- treve 12y ago
  It does

sargun 12y ago

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.

treve 12y ago

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

reissbaker 12y ago

> 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 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 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.