Nginx load balancing and reverse proxy extension functions

This article mainly introduces the related functions of Nginx Plus, which spans the various versions of Nginx plus R5/R6/R7/R9. The more advanced usage of Nginx reverse proxy and load balancing is involved. Mainly include: HTTP load balancer, HTTP long connection, TCP and UDP load balancing, upstream connection limit, the shortest time Equalization algorithm, session consistency, real-time health check, DNS re-resolution, access control, client connection limit, client bandwidth limit, unbuffered upload file, SSL/TLS optimization, cache optimization, API functionality, configuration best practices, etc.

What is Nginx Plus?

As the name implies, it is the enhanced version or the extended version of Nginx. We know that Nginx is open source, free, but many features of Nginx Plus will require a fee. Nginx Plus can be used as a load balancer, a Web server, and also as a content cache. Since it is an enhanced version of Nginx, there is no doubt that the function will be more powerful than nginx. Nginx Plus provides many proprietary features for the production environment, including session consistency, real-time update API configuration, and effective health checks, based on the existing features of open source Nginx.

Version update for NGINX Plus

NGINX Plus R5 and newer versions can support load balancing based on TCP applications (such as MySQL). This is not limited to HTTP load balancing, but greatly expands the scope of Nginx as a load balancer. The TCP load balancing function in R6 has been greatly expanded, including health check, dynamic update configuration, SSL terminal and so on. Wait until the R7,TCP load balancer function is almost as basic as HTTP load balancing. Z again to the R9, you can support UDP. With these updates, NGINX Plus is far beyond the Web application level, becoming a more meaningful load balancer . After all, the agreement is a basic level of things, the more protocols supported, the wider the application surface. From the initial http/smtp to the TCP to the Udp,nginx Plus, the step becomes more and more powerful.

Both open-source Nginx and Nginx Plus Support load balancing for HTTP, TCP, and UDP applications. But Nginx Plus offers some enterprise-class features that are chargeable, including session consistency, health checks, dynamic update configurations, and more.

HTTP Load Balancing

NGINX Plus provides many optimizations for HTTP load balancing, such as HTTP upgrades, long-connection optimizations, content compression, and response caching. The implementation of HTTP load balancing in Nginx Plus is also very simple:

HTTP {    upstream My_upstream {        server server1.example.com;        Server server2.example.com;    }    server {        listen;        Location/{            proxy_set_header Host $host;            Proxy_pass Http://my_upstream;}}}    

The host can be set by the proxy_set_header command, and the proxy_pass request is forwarded to the upstream my_upstream .

HTTP Long Connection

HTTP Long connection--http keepalives refers to the long connection established by Nginx Plus and the upstream server. If the client and Nginx plus have long connections, you can specify the HTTP protocol as 1.1/2.0 on the client.

The HTTP protocol is used by the underlying TCP protocol to transmit the request and receive the response. HTTP1.1/2.0 supports long connections or re-use of TCP to avoid the overhead of repeatedly creating and destroying TCP connections.

Let's look at the HTTP long connection between the client and Nginx Plus:

Nginx is a full-meaning reverse proxy, and is unambiguous on long connections. It manages long connections from the client to the Nginx, as well as managing long connections from Nginx to upstream servers, both of which are completely independent .

Long connections for Nginx management:

NGINX makes a "cache" of idle connections to the upstream server and does not turn them off directly. If there is a request, Nginx first from the active connection of the cache to take a use, rather than immediately create a new, if the cache is empty then nginx to create a new connection. This operation maintains the minimum necessary number of connections to the upstream, reducing latency between nginx and upstream servers and reducing the utilization of ephemeral ports, so nginx can handle large concurrency. This technique, coupled with other load-balancing techniques, can sometimes be called connection pooling or connection multiplexing.

In order to configure the idle long connection cache, you need to specify several instructions:proxy_http_version,proxy_set_header,keepalive

server {    listen;    Location/{        Proxy_pass http://backend;        Proxy_http_version 1.1; # only http1.1/2.0 can support long connection        proxy_set_header Connection "";    }} Upstream backend {    server webserver1;    Server webserver2;    # Maintain a maximum of idle connections to each upstream server    keepalive 20; # Idle long connection cache time is 20}

Load balancing for TCP and UDP

As an extension to the HTTP protocol, NGINX Plus can directly support applications based on TCP and UDP protocols. TCP-based, such as MySQL, supports UDP-like DNS and RADIUS applications. For TCP requests, NGINX plus receives a TCP request from the client and then creates a TCP request to initiate access to the upstream server.

Stream {    upstream My_upstream {        server server1.example.com:1234;        Server server2.example.com:2345;    }    server {        Listen 1123 [UDP];        Proxy_pass My_upstream; #注意这里没有http://    }}

Support for TCP requests appears in the Nginx Plus R5,R6 and R7 versions are primarily optimized for this feature, when the load balancing of TCP requests to R7 is strong enough to match HTTP load balancing, and to R9, it can support UDP. Here is an impression that the TCP load Balancer feature is described in more detail later.

Limit of upstream connections

You can also make a limit on the number of connections for load balancing. The connection here refers to the HTTP/TCP/UDP request connection that Nginx plus sends to the upstream server (for UDP it is a session). With the connection limit feature, NGINX plus no longer creates a new connection or session when the number of HTTP/TCP connections to the upstream server or the number of UDP sessions exceeds a certain value. Client-side request connections can be queued or not processed. This can max_conns,queue be achieved through directives:

Upstream backend {    zone backends 64k;    Queue timeout=30s;    Server WebServer1 max_conns=250;    Server Webserver2 max_conns=150;}

serverThe instruction indicates that the WEBSERVER1 hosts up to 250 connections and webserver2 a maximum of 150, and that more can be placed in queue queues waiting. There is also a limit to the number of connections and wait times that are waiting in queue queues. When the number of WebServer1 and webserver2 connections is lowered below the respective maximum number of connections, the connections waiting in queue queues are ready to fill up.
queue 750 timeout=30sIndicates that a total of 750 connections can be queued, with each connection waiting for 30s.

Limiting connections is useful for providing clients with a sustainable and predictable service--not necessarily because of a server load that is too large to hang out. As a general rule, how much load a server can carry can be tested by some means, so the relative security of the server can be ensured by taking this affordable line as the value of the Max_conns instruction.

Equalization algorithm with minimum time

A new equalization algorithm--least time is added to the Nginx Plus R6, which is considered as an extension of the least-connection equalization algorithm (Least Connections).

This algorithm takes into account the current number of connections and the average response time of each node in the connection pool. The goal is to make the current request choose a server that responds faster and with fewer connections , rather than choosing a slower response and more connections.

When each server node of the connection pool has significantly different response latencies, this algorithm is superior to the others (Round-robin/ip-hash/lease connections). A typical application scenario is that if there are two data centers distributed across different geographies, then the local data center will be much less than the offsite data center delay, this time can not only consider the current number of connections, the response delay will also be counted into consideration. Least time algorithm is more inclined to choose local, of course, this is only a "more inclined" problem, and can not replace the Nginx basic error transfer function, even if the local data center response faster, if it hangs out Nginx Plus can immediately switch to the Remote data center.

The "minimum time" can be computed in two ways, from the time the request is sent to the top of the server to the response header, and from the time the request is sent to the full request body, header_time respectively response_time .

Session consistency

The session consistency (session persistence) problem can be achieved by specifying the Ip-hash equalization algorithm, and there is a more general implementation, which is implemented in Nginx Plus.

NGINX Plus can identify the user session, so it can identify different clients and can send requests from the same client to the same upstream server. This is useful in situations where the application saves the user state, and avoids the load balancer following an algorithm to send the request to another server. In addition, this is also useful for clustered servers that share user information.

Session consistency requires the same server for each request of the same client, and load balancing requires that we use an algorithm to go to the server connection pool to choose the next one, then these two contradictory ways can coexist? Yes, NGINX plus follow the steps below to decide which one to use:

• If request matches the rule of a session consistency, then the upstream server is selected according to this rule;

• If no matching or matching servers are unavailable, use the load balancing algorithm to select the upstream server;

In order to ensure session consistency, Nginx Plus provides several rules for sticky cookie,sticky learn and sticky route.

Sticky cookie Rules

For the sticky cookie rule, when the client's first request selects an upstream server and returns a response from the upstream server, NGINX Plus adds a session cookie for the response to authenticate the upstream server. When the subsequent request comes back, NGINX plus takes out the cookie, analyzes which server it is, and sends the request to the same server.

Using Directives sticky cookie , configure the following:

Upstream backend {    server webserver1;    Server webserver2;    Sticky Cookie srv_id expires=1h domain=.example.com path=/; }

The name of the cookie is called srv_id, which is used to "remember" which server; the expiration time is 1h,domain .example.com ; path is /
Nginx Plus in the first response, insert a name called srv_id cookie , to "Remember" the first request is sent to which upstream, the following request with this cookie , the same is again by Nginx plus screening, and then sent to the same server. This will ensure the consistency of the session.

Sticky Route Rules

sticky cookiesimilar to the rules, but "remember" the way the upstream server is different.
When the client initiates the first request, the server that receives it assigns a route, and all requests initiated by the client are then brought with the route information, either in a cookie or in a URI. Then compare the route parameters in the server directive and decide which server to select. If the specified server cannot be processed, the load balancing algorithm is given to select the next server.

Map $cookie _jsessionid $route _cookie {    ~.+\. p<route>\w+) $ $route;} Map $request _uri $route _uri {    ~jsessionid=.+\. p<route>\w+) $ $route;} Upstream backend {    server backend1.example.com route=a;    Server backend2.example.com route=b;    # Select first Non-empty variable; It should contain either ' a ' or ' B '    sticky route $route _cookie $route _uri;}

Here, the route is JSESSIONID cookie selected in, as it contains a then the Select server, backend1 if it contains B is selected backend2 , if none are included then $request_uri make similar choices in, and so on.

Whichever way you choose to keep the session consistent, if the selected server is not available, the next server will continue processing in the server list according to the load Balancing algorithm (such as Round-robin).

Real-time Health check

As mentioned earlier, Nginx has two major functions: one is to expand, add more servers to meet the larger concurrency, and the second is to detect the failure server, in order to eliminate the time. Then, how to define a "fail Server" (failed server) becomes very important. This section is to discuss this issue-real-time Health check (Active Checks). This is the function of Nginx Plus, and it is charged.

The open source version of Nginx provides a simple health check and can be automatically failed over. But how to define an upstream server "fail" open source Nginx is simple to do. Nginx Plus provides a customizable, comprehensive evaluation standard , in addition to the Nginx plus can gently add new server nodes to the cluster. This feature makes Nginx plus possible to identify more diverse server errors, effectively increasing the reliability of the HTTP/TCP/UDP application.
Here are the instructions to be used: health_check,match

Upstream My_upstream {    zone my_upstream 64k;    Server server1.example.com slow_start=30s;} server {    # ...    location/health {        internal;        Health_check interval=5s uri=/test.php Match=statusok;        Proxy_set_header HOST www.example.com;        Proxy_pass http://my_upstream    }}match statusok {    # do health check status in/test.php    ;    Header content-type = text/html;    Body ~ "server[0-9]+ is Alive";}

health_checkIndicates that interval=5s every 5s is detected at once, uri=/test.php indicating that there is a /test.php health check in, NGINX plus automatically initiates a URI request, the URI can be customized, and you perform the check logic in it, such as mysql/redis whether it is normal, Then make a certain response; In the match directive, the response is matched by some rules /test.php . /test.phpThe responses can include status,header,body These, which are used to match the following instructions. All checks pass, even if healthy, the server is marked as active, if a match fails, for example, Content-Type = text/json or if status = 201 it is counted as failed, the server is unhealthy and is marked inactive.

DNS Re-parsing

Nginx plus starts DNS parsing and automatically caches resolved domain names and IPs, but in some cases it needs to be re-parsed, which can be done using the following directives:

Resolver 127.0.0.11 valid=10s;upstream Service1 {    zone Service1 64k;    Server www.example.com  service=http resolve;}

127.0.0.11 is the address of the default DNS server, in this case the Nginx plus each 10s DNS server initiates a re-resolution request.

Access control

NGINX Plus Release 7 mainly adds to the security of TCP load balancing. such as access controls and DDoS protection.
You can now allow or deny access to a reverse proxy or a load-balanced TCP server, simply by configuring a simple IP or an IP sample to achieve:

server {    # ...    Proxy_set_header Host www.example.cn;    Proxy_pass http://test;    Deny 72.46.166.10;    Deny 73.46.156.0/24;    Allow all;}

The first deny instruction denies access to an IP, and the second denies an IP range, except that the two remaining are allowed to be accessed. An IP that is denied access will be returned with a 403 error.

Limit of client connections

In addition to limiting the number of upstream server connections, you can also limit the number of client connections, which is implemented in NGINX Plus R7. You can limit the number of requests that clients send to TCP applications that are represented by Nginx plus proxies, preventing excessive requests to TCP. In your app, it might be a bit slower than the other part. For example, asking for a chunk of your app will generate a lot of MySQL requests, or fork out a whole bunch of work processes. The attacker would then use this to generate thousands of requests, causing your server to be overloaded and paralyzed.

However, with the connection number limit feature, you can limit_conn my_limit_conn minimize the attack risk by configuring directives to limit the maximum number of requests that the same client (IP) can initiate.

Stream {    limit_conn_zone $binary _remote_addr zone=my_limit_conn:10m;    # ...    server {        limit_conn my_limit_conn 1;        # ...    }}

This directive restricts each IP to only one connection at a time.

Client Bandwidth Throttling

R7 also adds a feature that limits the maximum bandwidth (Bandwidth limiting) for uploads and downloads per client connection.

server {    # ...    Proxy_download_rate 100k;    Proxy_upload_rate  50k;}

With this configuration, the client can only download at 100kbytes/s speed and upload at 50kbytes/s speed. Because clients can open multiple connections, if you want to limit the total upload/download speed, you also have to limit the number of connections to a single client.

Upload files without buffering

This is an added feature in R6. You can use unbuffered uploads in R6 and later versions, meaning that Nginx plus can be uploaded via larger HTTP requests such as upload. Unbuffered uploads can be uploaded as soon as these requests come in, rather than buffering all uploads as before and forwarding them to your upstream server.

By default, Nginx receives data when it is uploaded and buffers it into buffers to avoid binding the resource to the backend script based on the worker process, but buffering is almost unnecessary for event-driven backend languages such as node. js. This modification improves the responsiveness of the server to uploading large files because the application can respond to the data as soon as it is received, making the upload progress bar real-time and accurate. Again, this improvement reduces disk I/O.

SSL/TLS optimization

In R6, you can provide a certificate to the client when dealing with an upstream HTTPS or UWSGI server. This greatly improves security, especially when communicating with security services on unprotected networks. R6 supports SSL/TLS client authentication for IMAP, POP3, and SMTP.

Cache optimization

The Proxy_cache directive can support variables, a simple improvement that allows you to define several disk-based caches and make free choices based on the requested data. It is useful when you plan to create huge content caches and save them to different disks.

API features

Some of the instructions of the Upstreem module can be modified not only by manual modification, but also by the way of Restful Api , and automatically updated immediately. With this feature, NGINX Plus has some features that you can change through the API. The application has been greatly improved. Of course this is also a charge:

Upstream backend {    zone backends 64k;    Server 10.10.10.2:220 max_conns=250;    Server 10.10.10.4:220 max_conns=150;} server {    listen;    server_name www.example.org;    Location/api {        API write=on;    }}

With the API, you can use the Curl tool to dynamically modify the configuration, such as using the Post command to add a cluster node:

$ curl-ix post-d ' {"Server": "192.168.78.66:80", "Weight": "$", "Max_conns": "$"} ' http://localhost:80/api/1/http/ upstreams/backend/servers/

The equivalent of adding a configuration like this:

Upstream backend {    zone backends 64k;    Server 10.10.10.2:220 max_conns=250;    Server 10.10.10.4:220 max_conns=150;    #此处是通过api添加的    server 192.168.78.66:80 weight=200 max_conns=150;}

If you need to modify a node configuration, you can use the natural order of the server nodes in the connection pool (starting at 0) as their respective unique IDs, and then use the Patch/delete method to manipulate them:

$ curl-ix patch-d ' {"Server": "192.168.78.55:80", "Weight": "$", "Max_conns": "+"} ' http://localhost:80/api/1/http/ Upstreams/backend/servers/2

This command modifies the third of the above connection pools to be server 192.168.78.66:80 max_conns=200; :

Server 192.168.78.55:80 weight=500  max_conns=350;

If you want to return all the node information, you can use:

$ curl-s http://localhost:80/api/1/http/upstreams/backend/servers/

The return is a JSON string.

{      "Backup": false,      "down": false,      "Fail_timeout": "10s",      "id": 0,      "Max_conns": +,      "Max_ Fails ": 1,      " "Route": "",      "server": "10.10.10.2:220",      "slow_start": "0s",      "weight": 1      },      {      "Backup": false,      "down": false,      "Fail_timeout": "10s",      "id": 1,      "Max_conns":      Max_fails ": 1,      " "Route": "",      "server": "10.10.10.4:220",      "slow_start": "0s",      "weight": 1      },      {      "backup": false,      "down": false,      "Fail_timeout": "10s",      "id": 2,      "Max_conns": 200,      "Max_fails": 1,      "route": "",      "server": "192.168.78.66:80",      "slow_start": "0s",      "weight": +      }  }

Best Practices for configuration

It is a good practice to create separate directories and files for different application configurations and include then merge them together with instructions. The standard NGINX plus configuration is to place the configuration files for each application in the respective CONF.D directory directory:

HTTP {    include/etc/nginx/conf.d/*.conf;} stream {    include/etc/nginx/stream.d/*.conf;}

The HTTP and stream modules belong to different directories, while HTTP is the configuration of the HTTP request, and the stream is the configuration of the TCP/UDP request. There is no unified standard, mainly to see the developers themselves can easily identify and modify.