Upcoming SPDY support details

Re: Upcoming SPDY support details

Valentin V. Bartenev — Thu, 17 May 2012 14:30:01 -0400

On Thursday 17 May 2012 17:52:30 Alek Storm wrote:
> That's perfectly reasonable. Thanks for the quick and clear answers. Is
> there somewhere online the in-progress SPDY implementation has been posted?
> If not, what's the current estimated date of release?
>

We usually post the code on public only after the completion of the development
cycle of some full-fledged functionality, internal testing and review (sometimes
double or even triple code review). SPDY is the very big one, so it takes time.

As you've already seen on roadmap ( http://trac.nginx.org/nginx/roadmap ), the
end of May - early June is our goal.

wbr, Valentin V. Bartenev

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Upcoming SPDY support details

Alek Storm — Thu, 17 May 2012 09:58:01 -0400

That's perfectly reasonable. Thanks for the quick and clear answers. Is
there somewhere online the in-progress SPDY implementation has been posted?
If not, what's the current estimated date of release?

Alek

On Thu, May 17, 2012 at 8:17 AM, Valentin V. Bartenev wrote:

> On Thursday 17 May 2012 16:06:21 Alek Storm wrote:
> > On Thu, May 17, 2012 at 6:23 AM, Valentin V. Bartenev
> wrote:
> > > First implementation of SPDY support will work only on frontend side.
> So,
> > > nginx
> > > will be able to talk with backends by HTTP, FastCGI, uwsgi, or SCGI
> > > protocols.
> >
> > Got it. Looking forward to backend SPDY support, so crucial advantages
> like
> > multiplexing are preserved. Will nginx at least add headers like
> > "X-Priority" to the forwarded request?
>
> Surely, I added the $spdy_request_priority configuration variable and it is
> suitable for such tasks.
>
> > > that
> > > the next step is to add pushing by special response header from backend
> > > (like
> > > "X-Accel-Redirect" but with the list of URIs to push).
> >
> > That'll work, but am I correct in assuming that the response containing
> > "X-Accel-Redirect" is different from the response to the original
> request?
>
> In the most simplest implementation they will be the same.
>
> > If they are the same, then nginx will not be notified of the URIs to push
> > until the server is ready to send the headers for the response to the
> > original request. This would be more restrictive than SPDY's semantics,
> > which allow pushing resources before the SYN_REPLY frame for the original
> > request is even sent.
>
> Yes, you're right. And this question is still undecided and requires
> further
> investigation. I think that we also need some sort of configuration
> directives
> for server pushing.
>
> wbr, Valentin V. Bartenev
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Upcoming SPDY support details

Valentin V. Bartenev — Thu, 17 May 2012 09:20:01 -0400

On Thursday 17 May 2012 16:06:21 Alek Storm wrote:
> On Thu, May 17, 2012 at 6:23 AM, Valentin V. Bartenev wrote:
> > First implementation of SPDY support will work only on frontend side. So,
> > nginx
> > will be able to talk with backends by HTTP, FastCGI, uwsgi, or SCGI
> > protocols.
>
> Got it. Looking forward to backend SPDY support, so crucial advantages like
> multiplexing are preserved. Will nginx at least add headers like
> "X-Priority" to the forwarded request?

Surely, I added the $spdy_request_priority configuration variable and it is
suitable for such tasks.

> > that
> > the next step is to add pushing by special response header from backend
> > (like
> > "X-Accel-Redirect" but with the list of URIs to push).
>
> That'll work, but am I correct in assuming that the response containing
> "X-Accel-Redirect" is different from the response to the original request?

In the most simplest implementation they will be the same.

> If they are the same, then nginx will not be notified of the URIs to push
> until the server is ready to send the headers for the response to the
> original request. This would be more restrictive than SPDY's semantics,
> which allow pushing resources before the SYN_REPLY frame for the original
> request is even sent.

Yes, you're right. And this question is still undecided and requires further
investigation. I think that we also need some sort of configuration directives
for server pushing.

wbr, Valentin V. Bartenev

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Upcoming SPDY support details

Alek Storm — Thu, 17 May 2012 08:08:01 -0400

On Thu, May 17, 2012 at 6:23 AM, Valentin V. Bartenev wrote:

> First implementation of SPDY support will work only on frontend side. So,
> nginx
> will be able to talk with backends by HTTP, FastCGI, uwsgi, or SCGI
> protocols.
>

Got it. Looking forward to backend SPDY support, so crucial advantages like
multiplexing are preserved. Will nginx at least add headers like
"X-Priority" to the forwarded request?

First implementation will have no support of SPDY server push. I believe
> that
> the next step is to add pushing by special response header from backend
> (like
> "X-Accel-Redirect" but with the list of URIs to push).
>

That'll work, but am I correct in assuming that the response containing
"X-Accel-Redirect" is different from the response to the original request?
If they are the same, then nginx will not be notified of the URIs to push
until the server is ready to send the headers for the response to the
original request. This would be more restrictive than SPDY's semantics,
which allow pushing resources before the SYN_REPLY frame for the original
request is even sent.

Alek
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Upcoming SPDY support details

Valentin V. Bartenev — Thu, 17 May 2012 07:26:00 -0400

On Thursday 17 May 2012 13:43:29 Alek Storm wrote:
> Hi all,
>
> I'm developing SPDY (draft 2) support for Tornado, a Python web framework
> that often uses nginx as a reverse proxy. AFAICT, nginx will roll out its
> own SPDY support in 1.3, to be released at the end of May or in early June.
> I'd like Tornado to complement nginx's design, but I can't find any details
> of its SPDY implementation online or in svn, so I'll ask a few questions
> here.
>
> 1. To avoid the significant overhead of an SSL connection, nginx
> communicates with the server behind the reverse proxy on unencrypted HTTP.
> However, whether to use HTTP or SPDY framing is normally decided via NPN
> negotiation during the SSL handshake. Since the backend server can't
> distinguish between a forwarded HTTP or SPDY connection without the SSL
> layer, will there be a mechanism for delegating HTTP connections to one
> address/port, and SPDY to another? Alternately, will nginx serve as an
> HTTP<=>SPDY gateway, so that all requests appear to be SPDY to the backend
> server?

First implementation of SPDY support will work only on frontend side. So, nginx
will be able to talk with backends by HTTP, FastCGI, uwsgi, or SCGI protocols.

Also, we will add a variable in nginx configuration, that will indicate client
connection by spdy protocol in case if someone wants to write it in the log or
notify the application by sending special header.

> 2. Will there be any way to take advantage of nginx's caching when pushing
> static resources that would normally be served by it? For example, the
> backend server could send a SYN_STREAM frame with the UNIDIRECTIONAL flag
> set and only the "url" header included - if the URL points to a location
> that nginx would serve, nginx takes over, filling in the rest of the
> headers and serving the file's contents.
>

First implementation will have no support of SPDY server push. I believe that
the next step is to add pushing by special response header from backend (like
"X-Accel-Redirect" but with the list of URIs to push).

wbr, Valentin V. Bartenev

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Upcoming SPDY support details

Alek Storm — Thu, 17 May 2012 05:44:00 -0400

Hi all,

I'm developing SPDY (draft 2) support for Tornado, a Python web framework
that often uses nginx as a reverse proxy. AFAICT, nginx will roll out its
own SPDY support in 1.3, to be released at the end of May or in early June.
I'd like Tornado to complement nginx's design, but I can't find any details
of its SPDY implementation online or in svn, so I'll ask a few questions
here.

1. To avoid the significant overhead of an SSL connection, nginx
communicates with the server behind the reverse proxy on unencrypted HTTP.
However, whether to use HTTP or SPDY framing is normally decided via NPN
negotiation during the SSL handshake. Since the backend server can't
distinguish between a forwarded HTTP or SPDY connection without the SSL
layer, will there be a mechanism for delegating HTTP connections to one
address/port, and SPDY to another? Alternately, will nginx serve as an
HTTP<=>SPDY gateway, so that all requests appear to be SPDY to the backend
server?

2. Will there be any way to take advantage of nginx's caching when pushing
static resources that would normally be served by it? For example, the
backend server could send a SYN_STREAM frame with the UNIDIRECTIONAL flag
set and only the "url" header included - if the URL points to a location
that nginx would serve, nginx takes over, filling in the rest of the
headers and serving the file's contents.

I'd appreciate any guidance you may have.

Thanks,
Alek Storm
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel