Slashdot Mirror

← Back to Stories (view on slashdot.org)

HTTP/2 Finalized

Posted by Soulskill on from the onward-and-upward dept.

An anonymous reader writes: Mark Nottingham, chair of the IETF HTTP working group, has announced that the HTTP/2 specification is done. It's on its way to the RFC Editor, along with the HPACK specification, where it'll be cleaned up and published. "The new standard brings a number of benefits to one of the Web's core technologies, such as faster page loads, longer-lived connections, more items arriving sooner and server push. HTTP/2 uses the same HTTP APIs that developers are familiar with, but offers a number of new features they can adopt. One notable change is that HTTP requests will be 'cheaper' to make. ... With HTTP/2, a new multiplexing feature allows lots of requests to be delivered at the same time, so the page load isn't blocked." Here's the HTTP/2 FAQ, and we recently talked about some common criticisms of the spec.

1 of 171 comments (clear)

  1. Re:Not really happy by raxx7 · · Score: 5, Informative

    You might be happier if you researched why HTTP pipelining is off in most browsers and what problem it actually wants to solve.

    First, HTTP/1.1 pipelining and HTTP/2.0 are not about increasing the number of request your server can handle. It's mainly about reducing the effect of round trip latency in page loading times, which is significant.
    If a browser is fetching a simple page with 10 tiny elements (or even cached elements subject to conditional GET) but the server round trip latency is 100 ms, then it will take over 1 second to load the page.

    HTTP was a first attempt to solve this problem, by allowing the server to send multiple requests over the connection without waiting for the earlier requests to complete.
    If you can pipeline N requests, the round trip latency contribution is divided by N.
    However, HTTP/1.1 pipelining has two issues which led most browsers to disable it by default (it's not because they enjoy implementing features not be used):
    - There are or were a number of broken servers which do not handle pipelining correctly.
    - HTTP/1.1 pipelining is subject to head of line blocking: the server serves the requests in order and a small/fast request may have to wait inline behind a larger/slow request.

    Instead, browsers make multiple parallel requests to each server.
    However, because some servers (eg, Apache) have problems with large numbers of requests so browsers use arbitrary low limits (eg, 4-8 parallel requests per hostname).

    HTTP/2.0 attempts to solve these shortcomings by:
    a) being new, hopefully without broken servers out there
    b) using multiplexing, allowing the server to serve the requests in whatever order. Thus, no head-of-line blocking.

    So. HTTP/2.0 is, fundamentally, HTTP/1.1 pipelining without these shortcomings. We hope.