SPDY proxy?

[Lars Eggert]

Hi,

wondering what the status of http://www.chromium.org/spdy/spdy-proxy is? A continuation of the work we've been doing with Binoy would benefit if a SPDY proxy were available. Is anyone working on this?

Thanks,
Lars

[William Chan (陈智昌)]

[ +rch ]

Yes, Ryan is working on this.

[Mike Belshe]

On Tue, Sep 28, 2010 at 7:25 AM, William Chan (陈智昌) <will...@chromium.org> wrote:

[ +rch ]

Yes, Ryan is working on this.

To expand on this a bit - yes - efforts are underway.  I'm not sure if that will be a public tool.  One of these days, if nobody else gets to it, I'm going to hack on the in-mem-server to turn it into a proxy and put it in front of belshe.com :-)

Mike

[Roman Shterenzon]

I'm curious...

Regarding the http://www.chromium.org/spdy/spdy-proxy - what is the
reasoning behind tunneling SSL through SPDY? It looks like an
additional overhead without any added benefits. Should several SSL
streams be tunnelled through one SPDY session?

And regarding putting such a proxy before your website - I think that
the current chrome doesn't yet support Alternate-Protocol: XXX:spdy/2

--Roman

[Ryan Hamilton]

Howdy,

Yes, work is proceeding on the SPDY Proxy proxy.  The most visible public effort at the moment is adding support in Chromium for talking to a SPDY (aka HTTPS proxy).  You can follow the progress in this issue in the Chromium bug system.  On the server side, we have added support in the open source Apache module mod_spdy so that when used in conjunction with mod_proxy, Apache can act as a SPDY Proxy.  In addition, I have implemented a stand-alone SPDY proxy based on the flip in-memory server code base, and just need to commit it to the Chromium tree.

Cheers,

Ryan

[Ryan Hamilton]

Hi Roman,

Tunneling SSL through a SPDY Proxy does add extra overhead.  In many circumstance, you are right, this overhead does not provide any additional benefits.  In such circumstance, it would make the most sense to use such a SPDY Proxy only for HTTP urls (for example with a proxy.pac that sends HTTPS URLs direct).  However there are also scenarios when tunneling SSL through a SPDY Proxy makes sense.  One simple case is using a SPDY Proxy as a "web VPN".  Such a proxy would know how to connect to hosts which do not have hostnames that resolve publicly.  This would allow users to send both HTTP and HTTPS traffic through the proxy for hostnames that they are unable to reach directly.  This would allow a SPDY Proxy enabled browser to be a VPN client.

Cheers,

Ryan

[Mike Belshe]

On Tue, Sep 28, 2010 at 8:35 AM, Roman Shterenzon <roman.sh...@gmail.com> wrote:

I'm curious...

Regarding the http://www.chromium.org/spdy/spdy-proxy - what is the
reasoning behind tunneling SSL through SPDY? It looks like an
additional overhead without any added benefits. Should several SSL
streams be tunnelled through one SPDY session?

The multiplexing makes it valuable - a single SPDY connection can multiplex many HTTP and SSL streams concurrently.  So, the device can make just one TCP connection to the proxy, and then just send everything. 

Even better (we are not working on this though) might be the idea of a "trusted proxy", where all requests (secure or not), could be sent securely to the proxy, and then the proxy could rewrite as standard HTTPS on the other side.  This could be a useful solution for sites that today implement SSL-MITM solutions with certificates.

And regarding putting such a proxy before your website - I think that
the current chrome doesn't yet support Alternate-Protocol: XXX:spdy/2

It does.

Mike

[Lars Eggert]

Hi,

On 2010-9-28, at 21:14, Ryan Hamilton wrote:
> Yes, work is proceeding on the SPDY Proxy proxy. The most visible public effort at the moment is adding support in Chromium for talking to a SPDY (aka HTTPS proxy). You can follow the progress in this issue in the Chromium bug system.

great, thanks!

> On the server side, we have added support in the open source Apache module mod_spdy so that when used in conjunction with mod_proxy, Apache can act as a SPDY Proxy.

I think I dimly remember that Binoy mentioned that the SPDY version in mod_spdy was older or otherwise less capable than the one in flip. Has this changed (or am I misremembering?) We'd obviously be mostly interested in testing the most recent SPDY flavor.

> In addition, I have implemented a stand-alone SPDY proxy based on the flip in-memory server code base, and just need to commit it to the Chromium tree.

Great, I think that'd be the best basis for our testing. We'll check it out when it's available.

Thanks,
Lars

[Bryan McQuade]

mod_spdy is out of date with respect to chromium trunk, but it's easy
to sync since we just pull our spdy encode/decode code from chromium's
repository. If that'd be helpful for you, just let me know and we can
sync the code with the Chrome 6 release.

Currently the main drawback to mod_spdy is that it doesn't yet support
true multiplexing. Since apache is designed to process one request per
connection at a time, we currently build a queue of incoming requests
and process them serially, one at a time. This can be sub-optimal in
that a request at the head of the queue can block processing of
requests deeper in the queue. If you are ok with the current queuing
behavior then mod_spdy should work just fine for you once we sync with
Chrome 6, but it's important to keep the queuing limitation in mind
when doing performance testing.

Matthew, who was working on mod_spdy, wrote up a nice document
describing our proposal to add multiplex support in mod_spdy. It's
somewhat difficult but not impossible to get this working in apache.
You can read more about it here:
http://code.google.com/p/mod-spdy/wiki/MultiplexIdeas

We welcome code contributions if you are interested in contributing to
mod_spdy. We just ask that contributors share their ideas first so we
can discuss them, before sending the finished code out for review.

Thanks!
-Bryan

[Roman Shterenzon]

>> And regarding putting such a proxy before your website - I think that
>> the current chrome doesn't yet support Alternate-Protocol: XXX:spdy/2
>
> It does.
> Mike

Then I believe that I'm missing something.
I did a simple test with the sample Rack (http://rack.rubyforge.org/)
application pasted below, it just returns the Alternate-Protocol,
Content-Type and Content-Length. The Chrome 6.0.472.63 doesn't attempt
to connect to the specified port on first access, neither when the
link is followed.
I looked into Chromium sources once, and I think that only npn-spdy
was supported at that time, but not other forms which are specified
here:
http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2#TOC-Server-Advertisement-of-SPDY-throug

--- cut here ---

use Rack::ContentLength

headers = {
'Content-Type' => 'text/html',
'Alternate-Protocol' => '10040:spdy/2'
}

body = <<EOF
<html>
<head><title>test</title>
</head>
<body>
<a href='/hello'>Hello world!</a>
</body>
</html>
EOF

app = lambda { |env| [200, headers, body] }
run app

--- cut here ---

--Roman

[Mike Belshe]

On Wed, Sep 29, 2010 at 10:01 AM, Roman Shterenzon <roman.sh...@gmail.com> wrote:

>> And regarding putting such a proxy before your website - I think that
>> the current chrome doesn't yet support Alternate-Protocol: XXX:spdy/2
>
> It does.

Sorry I didn't realize you were asking for the non-TLS version of this.  Chrome will only follow it for NPN spdy, which would be:

Alternate-Protocol: XXX:npn-spdy/2

Mike