LWN.net Logo

Reducing HTTP latency with SPDY

Reducing HTTP latency with SPDY

Posted Nov 20, 2009 9:17 UTC (Fri) by Kamilion (subscriber, #42576)
Parent article: Reducing HTTP latency with SPDY

Is it just me or does this sound a lot like what you would end up with if I asked you to describe the concept "HTTP Over SSH" in detail?

This sounds like a job for

subsystem /usr/bin/sshttpd


(Log in to post comments)

Reducing HTTP latency with SPDY

Posted Nov 20, 2009 12:53 UTC (Fri) by butlerm (subscriber, #13312) [Link]

Yes. Although SPDY does other things like header compression that would have
to be done above the SSH level. And SSH would have to be adapted to do
TLS/SSL style certificate validation. TLS over SSH would be rather
redundant, encryption wise.

Reducing HTTP latency with SPDY

Posted Nov 22, 2009 12:00 UTC (Sun) by Kamilion (subscriber, #42576) [Link]

SSH2 supports zlib stream compression.

Honestly, I think I prefer SSH's key exchange over TLS.
But then again, they protect different sorts of things.

RFC 4255 sort of makes that moot though, by publishing the server's public key fingerprint hash in the DNS record. Still, if you force a handshake with an unknown domain, DNS is easy to poison as well.

Would SPDY be better off as being considered a new type of proxy protocol to something like squid that could maintain and cache data instead of a server access protocol?

Also, most people tend to forget that encryption isn't mandatory for SSH data channels.

There's no reason why you couldn't pass HTTP/1.1 as is over a SSH channel to a named subsystem.

And sshttpd is as good a name as any, I suppose.

Though, I must ask...

I am one of those crazy bastards with hundreds of open tabs across multiple monitors.

Right now, most of them lay dormant, eating only my own resources.

How can I justify maintaining an open channel to each of these hundreds of sites and servers when I can only realistically balance about six in view?
(TooManyTabs for Firefox helps a bit...)

How many more out there are there like me that care?
How many more that won't care how many resources they abuse?

It's sort of rhetorical and doesn't really require a response, however, I am still curious as to other's viewpoints and opinions.

Reducing HTTP latency with SPDY

Posted Nov 27, 2009 1:36 UTC (Fri) by efexis (guest, #26355) [Link]

I think maybe many of those many tabs you have open may be facing sites that don't need to keep the connection to you open after the data is transmitted and so will just get closed... in the mean time, if one of those pages has a long URL you've used to access it (which includes form GETs), that URL gets sent to each subcomponent request of the page that needs fetching (images, iframes, scripts) as the HTTP REFERER... as does any set cookie string. While a protocol that allows you to send those only once may not be a big win for you, for a server that's dealing with tens/hundreds of thousands of requests a minute, that's a massive saving, as it is for the series of tubes connecting that server to you.

For sites that do want to keep the connection open there could be additional savings for the server. Imagine the normal process of doing this (for instant message delivery etc) involves you opening a connection to the remote web server, which parses your request, and then fires up an instance of perl or php etc to handle it. To hold the connection open, that instance of perl/php will stay running, holding the connection open, and printing to it should it need. With a multiplexing connection this needn't be true; a minimal connection handling server can stay running, holding details of the connection (inter-connection persistent headers etc) in its memory, but allowing the script process to unload until next needed again, if it's needed again. The other option is that other request handlers may be able to open a channel to you through the held open connection and send data to you. Without this (assuming an instant-messenging model) both the sender and receiver of the message would each have their own instances of the script processor running, with the process handling the senders request connecting to the process handling the receivers request, and sending it the message which it would then bounce on to you.

So yeah don't worry about it, this should all mean you can keep all your tabs open, and now with up to 50% less guilt! :-)

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds