Seamless SPDY support for existing web servers (SPDY-HTTP reverse proxy) | Hacker News Reader

Seamless SPDY support for existing web servers (SPDY-HTTP reverse proxy)

github.com

53 pointsmoonboots18 comments

I had a look at the code on GitHub and could only find code that seems to start and stop threads. Is there more coming?

I was scratching my head looking around the code until I saw this huge text in the README:

STATUS: incomplete, prototype, work in progress, non-functional, etc, etc

The rest of the README is aspirational. It's a little confusing.

Author here: Yes, the README is aspirational, its a checklist for myself. I put the STATUS line there for everyone else, but it appears no one actually reads it. (Heck, not one other person on HN actually tried it out, because it sure as heck doesn't work yet).

I hadn't put any publicity out about the code yet, I had just pushed it up to github a few days ago because I wanted to move the code around to some other machines, I didn't expect anyone to pick it up.

It's a neat trick but I'd need to see benchmarks that prove this is beneficial.

Natively sure, but through the overhead of a reverse-proxy? Hmm.

Still seems likely to help, since the HTTP connection can go over a fast, low-latency loopback interface.

The overhead of a reverse proxy in terms of latency is essentially zero. Just think about it like this: with HTTP sometimes you need to wait for some extra packages to go back and forth. These packages need to travel over the Internet. You can trade in these packages with packages, which travel though your loopback device. Seems like a good bargain to me.

Also to make benchmarks, it helps to have a working product first.

SPDY wouldn't just help on an isolated benchmarkable level; if the Internet en masse significantly decreased the total number of TCP connections, there would be a benefit to the herd. Congestion control would just work better. It's hard to measure such things.

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

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

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.

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.

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

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

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.

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.

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.

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?

Yes, this could totally work in SPDY.

Reply on news.ycombinator.com