The HTTP/2 implementation | Hacker News Reader

The HTTP/2 implementation

mailman.nginx.org

331 pointsthresh107 comments

http://www.http2demo.io/

HTTP/1.1 1.37s

HTTP/2 1.46s

Mine was HTTP/1.1 at 1.44s versus HTTP/2 at 0.54s. (connection speed: 330 mbps (ethernet->cable modem); client: chrome 46.0.2490.22)

Got 1.71 (HTTP/1) vs 2.40 (HTTP/2) at the first test

And 2.31 vs 0.64 at the second

14s vs. 0.5s (Safari / OS X El Capitan). Quite impressive.

I wonder if there's some setting wrong that makes this take 14s for me using http/1. Any ideas?

Edit: same with Chrome and similar on Sarafi/iPhone (6s vs 0.6). I wonder if the difference is magnified by higher latency because I'm in Europe? If yes, I guess http/2 is a godsend for all non-Americans.

I've run it a few times. It seems to depend on normal networking conditions, which makes sense. I've had 1 run as low as 1sec and as high as 6.

Europe is not the main cause. I'm getting 1.2s vs 0.6s consistently.

Your ISP is doing some nasty stuff.

For me it was: HTTP/1.1 => 3.07s vs HTTP/2 => 0.76s

I was getting similar result in FF until :/ disabled caching, then 1&2 got very close values. So the 0.76 doesn't look accurate.

In incognito I got 3.33s for v1.1 and 1.24s for v2 in Chrome and 3.30s (v1.1) and 1.43s (v2) in FF.

You're right that in FF/Chrome for runs N+2 I get about half of the first run (0.86s for v2) so it looks like there's some kind of caching going on -- it's still twice as fast with v2.

I got 3.14s vs 1.01s on my Android smartphone with Chrome. Nice improvement.

Browser? OS?

HTTP/1.1: 2.06s HTTP/2: 0.45s

with Chrome 45 on 64-bit Debian 8

I think this website is now going through a bit of Hug of Death, since was seeing reasonable numbers before (1.3ish for http/1.1, and 0.6ish for http/2) and now I'm seeing multiple seconds for both.

I don't think this test is accurate.

I do get better times for 2 on Firefox, but if I start Firebug and disable caching, the http 1 time does not change, but http 2 is bigger and at that point 2 is better by fraction of second (sometimes worse).

Interestingly on Konqueror http is consistently worse than http 1.

If a page that was designed to highlight performance of something that http 2 should be better at (making many small requests) doesn't show drastic improvement and sometimes http 2 looks worse, makes me doubt whether http 2 brings anything to the table

Because users are typically running with firebug enabled, and caching disabled. This could be an issue with inspection of http2 traffic having more overhead when you are listening in... not an issue with the protocol or the test.

I'm not saying the test is "fair" but what you're describing isn't a fair scenario at all. I'm not sure if the latest fiddler or other dev proxy supports http2, but that might be a better way to judge.

Also, are you sure the the version of Konqueror you are using is actually using http2, or a fallback to 1.1?

HTTP/1.1: 1.53s, 1.97s, 1.32s, 1.65s, 1.48s = average 1.59s

HTTP/2: 1.09s, 0.87s, 1.19s, 0.92s, 1.30s = average 1.07s

The slowest of five HTTP/2 results is still faster than the fastest HTTP/1.1 result, and on average it's nearly 50% faster.

(I'm on a 37 Mbps network in New York, using Firefox 40.0.3 on Windows 8.1 with a cleared cache.)

In Australia, where the median latency to the rest of the internet is 200-300ms the difference would be remarkably higher. On this page, I get 5s vs 1.5s.

Seconding this (also in Australia, behind several corporate proxies). I am getting ~7s vs ~2s.

I didn't realise before how http2 will improve things for me, but you're right about Oz. 8.25 vs 4.36.

5.71s vs 1.67 in Brisbane, AU. Nice!

HTTP 1.1 - 0.64s, 2.0 - 0.60s. Firefox Aurora, Linux.

I'd like to know more about how this benchmark runs and what it's actually measuring. Page load times and responsiveness are notoriously hard to define.

I don't mean to nitpick the benchmark too much, it's obviously measuring something, but it's also nice to be able to weigh it against other tests and design goals.

It tells you what it is measuring on the page. It downloads an array of 200 small images from a CDN to make a single larger image and times the process.

Try https://http2.golang.org/, while it's not benchmarking per se, there are some fun examples under https://http2.golang.org/gophertiles and the code is all here: https://github.com/bradfitz/http2/tree/master/h2demo

This test 'cheats' in favor of HTTP 2.0. The problem is that there are ways around the HTTP 1.1 limitation of 'one connection, one thing,' and this test uses absolutely none of those ways. It makes a connection, receives an image, closes a connection, opens a connection, receives an image,... 200 times.

The HTTP/2 test does exactly what it's designed to do: opens a lot of connections and receives the images pretty much all at once.

This isn't to downplay HTTP/2, but it's something that should be noted for _this_ test.

Alternatively you could say that using all of the various tricks to speed up HTTP 1.1 would be cheating in favor of 1.1. Personally, I prefer not to have to think about how to optimize my websites; just let the protocol figure it out for me.

Elsewhere in the comments here, it's mentioned that nginx doesn't yet have server push so maybe it's fair to call these naive test setups then? I'd certainly buy that HTTP/2 has more head room for acceleration and optimization but I'm curious what the difference there would be. However, it starts to sound like programming language benchmarks where the test servers aren't setup in an "idiomatic" manner.

I believe that HTTP/2 isn't opening many connections. It's opening one TCP connection and multiplexing many requests through that. This would allow for exploiting a pre-warmed TCP connection in subsequent requests. I've always felt that was a flaw in HTTP/2: with minor modifications, that multiplexing protocol could have been split out.

I'm interested to see how HTTP/2 could accelerate your modern jumbo media websites. The ones with a dozen or so tracking bugs, ads, etc. All splattered across multiple domains with ad servers that aren't quite as zippy as one would wish.

Hmmm...

http://imgur.com/WyjSpBK

I'm probably an outlier.

My tests at home also show only ~200 ms difference.

Nearly a 3x speedup for me. I'm about 39ms latency from the CDN hosts. (I'm in Taiwan, FF 40.0.3)

http://i.imgur.com/DjTycqt.jpg

The first time I load the page in Chrome (45), the HTTP/1.1 test takes 3–5 seconds but subsequent refreshes take about 1.5s, so there must be some caching or connection keep alive that probably invalidates this test. HTTP/2 is always less than 1 second.

I think the caching makes it more like a real world scenario and even with it the benefits of HTTP/2 are notable.

I noticed something similar when this was posted before, but after refreshing the page a bunch of times and noting how long the resources took in Chrome Inspector, it looks to me like the CDN just occasionally takes a really long time (like, several seconds) to serve one or two images, which can easily throw the results one way or the other if it happens.

Holy cow.

Moto g, android 5.0.2, HSPA, chrome.

http/1.1 29.75, http/2 12.87

Nice test.

There is world map at the bottom of the page.

Feels like they may have exaggerated their fiber coverage of Greenland :)

http://www.http2demo.io/

I love HTTP/2 and all, but keep in mind this is literally the worst possible scenario for HTTP/1.1 and the best possible scenario for HTTP/2.

- Loading 250 resources from the exact same domain, where HTTP/1.1 can load at most 2-6 in parallel

- Head of line blocking since all requests are going to the same host

- 4-6x as many TCP connections with HTTP/1.1, so 4-6x more likely to encounter TCP congestion/flow issues.

This test is only relevant to you if your website only uses a single hostname, and loads all dependent resources from that same hostname. Sadly the median number of domains accessed for a typical webpage is 18...

http://httparchive.org/trends.php

It's certainly true that real websites use many different hostnames, but keep in mind that one of the reasons why (apart from ad networks and such) is to help pages load faster over HTTP/1.1. If that factor were removed, it'd remove the need to put together a fleet of static content servers with numbered hostnames.

Except, in real life, you're also loading stuff like social buttons (facebook, twitter, google plus and so on) and tracking^W marketing probes from third parties. So, to me, HTTP2 is not that interesting.

Realistically, how many sites load those assets synchronously and how many sites need them loaded to provide the main functionality? Its a stretch to write off http/2 just for that!

I did not write off HTTP2, I just said that it is not has interesting as marketed. It's great for some usecase like tiled maps for instance. Not worth the trouble for other usecase. That's all. Akamaï already demonstrated so, not long ago.

I feel like it simplifies workflow, site design etc; serving your content from several domains is a hack and a half. I can see your point for non-greenfield dev, can't say there is a large amount of motivation to switch it out (aside from new toys!!!).

>> where HTTP/1.1 can load at most 2-6 in parallel > So, to me, HTTP2 is not that interesting

If you have more than 2-6 of your own resources (scripts, CSS, images) on a page it should be. Third party resources is orthogonal to that.

This demo is better, lets you adjust latency: http://http2.golang.org/gophertiles

Odd. For me, on my work connection, HTTP 2 is consistently worse:

    1.1     2.0
    ---     ---
    2.03    3.60
    2.00    3.19
    1.85    1.92
    1.72    3.69
    2.11    4.64
    2.13    4.13
    1.92    2.35

Network congestion is one of those areas where the multiple parallel TCP connections used in the HTTP1 demo can improve performance for you.

It's just netting you a larger share of the limited network resources at the expense of others on the network.

HTTP 1.1: 2.0 s HTTP 2.0: 1.6 s

Not very dramatic diffence. Location Europe, using 4G connection.

HTTP 2.0 is surely nice for initial page load but for subsequent data loads I prefer websocket (in the context of SPAs).

"for subsequent data loads I prefer websocket"

There is notable difference here. Developer needs to write code to implement server-push in Websockets but HTTP2 servers will do that for you by sending all dependancy files with a single request.

How is server push implemented in current nginx?

Can nginx itself automatically parse HTML/CSS and send required resources?

Is there a mechanism for the proxied application to specify additional resources? (for JavaScript use)

AFAIK Server Push is not supported (it wasn't supported in the `ngx_http_spdy_module` either). This was also mentioned in the alpha patch announcement:

HTTP/2's 'Server Push' feature is not supported in this patch and will not be supported in the first production-ready release of the HTTP/2 implementation. This feature might appear in a future NGINX release. [1]

[1]https://www.nginx.com/blog/early-alpha-patch-http2/

Getting slightly off topic, but I'm confused about an aspect of server push (maybe you can help). Even on HTTP/1, the client typically only downloads assets on the first page load for a given website, then it caches them. Subsequent requests for other pages are much quicker because the assets don't need to be downloaded again. With server push, would the server typically send all linked assets on every request? Or can it somehow keep track of which clients have cached which assets, and avoid wasting bandwidth?

Yes that would be one possible implementation. It's up to the server and can vary quite a bit depending on the scenario, which is why Nginx hasn't tackled the problem yet.

I believe that it's going to take a while to find good heuristics that work in most of the cases. Until then only big companies like Google will have the financial incentive to develop their own custom version that's tailored to their specific use-case.

The browser can cancel the stream after the first "stream open" frame (assuming latency isn't too high, obviously)

One proposed mechanism for doing server push is for the application server to send Link: rel=preload headers: https://github.com/icing/mod_h2/issues/38

Once you've got code running on the client then there's significantly less need for server push, as you can initiate requests in a bunch of ways, XHRs or <img> tags etc.

Server push's big win is in getting necessary resources down to the client on the initial page load without waiting for numerous round. As such, you'll see the biggest gains on high latency connections, e.g. mobile.

Oh. I hoped for an announcement like 'it's in the latest stable version'.

That they are working on it is well known for quite some time - am I missing something?

They did sort of announce that (though it doesn't recommend it for production yet):

https://www.nginx.com/blog/nginx-plus-r7-released/

"The update provides a fully supported implementation of the new HTTP/2 web standard, the first of its kind for a leading web server."

and

"Note: Based on user testing of the alpha-level patch, and with the early support from corporate co-sponsors Automattic and Dropbox, the final open source version of HTTP/2 will become available following the release of R7."

Great! Now we just need proper HTTP2 support in Amazon ELB...

This is what I'm waiting for as well. Hopefully it comes sooner rather then later.

It tends to be amazing how certain closed platforms magically get new features right after they get released in open source projects.

if elb would use nginx, that wouldn't be a problem. You can sell closed platforms which depending on gpl / agpl code and you would not need to release any code if you don't modify it.

Right, but they don't use nginx. He is either suggesting that it suddenly becomes a priority when they might lose customers because the feature is available elsewhere; or that they go look at the source code of free software to figure out how to implement the feature; and maybe suggesting that they lift some of the free software's code for their own project. The latter would violate AGPL but probably not GPL, as long as they don't distribute a binary.

it would not hurt AGPL. If they build software around AGPL which configures the AGPL it won't break it, you wouldn't change any line of code. As long as your project won't depend on the AGPL (the AGPL binary should be replaceable with project XYZ which isn't AGPL).

Let's say you build a closed source configuration tool which works for AGPL webserver and a non AGPL webserver, then you wouldn't violate the AGPL as long as the AGPL webserver won't be changed and just be used.

Images are fun. But I'd like to see a demo showing how http/2 can affect asset managers / web development. Perhaps show a site with 1-5 bundled css / js vs 100-500 individual css / js.

Does a demo like that exist?

Does it support prioritizing different files, so a browser can download things in an order that gets the page rendered faster?

Yes, it does.

Ugh, gimme

"Support for HTTP/2 with weighted and dependency-based prioritization." @ http://nginx.org/en/

I wish unencrypted HTTP/2 without TLS could be supported in major browsers. Although use of encryption should be very strongly encouraged, making it mandatory creates a lot of headaches in certain scenarios.

Such as?

Generating a trusted certificate?

Do you need to generate a cert for all HTTP/2 usage? Is there no opportunistic encryption?

There's no opportunistic encryption by design.

Lets Encrypt and is paving the way toward making that easier, and at this point it's already not all that hard.

Lets Encrypt's certs are not [yet] trusted since you are required to install a root certificate, for many end users this is not an option.

True, but they expect to have that done within a month. If you really want http 2.0 before that, then use one of the other free CAs

Browsers shouldn't be the internet police. If either server or client wants to use encryption, encryption should be used. The browser should not have a say in this decision.

Examples of cases where unencrypted HTTP makes sense:

* Public, non-sensitive content that you need to distribute or broadcast using CDNs (such as Amazon's), who may charge you hundreds or thousands of dollars to install a custom server certificate if you want to use your own domain

* Servers with limited CPU power and which are not serving sensitive content (e.g. embedded devices, Raspberry Pis, Arduinos et al.)

* Getting a website up for $0.00 without paying some troll corporation to "validate" your certificate

* Getting a website up to distribute information without revealing YOUR identity

In any case, there are use cases, and it should not be the job of the browser to police this.

> * Public, non-sensitive content that you need to distribute or broadcast using CDNs (such as Amazon's), who may charge you hundreds or thousands of dollars to install a custom server certificate if you want to use your own domain

If TLS is mandatory, the price of this will have to go down

> * Servers with limited CPU power and which are not serving sensitive content (e.g. embedded devices, Raspberry Pis, Arduinos et al.)

I've served TLS off embedded devices like these no problem

>* Getting a website up for $0.00 without paying some troll corporation to "validate" your certificate

Certificates are free (WoSign, StartCom, LetsEncrypt)

>* Getting a website up to distribute information without revealing YOUR identity

None of the free CAs validate anything beyond your email address (StartCom demands an address, but they don't seem to do much beyond validate that it's a valid address). DV certs are not to validate identity, just that you are the domain owner

> I've served TLS off embedded devices like these no problem

I doubt it -- Raspberry Pi is easy, but even HTTP on an Arduino would be a stretch.

> > * Servers with limited CPU power and which are not serving sensitive content (e.g. embedded devices, Raspberry Pis, Arduinos et al.) > I've served TLS off embedded devices like these no problem

On e.g. a esp8266 you can only have a single TLS connection at a time. While you can have hundreds of normal TCP sessions.

> Certificates are free (WoSign, StartCom, LetsEncrypt)

  - WoSign doesn't work on mildy old devices
  - StartCom certs are expensive to revoke
  - LetsEncrypt doesn't exist yet

Why dont WoSign certs work on old devices? Their intermediate is cross-signed by Startcom

WoSign stopped doing free SSL in the last day or two, FYI.

https://buy.wosign.com/free/ looks like they're still doing it... haven't actually tried to get a cert signed

Looks like it's just a weaker offering now: only for a year and only 1 domain, no altnames[0]! The demise of this free option was predicted/discussed just 9 days ago in another HN thread[1]

[0] https://buy.wosign.com/free/

[1] https://news.ycombinator.com/item?id=10185174

> If either server or client wants to use encryption, encryption should be used.

The browsers are the client and they decided to require encryption.

Browsers shouldn't be the internet police. If either server or client wants to use encryption, encryption should be used. The browser should not have a say in this decision.

It's infuriating that they seem to think this is part of their role now. I don't see how forcing you to go through a CA promotes participation.

CDNs (well, CloudFront and CloudFlare but I assume this is the same for others) only charge you for using custom SSL certs if you can't get by with SNI, since it means they have to provision IPs at every endpoint.

With HTTP2, SNI isn't an issue.

Just because the CA system currently sucks (letsencrypt.org may help this) doesn't mean you should give up on crypto entirely.

What if I have a bare IP address and don't feel like getting a domain name for it?

Don't know about you but I have a really hard time remembering those long 128 but addresses. A domain name is just so much easier.

Well if you have a /64 (which is the recommended minimum), then you probably have the first 64 bits memorized before too long. After that you can get creative with ::dead:beef or whatever.

Such as if you are ZeroConf networking with someone in the same area.

You can get a certificate for an ip address.

I couldn't find any info on this when I researched before, but I guess some CA's will do it and some won't. GlobalSign seems to.

I wish there was opportunistic encryption, or at least a system more similar to how ssh keys work.

From inside a Panera:

Http/1.1: 12.60s, 20.25s Http/2: 38.15s, 30.06s

Might be an issue with a transparent proxy.

Neat, I'll be keeping an eye on this, it should be a similar process to loading the SPDY module in nginx, right? I'm not that much of a sysops guy, but it was (from what I remember) quite easy to get that loaded up.

I managed to get my own site going with SPDY 3.1 draft, so I'm quite eager to get HTTP2 support going - if not for it's multiplexing, just to be ahead of the curve!

Does this mean nginx is not going to be able to listen for both SPDY and HTTP2.0 connections on the same IP at the same time ?

No. From the article:

> The SPDY support is removed, as it's incompatible with the new module.

I wonder what happens to the SPDY-specific directives once support is removed. I use 'listen 443 ssl spdy;' and 'add_header Alternate-Protocol 443:npn-spdy/3;'. If these are just ignored no problem, but I wonder if it breaks anything?

Those directives will no longer pass the linting that nginx does on its configuration file. New versions of Nginx with spdy support removed will not start until you remove those directives.

They are treated as syntax errors, but I think it does give an error message that spdy is deprecated and to remove.

SPDY is getting removed from most browsers as well (because it was an experiment in the first place) so unless you have a specially coded web client with SPDY patched back in, there will be fewer and fewer clients able to request SPDY.

would be interesting to see the difference in speed with a real world site instead of 200 images.

Will this be a drop in replacement for 1.1 with nginx? will nginx fall back to 1.1 on browsers that don't support 2?

Is it worth upgrading from SPDY 3.1? Opinions welcome.

Anyone know what stable version this will ship in?

1.9.5, most likely.

is that the complete http2 implementation in just few k lines of code? wow.

10k LoC is more than enough for an HTTP/2 implementation.

Are there tests?

Reply on news.ycombinator.com