
Nginx now supports Websockets - Jhsto
http://nginx.com/news/nginx-websockets.html
======
trebor
What 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.

~~~
MartinMond
You mean like <https://github.com/wandenberg/nginx-push-stream-module>? :)

~~~
trebor
That does look intriguing. I'll have to do some research to see if its
suitable to my use case. Thanks Martin.

------
shykes
This is great. At dotCloud we've reluctantly ported our distributed routing
layer (<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>). Now
that problem 2 is solved as well, we might be able to port Hipache back to
Nginx in the future :)

Go Nginx!

------
pornel
Earlier discussion: <http://news.ycombinator.com/item?id=5240356>

------
MatthewPhillips
This 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
It's looking for the upgrade header in HTTP, and then, yes, proxying that
connection.

~~~
sprobertson
Yup, nice to have this built in rather than relying on an additional layer
(Varnish, HAProxy, 3rd party module, etc.)

------
ck2
Wow, realtime upvoting/downvoting for everyone now :-)

------
kevinfat
So 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
Think 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)>

~~~
kevinfat
I've never dealt with Comet. I need the long detailed answer for complete
noobs.

~~~
jacobolus
The old version of that wikipedia article had a bit more background
explanation:
[http://en.wikipedia.org/w/index.php?title=Comet_%28programmi...](http://en.wikipedia.org/w/index.php?title=Comet_%28programming%29&oldid=215165715)

~~~
kevinfat
If 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?

------
felipesabino
So hopefully heroku will soon be able to support Web Sockets instead of only
xhr-polling

[https://devcenter.heroku.com/articles/http-
routing#websocket...](https://devcenter.heroku.com/articles/http-
routing#websockets)

[https://devcenter.heroku.com/articles/using-socket-io-
with-n...](https://devcenter.heroku.com/articles/using-socket-io-with-node-js-
on-heroku)

~~~
Nikkau
They are busy trying to be able to support Rails apps for now.

------
csense
Does 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!

~~~
rdtsc
> 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?

~~~
csense
I was thinking that a prominent use-case for JS websockets would be writing a
JS client for $PROTOCOL which runs in the browser, where $PROTOCOL is some
TCP-based protocol like IRC that was developed years before websockets
existed.

> 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.

~~~
rdtsc
> writing a JS client for $PROTOCOL which runs in the browser, where $PROTOCOL
> is some TCP-based protocol like IRC that was developed years before
> websockets existed.

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.

------
mc
What's the difference between this new support and the nginx-push-stream
module? <https://github.com/wandenberg/nginx-push-stream-module>

~~~
mnutt
nginx-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
Good comparison. Thanks.

------
andyfleming
Is there any documentation on usage?

~~~
foenix
Not really, but I used this link:
<http://trac.nginx.org/nginx/changeset/5073/nginx> to set up this config:
<https://gist.github.com/octaflop/4991052> for this server:
<https://gist.github.com/octaflop/4991187> hosted on this site:
<https://legionofevil.org/>

Hope that helps! (IRC is also quite handy today)

------
azakai
Excellent!

Now all we need is WebRTC.

~~~
twistedpair
And for most corporations like mine to stop blocking websockets. What do you
mean let some odd port through the firewall?

~~~
mateuszf
How about serving it using SSL on port 443?

~~~
infamouscow
WebSockets over SSL (wss://) work just fine. Faris Chebib provided a nginx
config file in #nginx earlier today.
<https://gist.github.com/octaflop/4991052>

------
krob
Now how to interact with their support, and hopefully some tutorial on
integration with the multitude of different languages.

~~~
kcbanner
This has nothing to do with languages. Nginx can now proxy WebSockets to
arbitrary servers.

------
davidw
What were people using previously? Just plopping their node.js or whatever
straight on the network?

~~~
dcraw
I've had good results so far with 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
Hey... saw your comment here <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

------
tslocum
Any ETA on SPDY support being included (instead of requiring a patch)?

~~~
newman314
Looks like the next release.

<http://trac.nginx.org/nginx/roadmap>

It's only SPDY/2 for now although SPDY/3 eventually.

------
Doublon
This day has finally come!

------
r3demon
Great news!

------
churreiro
Good news, finally, not just need to wait couple of months until they solve
all the initial bugs to migrate our existing apps! ;)

