On: Seamless SPDY support for existing web servers (SP...

[utunga]

seems to me that one of the main ways SPDY speeds things up is by sending of hints and attached content all in one connection. If you are proxying over http, you can't have access to any of the domain specific information, and thus you won't see hardly any of the SPDY benefits

[jganetsk → utunga]

I'm not sure if that's one of the most important parts of SPDY. Multiplexing multiple streams over one TCP connection and differentiated quality of service (some streams have higher priority than others) still work perfectly in this kind of system, and provide huge benefits.

[simonw → utunga]

I don't know the details of how SPDY works, but could this proxy be taught some custom HTTP headers (X-SPDY-Hint: /static/site.css) which can be trivially sent by the proxies application and could be used to enable advanced SPDY features?

[jganetsk → simonw]

Yes, this could totally work in SPDY.

[moonboots → utunga]

I'm not sure what you mean by lack of domain specific information and hints. A SPDY proxy shifts the expensive aspects of HTTP from high latency client-server connections to proxy-server connections where they are comparatively cheaper due to lower latency.

[willvarfar → moonboots]

Exactly; my take is clients connecting over Internet via SPDY to a gateway that uses HTTP keep-alive over LAN to your servers confers most of the advantages of SPDY.

[moonboots → willvarfar]

SPDY improves upon keep-alive by reducing the number of connections that need to be created and in eliminating blocking.

SPDY reduces the number of persistent HTTP connections between client and server from around six (depending on browser) to one. High latency connections increase the time required to create these initial connections, and round trip times have not been consistently declining despite bandwidth improvements.

HTTP requests over each keep alive connection are blocking, i.e. the server must response before another request can be made. SPDY addresses this blocking by multiplexing requests and responses. Note that the head-of-line blocking that jganetsk mentioned is a separate issue.

[jganetsk → willvarfar]

Yes, keep-alive does confer many advantages of SPDY. But it does not solve head-of-line blocking.

[willvarfar → jganetsk]

Imagine nginx spoke SPDY. Now replace nginx with this new proxy. Now imagine that its talking keep-alive HTTP on the inside.

The gateway can even send the incoming requests between many servers and aggregate the results and send them back to the client out of order, as per SDPY

[jganetsk → willvarfar]

I agree with you. My point was that a reverse proxy that does not speak SPDY on the outside would suffer from head of line blocking.

[tbatterii → utunga]

I agree, as it's described, it sounds like the equivalent of putting nitrous and a spoiler on a chevette.