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.
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!
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.
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 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 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?
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.
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.
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.
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 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.
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...
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!!!).
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.
"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."
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]
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.
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.
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.
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
> > * 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
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]
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.
> * 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
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.
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.
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.
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.
110 comments
[ 2.0 ms ] story [ 151 ms ] threadLet'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.
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!
HTTP/2 1.46s
And 2.31 vs 0.64 at the second
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.
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.
HTTP/1.1: 2.06s HTTP/2: 0.45s
with Chrome 45 on 64-bit Debian 8
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
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/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.)
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.
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.
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.
http://imgur.com/WyjSpBK
I'm probably an outlier.
http://i.imgur.com/DjTycqt.jpg
Moto g, android 5.0.2, HSPA, chrome.
http/1.1 29.75, http/2 12.87
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/
- 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
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.
It's just netting you a larger share of the limited network resources at the expense of others on the network.
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).
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.
That they are working on it is well known for quite some time - am I missing something?
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."
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)
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/
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.
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.
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.
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 doubt it -- Raspberry Pi is easy, but even HTTP on an Arduino would be a stretch.
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)
[0] https://buy.wosign.com/free/
[1] https://news.ycombinator.com/item?id=10185174
The browsers are the client and they decided to require encryption.
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.
> The SPDY support is removed, as it's incompatible with the new module.
They are treated as syntax errors, but I think it does give an error message that spdy is deprecated and to remove.
Http/1.1: 12.60s, 20.25s Http/2: 38.15s, 30.06s
Might be an issue with a transparent proxy.
Does a demo like that exist?
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?