9 ms·
Nginx now supports Websockets
- Doublon 14y agoThis day has finally come!
- krob 14y agoNow how to interact with their support, and hopefully some tutorial on integration with the multitude of different languages.
- kcbanner 14y agoThis has nothing to do with languages. Nginx can now proxy WebSockets to arbitrary servers.
- r3demon 14y agoGreat news!
- trebor 14y agoWhat nginx needs to become the ultimate platform, in my opinion, is to provide an API for interacting with WebSockets by transient processes (such as PHP). That way it acts as a surrogate pub-sub handler, whether or not your instance stays as a running process. 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.
- the_gipsy 14y agoPHP simply is not suited for long lived processes. If you only want the ability to push something to clients without polling, then maybe you could set up something very simple with python, and communicate over redis or some other MQ.
- 0x0 14y agoWhat makes you say that? I've been running several PHP processes for weeks at a time with no problems, feeding on busy TCP connections for the whole time.
- the_gipsy 14y agoI didn't say that you can't do it.
- 0x0 14y agoBut why do you find it unsuitable?
- Shorel 14y agoIt has ugly syntax and bad standard function names, and some people code ugly things with it. /sarcasm
- the_gipsy 14y agoIt is build around a model of process input, spit output, exit; which is not what you want for long living processes. There are many articles about it's flaws, my favourite is this one: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
- elliotanderson 14y agoA few years ago I would have agreed, but I have several PHP daemons consuming messages from RabbitMQ and their uptime is in the range of months. Throw a little supervisord into the mix to keep an eye on things and you'd be surprised how far it has come.
- MartinMond 14y agoYou mean like https://github.com/wandenberg/nginx-push-stream-module https://github.com/wandenberg/nginx-push-stream-module? :)
- lux 14y agoRatchet (http://socketo.me/ http://socketo.me/) has started to make this easier. 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.
- jqueryin 14y agoI recently did a presentation on Ratchet with working demos. You can view all of the source code via the github repository: https://github.com/cballou/php-websockets-demos 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).
- lux 14y agoCool, browsing through your demos now!
- trebor 14y agoRatchet does look nice, but has several deployment dependencies and architectural constraints. Hopefully with nginx now adding the features to be a WebSocket proxy you could get HAProxy out of the way (unless you wanted it).
- FooBarWidget 14y agoNow that Nginx supports WebSockets, Phusion Passenger can start supporting WebSockets as well and allowing all hosted apps access to it. Node.js support is experimental, and there are plans to support PHP and other languages as well.
- deleted 14y ago[deleted]
- pornel 14y agoEarlier discussion: http://news.ycombinator.com/item?id=5240356 http://news.ycombinator.com/item?id=5240356
- churreiro 14y agoGood news, finally, not just need to wait couple of months until they solve all the initial bugs to migrate our existing apps! ;)
- ck2 14y agoWow, realtime upvoting/downvoting for everyone now :-)
- davidw 14y agoWhat were people using previously? Just plopping their node.js or whatever straight on the network?
- istvanp 14y agoWe are using HAproxy to direct traffic and nginx only as a web server. The config looks something like this: http://stackoverflow.com/a/8640394/218413 http://stackoverflow.com/a/8640394/218413
- adamkittelson 14y agoSomething like varnish or haproxy. In my setup I had varnish proxying "/websocket" directly to my app server, and everything else to nginx.
- brendanobrien 14y agoI've been using HAProxy in the interim.
- jsharpe 14y agoI use python's Tornado webserver directly on the network. Don't know if it's the best idea, but seems to work fine for my purposes.
- dcraw 14y agoI've had good results so far with node-http-proxy: https://github.com/nodejitsu/node-http-proxy/ 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).
- mason55 14y agoHey... saw your comment here http://news.ycombinator.com/item?id=5172775 http://news.ycombinator.com/item?id=5172775 about the work you did on unrolling arrays in mongo_fdw. Any chance you can email me about it (that thread is closed). username @ gmail.com
- 14y ago
- azakai 14y agoExcellent! Now all we need is WebRTC.
- twistedpair 14y agoAnd for most corporations like mine to stop blocking websockets. What do you mean let some odd port through the firewall?
- mateuszf 14y agoHow about serving it using SSL on port 443?
- infamouscow 14y agoWebSockets over SSL (wss://) work just fine. Faris Chebib provided a nginx config file in #nginx earlier today. https://gist.github.com/octaflop/4991052 https://gist.github.com/octaflop/4991052
- elliotanderson 14y agoWebsockets run on port 80 natively. It's all done through a HTTP Upgrade header to turn the connection into a websocket. 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.
- ef4 14y agoThat's the beauty of this nginx feature. Up until now, the easiest way to add websockets to an existing application was to put them on a separate (weird) port. 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.
- felipesabino 14y agoSo hopefully heroku will soon be able to support Web Sockets instead of only xhr-polling https://devcenter.heroku.com/articles/http-routing#websockets https://devcenter.heroku.com/articles/http-routing#websocket... https://devcenter.heroku.com/articles/using-socket-io-with-node-js-on-heroku https://devcenter.heroku.com/articles/using-socket-io-with-n...
- Nikkau 14y agoThey are busy trying to be able to support Rails apps for now.
- creativename 14y agoThis. I really hope they're able to get that integrated soon. That would be awesome.
- michaelneale 14y agoBoth cloudbees and apcera co-funded this feature for that reason. Heroku do have a routing mesh with more moving parts than just nginx though - so it will likely be a much harder change for them.
- andyfleming 14y agoIs there any documentation on usage?
- foenix 14y agoNot really, but I used this link: http://trac.nginx.org/nginx/changeset/5073/nginx http://trac.nginx.org/nginx/changeset/5073/nginx to set up this config: https://gist.github.com/octaflop/4991052 https://gist.github.com/octaflop/4991052 for this server: https://gist.github.com/octaflop/4991187 https://gist.github.com/octaflop/4991187 hosted on this site: https://legionofevil.org/ https://legionofevil.org/ Hope that helps! (IRC is also quite handy today)
- pixie_ 14y agoThis should fix my problem of not being able to connect to my site though a corporate firewall because I run multiple tornado instances on a single server on different ports. Before nginx wasn't able to route port 80 requests to the chat sub-domains, but now it will be able to.. w00t
- MatthewPhillips 14y agoThis announcement is a little light on details. What does Nginx supporting WebSockets even mean? Isn't it just looking for ws:// and proxy-passing that on to your application?
- pkulak 14y agoIt's looking for the upgrade header in HTTP, and then, yes, proxying that connection.
- sprobertson 14y agoYup, nice to have this built in rather than relying on an additional layer (Varnish, HAProxy, 3rd party module, etc.)
- elliotanderson 14y agoAs pkulak said, Nginx didn't understand the Upgrade header so you couldn't proxy http and ws connections on the same port. 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.
- csense 14y agoDoes the backend which nginx talks to have to speak the Websocket protocol? 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!
- jcheng 14y agoThe changes to nginx appear to be to support HTTP Upgrade in general, nothing specific for websockets. But I can't think of any other upgrade protocols that general purpose web browsers would give your JS code access to. 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!
- rdtsc 14y ago> Does the backend which nginx talks to have to speak the Websocket protocol? 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?
- shykes 14y agoThis is great. At dotCloud we've reluctantly ported our distributed routing layer (http://github.com/dotcloud/hipache http://github.com/dotcloud/hipache) from Nginx to Node + node-http-proxy, because we needed 1) high-volume dynamic configuration and 2) websocket support. Problem 1 can already be addressed by combining a Redis backend and Nginx's awesome Lua scripting engine (https://github.com/samalba/hipache-nginx 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!
- kevinfat 14y agoSo in practical terms how does one setup backends to use WebSockets. For example, suppose you have nginx in front of a bunch of Unicorn or Rainbow processes and there are two clients that have made websocket connections. Consider a chat application. One of them sends a websocket message and the backend that receives it needs to push the message along the other websocket connection. But how does it know which backend to forward to? What is the intended idiomatic way of maintaining the necessary state?
- taylorbuley 14y agoThink of it like an HTTP request, except a two-way and very long-lived. Not too unlike Comet except with a secure-by-design approach. http://en.wikipedia.org/wiki/Comet_(programming) http://en.wikipedia.org/wiki/Comet_(programming)
- kevinfat 14y agoI've never dealt with Comet. I need the long detailed answer for complete noobs.
- jacobolus 14y agoThe old version of that wikipedia article had a bit more background explanation: http://en.wikipedia.org/w/index.php?title=Comet_%28programming%29&oldid=215165715 http://en.wikipedia.org/w/index.php?title=Comet_%28programmi...
- kevinfat 14y agoIf I am understanding correctly the suggestion is to have a distributed hash table that any backend can lookup to find the other backend it should forward to. And since the distributed hash table is critically important persistent data I'm assuming that using something like Memcached is not a good idea? What would be advisable instead?
- mc 14y agoWhat's the difference between this new support and the nginx-push-stream module? https://github.com/wandenberg/nginx-push-stream-module https://github.com/wandenberg/nginx-push-stream-module
- mnutt 14y agonginx-push-stream handles the websocket connections itself and exposes a pubsub channel, so that your backend app doesn't have to worry about holding connections open. Whereas I believe the new websocket functionality allows you to proxy to websocket-enabled backend apps.
- mc 14y agoGood comparison. Thanks.
- tslocum 14y agoAny ETA on SPDY support being included (instead of requiring a patch)?
- newman314 14y agoLooks like the next release. http://trac.nginx.org/nginx/roadmap http://trac.nginx.org/nginx/roadmap It's only SPDY/2 for now although SPDY/3 eventually.