First, you need to worry about the security implications of each internal server that you expose intentionally. Just how much damage can someone with direct access to your Redis instance cause? Better read http://redis.io/topics/security, and repeat this for every other service you want to expose.
Second, you are going to effectively need a whitelist of allowed connections, either in the proxy, or at the firewall level (which most people are going to forget to configure, if they even know how). Without that you are going to allow arbitrary bypass of your firewall for internal services, as well as effectively running an open proxy for anyone looking to bounce their malicious traffic through your server.
If you want a client-side app that uses TCP, why must you do it over the web? The appeal of write-once-run-everywhere?
It's not entirely bogus, just mostly so. I really dislike this whole "the internet == the web" way of thinking, though.
Down that path lies madness.
So it's really more like a NAT bridge.
WebBrowser --- data ---> WebTCP bridge (translate data to servers) --- data ---> redis/rabbitmq/any_tcp(and i think udp also possible?)_server_even_smtp
We really need to stop reinventing the wheel
Pub/sub is well catered for by socket.io (websockets).
This glue belongs on the server.
If I did need arbitrary TCP connections my first thought would be a websocket proxy...
That is to say, if you need a TCP connection to any server, you probably should not be implementing it over HTTP (well, this is where definitions get difficult, since you know, HTTP is technically TCP. Fuck)
There is always a chasm between whipping up a cool hack and making something usable. This hack needs a long bridge in between.