Google dumps SPDY in favour of HTTP/2, any plans for nginx?

Server NGINX
1

Google dumps SPDY in favour of HTTP/2, any plans ore roadmap for HTTP/2
in
nginx?

see
https://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html

"HTTP is the fundamental networking protocol that powers the web. The
majority of sites use version 1.1 of HTTP, which was defined in 1999
with
RFC2616. A lot has changed on the web since then, and a new version of
the
protocol named HTTP/2 is well on the road to standardization. We plan to
gradually roll out support for HTTP/2 in Chrome 40 in the upcoming
weeks.

HTTP/2’s primary changes from HTTP/1.1 focus on improved performance.
Some
key features such as multiplexing, header compression, prioritization
and
protocol negotiation evolved from work done in an earlier open, but
non-standard protocol named SPDY. Chrome has supported SPDY since Chrome
6,
but since most of the benefits are present in HTTP/2, it’s time to say
goodbye. We plan to remove support for SPDY in early 2016, and to also
remove support for the TLS extension named NPN in favor of ALPN in
Chrome at
the same time. Server developers are strongly encouraged to move to
HTTP/2
and ALPN."

cheers,

mex

Posted at Nginx Forum:

2

Indeed. The Wikipedia page covers it quite well FYI -

So what is really being asked is for a roadmap for the implementation of
the non-draft differences (i.e HTTP/2.0 allows for non TLS
communication,
and multiplexes differently). I am sure nginx will once again be at the
forefront of technology and implement it when possible. :slight_smile:

3

Pedantic, but I object to the wording in the title :slight_smile: … SPDY was/is an
experimental branch of HTTP/2, and now that HTTP/2 is in the final
stages
of becoming a standard, there is no longer the need for SPDY and hence
the
announcement of a deprecation timeline – it’s not and never was SPDY
vs.
HTTP/2. That aside…

From what I understand (at least from a few conversations at
nginx.conf),
there is already some existing efforts around enabling http/2 support?
I’d
love to see some official product plans and/or timelines as well.

ig

4

Hello!

On Tue, Mar 17, 2015 at 09:49:04AM -0400, alexandru.eftimie wrote:

Will there be support for http/2 for upstream connections? I can’t seem to
find anything about this online ( either SPDY or HTTP/2 for upstream
connections )

No, and there are no plans.

–
Maxim D.
http://nginx.org/

5

Will there be support for http/2 for upstream connections? I can’t seem
to
find anything about this online ( either SPDY or HTTP/2 for upstream
connections )

Posted at Nginx Forum:

6

Hello!

On Tue, Mar 17, 2015 at 03:01:09PM +0100, Daniël Mostertman wrote:

HTTP/2 is an actual HTTP, and does not even require protocol renegotiation
support.
HTTP/2 support plans were announced on Feb 25, 2015:
How NGINX Plans to Support HTTP/2 - NGINX

HTTP/1.0 and HTTP/1.1 are supported for upstreams, so it only makes sense
HTTP/2 follows suit.

In no particular order:

  • No, HTTP/2 isn’t “an actual HTTP”. It’s a completely different
    protocol,
    mostly based on SPDY.

  • As previously said, there are no plans to support neither HTTP/2
    nor SPDY for upstream connections.

Feel free to provide patches if you think it’s something needed.
Most likely you’ll understand the reasons “why it wouldn’t be”
while working on the patches.

–
Maxim D.
http://nginx.org/

7

Maxim D. schreef op 17-3-2015 om 14:49:

Hello!

On Tue, Mar 17, 2015 at 09:49:04AM -0400, alexandru.eftimie wrote:

Will there be support for http/2 for upstream connections? I can’t seem to
find anything about this online ( either SPDY or HTTP/2 for upstream
connections )
No, and there are no plans.
I don’t see why it wouldn’t be. HTTP/2 is not the same kind as SPDY.
HTTP/2 is an actual HTTP, and does not even require protocol
renegotiation support.
HTTP/2 support plans were announced on Feb 25, 2015:
How NGINX Plans to Support HTTP/2 - NGINX

HTTP/1.0 and HTTP/1.1 are supported for upstreams, so it only makes
sense HTTP/2 follows suit.

8

On Tuesday 17 March 2015 09:49:04 alexandru.eftimie wrote:

Will there be support for http/2 for upstream connections? I can’t seem to
find anything about this online ( either SPDY or HTTP/2 for upstream
connections )

The problems that SPDY (and HTTP/2) is trying to solve usually do not
exist in upstream connections, or can be solved more effectively using
other methods already presented in nginx (e.g. keepalive cache).

Could you provide any real use case for HTTP/2 in this scenario?

wbr, Valentin V. Bartenev

9

other methods already presented in nginx (e.g. keepalive cache).

Could you provide any real use case for HTTP/2 in this scenario?

My guess would be if your upstream is actually a „real“ internet-server
(that happens to do http/2).

Somebody trying to build the next „CloudFlare/Akamai/WhateverCDN“?
:wink:

Is a world possible/imaginable that only does http/2?

Rainer

10

I think the ability to “push” content, and prioritize requests are
examples
of capabilities that might require intelligence upstream, and therefore
a
requirement to proxy HTTP/2 upstream. However, I expect much of this is
still theoretical at this point, and until there are actually upstream
servers that are providing effective capabilities here, HTTP/1.1 will
perform just as good as HTTP/2? I also expect that some of these
benefits
could only be achieved if the upstream server knows it is talking to a
specific client, in which case it would make more sense to use an
HAProxy
approach, where one client connection is mapped to one upstream
connection…

On Tue, Mar 17, 2015 at 6:37 PM, Rainer D. [email protected]

11

A CDN was the exact reason i asked the question in the first place, at
the
moment not even cloudflare offers spdy or http/2 for upstream servers (
they
use nginx and have spdy enabled ).

Seems to me like http/2 for upstream would make building a CDN /
Accelerator
easier(or at least better) for alot of people.

I’m not trying to push for this though, it was just a simple question.

Posted at Nginx Forum:

12

On Wednesday 18 March 2015 04:32:55 Mark Mielke wrote:

I think the ability to “push” content,and prioritize requests are examples
of capabilities that might require intelligence upstream, and therefore a
requirement to proxy HTTP/2 upstream.

“Server push” doesn’t require HTTP/2 for upstream connection.

Upstreams don’t request content, instead they return it, so there’s
nothing
to prioritize from the upstream point of view.

However, I expect much of this is
still theoretical at this point, and until there are actually upstream
servers that are providing effective capabilities here, HTTP/1.1 will
perform just as good as HTTP/2?

HTTP/1.1 actually can perform better than HTTP/2.

HTTP/1.1 has less overhead by default (since it doesn’t introduce
another
framing layer and another flow control over TCP), and it also uses more
connections, which means more TCP window, more socket buffers and less
impact from packet loss.

There’s almost no reason for HTTP/2 to perform better unless you’re
doing
many handshakes over high latency network or sending hundreds of
kilobytes
of headers.

wbr, Valentin V. Bartenev

13

Hi Valentin:

Are you talking about the same “push” as I am? HTTP/2, or at least SPDY,
had the ability to push content like CSS in advance of the request,
pushing content into the browsers cache before it needs it. I’m not
talking about long polling or other technology. I’ve only read about
this
technology, though. I’ve never seen it implemented in practice. And for
prioritization, it’s about choosing to send more important content
before
less important content. I don’t think you are correct in terms of future
potential here. But, it’s very likely that you are correct in terms of
current potential. That is, I think this technology is too new for
people
to understand it and really think about how to leverage it. It sounds
like
you don’t even know about it…

On Wed, Mar 18, 2015 at 10:45 AM, Valentin V. Bartenev [email protected]

14

On 2015-03-17 07:43, Maxim D. wrote:

  • As previously said, there are no plans to support neither HTTP/2
    nor SPDY for upstream connections.

Which of the two will be supported, or will both be supported, and is
there any code in developement we can access to test out and provide
feedback?

15

On Wednesday 18 March 2015 19:11:18 Mark Mielke wrote:

Hi Valentin:

Are you talking about the same “push” as I am? HTTP/2, or at least SPDY,
had the ability to push content like CSS in advance of the request,
pushing content into the browsers cache before it needs it.

Yes, about that one.

I’m not talking about long polling or other technology. I’ve only read about
this
technology, though. I’ve never seen it implemented in practice.

The mod_spdy Apaches’s module has “server push” implementation for a
long time already.
And it can be used with mod_proxy or mod_fastcgi without a problem.

See:
https://code.google.com/p/mod-spdy/wiki/OptimizingForSpdy#Using_SPDY_server_push

And for prioritization, it’s about choosing to send more important content
before
less important content.

The prioritization mechanism in SPDY/HTTP2 mostly solves the problem
introduced
by multiplexing, i.e. by the new protocol itself. When you have only
one pipe then
you should carefully choose what to send first.

It already works pretty good in nginx with SPDY on client side and HTTP
or FastCGI
on backends. There’s almost no room for improvement.

I don’t think you are correct in terms of future potential here. But, it’s very
likely that you are correct in terms of current potential. That is, I think
this technology is too new for people to understand it and really think about
how to leverage it. It sounds like you don’t even know about it…

Well, do you know that the FastCGI protocol has multiplexing ability
since
introduction in 1996? So, nothing new, and I cannot remember any widely
used
implementation. The reason is that multiplexing is a very complicated
thing
with questionable benefits, especially when we are talking about fast
and
persistent connections between web server and application.

At least, this should be well studied at first, since the proper
implementation
on the backend side will take lots of programming hours.

As for the future, personally I believe that SCTP has much better
potential.

wbr, Valentin V. Bartenev

16

It’s awesome to see you all excited about HTTP/2.

We don’t have any test builds (that I know of) in the wild, so I’m not
sure what you’re seeing, George. As we get closer to a release, there
may be opportunities for test builds. If you’re interested in that,
please send me an email offlist and I’ll see what I can do.

sarah

17

Definitely looking forward to Nginx’s implementation of HTTP/2 as it’s
one
of the missing pieces in comparison test with other HTTP/2 enabled web
servers like h2o and OpenLiteSpeed
https://h2ohttp2.centminmod.com/webpagetests1.html :slight_smile:

Do some folks have access to experimental builds of Nginx with HTTP/2
already ? As I have seen 2 sites so far which show Nginx headers but
being
served via h2-14 in Chrome/Opera 28 so far.

cheers

George

Posted at Nginx Forum:

18

On Mar 31, 2015, at 11:39 PM, George [email protected] wrote:

thanks Sarah

dug deeper and apparently those nginx reported header sites were behind
Google Pagespeed’s service so that must of been why HTTP/2 was reported

That does seem like a likely reason.

.s.

19

thanks Sarah

dug deeper and apparently those nginx reported header sites were behind
Google Pagespeed’s service so that must of been why HTTP/2 was reported

Posted at Nginx Forum: