Shulou(Shulou.com)06/01 Report--

This article introduces the knowledge of "what is the method of Nginx session persistence". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

You will encounter the problem of session persistence when using load balancer. The common methods are:

1.ip hash, which assigns requests to different servers according to the IP of the client

2.cookie, the server sends a cookie to the client, and the request with a specific cookie is assigned to its publisher

Note: cookie requires browser support and sometimes leaks data

How 1.Sticky works:

Sticky is a module of nginx. It is a nginx load balancing solution based on cookie. It distributes and identifies cookie to make requests from the same client fall on the same server. The default identity is route.

(a) the client initiates an access request for the first time, and after receiving the request, nginx finds that there is no cookie in the request header, and then distributes the request to the backend server by polling.

(B) the back-end server processes the request and returns the response data to nginx.

(C) at this time, nginx generates cookie with route and returns it to the client. The value of route corresponds to the backend server, which may be plaintext or Hash values such as md5, sha1, etc.

(d) the client receives the request and saves the cookie with route.

(e) when the client sends a request next time, it will bring route,nginx and forward it to the corresponding backend server according to the value of the received cookie.

two。 Recompile nginx to add nginx-sticky-module module

Query the related documents of this module on bitbucket.org

Https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng/overview

# you can use the following command to query the current nginx compilation parameters:

/ usr/local/nginx/sbin/nginx-V

[root@nginx] # mkdir-p / server/tools

[root@nginx ~] # cd / server/tools

[root@nginx tools] # / usr/local/nginx/sbin/nginx-V

Nginx version: nginx/1.8.0

Built by gcc 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)

Built with OpenSSL 1.0.1e-fips 11 Feb 2013

TLS SNI support enabled

Configure arguments:-prefix=/usr/local/nginx-- user=nginx-- group=nginx-- with-http_stub_status_module-- with-http_ssl_module

# download the software package for this module ()

# most of the nginx-sticky-module module packages on other platforms are inconvenient to download from foreign resources. Find the package on GITHUB

[root@nginx tools] # wget https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng/get/08a395c66e42.zip

# decompression

[root@nginx tools] # unzip-D nginx-goodies-nginx-sticky-module-ng-08a395c66e42.zip

[root@nginx tools] # mv nginx-goodies-nginx-sticky-module-ng-08a395c66e42 nginx-sticky-module-ng

# nginx directory before backup (Note: nginx logs may be large)

[root@nginx tools] # cp-rf / usr/local/nginx/ / server/backup/

# go to the previously compiled nginx directory and re-compile and install

# Note: overwrite installation

[root@nginx tools] # cd nginx-1.8.0

[root@nginx nginx-1.8.0] # / configure-- prefix=/usr/local/nginx-- user=nginx-- group=nginx-- with-http_stub_status_module-- with-http_ssl_module-- add-module=/server/tools/nginx-sticky-module-ng

[root@nginx nginx-1.8.0] # make

[root@nginx nginx-1.8.0] # make install

# check the nginx compilation parameters again after installation

[root@nginx tools] # / usr/local/nginx/sbin/nginx-V

Nginx version: nginx/1.8.0

Built by gcc 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)

Built with OpenSSL 1.0.1e-fips 11 Feb 2013

TLS SNI support enabled

Configure arguments:-prefix=/usr/local/nginx-- user=nginx-- group=nginx-- with-http_stub_status_module-- with-http_ssl_module-- add-module=/server/tools/nginx-sticky-module-ng

# you need to restart nginx to use the sticky module

[root@nginx tools] # service nginx restart

# Edit configuration file, for example:

Upstream www_web_com {

# ip_hash

Sticky expires=1h domain=web.com path=/

Server 10.0.0.16:8080

Server 10.0.0.17:8080

}

# specific configuration can be based on the company's relevant business configuration

# then open the website for testing. In the case of using sticky, no matter how you refresh it, the result is as follows

# when you don't use the Nginx sticky module, it changes a few times (sometimes once, sometimes several times)

Note: every real back-end server has a unique route value, so no matter how many nginx proxies with sticky installed on the front end of your real server, it will not change.

The use of 3.sticky module

# location: within the upstream tag

Upstream {

Sticky

Server 127.0.0.1:9000

Server 127.0.0.1:9001

Server 127.0.0.1:9002

}

# parameters, parsing

Sticky [name=route] [domain=.foo.bar] [path=/] [expires=1h]

[hash=index | md5 | sha1] [no_fallback] [secure] [httponly]

[name=route] sets the cookie name used to record the session

[domain=.foo.bar] set the domain name of cookie

[path=/] set the URL path of cookie, default root directory

[expires=1h] set the lifetime of cookie. If it is not set by default, the browser will become invalid when the browser is closed. It needs to be a value greater than 1 second.

[hash=index | md5 | sha1] sets whether the identity of the server in cookie is in clear text or MD5. Default is md5.

[no_fallback] set this item. When the backend machine of sticky dies, nginx returns 502 (Bad Gateway or Proxy Error) without forwarding it to other servers. It is not recommended to set it.

[secure] set cookie with security enabled, which requires HTTPS support

[httponly] allows cookie not to leak through JS, unused

4. Other parameters: syntax:

The following is an excerpt from: http://blog.csdn.net/yu870646595/article/details/52056340

Session_sticky [cookie=name] [domain=your_domain] [path=your_path] [maxage=time] [mode=insert | rewrite | prefix]

[option=indirect] [maxidle=time] [maxlife=time] [fallback=on | off] [hash=plain | md5]

Mode sets the mode of cookie:

Insert: in the reply, this module directly inserts the cookie with the corresponding name through the Set-Cookie header.

Prefix: no new cookie will be generated, but a specific prefix will be added to the cookie value of the response. When the browser requests again with this cookie with a specific identity, the module deletes the prefix before passing it to the backend service, and the backend service gets the original cookie value. These actions are transparent to the backend. Such as "Cookie: NAME=SRV~VALUE".

Rewrite: the cookie for session sticky set by the backend is overridden with the server identity. If the cookie is not set by the back-end service in the response header, it is considered that the request does not require session sticky. Using this mode, the back-end service can control which requests require sesstion sticky and which do not.

Option sets the option for cookie for session sticky, which can be set to indirect or direct. Indirect does not transmit the cookie of the session sticky to the backend service, which is completely transparent to the backend application. Direct is the opposite of indirect.

Maxidle sets the maximum idle timeout for session cookie

Maxlife sets the maximum lifetime of session cookie

Maxage is the lifetime of cookie. When not set, the browser or App becomes invalid when it is closed. The next time you start, the back-end servers will be randomly assigned. So if you want the client's request to fall on the same back-end server for a long time, you can set maxage.

There is a fixed number of hash values, both in plaintext and hash. Because hash is the identity of server, there are as many hash values as there are server.

5. Other things that need to be noticed

(a) requests from the same client may fall on different back-end servers

If the client initiates multiple requests at the same time. Since these requests do not have a cookie, the server randomly selects the backend server and returns a different cookie. When the last of these requests returns, the client's cookie stabilizes, and the value is based on the last returned cookie.

(B) cookie may not be effective

Because cookie is originally issued by the server, if the client disables cookie, the cookie will not take effect.

(C) clients may not have cookie

When an Android client sends a request, it usually does not take all the cookie with it. You need to specify which cookie will carry it. If you want to use sticky for load balancing, please add cookie to Android development.

(d) the cookie name should not be the same as the cookie used by the business. The default cookie name for Sticky is route, which can be changed to any value.

(e) the first request sent by the client is without cookie. The cookie sent by the server will not take effect until the next request from the client.

(F) the Nginx sticky module cannot be used in conjunction with ip_hash

This is the end of the content of "what is the method of Nginx session persistence". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.