Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
This sounds like a job for
Reducing HTTP latency with SPDY
Posted Nov 20, 2009 12:53 UTC (Fri) by butlerm (subscriber, #13312)
Posted Nov 22, 2009 12:00 UTC (Sun) by Kamilion (subscriber, #42576)
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.
Posted Nov 27, 2009 1:36 UTC (Fri) by efexis (guest, #26355)
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