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

[Valentin V. Bartenev]

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