4 ms·
Seamless SPDY support for existing web servers (SPDY-HTTP reverse proxy)
- ck2 15y agoIt'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.
- JoshTriplett 15y agoStill seems likely to help, since the HTTP connection can go over a fast, low-latency loopback interface.
- ma2rten 15y agoThe 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.
- jganetsk 15y agoSPDY 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.
- cenuij 15y agoWhy not just use Go? you get SPDY and latest websocket, the worst part? Oh you might have to write some code that matches a few Go interfaces. Boohoo my fingers don't hurt anymore.
- venti 15y agoI had a look at the code on GitHub and could only find code that seems to start and stop threads. Is there more coming?
- MarkSweep 15y agoI 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.
- pquerna 15y agoAuthor 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.
- utunga 15y agoseems 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
- tbatterii 15y agoI agree, as it's described, it sounds like the equivalent of putting nitrous and a spoiler on a chevette.
- moonboots 15y agoI'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 15y agoExactly; 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.
- jganetsk 15y agoYes, keep-alive does confer many advantages of SPDY. But it does not solve head-of-line blocking.
- willvarfar 15y agoImagine 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