I’ve implemented the WebSocket wire protocol as an incremental parser,
making it
suitable for use in high-end asynchronous servers such as NGINX. The
code is
open source (BSD-licenced) and available on GitHub1. I plan on using
it to
tunnel other protocols (svn and git, in particular) over HTTP. I have a
nice
setup that works well on the client side, but I’d like to integrate this
with my
existing NGINX stack with includes virtual hosting and a bunch of other
stuff (I
can’t use another server directly unless I use a non-default port).
To the best of my understanding, NGINX has no support for WebSockets.
The HTTP
proxy module does not support HTTP 1.1 and WebSockets are incompatible
with both
SCGI and FastCGI because of the “Content-Length” problem (it is assumed
to be 0
if unspecified).
I’d like to implement an NGINX module that specifically handles
WebSockets so
that I can integrate my tunnel in my NGINX setup. I have absolutely no
experience with the NGINX source code, but I’ve found a nice guide on
writing
NGINX modules[2]. After initial reading, I understand that I need to
write an
Upstream (proxy) handler. Is this correct?
The HTTP proxy module has a scary note that says:
Note that when using the HTTP Proxy Module (or even when using FastCGI), the
entire client request will be buffered in nginx before being passed on
to the
backend proxied servers.
Is this a limitation cause by NGINX’s architecture, or is this by design
(e.g. for validation of body against headers, etc.)?
The bigger problem, however, is that there is no standard interface to
application servers for this new WebSocket protocol. There is some
discussion[3] on an Apache enhancement request that basically proposes a
modification of CGI. Since CGI has already been demonstrated to be a
performance problem, I’m looking for an alternate solution, maybe
something
closer to SCGI? Anyone have suggestions?
I have been looking for websockets support. I have written a server
push back end for nginx using the “keep-alive” module. I have one
persistent connection for the server push. this connection is an async
client control. then each new “command/request” from the client is a new
http connection. I use fcgi, because fcgi also requires a “length” a
single connection is not possible.
websockets would make make my life easier( and faster). with websockets
support nginx would become the defacto standard for web applications.
because of client/browser security using another port for websockets is
undesirable.
I am not a nginx expert but I assume that the buffering the full request
is a performance issue.
NGINX modules[2]. After initial reading, I understand that I need to write
an Upstream (proxy) handler. Is this correct?
Not really.
The HTTP proxy module has a scary note that says:
Note that when using the HTTP Proxy Module (or even when using FastCGI),
the entire client request will be buffered in nginx before being passed on to
the backend proxied servers.
Is this a limitation cause by NGINX’s architecture, or is this by design
(e.g. for validation of body against headers, etc.)?
It just means that you can’t use existing upstream modules and
upstream interface.
The bigger problem, however, is that there is no standard interface to
application servers for this new WebSocket protocol. There is some
discussion[3] on an Apache enhancement request that basically proposes a
modification of CGI. Since CGI has already been demonstrated to be a
performance problem, I’m looking for an alternate solution, maybe something
closer to SCGI? Anyone have suggestions?
I think what you need here is a simple protocol upgrade functionality
that switches to tcp proxying for particular connection once it
encounters upgrade in connection header. And everything else is up to
application server.
So you don’t really need to parse websocket protocol in nginx unless
it is your application server.
says:
etc.)?
that basically proposes a
encounters upgrade in connection header. And
everything else is up to
application server.
So you don’t really need to parse websocket
protocol in nginx unless
it is your application server.
I want to use websockets in my appliaction server. My provider has
always in front of the application server an nginx-server.
And since nginx currently doesn’t support websockets I have a problem.
So I just wanted to ask, how is the progress about proxiing websocket
communications?
I would be very great and I could imagine that other users may ask for
that, too in the near future.
I’ve been playing with websockets for awhile now and I don’t think it
can make a difference for your provider. Real time web application are
really expensive to handle, each frame costs almost as much as
keepalive request, but you don’t usually expect hundreds of requests
from each client every second. It’s like streaming video by 100 bytes
at a time.
So, it has to be some kind of frame multiplexing over a single
connection with backend and even then it’s still a lot to handle.
Hello,
I want to use websockets in my appliaction server. My provider has
always in front of the application server an nginx-server.
And since nginx currently doesn’t support websockets I have a problem.
So I just wanted to ask, how is the progress about proxiing websocket
communications?
I would be very great and I could imagine that other users may ask for
that, too in the near future.