HTTP/2 is not the future, it’s the present

http://blog.eleven-labs.com/en/http2-future-present/

by Eleven_Wilson • 9 years ago

185 108 9 years ago

blog.eleven-labs.com

merb3• 9 years ago

and it's not as good as it could've be. the statefulness makes it really really really really really akward.

blowski• 9 years ago

I haven't worked with HTTP2 much - I thought it was still stateless. Are you referring to HPACK?

merb3• 9 years ago

http://httpwg.org/specs/rfc7540.html#StreamStates

sametmax6• 9 years ago

HTTP2 has been created for big players. When you are a small team, benefits from it are not that interesting. Plus mandatory TLS is making boostraping a project unnecessary hard.

fredsir• 9 years ago

If you mean bootstrapping a webservice-project, I don't believe it's hard in any way. With offerings like Lets Encrypts, it's incredibly easy and takes no more than 20 minutes.

acjohnson55• 9 years ago

So, don't use it. It's not as though you're being forced to upgrade.

frik3• 9 years ago

You are right. More and more propaganda these days to steer the crowd to things were only the top players benefit. HTTP 0.9/1.x with or without TLS (aka HTTPS) is still relevant. And making TLS mandatory is a very bad decisions, it will hurt every dev who had to touch lower level APIs or do performance optimization or debugging a lot. Sometimes it would help to think a bit father then ones nose is long.

olavgg• 9 years ago

Agreed, I think PHK nails his concerns here: https://www.varnish-cache.org/docs/trunk/phk/http20.html

merb3• 9 years ago

btw. I don't talk about the forced TLS stuff. besides I'm working in a company who sells boxes for intranet's (where deploying TLS for domains is not always easy, lack of proper DNS or other things, etc...)

The spec has just a lot of edge cases especially when handling state/what exactly is a specification violation. Especially handling clients who opened a connection and now are in closing state, can be really really tricky to handle. On the implementation side the Statefulness adds a lot of overhead, that HTTP/1.1 did not had (besides other flaws) I think HTTP/2 was a little bit rushed, but I guess HTTP/3 will clean up some stuff.

rita3ko2• 9 years ago

It's not Eleven-Lab's present, seeing as they don't support HTTPS, and HTTP2 doesn't work without it.

lumisota2• 9 years ago

The standard [1] doesn't require the use of TLS/HTTPS. However, all of the major implementations only support HTTP/2 over TLS.

[1] RFC7540 - https://tools.ietf.org/html/rfc7540

rita3ko2• 9 years ago

Correct, "all of the major implementations" :)

jajern• 9 years ago

I think you should usually practice what you preach. I did a HTTP/2 test on their server and it doesn't support it.

magicbuzz• 9 years ago

To be clear, Server Push as described in the article is not actually provided by nginx yet and thus by the server config in the article. I have no doubt that the awesome nginx folks will implement in due time though.

avichalp• 9 years ago

Its implementation is already present in nginx plus since 2015. https://www.nginx.com/blog/http2-r7/ Not sure if they are going to provide server pushes in the community version soon.

juliangoldsmith2• 9 years ago

From your link:

The “Server Push” feature defined in the HTTP/2 RFC is not supported in this release. Future releases of NGINX Plus might include it.

pcollins1232• 9 years ago

I'm not sure they will ever implement it actually. Nginx does not support HTTP/2 server push as of March 2017 (v1.11).

Owen Garrett at nginx has summarized the reasons as follows:

- it is a non-essential and optional part of http/2

- if the client already has the resource cached, then by pushing it to them you might be unnecessarily wasting bandwidth.

- server push spec might change in the future.

- Link headers as hints is useful, but usage has been low from web developers.

- server push has been available as part of SPDY and was not utilized by many web developers.

Read his original comments here[1]. This table[2] accurately describes the pro's and con's of server hints vs server push.

Personally this disappoints me because I think this would be a valuable feature for web developers willing to invest the time to optimize page speeds. I also know that some large CDN's like Cloudflare have implemented their own version within nginx to optimize page downloads.

[1] https://www.nginx.com/blog/http2-r7/

[2] https://www.chromium.org/spdy/link-headers-and-server-hint

yoavm• 9 years ago

This just made me add the 'http2' directive to my Nginx configs, and it seems that I'm getting a 15% decrease of loading time for my websites. Should have done this long ago...

pixl976• 9 years ago

Just to be sure, use a site like ssllabs.com to make sure you are actually using an ALPN. For example on Ubuntu 14, setting http2 does nothing, as it requires Openssl 1.0.2. If you are using Ubuntu 16, or a distro that provides the newer Openssl it should work correctly.

Dylan16807• 9 years ago

It's quite useful, I just wish it wouldn't segfault my apache processes.

solidr53• 9 years ago

Can somebody ask mr. Heroku why they don't support it...

6t6t6t63• 9 years ago

You should probably not be serving a site directly from Heroku anyway. Put Cloudflare in front of your Heroku and you will get HTTP2

TazeTSchnitzel2• 9 years ago

Remember, in may 1996, the very first HTTP protocol version (HTTP/1.0) was born.

Uh, what? HTTP predates 1996. The first version was HTTP/0.9, from 1991. 0.9 is still supported by a lot of web servers, too!

hdhzy• 9 years ago

And browsers! Causing interesting bugs: https://bugs.chromium.org/p/chromium/issues/detail?id=669800

kupiakos• 9 years ago

Wow, that's a disaster. Hopefully it was a wake-up call to the Shoutcast administrators to not depend on 10+ year old software that doesn't follow actual standards.

yes_or_gnome• 9 years ago

Personally, I've found it hard to find much information about pre-HTTP/1.0. To my understanding, "HTTP/0.9" is a retroactive version number. The original HTTP protocol was incredibly simple. An HTTP Request was simply "GET /", then the response was just the content immediately followed by a closed connection. There were no headers.

"HTTP/0.9" is used to describe the implementations of "HTTP/1.0" before it was -- for lack of a better word -- 'ratified'.

If you, or anyone, has more information or analysis of pre-HTTP/1.0 protocol implementations (client or server), I would be very interested in reading it.

Also, if there is a public, pre-HTTP/1.0 HTTP server available on the internet, I would very much like to check it out.

Thanks.

Edit: Alternatively, if it's possible to run an pre-HTTP/1.0 server (or client), that would be phenomenal. It only occurred to me after making the comment, however I highly doubt that it would be a simple process to get one running. I suspect that I wouldn't be able to spin a Docker container with some ancient version of Apache (I assume due to changes in the Linux environment, shared libraries, changes to gcc, etc.), but possibly, a VM running an equally-ancient version of Red Hat (pre-EL) would do the trick.

TazeTSchnitzel2• 9 years ago

This is the only reference I've known: https://www.w3.org/Protocols/HTTP/AsImplemented.html

It's a little more sophisticated than GET /, as you can also specify a full URL.

Also, if there is a public, pre-HTTP/1.0 HTTP server available on the internet

Most HTTP/1.0+ web servers still support HTTP/0.9. I don't know of any 0.9-only servers though, but there's probably some.

cagenut• 9 years ago

Anyone combining h2o and node in interesting ways they'd like to share/blog-about yet?

cflat• 9 years ago

As I've said previously [1][2][3], you shouldn't PUSH with `Link re="preload"` for performance gains. You will likely run into TCP HOL Blocking or browser request race conditions. Instead send PUSH_PROMISES in the whitespace while the client waits for the TTFB.

[1] https://news.ycombinator.com/item?id=14082636 [2] https://shouldipush.com [3] https://youtu.be/GjWD1pOkxUk?t=1534

webo• 9 years ago

Is the common pattern to support http2 at the highest level?

If a request goes through CDN/edge network -> Load Balancer -> nginx -> Python app, should http2 be enabled on all components or is enabling just on the CDN enough? Any pros/cons?

With HTTPS, usually enabling on the CDN is good enough for most cases.

bluejekyll3• 9 years ago

That will only get you the protocol. All of the server push stuff for example, needs to be supported by the actual web server.

luhn• 9 years ago

No, a CDN can support HTTP/2 server push on it's own. For example, https://www.cloudflare.com/website-optimization/http2/server...

predakanga2• 9 years ago

That's not correct - while any HTTP/2 capable servers along the path may implement server push, the most important one is the closest server to the user (i.e. the CDN). The only requirement is that the intermediate servers must not strip out the server push headers/tags, so that the edge server knows what to actually push.

It's quite possible to have your own server provide HTTP/1.1 and still take advantage of server push, and this is a usecase supported by Akamai[1], Cloudflare[2], and I suspect other CDNs (can't find details) - you may get better performance using HTTP/2 on that intermediate link, but that's less likely to be because of server push.

[1] https://blogs.akamai.com/2016/04/are-you-ready-for-http2-ser... [2]: https://blog.cloudflare.com/announcing-support-for-http-2-se...

predakanga2• 9 years ago

Enabling HTTPS on the CDN is good for the users, but please consider using it between the CDN and your network as well - if nothing else, it prevents situations like this: https://medium.com/@karthikb351/airtel-is-sniffing-and-censo...

6t6t6t63• 9 years ago

I'd like to see a web framework that implements well HTTP2.

AFAIK, the Assets Pipeline in Rails is not designed for HTTP2 and I think that there are no immediate plans to implement it.

chucke2• 9 years ago

AFAIK, the Assets Pipeline in Rails is not designed for HTTP2...

Not true. You can define as many manifests as you want, and design your own heuristics around resources in rails. It doesn't need to be an HTTP feature.

You have to patch rails to fill up the link header with the assets however. If you do it, proper reverse proxies like h2o can serve assets using server push.

6t6t6t63• 9 years ago

You have to patch rails

That sounds like a bad idea in the long term... ;)

daphreak• 9 years ago

While I look forward to a faster desktop and mobile browsing experience with HTTP/2 I do worry about the complexity. I hope that the simpler protocols remain supported for a long time to enable implementations on low resource embedded systems.

The last thing we need is for all the closed-source, internet-connected, black boxes in our lives to poorly implement a complicated web standard protocol. There are so many places where we have already seen vulnerabilities with implementations of simple web severs and clients.

MichaelGG2• 9 years ago

What looks particularly complex about HTTP/2?

The "simple" text based protocols are NOT simple to implement correctly. Go try out line-wrapping and play with using \r\n vs \r vs \n as line endings and tell me what the compatibility ends up like.

And this does create real-world security problems. Some VoIP companies allow you to make free calls by screwing with their SIP proxies because popular software handles line endings differently allowing you to make their edge software interpret packets differently than their core.

Even parsing is easier in a nice binary format (and much, much, faster, too).

ris• 9 years ago

It's not got much to do with the serialization protocol itself as such - most server software uses a library which handles it properly and then doesn't have to worry about it. It's more that web developers have to get bits of their stack (the dynamic and static serving aspects) to cooperate in ways they never had to before (in fact, the general wisdom was to separate them as much as possible as they have totally different requirements when it comes to performant serving).

This is not even to get into persistent connections & server push etc., which is quite a big subject for developers used to handling independent fire-and-forget requests.

I guess I'm saying the massively complexity comes in trying to use these new features.

KirinDave3• 9 years ago

I'd like to go further: HTTP/2 is the present not just for content serving, but could be for APIs.

Right now, everyone who's supported both mobile and web APIs (or cared about bandwidth constraint) can tell you how frustrating it is that well factored restful (or rest-ish) APIs are often the casualty of accepting the realities in mobile client support. You end up increasingly collapsing requests into one Special Bigger Request because One Special Bigger Request almost always has better performance on bandwidth-constrained clients than the same performance elsewhere.

And this is especially frustrating because often times the client can't tell us exactly what they need in the initial request. The best we often can do is stash an etags header in the request and try and get very fancy there. We end up with smarter endpoints which require tons more programmer maintenance, and move us away from the world of autogenerated and automatically audited endpoints.

HTTP/2 w/ Push offers us a way to split the difference. While individual endpoints can be served very quickly, we can have our APIs recognize (via etags, probabilistic inference, previous negotiation, etc) that more data is about to be requested and push it immediately.

This means we can keep our well-factored, simple API designs that we developed 10 years ago without sacrificing performance to the bandwidth-constrained. It means that we can further lean on the abstraction Service Worker gives us in web clients to just naively poll in client code and trust in clientside caching to make this efficient (with the fallback being the same network call we would have always made).

It's why I'm absolutely infuriated with so many languages for balking at supporting HTTP/2 as part of their stack (more often than not, on the grounds that SSL + ALPN seems tedious to implement).

renke1• 9 years ago

I agree with everything you said.

One thing though, I think "One Special Bigger Request" still makes sense in a lot of situation where you have some kind of "transaction" going on. I often encountered code that calls multiple HTTP endpoints and a failure in one of those requests would actually lead to inconsistent data in the backend. This code is pretty common because many developers assume that requests never fail.

KirinDave3• 9 years ago

Transactional mutations have to have a commit phase. I agree.

shanemhansen• 9 years ago

I think that within a datacenter, a bunch of microservices make sense. When communicating with a customer, you want to craft just the data they need and minimize roundtrips.

GraphQL seems to be a great candidate for bridging this gap. I recommend using graphql to allow clients can use to make "One Special Bigger Request" which then gets split into multiple requests on the backend.

KirinDave3• 9 years ago

I see no reason why this isn't compatible with gql. But even then, gql is hard to architect right unless you fence off a rather minimal subset of it.

derefr• 9 years ago

The thing about One Special Bigger Request is that it isn't cacheable. GraphQL is no exception: https://philsturgeon.uk/api/2017/01/26/graphql-vs-rest-cachi...

If you want network-level caching, you want multiple atomic resource requests. HTTP2 enables this.

tootie• 9 years ago

HATEOAS + Server Push would be beautiful.

chucke2• 9 years ago

I'd like to go further: HTTP/2 is the present not just for content serving, but could be for APIs.

Very true. The talk around around server push has suffered a bit from tunnel-vision, only taking browser-media delivery into account, making it look like a browser feature only.

HTTP2 + server push can actually make GraphQL less relevant, same way that there hasn't been talk around supporting websockets in it (it just doesn't look necessary anymore).

But for all this to happen, server push needs to become cacheable. And I really hope that the cache digests rfc takes off and gets more implementations.

_m8fo• 9 years ago

Can someone recommend an up-to-date book/guide on HTTP(2)? I'm thinking this may do: https://http2.github.io/, but I'm not sure if that's the best guide.

Much of the jargon in the comments is unknown to me. The article in the OP is a good start.

shurcooL• 9 years ago

I've learned most things about HTTP/2 from talks given by Brad Fitzpatrick. Go's HTTP/2 support in standard library was largely implemented by him.

spankalee• 9 years ago

For those interested in HTTP/2 Push, check out Eric Bidelman's Push Manifest format[1], which is a JSON format describing the dependencies to push for any request URL. You can generate the manifest by hand or with tools, and then there are servers that can read the manifest and push the right resources.[2]

In Polymer we're most of the way done with support for automatically generating push manifests from a dependency analysis of your project[3] and have push manifest support in our dev server and soon a small production server, so you can `polymer deploy` and get a push-enabled site.

[1] https://github.com/GoogleChrome/http2-push-manifest

[2] https://github.com/GoogleChrome/http2push-gae

[3] https://github.com/Polymer/polymer-build/pull/172

pcollins1232• 9 years ago

This is really interesting thanks.

Doesn't this lead to the most highly used static assets being pushed for every subsequent request? Isn't that wasteful?

I use varnish cache extensively and am considering writing a probabilistic server push module. It could keep track of subsequent requests and push the next set of assets. This is more of a server module approach rather than client side.

Any thoughts on that?

ElijahLynn• 9 years ago

Worth watching: https://www.youtube.com/watch?v=CkFEoZwWbGQ (HTTP/2: What no one is telling you by Hooman Beheshti @ Fastly)

tldr; H2 can be slower than H1.1 under degraded network connections. e.g. mobile connections with high packet loss.

treve• 9 years ago

It's here, but current server-side implementations are super weak. rel="preload" is a hack. Only the few languages that have a native HTTP 2 push api are really here.

HTTP/2 is not the future, it’s the present

Related Stories