WebSocket proxy support added to nginx trunk

http://trac.nginx.org/nginx/changeset/5073/nginx

by runesoerensen • 13 years ago

261 54 13 years ago

trac.nginx.org

thruflo• 13 years ago

That's excellent news! Having explored the workarounds, involving additional layers of deployment stack and / or manual compilation, I'll be delighted when this gets released and package managed.

Hello71• 13 years ago

*packaged

gritzko• 13 years ago

At last!

andyfleming2• 13 years ago

Agreed! I'm excited to see this functionality making its way into nginx. Any details on when it will be officially released and make its way into repositories?

alexjarvis• 13 years ago

This is nice to see. I wonder how it compares to HAProxy http://haproxy.1wt.eu/ which also works with SSL and Secure WebSockets (wss://).

densone3• 13 years ago

The only thing better than haproxy and not by a long shot would be something like a bigip. My 2 pennies.

moomin• 13 years ago

If all you're looking for is proxying, I'd agree. But nginx remains a good solution for caching + proxying.

jlongster2• 13 years ago

How long does it usually take for things to go from trunk to release? This will be awesome when it's ready because I can keep my production stack really simple. All the existing solution for proxying sockets seemed way too complex, and I typically just run them on different IPs, but even that's annoying.

moonboots2• 13 years ago

The next dev release with websocket proxy support is scheduled for tomorrow [1].

[1] http://trac.nginx.org/nginx/roadmap

andyfleming2• 13 years ago

Any date/guess on a production release?

alptrv2• 13 years ago

Can anyone explain how proxying websockets wouldn't hit the port number limit on the proxy server? If I understand correctly, when we would proxy tcp connections the workers on the backend server would able to hold only up to 64k connections to the proxy server (in the case when proxy server has only one IP-address)? Am I missing something?

wmf3• 13 years ago

Yep, you need multiple IP addresses and other tricks to create over 64K connections to a single backend: http://www.metabrew.com/article/a-million-user-comet-applica...

One workaround that comes to mind is to have each backend listen on multiple ports.

alexkus• 13 years ago

You don't need any special tricks in the backend. The only limits on the backend are the number of file descriptors.

You only need special tricks when you want to simulate a large number of client connections from a single machine (or bunch of machines). The client(s) have a requirement of a unique IP/source-port combination; not the server.

chatmasta• 13 years ago

Could someone explain why this is helpful? What's an example of a use case where this becomes one of the better solutions?

craigching• 13 years ago

Sorry if this is obvious, but you need it when nginx is your front-end and you want to use web sockets without exposing your backend. A lot of people deploy nginx in their DMZ because of its security and don't want to expose their backend servers, e.g. JEE or Ruby or what have you.

Wintamute• 13 years ago

AFAIK there aren't that many robust approaches for reverse proxying web sockets. Apache mod_proxy doesn't work with web sockets, nginx (until now) only worked with websockets if you compiled and patched an unstable dev branch yourself, and not everyone was happy to get their hands dirty with HAProxy. An alternative was to build your own reverse proxy in Node.JS using node-http-proxy, but again, not everyone's cup of tea.

Use cases of websockets enabled reverse proxies are for when you have a number of websockets based apps all sitting on the same box or in the same private local network and you need a way to route incoming traffic to them based on the hostname or path or whatever.

imsofuture2• 13 years ago

FWIW, I've found HAProxy even more joyous to work with than nginx.

exratione• 13 years ago

See this series of posts:

http://www.exratione.com/2012/07/proxying-websocket-traffic-...

http://www.exratione.com/2012/08/websockets-over-ssl-stunnel...

http://www.exratione.com/2012/12/websockets-over-ssl-haproxy...

"So let us say that you are developing a Node.js / Socket.IO application that both uses websockets and serves files the old-fashioned way, such as through Express - this is a fairly common situation. You want to have an HTTP proxy server rather than Node.js field all incoming traffic, so that you can set up load balancing, route requests for static files to some other server process, avoid having to set up SSL configuration in Node.js, and so forth.

"Unfortunately at this point in time it isn't completely straightforward to proxy both websocket traffic and ordinary web requests for Node.js through a single port - which would be the ideal situation. It becomes even less straightforward if you want to use SSL. The following is a brief overview of present options as of early Q3 2012."

"The up-front summary: if you are reading this after Nginx adds support for proxying websocket traffic to Node.js (supposedly coming up in version 1.3), then everything is rainbows and unicorns - just use Nginx. If you are reading this prior to Nginx support for proxying of websocket traffic, then you will likely have to do more work and investigation in order to create a good proxy setup for your servers."

sujithr• 13 years ago

Now you won't need a separate reverse proxy for Websockets. That also means, with just nginx, now you can have both websocket and http on the same url subdomain (for same origin policy and sharing ssl certificate etc).

tlrobinson• 13 years ago

Does this support sticky sessions?

Normally I think it's best for HTTP backends to be stateless, but WebSockets open up interesting possibilities for RPC solutions like NowJS (https://github.com/Flotype/now), dnode (https://github.com/substack/dnode), and others (https://github.com/kriskowal/q-connection) that benefit from keeping state in memory in the app servers.

I'd be interested to hear about other load balancing techniques for WebSockets.

runesoerensen• 13 years ago

I'd expect the ip_hash directive to work as usual http://wiki.nginx.org/HttpUpstreamModule#ip_hash although it's not exactly sticky sessions. There's a separate module for that https://github.com/michaelneale/nginx-sticky-module

mattyb• 13 years ago

HAProxy can, reportedly, load balance WebSocket connections:

http://blog.exceliance.fr/2012/11/07/websockets-load-balanci...

dotCloud's Hipache also looks like it was basically written to solve this problem:

https://github.com/dotcloud/hipache

jabr3• 13 years ago

WebSockets are persistent connections, not a state-management trick spanning multiple connections/requests. The only time nginx is involved in "routing" the socket is on the initial connection. Once established, nginx is simply relaying data over an active, persistent TCP/unix sockets.

For the initial connection, you can use any of nginx's normal proxy load balancing options (ip_hash, least_conn, etc).

pixie_• 13 years ago

This 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

adamkittelson• 13 years ago

Right on!

I'm using nginx and thin, but I'm currently having to use varnish for proxying my websocket connections to thin because nginx can't do it. Then I have to use stunnel for ssl termination because varnish doesn't support it. I'll be able to cut both of those pieces of software out now.

densone3• 13 years ago

Why not just use haproxy?

mattdawson• 13 years ago

It's been over a year since I had to set this up, but I used HAProxy in a similar setup and still needed stunnel.

In the whole of my DevOps career, getting SSL working with web sockets was one of the most frustrating.

jenandre2• 13 years ago

We're using this to reverse proxy websockets over SSL and it's simple and wonderfully stable.

https://github.com/nodejitsu/node-http-proxy

donpdonp• 13 years ago

do you know how this compares to bouncy? I use bouncy as my web proxy including websockets and SNI. I love the flexability of writing the proxy in javascript. https://github.com/substack/bouncy

jenandre2• 13 years ago

It looks comparable to me... I hadn't seen bouncy before though, so I'll have to check it out if I run into any problems with node-http-proxy.

I agree, having the power to write your proxy code in javascript is really nice, especially compared to having to struggle with getting some infrastructure's DSL to work for you (e.g. nginx, varnish's).

kevinfat• 13 years ago

Are WebSocket connections persistent to a single backend? That is, suppose Nginx is in front of two Unicorn processes.

Will Nginx maintain a mapping table of client browser connection to Unicorn process, so that messages will always hit the same Unicorn process? Does that mean the Unicorn processes don't behave in a "stateless" manner?

Then what happens to the websocket if a Unicorn process dies and is restarted? What does the client browser do? What does Nginx do? What happens to the websocket connections if Nginx dies and there is a failover to a backup Nginx instance?

jabr3• 13 years ago

All this change in nginx does is allow WebSocket connections to be proxied, so your questions don't really make sense. WebSocket's work like TCP sockets, and your backend server still needs to manage the socket directly. For example, Unicorn is not a WebSocket server, though there are WebSocket-capable servers derived from Unicorn (e.g. http://rainbows.rubyforge.org/).

If your backend dies or drops the connection, the WebSocket closes, and the client will have to reconnect. If it was just dropped, you can use nginx's ip_hash proxy option to send the reconnect to the same backend server, but it would be a new WebSocket, and the client/server will have to recreate the session state.

cft2• 13 years ago

I find it quite interesting that Android default browser (and thus WebView) is the only modern browser that still does not support WebSockets. I wish Google shed some light on why this is. Unupdatable Android browser is the modern IE6.

wmf3• 13 years ago

Isn't Browser essentially unmaintained in favor of Chrome (which itself is somewhat crippled compared to the desktop version)?

cft2• 13 years ago

1. Even Android 4+ devices that support Chrome sold in major carrier stores still have Android browser as the default (which means that most users will use it) 2. Even in Android 4.2 WebView is based on default browser, meaning that any hybrid Android app does not have WebSockets built in.

This is the main reason why WebSockets are not ready for production.

pornel• 13 years ago

Or if you don't need realtime upload (only realtime download) then use Server-Sent Events, which is HTTP-compatible and thus supported by proxies already.

chrislea• 13 years ago

Hi all. I make Ubuntu packages of the Nginx development releases, so if you want to try out the WebSocket proxying and you're using Ubuntu, these should make it pretty easy to do:

https://launchpad.net/~chris-lea/+archive/nginx-devel

I've written up a very quick tutorial on how to set things up here:

https://chrislea.com/2013/02/23/proxying-websockets-with-ngi...

Hope people find these useful.

WebSocket proxy support added to nginx trunk

Related Stories