Http2 explained

http://daniel.haxx.se/http2/

by antouank • 11 years ago

180 65 11 years ago

daniel.haxx.se

otterley5• 11 years ago

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.

Lukasa3• 11 years ago

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.

bwross• 11 years ago

Additionally, a TCP connection is essentially an operating system resource; you need to set aside a port and space for a send and receive buffer. It might seem fine for a client to open hundreds connections, but imagine being a server with thousands of clients all opening hundreds of connections to you. You very quickly run out of resources and either have to close connections or reject new connections.

bsdetector2• 11 years ago

If you start out making 6 TCP connections then in a perfect network their receive windows all expand in parallel -- 6 times faster than a single HTTP2 connection. You're likely to see several HTTP2 connection made as well. There'll at least be a second one in case the first SYN is lost, just like with HTTP 1.

The key TCP benefit is keeping a connection open. That can be done with keep-alive as well.

jude-5• 11 years ago

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.

otterley5• 11 years ago

I don't buy the congestion-control argument. Transit routers have millions of connections going through them at any given point. What's an extra 10x in concurrency to them?

youngtaff• 11 years ago

Will Chan of Chromium wrote a good post explaining the congestion issues with opening many TCP connections - https://insouciant.org/tech/network-congestion-and-web-brows...

otterley5• 11 years ago

His test showed what happens on a slow network - too much parallelism leads to retransmits and congestion on a slow network. But it doesn't show ill effects on a fast network with plenty of bandwidth.

The question is how to get it right, and the problem is that you can't get it right without knowing the amount of bandwidth available to you in advance. Limiting concurrency limits congestion on slow networks, but it caps you unnecessarily on fast ones. The same is true for SPDY/http2; using a single stream will never give you the same concurrency as multiple streams.

patrickmcmanus6• 11 years ago

The first answer is that parallelism without priority (which is what parallel h1 is) can lead to some really horrible outcomes. Critical pieces of the page get totally shoved out of the way while bulky, but less important parts, get the bandwidth they need.That's why H2 and SPDY are both mux'd and prioritized.

also you can definitely over-shard with h1.. as said downthread that can cause congestion problems and indeed even packet loss. For a little while pinterest had gigantic packet loss problems that were due to over sharding of images.

The really annoying thing is that the "right amount of sharding" has to do with available bandwidth, the size of the resources being sent, and the latency between client and server.. Those things aren't really knowable on a generic per-origin basis when setting your links up - so the spdy/h2 approach works better in practice.

if I had a criticism here, its that implementing priority right is a lot trickier than just have a bunch of independent connections. We will probably see some bad implementations in the early days until folks internalize how important it is.

jerf2• 11 years ago

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

Lukasa3• 11 years ago

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!"

Lukasa3• 11 years ago

Ah, sorry, I misread your question! I don't actually know the lengthy reasoning for that edge case. =(

ashmud• 11 years ago

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?

pluma• 11 years ago

Basically, in HTTP 1.x there are only very specific times at which the server can respond throughout a request. In particular, there's no way to tell a client "please stop" when it is transmitting the request body.

So how most web applications handle request bodies that are too big is to either kill the connection (which to the client looks like a network issue) or patiently pipe the entire message to /dev/null before sending a response that indicates the message has not been processed (e.g. HTTP 413).

Unless I'm mistaken, this can be avoided if the client sends an honest Content-Length header, but this only works if the size is known in advance and the client is honest (you could submit an arbitrary number of bytes with a Content-Length header indicating something much smaller).

Because there is no clear way to distinguish a server aborting a request mid-body because of the size versus spontaneous existence failure, a client might misinterpret that and attempt to re-submit the same request later.

iso8859-1• 11 years ago

Most requests are GET, how would Content-Length help there?

stusmall• 11 years ago

"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• 11 years ago

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

bsdetector2• 11 years ago

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.

bch• 11 years ago

"clearly some actors on the Internet today seem to be confident that IETF will do good without these companies being involved"

That's impossible to believe. Now I wonder -- what's the _real_ reason ?

nly• 11 years ago

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.

patrickmcmanus6• 11 years ago

otoh - http on sctp on ipv6 with ipsec hasn't really moved the internet forward.

necubi• 11 years ago

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.

testrun• 11 years ago

I think he/she is not talking about the transport protocol (TCP/UDP), but the higher up layers (5 - 7) cramming functionality from the lower layers. Might be reading it the wrong way.

serge2k• 11 years ago

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.

jtokoph• 11 years ago

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?

derefr4• 11 years ago

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.

jude-5• 11 years ago

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.

derefr4• 11 years ago

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-5• 11 years ago

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.

pdkl95• 11 years ago

It is never a good idea to assume that a can opener[1] will always be available. While your decoder - an extra tool - may be available in "many" cases, there will always be a sizable minority of cases where it isn't. As the performance benefits of fixed-width fields are orthogonal to the fields being ASCII-vs-binary.

SCTP / "transport-layer protocol"

So we move yet another step down the path of obsoleting TCP port numbers by adding another layer of indirection[2]. Re-implementing ports by tunneling everything over HTTP{,2} was a bad idea when it started over a decade ago, and it's still the wrong way to solve the problem.

[1] http://en.wikipedia.org/wiki/Assume_a_can_opener

[2] See RFC 1925, Section 2, rule 11a. ( https://tools.ietf.org/html/rfc1925 )

muppetman• 11 years ago

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

geographomics• 11 years ago

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.

bagder2• 11 years ago

As the author of the document - thanks!

gaastonsr• 11 years ago

Beautifully written, thanks for this.

teddyh• 11 years ago

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

djhworld• 11 years ago

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 :(

Mojah• 11 years ago

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/

gremlinsinc• 11 years ago

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.

Http2 explained

Related Stories