

Http2 explained - antouank
http://daniel.haxx.se/http2/

======
geographomics
At the risk of not being quite critical enough for HN - that was an excellent
read.

Clear explanations, a very pleasant layout, and useful visual metaphors for
the trickier parts of the spec. I found it to be both enjoyable and
informative.

A really nice example of documentation done well.

~~~
bagder
As the author of the document - thanks!

------
nly
> 8.4.6. “It has layering violations”

> Seriously, that's your argument? Layers are not holy untouchable pillars of
> a global religion

If layers aren't 'untouchable pillars', then why have we not fixed the ones we
have? IPSec, IP, TCP and TLS are all a jumbled rotten mess. Poor layering has
resulted in a lot of warts like inefficient or underleveraged handshakes and
the lack of things like mobility, multi-homing, authentication, reliable
datagrams and stream multiplexing. What is really being said here is _yes_ ,
the layers we have (TCP, NAT) _really are_ untouchable pillars.

Cramming workarounds in to a higher, application-specific, layers doesn't
benefit the wider Internet.

~~~
necubi
Good luck getting _everybody_ to upgrade their kernel to support your new
transport protocol. Realistically, UDP and TCP are what we have. We may wish
they were more suited to modern use cases, but realistically we must build on
those foundations. If that means violating "layering" for performance, so be
it.

~~~
serge2k
Maybe instead of the "good luck" attitude we should start pushing an "upgrade
or suffer" attitude.

Seems far more reasonable than letting things stagnate for years. It's what
chrome is doing with sha1 certs.

Give a timeframe, if you don't get your upgrade in then too bad.

~~~
mobiplayer
Google can push that because there's a huge user base with Chrome and you
don't want your shiny ecommerce site to be marked as not safe by Chrome, do
you?

On the other hand, the packets moved through the wires to send this comment to
HN and the ones moved to send this comment to your computer are easily managed
by dozens of different people and a handful of different companies with
different agendas, budgets, needs and even skills. Cisco definitely
manufactured and sold most of the devices out there, but they surely don't
manage them or decide when they're upgraded. It gets worse, because actually
there's not only Cisco out there.

I'm not saying it can't be done, but just look at the slow IPv6 adoption,
despite the efforts of all the big players (Google, Cisco, Juniper, Microsoft,
Linux, ... !) supporting it in a timely manner, it's still not there.

~~~
gsnedders
Also remember that everything Google has ever pushed through has been _above_
UDP/TCP, because it's _far_ easier to push through changes on top of that than
not. There's a reason why QUIC is being developed on top of UDP instead of as
a transport layer in its own right.

------
jerf
"One of the drawbacks with HTTP 1.1 is that when a HTTP message has sent off
with a Content-Length of a certain size, you can't easily just stop it. Sure
you can often (but not always – I'll skip the lengthy reasoning of exactly why
here) disconnect the TCP connection"

Can someone give me more of a hint of that reasoning so that I can at least
search for it? I'm intrigued, but the search terms I'm trying all come back
with explanations of why you might need Content-Length, a different issue.

~~~
Lukasa
Sure. The only way to stop a message before the content-length is transmitted
is to kill your TCP connection. This is inefficient: you need to recreate it,
bearing all the TCP set-up cost all over again, and then deal with the small
initial congestion window on your new connection.

HTTP/2 allows you to avoid that by saying "I'm done with this stream now,
sorry!"

~~~
ashmud
How do web browsers handle cancelled requests? Subjectively speaking, it feels
like browsers can take a while to recover from cancelling the loading of a
large page/page with a large number of assets. Could this be part of that?

~~~
patrickmcmanus
you're right. Cancel's in H1 are very painful because all the in-progress
transactions have to be torn down completely. New transactions have to set
them all up again.

H2 let's you just send the server a short message that says "stop sending that
stream" and you can go ahead and pipeline a new request right along with that
cancel.

This happens a lot more than you think as you browse through a collection of
things and are just scanning them and clicking the next button - that's a
really common use case h2 will handle much better.

------
stusmall
"Some of the bigger players in the HTTP field have been missing from the
working group discussions and meetings. I don't want to mention any particular
company or product names here, but clearly some actors on the Internet today
seem to be confident that IETF will do good without these companies being
involved..."

I haven't been following this much, who is he referring to?

~~~
mongol
Probably Apple, there is another mention of them later on in the document.

~~~
bsdetector
Could be. Mobile Safari uses pipelining, so for Apple there's not a lot of
benefit from HTTP2. It isn't a big enough deal for them to push a new
protocol, like it is to say Google that doesn't have pipelining in their
browser.

~~~
bagder
Sorry, but that doesn't make a lot of sense. Pipelining is far from a
replacement for HTTP/2 as the document explains a bit. Besides, Safari already
supports SPDY because of this.

------
otterley
I'm still not entirely sure why the problems inherent in single-stream
connections (request/response) couldn't be solved simply by removing the
artificial RFC-recommended limitation on parallel connections to a server. As
the author says, providers have been escaping this limitation for years by
simply adding hostname aliases, but has nothing negative to say about it.

Modern HTTP servers are highly concurrent; allowing 100 connections per
request doesn't seem like a problem nowadays. And doing so would solve 99% of
the browser performance problem without introducing a significantly more
complicated multiplexing protocol.

~~~
Lukasa
Because running multiple TCP connections in parallel plays havoc with TCP
congestion control and also plays poorly with the TCP slow-start logic. Every
TCP connection begins its receive window again and so it starts small, so
fetching many moderately-sized or large resources (think images) will cost you
many round trips you didn't need to spend.

~~~
jude-
Moreover, it's bad from a QoS standpoint. Opening many TCP streams in parallel
is not fair to other users sharing the routers between you and the server.
You'd get more than your fair share of bandwidth.

~~~
otterley
Only if you don't assume that everyone else will also use the same number of
streams in parallel. If everyone else's utilization is increased by the same
factor, the utilization balance should remain the same.

~~~
jude-
The goodput decreases for everyone then, since each flow requires a 3-RTT
handshake and 1-2-RTT tear-down. This is particularly bad if you're starting
up a lot of small flows, where the control-plane information becomes a non-
negligible fraction of the total data sent.

I think ideally, we'd create a TCP variant where localhost maintains a per-
destination receiving window for all flows to that destination, so flows
running in parallel or flows started in rapid succession won't have to start
their windows at 0 and slowly increase them. Moreover, this way congestion
control applies to all packet flows for a (source, destination) pair, instead
of to individual flows.

HTTP/2 and HTTP pipelining take a crack at this by running multiple
application-level flows (i.e. HTTP requests) through the same receiving window
(i.e. the same TCP socket), but they're not the only application-level
protocols that could stand to benefit.

------
jtokoph
Does anyone know how WebSockets fit into the http2 world? Will we just end up
using http2 server push and the rest of the protocol as a substitute for
WebSockets?

~~~
derefr
WebSockets were always _intended_ for only one specific thing—allowing web
browsers and web servers to speak connection-oriented, stateful wire protocols
(like IRC or IMAP) at one-another over an HTTP tunnel.

Any other usage than this has been merely a _polyfill_ for lack of
efficiently-multiplexed or easily-server-initiated messaging.

Given an efficiently-multiplexed, bidirectional-async messaging channel in the
form of HTTP2, WebSockets can fall back to just being for what they're for,
and we can relegate their polyfill usage to the same place Comet "async
forever iframes" have gone.

------
Mojah
If anyone is looking for a practical guide to using HTTP/2, what changes it
will bring compared to HTTP/1.1 in terms of architecting websites and web
applications, I've written a guide on that: [http://ma.ttias.be/architecting-
websites-http2-era/](http://ma.ttias.be/architecting-websites-http2-era/)

------
gremlinsinc
Wow - was expecting something scary, super technical and over my head - very
easy overview - not that I'm not technical I do server support for a huge web
hosting firm - but sometimes http docs get way too tech spec --this was very
clear to understand.

------
djhworld
Is there a "one page" HTML version of this? I tend to read stuff on my phone
via apps like Instapaper etc, PDFS don't really suit mobile devices :(

------
muppetman
I find it amusing that the document that explains HTTP2 is a PDF I have to
download. There's no HTML version.

(Yes, I'm aware that HTTP != HTML.)

------
teddyh
Still not even a _mention_ of SRV records in the “critiques” section. I’m more
saddened than surprised, really.

------
gaastonsr
Beautifully written, thanks for this.

------
jude-
> 8.4.4. “Not being ASCII is a deal-breaker”

> Yes, we like being able to see protocols in the clear since it makes
> debugging and tracing easier. But text based protocols are also more error
> prone and open up for much more parsing and parsing problems.

> If you really can't take a binary protocol, then you couldn't handle TLS and
> compression in HTTP 1.x either and its been there and used for a very long
> time.

First, you can have the best of both worlds of fixed-sized frames and human
readability: make sure each HTTP keyword has a finite, short length. ASCII
abbreviations are an acceptable means to this end. This would also eliminate a
lot of the implementation difficulties and performance penalties of writing
and using a parser.

Second, TLS and compression are not integrated into HTTP/1.1, meaning that
people who want to be able to read an HTTP stream on the wire can do so by
disabling these features. It's disingenuous to claim that people don't care
about human readability just because these extensions exist.

~~~
derefr
Why not just have the wire sniffer decode the frames before presenting them.
If you're interested in what's going on at the HTTP level, you aren't reading
packetwise IP packet dumps, because it's hard to make sense of anything and
everything is all mixed together; you're looking at _abstracted, higher-level_
flows, where it's just taken for granted that you have a set of linear TCP
streams.

HTTP2 is a(n SCTPish) transport-layer protocol squished in underneath an
application-layer protocol. Use tools that abstract away the transport-layer
protocol.

Or, just, y'know, disable HTTP2? It's an "optional feature" as much as TLS and
compression are. Everything that speaks HTTP2 also speaks HTTP1.1, just like
everything that speaks compressed/encrypted HTTP also speaks
uncompressed/unencrypted HTTP.

~~~
jude-
> Why not just have the wire sniffer decode the frames before presenting them.

Certainly possible, but why make our lives harder by implementing HTTP/2 such
that it requires a decoder to read in the first place? If the number of bytes
sent remains the same, why not make the fields as self-documenting as
possible?

> Everything that speaks HTTP2 also speaks HTTP1.1

No, they have fundamentally different wire formats. This statement isn't even
true for HTTP/1.1 and HTTP/1.0, which both have the same wire formats and
share many fields but have different interpretations for some of them.

~~~
MichaelGG
>Certainly possible, but why make our lives harder

I cannot imagine anyone that has written a compliant HTTP parser, or attempted
to make a fast HTTP implementation thinking the new framing is _harder_.

As the article mentions, yeah, it would be nice to be able to look through raw
captures. But overall, it's simply too much of a massive downside. It wastes
space and burns CPU for nearly zero benefit.

Text protocols make developers start treating them like text than protocols,
so you end up with a nightmare of things that look ok to humans but introduce
compatibility or security issues when parsing. Even getting line endings right
is a pain.

