HTTP/2 is here. Goodbye SPDY? Not quite yet

https://blog.cloudflare.com/introducing-http2/

by akerl_ • 11 years ago

267 69 11 years ago

blog.cloudflare.com

ropiku2• 11 years ago

Does anyone know if they support HTTP/2 on the backend side too ? They didn't with SPDY and I think it would help to multiplex connections all the way.

jgrahamc6• 11 years ago

Not right now. We are currently experimenting with Server Push because we think it will help with the end user experience more than HTTP/2 to the origin server. You can see that running on the experimental server https://http2.cloudflare.com/

The question is... does HTTP/2 on the backend help that much. We aren't restricted like a browser in terms of bandwidth, latency or number of connections we can open. Greatest benefit for HTTP/2 is between browser and us, but origin HTTP/2 hasn't been forgotten.

alimbada2• 11 years ago

Surely HTTP/2 to the origin server will reduce latency between Cloudflare and the origin server and thus reduce overall latency to the browser?

predakanga• 11 years ago

I've love to see CloudFlare enable admins to utilize Server Push without extra configuration on their backend.

My ideal situation is one where I can have my webapp specify it's dependencies through a spec such as Server Hints[1], and have them be requested and cached edge-side, turned into a Server Push to the end user.

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

manigandham2• 11 years ago

Wouldn't HTTP/2 to origin give most of the benefits of Railgun, other than the change delta acceleration?

Seems like for high traffic sites and APIs the persistent non-blocking multiplexed connections with binary transfer might make a big difference?

I think Instart Logic uses the same kind of model in between their proxy nodes called IPTP (inter-proxy transport protocol).

tgb• 11 years ago

Those page load improvement numbers seem ridiculously good (factor of almost 2 versus HTTP 1.1). Are they really expecting that to hold up in real world cases?

therealmarv6• 11 years ago

You see nearly 90% of this improvements already for years with SPDY. SSL with HTTP 1.1 was really slow before Google, FB etc. starting using SPDY years ago. So comparing HTTP 1.1 with SSL to HTTP/2 with SSL seems legit for me.

rplnt• 11 years ago

I thought HTTP/2 was going to be SSL only? Or was that other protocol?

contravariant• 11 years ago

In their demo[1] it is 20x faster for me, I had to disable http pipelining for it to work correctly (not sure why, but http/2 became a lot faster after I had disabled pipelining).

Minor nitpick: I don't agree with the way they calculate the percentage, if it takes 5% of the time then it's 20x (i.e. 1900%) faster, not 95%.

[1] https://www.cloudflare.com/http2/

stock_toaster2• 11 years ago

Oddly their demo shows Safari 9 (el cap) as not supporting http/2, but only spdy. Other test sites (akamai) show safari using http/2 just fine -- safari does appear (wireshark capture) to be sending the tls alpn h2 thingy.

bsdetector• 11 years ago

Isn't it interesting that even today, after Microsoft Research showed that pipelining could be almost as fast as SPDY and when activating it in Firefox is an about:config away, people still refuse to include it in any tests?

Google never showed any results vs pipelining. They just said "head of line blocking bad" and "one TCP connection per user good" (for tracking) and people just ate it up without evidence because, I suppose, they viewed HTTP/2 as conceptually simpler and more elegant. Nevermind that HTTP/2 didn't address any criticism that PHK had... that's ok because Google was just going to do it anyway.

NoGravitas• 11 years ago

I'm quite surprised that there are a lot of browsers in the wild that support SPDY, but not HTTP/2, given auto-updating. But that's what their numbers show. Maybe mobile skews this?

therealmarv6• 11 years ago

I think it has more to do with "old" IE11 version on Windows<10: See http://caniuse.com/#search=http%2F2 vs. http://caniuse.com/#search=spdy

A awful lot of companies still use IE and not Windows 10 ;)

chriselsen2• 11 years ago

The caniuse.com data on http/2 appears to have some flaws. Biggest buckets for browsers that support SPDY but not HTTP/2 for our website right now are: a) Chrome for mobile b) Safari on older Mac OS X versions c) Older Chrome for desktop versions d) Internet Explorer (small impact) Other websites might see different ratios depending on their audience.

Stay tuned for instructions on how to gain protocol version insight for your own website on CF.

therealmarv6• 11 years ago

Hmm, does anyone know how to support SPDY and HTTP/2 on a nginx>=1.9.5 and which has only module "ngx_http_v2_module" build inside? What is the configuration for nginx to support SPDY and HTTP/2 ?

jgrahamc6• 11 years ago

We developed our own patch to NGINX that allows it to support both SPDY/3.1 and HTTP/2 and to negotiate correctly. Stock NGINX allows you to have one or the other, but not both.

therealmarv6• 11 years ago

Would be nice to see that patch open sourced (at least I can hope) ;) :)

newman314• 11 years ago

I believe it's either or but not both.

mei0Iesh2• 11 years ago

You can't: "This patch replaces the SPDY module in NGINX."

https://www.nginx.com/blog/http2-r7/

"Before installing the nginx‑plus‑http2 package, you must remove the spdy parameter on all listen directives in your configuration (replace it with the http2 and ssl parameters to enable support for HTTP/2). With this package, NGINX Plus fails to start if any listen directives have the spdy parameter.

NGINX Plus R7 supports both SPDY and HTTP/2. In a future release we will deprecate support for SPDY. Google is deprecating SPDY in early 2016, making it unnecessary to support both protocols at that point."

xpose2000• 11 years ago

In terms of optimal performance for end users... I should now be hosting all files on my own server w/ Cloudflare rather rather something like Google's CDN? For example, jQuery. Reason being, is that those files will all load in parallel on my own domain, whereas for another domain like Google, it'd have to renegotiate an SSL connection and wait a bit longer?

Is this correct? Or is there more to it than that?

ropiku2• 11 years ago

For HTTP/2 it's a lot better to have fewer domains since they download in parallel as you say. I think the only advantage of hosting jQuery from a shared place would be caching between servers. CloudFlare already acts as a CDN for your static files.

kaizendad• 11 years ago

Wouldn't caching be a big thing for libraries like jQuery? Its highly-likely that jQuery was used by one of the other most recent sites a user visited... why not still take advantage of the fact jQuery may be cached locally?

buro92• 11 years ago

You are correct.

What I'm now doing is reducing the number of third party domains I call.

In essence, where I used to use cdnjs.cloudflare.com or whatever other externally hosted JS or CSS, I'm now mostly self-hosting, but still behind CloudFlare.

You can see this in action on https://www.lfgss.com/ which is now serving everything it can locally... only fonts and Persona really remain external.

I have been using preconnect hints to try and reduce the latency created by contacting those 3rd parties, but TBH the fact that I use SSL as much as possible meant that those connections take time to establish. In that time, most of the assets can be delivered over my already open connection.

There is an argument that cdnjs/Google CDN or whatever is better for the web, but personally I'm unconvinced. I think one should self-host/control all of the JavaScript that runs on your own site, and that unless the exact versions of the exact libs are cached in end user browsers the benefits are not even there.

This also looks to be a smarter thing to do anyway; the increasing prevalence of ad-blocking tech is impacting 3rd party hosted assets, and thus the experience of your users. You can mitigate that by self-hosting.

I haven't obliterated first-party extra domains, for example I still use a different domain for uploaded assets by users. This is a security thing, if I could safely do it I'd serve everything I can from just the one domain.

Basically: Self-host, http/2 has brought you the gift of speed to make that good again.

X-Istence• 11 years ago

If your first-party extra domains are advertised in your SSL cert, then Chrome at least will use the same connection for those assets too.

See this: https://blog.cloudflare.com/using-cloudflare-to-mix-domain-s...

jedberg• 11 years ago

You're not quite correct. In most cases, yes, but for JQuery specifically, your users will get better performance by continuing to use the Google CDN.

The reason being that most likely they've already got it in their cache and won't make a new call to Google (or you) at all.

manigandham2• 11 years ago

There are way too many versions in use everywhere, not to mention way too many CDNs, for this to have much of an impact.

CF is already a CDN so it's better to just pipe all the assets through a single connection rather than the more likely chance of setting up another connection just for jquery.

mutagen• 11 years ago

I think the case for hosting jQuery and the like, on external, presumably cached CDNs is overstated. Library version fragmentation and to a lesser extent, CDN fragmentation, have to be weighed against the cost of the additional connection.

jon_wu2• 11 years ago

Ideally, CloudFlare would allow you to route specific paths to different backends so you could just aggregate multiple services within your single domain for the fewest connections and DNS lookups.

Feels crazy but this makes me think to proxy imgix, which uses Fastly (not supporting SPDY or HTTP/2 yet), through CloudFlare. I'll just set up CNAMEs on my imgix account that are subdomains of my main domain, then add them to CloudFlare with acceleration on - but no caching (since imgix serves images by user agent). This adds an extra datacenter to datacenter hop, but hopefully that's really fast and upgrading the client to SPDY or HTTP/2 would outweigh that.

Anybody else tried something like this?

eastdakota3• 11 years ago

Coming soon.

eastdakota3• 11 years ago

One advantage of a service like CDNJS for a resource used by a number of unique sites, like jQuery, is that the resource will often be in the browser's cache. That value diminishes quickly if the particular version of the resource and the location from which it is served is not widely used. So, for widely used resources like jQuery, it can still make sense even in an HTTP/2 world to use a third party service. On the other hand, other HTTP/1.1 performance techniques, like domain sharding, can actually substantially hurt HTTP/2 performance.

mei0Iesh2• 11 years ago

I'm using HTTP/2. Here's some quick stats:

    # tail -n100000 access.log | grep 'jquery.js' | grep 'HTTP/1' | wc

    3,095

    # tail -n100000 access.log | grep 'jquery.js' | grep 'HTTP/2' | wc

    6,074

d0ugie• 11 years ago

For me, 505 and 1947 respectively. I guess my audience is hipper than yours. :)

Cshelton• 11 years ago

I really wish Microsoft gave HTTP/2 support to IE 11 on windows 8/8.1. Any insight as to why they decided not to support it on IE 11 for windows < 8.1 would be appreciated.

Many of our users are stuck with windows 8/8.1, or even 7 for many more years unfortunately. Some of them won't even have another browser as an option(enterprise...).

mattmanser• 11 years ago

They're not even updating IIS 8.5 to support HTTP/2 as far as anyone can tell, you'll have to update to windows server 2016 to get it.

snuxoll• 11 years ago

"Updating" IIS to support HTTP/2 means updating http.sys, something they are not keen on doing without a major OS upgrade.

prdonahue2• 11 years ago

See my point below about ALPN. You need to advertise support for HTTP/2 in the TLS ClientHello and this logic is contained (on a Microsoft platform) in schannel.dll.

Microsoft first added ALPN to SChannel in 8.1 and RARELY updates this library outside of OS releases, so that's (at least one reason) why you won't see on Windows 8/2012 Server.

danielsamuels2• 11 years ago

Is it possible to use HTTP/2 without SSL yet? I tried it a few weeks ago and my browser was just downloading a 4KB file with some random bytes in it, I assume this was the server response but it wasn't clear.

Skunkleton• 11 years ago

Per the spec SSL is not required, however all major browser implementations require TLS to negotiate using HTTP/2.

danielsamuels2• 11 years ago

So in theory it's not required but in practice it is? And to think it used to be IE which didn't follow specs.

ape4• 11 years ago

Both? Yuck.

tracker1• 11 years ago

Am I correct in assuming this means that cloudflare reads html to determine other files that need to be sent (css, js, images)?

Viper007Bond• 11 years ago

Push isn't supported so it's all on the browser to request the needed files.

jgrahamc6• 11 years ago

Yet

lawl• 11 years ago

An idea I heard (not cf related) was to analyze referers of past requests to be able to determine what resources a user most likely needs. They'll probably implement something like this sometime in the future, if they do it.

adamowen• 11 years ago

For comparison, I enabled HTTP/2 via CloudFlare on a dev site. Results: http://blog.adamowen.co.uk/deploying-http2-using-cloudflare-...

joeblau• 11 years ago

Just tested my side project https://www.gitignore.io and it now has sub second loading time. Unfortunately, adding Google analytics doubles the loading time to about 1.8 seconds.

treyp• 11 years ago

at least google analytics is non blocking

raullen• 11 years ago

Google's HTTP loadbanlancer and CDN have supported H2 for a long while.

xyproto• 11 years ago

Here's a small utility for checking if a web server offers HTTP/2: https://github.com/xyproto/http2check

HTTP/2 is here. Goodbye SPDY? Not quite yet

Related Stories