Slashdot Mirror
HTTP/2 Finalized
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.
I'm really going to miss being able to telnet to a server and troubleshoot using plain text. Feels like a lot of simple has disappeared from the internet
Yes, HTTP/2 is a multipllexing binary framing layer, but it has all the same semantics of HTTP/1.x on top.
HTTP/2 is 'just' an optimization. So if your webserver supports HTTP/1.x and HTTP/2 then you can still use telnet to check whatever you want and it should give the same result as HTTP/2.
But you also have to remember:
The IETF which is the group of people who design the Internet protocol made this statement:
https://www.iab.org/2014/11/14...
"Newly designed protocols should prefer encryption to cleartext operation."
The W3C made a similar statement, there are also drafts with the intention to moving to HTTPS by default.
So it is all moving to TLS protocols like HTTPS or STARTTLS for SMTP anyway. Those are clearly not text protocol either.
So even if you want to interact with the text protocol used inside that TLS-encrypted connection, you'll need to use a tool because netcat or telnet won't cut it.
Let's look at HTTP, because this is a HTTP/2 article.
That tool could be the openssl s_client, but as you can see that is kind of cumbersome:
echo -en "HEAD / HTTP/1.1\nHost: slashdot.org\nConnection: close\n\n" | openssl s_client -ign_eof -host slashdot.org -port 443 -servername slashdot.org
But I suggest you just use:
curl -I https://slashdot.org/
The main developer for cURL works for Mozilla these days and is one of the people working on the HTTP/2 implementation in Firefox and is writing a document explaining HTTP/2: http://daniel.haxx.se/http2/
So as you would expect Curl supports HTTP/2:
https://github.com/http2/http2...
Basically every browser include 'developer tools' which will also let you see the headers and everything else you are used from HTTP/1.x.
I would rather see we all move to using encrypted protocols then that we can still use telnet.
New things are always on the horizon
The main problem isn't the size of the stuff that gets loaded. What's dozens of kb these days? Even a megabyte takes a tenth of a second to transfer on my connection. The problem is latency: it takes more than 100ms for that megabyte of data to even start flowing, let alone get up to speed. That's what the multiplexing is intended to deal with.
That said, the root cause of all this is the sheer amount of unnecessary stuff on pages these days. Fancy multiplexing or not, no request can finish faster than the one that's never made.
And for the http/1.1 pipeline, it simple don't work... 90% of the sites can work with it, but others fail and fail badly... the page take forever to load, waiting for resources that were asked but never received. all browsers tried to enabled it and all had to revert it due to the (few but important) problems founds that are impossible to solve without a huge whitelist/blacklist of servers (impossible to really implement and a pain for all those important and old internal servers)
So the 2 major issues that http/2 want to solve are really the tls slow start and a working pipeline... By announcing http/2, a browser knows that this things do work and are safe to use, no more guessing games and workarounds for bad servers.
Higuita
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.
It's a bandwidth vs latency issue. HTTP1/1.1 is more latency sensitive, HTTP2 helps high latency. You say that pages load slowly because they're so large, yet these large bloated web pages consume nearly no bandwidth. HTTP2 multiplexing allows async requests and preemptive pushing of data, which should allow better usage of bandwidth. Fewer connections will also allow for quicker TCP relieve window ramp up and reduce the thundering hurd issue that many connections over a congested link creates.