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

[Mark Mielke]

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 <vbart at nginx.com>
wrote:

> 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
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>



-- 
Mark Mielke <mark.mielke at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150318/b4241689/attachment-0001.html>