I wonder how SPDY would work in a load-balanced environment.
- Should the load balancer use implement SPDY externally and use HTTP internally? - Should internal request be 100% SPDY-only and the load balancer implement both?
- Should the load balancer use implement SPDY externally and use HTTP internally? - Should internal request be 100% SPDY-only and the load balancer implement both?
Seems like SPDY would be beneficial as a replacement for HTTP everywhere though, because the payload for each request is smaller. However, SPDY seems to be optimized for the longer, higher latency, and slower connection between user and server rather than the faster internal connection between load balancers and servers. Finally, all SPDY communication is encrypted via TLS, so that process might add to a slowdown between internal systems.
Guess we'll need to benchmark it and see! Looks like Apache and Jetty are the only supporters of this so far. And I'd never us Apache as a direct front-end.
For simplicity put SPDY on the edge and reverse proxy HTTP to whatever you used to use, this gets you 90% of the way there.
In the future, I expect we'll see tools like Mongrel2 take over. SPDY on one end, and some type of messaging on the other side. This will become more desirable with technologies like web-sockets that will stream data back. HTTP is simple, but hardly optimized for speed, even on a LAN. Thrift, Protobuffs, MessagePack, even Erlang's Binary Protocol (i.e. BERT) are all better fits for the internal RPC protocol