Introduction to the WebSockets configuration method for Nginx server _nginx

Nginx 1.3.13 has been released, which supports the Connection:upgrade and upgrade headers, which means supporting the websocket agent. Many people are waiting for this new feature so that "Nginx support WebSockets?" became f The most frequently asked question on the #nginx channel on Reenode. With this approach, let's look at the websocket implementation of Nginx.
Nginx The newly added websockets configuration Directive

The configuration mentioned in the document is as follows: (Translator note: The link in the original text is not a link to the document.) Now Nginx's Official document has WebSocket's instructions http://nginx.org/en/docs/http/websocket.html)

Copy Code code as follows:

location/chat/{
Proxy_pass Http://backend;
Proxy_http_version 1.1;
Proxy_set_header Upgrade $http _upgrade;
Proxy_set_header Connection "Upgrade";
}

This configuration is indeed quite simple. The configuration of HTTP is supported by previous versions. We can also optimize the configuration to improve versatility by creating a linked variable that puts proxy_set_headers in a public inclusion file.

Copy Code code as follows:

Map $http _connection $upgrade _requested {
Default upgrade;
' Close;
}

This allows the variable $upgrade _requested to be used in Proxy_set_header Connection, and if there is no upgrade link request, conection This header is set to "", This will not interfere with ordinary requests. The advantage of this is that if you only use the http/1.1 proxy, then you do not need to configure another location to specialize in WebSockets.

Link upgrades do not seem to be ported back to a stable version, so if you want to use the link upgrade feature, you must use the development version. Thankfully, the development version of Nginx does not mean that it is not running a stable version, it simply means that the API will change, in which case it will only affect the creator of the module. Don't be afraid to install the development version to try this new feature.

Limitations:

So far, there are some limitations in websocket execution deployment:

The client must develop a link upgrade

The client must request a link upgrade or Nginx will fail. The current requirement is listed as part of the code, so I need to say how it failed, but I can be sure that it will be executed eventually, so I don't have to rely on it. This constraint is not a problem for anyone, only if the creator of the module might want to apply the connection to the backend and handle the response itself.

websockets Timeout
The websockets is still affected by the default of 60 seconds of proxy_read_timeout. This means that if you have a program that uses websockets, but may not send any data for more than 60 seconds, you either need to increase the timeout or implement a ping message to keep in touch. There are additional benefits to using the ping solution to find out if the connection was accidentally closed.

Keep-alive & WebSockets
keep-alive pings is not valid for the above timeout problem because they only send empty packets at the TCP level. They do not report to the application, so the application does not respond to them, so proxy_read_timeout still triggers.

WebSockets supports SSL
because the websockets is bound to the normal agent module, SSL works as usual.

Proxy caching
WebSockets uses two memory buffers to achieve the size of the proxy cache configuration (proxy_buffer_size), one for upstream data and the other for downlink data. Unlike normal proxy requests, WebSockets does not cache data to disk websockets.

Case sensitive Upgrade Head
There are some back-end programs on the upgrade head to do the case check, while supporting the "Upgrade" and "Upgrade" two ways, otherwise, only "upgrade" writing can work properly. If the configuration appears to be correct and is not working properly, try changing the size of the header.