Nginx now supports Websockets
nginx.com
nginx.com
That'd be a dream for what I want to do. At best, we have to use Node.js as a WebSocket provider and tie it in with the PHP sessions, etc. Not as simple as I'd like.
/sarcasm
Regardless of the naysaying people will always do about PHP and long-running processes, an Nginx WebSockets proxy/backend protocol would be a huge hit for PHP developers, and as demonstrated by Ratchet, can certainly be made to work just fine.
https://github.com/cballou/php-websockets-demos
The three demos are of increasing complexity, with the third being a WTF example of adding WebSockets to an existing PHP application (in this case, a basic CRUD todo app).
Problem 1 can already be addressed by combining a Redis backend and Nginx's awesome Lua scripting engine (https://github.com/samalba/hipache-nginx). Now that problem 2 is solved as well, we might be able to port Hipache back to Nginx in the future :)
Go Nginx!
To get around that you had to add either another reverse proxy that did offload ws:// connections or run them on separate ports and deal with issues like corporate firewalls.
https://devcenter.heroku.com/articles/http-routing#websocket...
https://devcenter.heroku.com/articles/using-socket-io-with-n...
If this is the case, and you're running a pure TCP application like IRC, you still need a separate Websocket-to-TCP bridge application running on the server to sit between nginx and your IRC server. How is this an improvement from the status quo? ("IRC" is just an example, you can feel free to replace it with your favorite protocol.)
Granted, this change makes life a little easier for users behind outbound-restricting firewalls, since you can now multiplex both HTTP and IRC on port 80. But IMHO it would be more logical to just have nginx directly proxy the IRC server to the client-side JS over Websocket.
Then again, maybe this patch is as close as it's possible to get without major revisions to the Websocket protocol: With Websocket's non-optional framing "feature," you might need IRC-specific knowledge to translate an IRC stream into frames in a way that won't break anything.
Any Websocket experts are welcome to weigh in!
But for those of us who are writing websockets-enabled web applications and trying to run them in nginx-heavy environments, just being able to share a port is a significant improvement over the status quo!
Isn't that what the "supporting websockets for the proxying layer" statement means? I don't even know why you'd expect anything else to happen.
> it would be more logical to just have nginx directly proxy the IRC server to the client-side JS over Websocket.
Again, I don't see the logic there at all. There is a TCP proxy external module you can compile in (and that was how you'd get it to proxy websocket connection before). But you want nginx to proxy and arbitrarily translate between some random protocol and transport of your choice.
> With Websocket's non-optional framing "feature," you might need IRC-specific knowledge to translate an IRC stream into frames in a way that won't break anything.
Yes framing is a feature. Why are you including in quotes sarcastically implying it is a bad feature.
It sounds like you just need a firewall with some rules, if you just want plain TCP connections to be forwarded to your backend, why involve a nginx at all then?
> Why are you including in quotes sarcastically
Because framing means the websocket spec can't easily support this use case.
> if you just want plain TCP connections to be forwarded to your backend
That's exactly what I want -- from a Javascript client in an unmodified browser.
AFAIK I can't get such connections in JS clients; I can only get the Websocket protocol.
I was thinking some cool hacks become possible if you could talk to an arbitrary TCP server from JS, using nginx as the middleman (with all its scalable non-blocking goodness).
Too bad Java is going the way of the dodo; Java applets could do TCP connections to the same origin back in the '90s.
Yes that would be cool. Websockets make it doable. Framing is not as big of an issue. Most TCP based protocols (save for file streaming) already have some messaging at a higher level. In IRC you can think of the line as a message.
Almost every protocol I built on top of the TCP transport had to have framing and I had to mess with buffers, message headers, terminators, partially filled messages.
> I can only get the Websocket protocol.
One cool new feature is WebRTC it should support a datachannel connections and peer-to-peer (now you can make the web server a peer as well). So there it seems would be another case of streaming binary data to the server.
> I was thinking some cool hacks become possible if you could talk to an arbitrary TCP server from JS,
Yeah that would be cool. JS code would instead have to dealt with websockets or WebRTC data channels. It wouldn't open a TCP, socket, bind, listen, connect all those things. Now on the server side you can anything you want. For example I like the web STOMP adopter that RabbitMQ people have. You can effectively send and receive MQ (STOMP) messages from a browswer to an exchange. That is cool. There are VNC viewers built with websockets and canvas. So it is doable but I don't think its place is to put in nginx as a standard compiled in features. These all can be plugins.
Hope that helps! (IRC is also quite handy today)
Now all we need is WebRTC.
Up until this release, anyone running both HTTP and WebSockets behind nginx has had to run them on separate ports (i.e. HTTP = 80, WS = 8080) and then use TCP proxying to load balance the websocket connections. Nginx didn't natively understand the Upgrade header - but now it does so you're free to use port 80 for everything.
But now nginx lets you multiplex those websocket connections over good old port 80 or 443, while still supporting regular HTTP(S) on those ports at the same time.
https://github.com/nodejitsu/node-http-proxy/
Easy to set up, and has the benefit of reducing the number of processes I need to maintain (my node server and my proxy server are the same).
1. Run nginx with something like HAProxy/Varnish infront
2. Run nginx alone with the app server on port 80/443 and the websocket server running on a special port. The app was then proxyed using the built in http_proxy, while the websocket was handled by tcp_proxy.
http://trac.nginx.org/nginx/roadmap
It's only SPDY/2 for now although SPDY/3 eventually.