I ve come to http2demo.io today and I already have some good experience with SPDY .. so, do you plan/adise using HTTP/2 cause the results seems valid and quite impressive, and it does not need SSL except of SPDY.
However seems to be Nginx thingy, is it a trouble?
Related
I was looking around for a way but I've only got that Nginx does implement the normal SNI and that's it.
Can it be that ESNI is still a "not yet ready" feature for Nginx?
Since ESNI (or ECH, as it's now called) is not supported by OpenSSL, it can't be supported by nginx, either.
Most articles consider using domain sharding as hurting performance but it's actually not entirely true. A single connection can be reused for different domains at certain conditions:
they resolve to the same IP
in case of secure connection the same certificate should cover both domains
https://www.rfc-editor.org/rfc/rfc7540#section-9.1.1
Is that correct? Is anyone using it?
And what about CDN? Can I have some guarantees that they direct a user to the same server (IP)?
Yup that’s one of the benefits of HTTP/2 and in theory allows you to keep sharding for HTTP/1.1 users and automatically unshard for HTTP/2 users.
The reality is a little more complicated as always - due mostly to implementation issues and servers resolving to different IP addresses as you state. This blog post is a few years old now but describes some of the issues: https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/. Maybe it’s improved since then, but would imagine issues still exist. Also new features like the ORIGIN frame should help but are not widely supported yet.
I think however it’s worth revisiting the assumption that sharding is actually good for HTTP/1.1. The costs of setting up new connections (DNS lookup, TCP setup, TLS handshake and then the actual sending HTTP messages) are not immaterial and studies have shown the 6 connection browser limit is really used never mind adding more by sharding. Concatenation, spriting and inlining are usually much better options and these can still be used for HTTP/2. Try it on your site and measure is the best way of being sure of this!
Incidentally it is for for these reasons (and security) that I’m less keen on using common libraries (e.g. jquery, bootstrap...etc.) from their CDNs instead of hosted locally. In my opinion the performance benefit of a user already having the version your site uses already cached is over stated.
With al these things, HTTP/1.1 will still work without sharded domains. It may (arguably) be slower but it won’t break. But most users are likely on HTTP/2 so is it really worth adding the complexity for the minority’s of users? Is this not a way of progressively enhancing your site for people on modern browsers (and encouraging those not, to upgrade)? For larger sites (e.g. Google, Facebook... etc.) the minority may still represent a large number of users and the complexity is worth it (and they have the resources and expertise to deal with it) for the rest of us, my recommendation is not to shard, to upgrade to new protocols like HTTP/2 when they become common (like it is now!) but otherwise to keep complexity down.
I plan to code a mighty web server. But I am unsure: should I do it in HTTP/1.x, or HTTP/2? I really don't like doing it in both (I know HTTP/2 is backward compatible to HTTP/1.x, but if it's superior AND is going to be adopted by the majority then I will only do it in HTTP/2 without the backward compatibility aspect).
How is the future looking like for HTTP/2? Are there any hints from standard bodies to change HTTP/2 or undo their mistakes?
Is HTTP/2 really worth it?
Finally, how is the expected HTTP/2 adoption by web browsers?
I would say this question is too broad for stack overflow, but will attempt and answer anyway:
I plan to code a mighty web server. But I am unsure: should I do it in
HTTP/1.x, or HTTP/2? I really don't like doing it in both (I know
HTTP/2 is backward compatible to HTTP/1.x, but if it's superior AND is
going to be adopted by the majority then I will only do it in HTTP/2
without the backward compatibility aspect).
No offence, and will give you the benefit of the doubt here that you are not trolling, but writing a web server is a major undertaking and you'd need to have detailed knowledge of the HTTP protocol amongst other things and it appears you don't have that to be honest. So you'll need to do a few years reading on the subject first.
HTTP/2 is not backwards compatible to HTTP/1.1. You basically start in HTTP/1.1 and upgrade to HTTP/2 if you support it (at a simplistic level). So you need to support both. And will do for some time. Even though browser support is good (see below) there will be numerous devices that won't speak HTTP/2 for some time. Some devices (primarily bots admittedly) still only speak HTTP/1.0.
How is the future looking like for HTTP/2? Are there any hints from standard bodies to change HTTP/2 or undo their mistakes?
Way too broad for Stackoverflows format.
Is HTTP/2 really worth it?
Yes.
Finally, how is the expected HTTP/2 adoption by web browsers?
HTTP/2 adoption can be seen here: http://caniuse.com/#search=http2
How is the future looking like for HTTP/2? and Finally, how is the expected HTTP/2 adoption by web browsers?
The HTTP/2 standard has passed acceptance and is being implemented by all major server vendors. In fact, server support has advanced, all major server vendors support HTTP/2 in their current releases. You can track all known implementations of HTTP/2 here.
Are there any hints from standard bodies to change HTTP/2 or undo their mistakes?
There will not be an HTTP 2.x. The standards body has already made this clear (although I can't find a link that proves it). the next version will be HTTP/3.
Is HTTP/2 really worth it?
Yes. The benefits of HTTP/2 are too long to list here. This article discusses them in depth.
When developing a web server you will need to take account of both HTTP1.x and HTTP/2. At the moment we are transitioning to HTTP/2 but you should provide backward compatibility to HTTP/1.x.
I'd like to move my client's site entirely to HTTPS in order to allow HTTP2 to work, however I was wondering is it ok (in the eyes of search engines) to serve older traffic (of which there is a lot and which would otherwise suffer a perf hit) that do not support HTTP2?
Is this dangerous to do from an SEO point of view? and
could you do the detection with tools like WURFL?
I want to stay current and offer improved perf/security to those on newer browsers but don't want those on older browsers in developing countries to suffer.
For what is worth, I did some tests a few weeks ago and I got the impression that Google's spiders don't see HTTP/2 yet. But as #sbordet pointed out the upgrade to HTTP/2 is optional, so just be sure to have a site that also responds to HTTP/1.1. Here are a few thoughts more:
Google's algorithms will penalize slower sites, but it is unlikely that you will take a big performance hit from using HTTPS in your servers.
Using HTTPS can actually boost your SEO. Doesn't have anything to do with HTTP/2.
Popular browsers that don't support HTTP/2: Safari and IE. Safari doesn't support any TLS crypto-suite compatible with HTTP/2, AFAIK. But that won't cause problems as long as you list HTTP/2-compatible suites first in your TLS server hello: ECDHE-RSA-AES128-GCM-SHA256 and ECDHE-RSA-AES256-GCM-SHA384 are the ones I know of. Then you can list weaker suites.
You don't need to serve different content depending on whether you use HTTP/2 or HTTP/1.1, as your question title may hint (sorry if I misunderstood).
Also, just because you updated to HTTP/2, it does not mean that your server cannot serve HTTP/1.1 anymore.
You can easily update to HTTP/2, and retain HTTP/1.1 support for older devices or networks that do not support or do not allow HTTP/2 traffic.
Whether a client and a server can speak HTTP/2 is negotiated: only if the server detects that the client supports it, then it will use it, otherwise the server will fallback to HTTP/1.1. Therefore you don't risk to make your site unavailable for older browsers in developing countries.
Then again, HTTP/2 implementations may vary, but typically they have to be prepared to clients that don't speak HTTP/2, and use HTTP/1.1 for those (because otherwise they won't be able to serve content and it will appear that the service is down).
Looking for possibilities / alternatives for backend HA in nginx. At the moment we are using lua-nginx which does not support HttpUpstream module, which would be first choice for me. I know a bit about pacemaker but not never used it so not sure if it would be good combination with nginx. Any hints, experience?