软件测试工程师 多进程 webserver javascript multithreading model transactions ftp vue响应式 vue表单提交 vue遍历 pmp教程 java数据分析 mysql入门 python配置环境 python命令行 python中re模块 python命令大全 java在线学习 java教学 java语言学习 java中的正则表达式 java的正则表达式 java8教程 java使用正则表达式 java调用接口 java的框架 java八种基本数据类型 java网页 linux教学 销售清单打印软件 python输入数字 pyh 跳一跳脚本 丁丁下载 js绝对值 网络克隆 skycc组合营销软件 ps制作表格 数独软件
当前位置: 首页 > 学习教程  > 编程语言

Nginx 学习总结

2020/8/11 19:00:35 文章标签:

以下所总结仅是学习记录,如有不对的部分,还请及时指出,十分感谢

参考文档目录都在末尾写出了作者的链接,有兴趣的可以直接点击

文章有点长,建议收藏后查看

Nginx、WSGI、 uWSGI、 uwsgi 简介

  • Nginx 简介
  • Nginx 和 uWSGI 的关系
  • Nginx 与 Apache 的异同
  • Nginx的优势
  • Nginx的模块与工作原理
  • Nginx 配置文件结构
  • Nginx 配置文件详解
  • Nginx 代理
  • Nginx 负载均衡

Nginx、WSGI、 uWSGI、 uwsgi 简介

当我们部署完一个应用程序,浏览网页时具体的过程是怎样的呢?首先我们得有一个 Web 服务器来处理 HTTP 协议的内容,Web 服务器获得客户端的请求,交给应用程序,应用程序处理完,返回给 Web 服务器,这时 Web 服务器再返回给客户端。Web 服务器与应用程序之间显然要进行交互,这时就出现了很多 Web 服务器与应用程序之间交互的规范,最早出现的是 CGI,后来又出现了改进 CGI 性能的FasgCGI,Java 专用的 Servlet 规范,Python 专用的 WSGI 规范等等。有了统一标准,程序的可移植性就大大提高了。这里我们只介绍 WSGI。

WSGI 全称是 Web Server Gateway Interface,也就是 Web 服务器网关接口,它是 Python 语言定义出来的 Web 服务器和 Web 应用程序之间的简单而通用的接口,基于现存的 CGI 标准设计,后来在很多其他语言中也出现了类似的接口。 总的来说,WSGI 可以分为服务器和应用程序两个部分,实际上可以将 WSGI 理解为服务器与应用程序之间的一座桥,桥的一边是服务器,另一边是应用程序。

按照 web 组件分类,WSGI 内部可以分为三类,web 应用程序,web 服务器,web 中间件。应用程序端的部分通过Python 语言的各种 Web 框架实现,比如 Flask,Django这些,有了框架,开发者就不需要处理 WSGI,框架会帮忙解决这些,开发者只需处理 HTTP 请求和响应,web 服务器的部分就要复杂一点,可以通过 uWSGI 实现,也可以用最常见的 Web 服务器,比如 Apache、Nginx,但这些 Web 服务器没有内置 WSGI 的实现,是通过扩展完成的。如 Apache,通过扩展模块 mod_wsgi 来支持WSGI,Nginx可以通过代理的方式,将请求封装好,交给应用服务器,比如 uWSGI。uWSGI 可以完成 WSGI 的服务端,进程管理以及对应用的调用。WSGI 中间件的部分可以这样理解:我们把 WSGI 看做桥,这个桥有两个桥墩,一个是应用程序端,另一个是服务器端,那么桥面就是 WSGI 中间件,中间件同时具备服务器、应用程序端两个角色,当然也需要同时遵守 WSGI 服务器和 WSGI 应用程序两边的限制和需要。更详细的内容可以看PEP-333 中间件的描述

Flask 依赖的 Werkzeug 就是一个 WSGI 工具包,官方文档的定义是 Werkzeug 是为 Python 设计的 HTTP和 WSGI 实用程序库。我们需要注意的是,Flask 自带的 Werkzeug 是用来开发的,并不能用于生产环境,Flask 是 Web 框架,而 Werkzeug 不是 Web框架,不是 Web 服务器,它只是一个 WSGI 工具包,它在 Flask 的作用是作为 Web 框架的底层库,它方便了我们的开发。

我们将 uwsgi 和 uWSGI 放在一起讲解。uWSGI 是一个 Web 服务器程序,WSGI,上面已经谈到,是一种协议,uwsgi 也是一种协议,uWSGI 实现了 uwsgi、WSGI、http 等协议。 uwsgi 的介绍可以看这里,uwsgi 是 uWSGI 使用的一个自有的协议,它用4个字节来定义传输数据类型描述。尽管都是协议,uwsgi 和 WSGI 并没有联系,我们需要区分这两个词。

Nginx 简介

Nginx 是高效的 Web 服务器和反向代理服务器,可以用作负载均衡(当有 n 个用户访问服务器时,可以实现分流,分担服务器的压力),与 Apache 相比,Nginx 支持高并发,可以支持百万级的 TCP 连接,十万级别的并发连接,部署简单,内存消耗少,成本低,但 Nginx 的模块没有 Apache 丰富。Nginx 支持 uWSGI 的 uwsgi 协议,因此我们可以将 Nginx 与 uWSGI 结合起来,Nginx 通过 uwsgi_pass 将动态内容交给 uWSGI 处理。

Nginx 和 uWSGI 的关系

从上面的讲解中,我们知道,uWSGI 可以起到 Web 服务器的作用,那么为什么有了 uWSGI 还需要 Nginx 呢?

最普遍的说法是 Nginx 对于处理静态文件更有优势,性能更好。其实如果是小网站,没有静态文件需要处理,只用 uWSGI 也是可以的,但加上 Nginx 这一层,优势可以很具体:

  1. 对于运维来说比较方便,如果服务器被某个 IP 攻击,在 Nginx 配置文件黑名单中添加这个 IP 即可,如果只用 uWSGI,那么就需要在代码中修改了。另一方面,Nginx 是身经百战的 Web 服务器了,在表现上 uWSGI 显得更专业,比如说 uWSGI 在早期版本里是不支持 https 的,可以说 Nginx 更安全。
  2. Nginx 的特点是能够做负载均衡和 HTTP 缓存,如果不止一台服务器,Nginx 基本就是必选项了,通过 Nginx,将资源可以分配给不同的服务器节点,只有一台服务器,也能很好地提高性能,因为 Nginx 可以通过 headers 的Expires or E-Tag,gzip 压缩等方式很好地处理静态资源,毕竟是 C 语言写的,调用的是 native 的函数,针对 I/O做了优化,对于动态资源来说,Nginx 还可以实现缓存的功能,配合 CDN 优化(这是 uWSGI 做不到的)。Nginx 支持epoll/kqueue 等高效网络库,能够很好地处理高并发短连接请求,性能比 uWSGI 不知道高到哪里去了。
  3. 如果服务器主机上运行了PHP,Python 等语言写的多个应用,都需要监听80端口,这时候 Nginx 就是必选项了。因为我们需要一个转发的服务。
WSGI:全称是Web Server Gateway Interface,WSGI不是服务器,python模块,框架,API或者任何软件,只是一种规范,描述web server如何与web application通信的规范。要实现WSGI协议,必须同时实现web server和web application,当前运行在WSGI协议之上的web框架有Bottle, Flask, Django。
uwsgi:与WSGI一样是一种通信协议,是uWSGI服务器的独占协议,用于定义传输信息的类型(type of information)
uWSGI:是一个web服务器,实现了WSGI协议、uwsgi协议、http协议等。
WSGI协议主要包括server和application两部分:
WSGI server负责从客户端接收请求,将request转发给application,将application返回的response返回给客户端;
WSGI application接收由server转发的request,处理请求,并将处理结果返回给server。application中可以包括多个栈式的中间件(middlewares),这些中间件需要同时实现server与application,因此可以在WSGI服务器与WSGI应用之间起调节作用:对服务器来说,中间件扮演应用程序,对应用程序来说,中间件扮演服务器。
WSGI协议其实是定义了一种server与application解耦的规范,即可以有多个实现WSGI server的服务器,也可以有多个实现WSGI application的框架,那么就可以选择任意的server和application组合实现自己的web应用。例如uWSGI和Gunicorn都是实现了WSGI server协议的服务器,Django,Flask是实现了WSGI application协议的web框架,可以根据项目实际情况搭配使用

Nginx 与 Apache 的异同

Nginx和Apache一样,都是一个HTTP服务器软件,功能实现上都采用模块化结构设计,都支持通用的语言接口,如PHP、Perl、Python等,同时还支持正、反向代理,虚拟主机,URL重写,压缩传输,SSL加密传输等。它们之间最大的差别是Apache处理速度很慢,且占用很多内存资源,而Nginx却恰恰相反;在功能实现上,Apache的所有模块都支持动、静态编译,而Nginx模块都是静态编译的,同时,Apache对Fcgi支持不好,而Nginx对Fcgi的支持非常的好;最重要的是,在处理连接方式上,Nginx支持epoll,而Apache却不支持;在大小上,Nginx安装包仅仅有几百K,和Nginx比起来Apache绝对是庞然大物。在了解了Nginx和Apache之间的异同点后基本知道了Nginx作为HTTP服务器的优势所在。

Nginx的优势

通过上面的简单介绍,Nginx作为HTTP服务器的优势是显而易见的,它有很多其它Web服务器无法比拟的性能和优势:
作为Web服务器,nginx处理静态文件、索引文件以及自动索引效率非常高。
作为代理服务器,Nginx可以实现无缓存的反向代理加速,提高网站运行速度。
作为负载均衡服务器,Nginx既可以在内部直接支持Rails和PHP,也可以支持HTTP代理服务器,对外进行服务。同时支持简单的容错和利用算法进行负载均衡。
在性能方面,Nginx是专门为性能优化而开发的,在实现上非常注重效率。它采用内核Poll模型,可以支持更多的并发连接,最大可以支持对50 000个并发连接数的响应,而且占用很低的内存资源。
在稳定性方面,Nginx采取了分阶段资源分配技术,使得对CPU与内存的占用率非常低。Nginx官方表示Nginx保持10 000个没有活动的连接,这些连接只占2.5M内存,因此,类似DOS这样的攻击对Nginx来说基本上是没有任何作用的。
在高可用性方面,Nginx支持热部署,启动速度特别迅速,因此可以在不间断服务的情况下,对软件版本或者配置进行升级,即使运行数月也无需重新启动,几乎可以做到7×24小时的不间断运行。

Nginx的模块与工作原理

Nginx由内核和模块组成,其中,内核的设计非常微小和简洁,完成的工作也非常简单,仅仅通过查找配置文件将客户端请求映射到一个location block(location是Nginx配置中的一个指令,用于URL匹配),而在这个location中所配置的每个指令将会启动不同的模块去完成相应的工作。
Nginx的模块从结构上分为核心模块、基础模块和第三方模块, HTTP模块、EVENT模块和MAIL模块等属于核心模块,HTTP Access模块、HTTP FastCGI模块、HTTP Proxy模块和HTTP Rewrite模块属于基本模块,而HTTP Upstream Request Hash模块、Notice模块和HTTP Access Key模块属于第三方模块,用户根据自己的需要开发的模块都属于第三方模块。正是有了这么多模块的支撑,Nginx的功能才会如此强大。
Nginx的模块从功能上分为三类,分别是:
(1) Handlers(处理器模块)。此类模块直接处理请求,并进行输出内容和修改headers信息等操作。handlers处理器模块一般只能有一个。
(2) Filters (过滤器模块)。此类模块主要对其他处理器模块输出的内容进行修改操作,最后由Nginx输出。
(3) Proxies (代理类模块)。就是Nginx的HTTP Upstream之类的模块,这些模块主要与后端一些服务比如fastcgi等操作交互,实现服务代理和负载均衡等功能。
下图展示了Nginx的模块下一次常规的HTTP请求和响应的过程。

在这里插入图片描述

在工作方式上,Nginx分为单工作进程和多工作进程两种模式。在单工作进程模式下,除主进程外,还有一个工作进程,工作进程是单线程的;在多工作进程模式下,每个工作进程包含多个线程。Nginx默认为单工作进程模式。
Nginx的模块直接被编译进Nginx,因此属于静态编译方式。启动Nginx后,Nginx的模块被自动加载,不像在Apache一样,首先将模块编译为一个so文件,然后在配置文件中指定是否进行加载。在解析配置文件时,Nginx的每个模块都有可能去处理某个请求,但是同一个处理请求只能由一个模块来完成。

Nginx 配置文件结构

Nginx的配置文件是一个纯文本文件,它一般位于Nginx安装目录的conf目录下,整个配置文件是以block的形式组织的。每个block一般以一个大括号“{}”来表示,block可以分为几个层次,整个配置文件中Main指令位于最高层,在Main层下面可以有Events、HTTP等层级,而在HTTP层中又包含有Server层,即server block,server block中又可分为location层,并且一个server block中可以包含多个location block。
一个完整的配置文件结构如下图所示。

在这里插入图片描述

Nginx 配置文件详解

Nginx安装完毕后,会产生相应的安装目录,一般为/etc/nginx/conf,其中nginx.conf为Nginx的主配置文件。这里重点介绍下nginx.conf这个配置文件。

Nginx配置文件主要分成四部分:main(全局设置)、server(主机设置)、upstream(负载均衡服务器设置)和 location(URL匹配特定位置的设置)。main部分设置的指令将影响其他所有设置;server部分的指令主要用于指定主机和端口;upstream指令主要用于负载均衡,设置一系列的后端服务器;location部分用于匹配网页位置。这四者之间的关系式:server继承main,location继承server,upstream既不会继承其他设置也不会被继承。
在这四个部分当中,每个部分都包含若干指令,这些指令主要包含Nginx的主模块指令、事件模块指令、HTTP核心模块指令,同时每个部分还可以使用其他HTTP模块指令,例如Http SSL模块、HttpGzip Static模块和Http Addition模块等。
下面通过一个Nginx配置实例,详细介绍下nginx.conf每个指令的含义。为了能更清楚地了解Nginx的结构和每个配置选项的含义,这里按照功能点将Nginx配置文件分为7个部分逐次讲解,下面就围绕这7个部分进行介绍。

Nginx的全局配置

下面这段内容是对Nginx的全局属性配置,代码如下:

 user  nobody nobody;
 worker_processes  4;
 error_log  logs/error.log  notice;
 pid        logs/nginx.pid;
 worker_rlimit_nofile 65535;
 events{
  use epoll;
  worker_connections      65536;
       }

对上面这段代码中每个配置选项的含义解释如下:

对上面这段代码中每个配置选项的含义解释如下:

  • user是个主模块指令,指定Nginx Worker进程运行用户以及用户组,默认由nobody账号运行。

  • worker_processes是个主模块指令,指定了Nginx要开启的进程数。每个Nginx进程平均耗费10M~12M内存。根据经验,一般指定一个进程足够了,如果是多核CPU,建议指定和CPU的数量一样的进程数即可。

  • error_log是个主模块指令,用来定义全局错误日志文件。日志输出级别有debug、info、notice、warn、error、crit可供选择,其中,debug输出日志最为最详细,而crit输出日志最少。

  • pid是个主模块指令,用来指定进程id的存储文件位置。

  • worker_rlimit_nofile用于指定一个nginx进程可以打开的最多文件描述符数目,这里是65535,需要使用命令“ulimit -n 65535”来设置。

  • events指令是设定Nginx的工作模式及连接数上限。

    events{
    use epoll;
    worker_connections      65536;
    }
    

    use是个事件模块指令,用来指定Nginx的工作模式。Nginx支持的工作模式有select、poll、kqueue、epoll、rtsig和/dev/poll。其中select和poll都是标准的工作模式,kqueue和epoll是高效的工作模式,不同的是epoll用在Linux平台上,而kqueue用在BSD系统中。对于Linux系统,epoll工作模式是首选。
    worker_connections也是个事件模块指令,用于定义Nginx每个进程的最大连接数,默认是1024.最大客户端连接数由worker_processes和worker_connections决定,即Max_client=worker_processes*worker_connections,在作为反向代理时,max_clients变为:max_clients = worker_processes * worker_connections/4。
    进程的最大连接数受Linux系统进程的最大打开文件数限制,在执行操作系统命令“ulimit -n 65536”后worker_connections的设置才能生效。

HTTP服务器配置

接下来开始进行HTTP服务器设置。
下面这段内容是Nginx对HTTP服务器相关属性的配置,代码如下:

http{
include      conf/mime.types;
default_type  application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] '
 '"$request" $status $bytes_sent '
 '"$http_referer" "$http_user_agent" '
 '"$gzip_ratio"';
 log_format download '$remote_addr - $remote_user [$time_local] '
 '"$request" $status $bytes_sent '
 '"$http_referer" "$http_user_agent" '
 '"$http_range" "$sent_http_content_range"';
client_max_body_size  20m;
client_header_buffer_size    32K;
large_client_header_buffers  4 32k;
Sendfile  on;
tcp_nopush     on;
tcp_nodelay    on;
keepalive_timeout 60;
client_header_timeout  10;
client_body_timeout    10;
send_timeout          10;

下面详细介绍下这段代码中每个配置选项的含义:

  • include是个主模块指令,实现对配置文件所包含的文件的设定,可以减少主配置文件的复杂度。类似于Apache中的include方法。
  • default_type属于HTTP核心模块指令,这里设定默认类型为二进制流,也就是当文件类型未定义时使用这种方式,例如在没有配置PHP环境时,Nginx是不予解析的,此时,用浏览器访问PHP文件就会出现下载窗口。
    下面的代码实现对日志格式的设定。
    log_format main '$remote_addr - remoteuser[remote_user [time_local] ’
    ‘"$request" $status KaTeX parse error: Double superscript at position 14: bytes_sent ' '̲"http_referer" “KaTeX parse error: Double superscript at position 20: …_user_agent" ' '̲"gzip_ratio”’;
    log_format download '$remote_addr - remoteuser[remote_user [time_local] ’
    ‘"$request" $status KaTeX parse error: Double superscript at position 14: bytes_sent ' '̲"http_referer" “KaTeX parse error: Double superscript at position 20: …_user_agent" ' '̲"http_range” “$sent_http_content_range”’;
  • log_format是Nginx的HttpLog模块指令,用于指定Nginx日志的输出格式。main为此日志输出格式的名称,可以在下面的access_log指令中引用。
  • client_max_body_size用来设置允许客户端请求的最大的单个文件字节数。
  • client_header_buffer_size用于指定来自客户端请求头的headerbuffer大小。对于大多数请求,1K的缓冲区大小已经足够,如果自定义了消息头或有更大的Cookie,可以增加缓冲区大小。这里设置为32K。
  • large_client_header_buffers用来指定客户端请求中较大的消息头的缓存最大数量和大小, “4”为个数,“128K”为大小,最大缓存量为4个128K。
  • sendfile参数用于开启高效文件传输模式。将tcp_nopush和tcp_nodelay两个指令设置为on用于防止网络阻塞。
  • keepalive_timeout设置客户端连接保持活动的超时时间。在超过这个时间之后,服务器会关闭该连接。
  • client_header_timeout设置客户端请求头读取超时时间。如果超过这个时间,客户端还没有发送任何数据,Nginx将返回“Request time out(408)”错误。
  • client_body_timeout设置客户端请求主体读取超时时间。如果超过这个时间,客户端还没有发送任何数据,Nginx将返回“Request time out(408)”错误,默认值是60。
  • send_timeout指定响应客户端的超时时间。这个超时仅限于两个连接活动之间的时间,如果超过这个时间,客户端没有任何活动,Nginx将会关闭连接。

HttpGzip模块配置

下面配置Nginx的HttpGzip模块。这个模块支持在线实时压缩输出数据流。要查看是否安装了此模块,需要使用下面的命令:

[root@localhost conf]# /etc/nginx/sbin/nginx  -V
nginx version: nginx/0.7.65

configure arguments: --with-http_stub_status_module --with-http_gzip_static_module --prefix=/etc/nginx
通过/etc/nginx/sbin/nginx  -V命令可以查看安装Nginx时的编译选项,由输出可知,我们已经安装了HttpGzip模块。

下面是HttpGzip模块在Nginx配置中的相关属性设置:

gzip  on;
gzip_min_length  1k;
gzip_buffers     4  16k;
gzip_http_version  1.1;
gzip_comp_level  2;
gzip_types  text/plain application/x-javascript text/css application/xml;
gzip_vary  on;
  • gzip用于设置开启或者关闭gzip模块,“gzip on”表示开启GZIP压缩,实时压缩输出数据流。
  • gzip_min_length设置允许压缩的页面最小字节数,页面字节数从header头的Content-Length中获取。默认值是0,不管页面多大都进行压缩。建议设置成大于1K的字节数,小于1K可能会越压越大。
  • gzip_buffers表示申请4个单位为16K的内存作为压缩结果流缓存,默认值是申请与原始数据大小相同的内存空间来存储gzip压缩结果。
  • gzip_http_version用于设置识别HTTP协议版本,默认是1.1,目前大部分浏览器已经支持GZIP解压,使用默认即可。
  • gzip_comp_level用来指定GZIP压缩比,1 压缩比最小,处理速度最快;9 压缩比最大,传输速度快,但处理最慢,也比较消耗cpu资源。
  • gzip_types用来指定压缩的类型,无论是否指定,“text/html”类型总是会被压缩的。
  • gzip_vary选项可以让前端的缓存服务器缓存经过GZIP压缩的页面,例如用Squid缓存经过Nginx压缩的数据

负载均衡配置

下面设定负载均衡的服务器列表:

upstream ixdba.net{
ip_hash;
server 192.168.12.133:80;
server 192.168.12.134:80  down;
server 192.168.12.135:8009  max_fails=3  fail_timeout=20s;
server 192.168.12.136:8080;
}

upstream是Nginx的HTTP Upstream模块,这个模块通过一个简单的调度算法来实现客户端IP到后端服务器的负载均衡。在上面的设定中,通过upstream指令指定了一个负载均衡器的名称ixdba.net。这个名称可以任意指定,在后面需要的地方直接调用即可。

  • 在HTTP Upstream模块中,可以通过server指令指定后端服务器的IP地址和端口,同时还可以设定每个后端服务器在负载均衡调度中的状态。常用的状态有:
    down,表示当前的server暂时不参与负载均衡。
  • backup,预留的备份机器。当其他所有的非backup机器出现故障或者忙的时候,才会请求backup机器,因此这台机器的压力最轻。
  • max_fails,允许请求失败的次数,默认为1。当超过最大次数时,返回proxy_next_upstream 模块定义的错误。
  • fail_timeout,在经历了max_fails次失败后,暂停服务的时间。max_fails可以和fail_timeout一起使用。
  • 注意 当负载调度算法为ip_hash时,后端服务器在负载均衡调度中的状态不能是weight和backup。

server虚拟主机配置

下面介绍对虚拟主机的配置。建议将对虚拟主机进行配置的内容写进另外一个文件,然后通过include指令包含进来,这样更便于维护和管理:

server{
listen          80;
server_name    192.168.12.188  www.ixdba.net;
index index.html index.htm index.jsp;
root  /web/wwwroot/www.ixdba.net
charset gb2312;
  • server标志定义虚拟主机开始,listen用于指定虚拟主机的服务端口,server_name用来指定IP地址或者域名,多个域名之间用空格分开。Index用于设定访问的默认首页地址,root指令用于指定虚拟主机的网页根目录,这个目录可以是相对路径,也可以是绝对路径。Charset用于设置网页的默认编码格式。
  • access_log logs/www.ixdba.net.access.log main;
  • access_log用来指定此虚拟主机的访问日志存放路径,最后的main用于指定访问日志的输出格式。

URL匹配配置

URL地址匹配是进行Nginx配置中最灵活的部分。 location支持正则表达式匹配,也支持条件判断匹配,用户可以通过location指令实现Nginx对动、静态网页进行过滤处理。
以下这段设置是通过location指令来对网页URL进行分析处理,所有扩展名以.gif、.jpg、.jpeg、.png、.bmp、.swf结尾的静态文件都交给nginx处理,而expires用来指定静态文件的过期时间,这里是30天

location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$  {
                root    /web/wwwroot/www.ixdba.net;
               expires 30d;
        }

以下这段设置是将upload和html下的所有文件都交给nginx来处理,当然,upload和html目录包含在/web/wwwroot/www.ixdba.net目录中。

        location ~ ^/(upload|html)/  {
                root    /web/wwwroot/www.ixdba.net;
                expires 30d;
        }

在最后这段设置中,location是对此虚拟主机下动态网页的过滤处理,也就是将所有以.jsp为后缀的文件都交给本机的8080端口处理

location ~ .*.jsp$ {
    index index.jsp;      
    proxy_pass http://localhost:8080;
}

StubStatus模块配置

StubStatus模块能够获取Nginx自上次启动以来的工作状态,此模块非核心模块,需要在Nginx编译安装时手工指定才能使用此功能。
以下指令实指定启用获取Nginx工作状态的功能

        location /NginxStatus {
                        stub_status      on;
access_log              logs/NginxStatus.log;
                        auth_basic              "NginxStatus";
      auth_basic_user_file    ../htpasswd;
        }

stub_status设置为“on”表示启用StubStatus的工作状态统计功能。access_log 用来指定StubStatus模块的访问日志文件。auth_basic是Nginx的一种认证机制。auth_basic_user_file用来指定认证的密码文件,由于Nginx的auth_basic认证采用的是与Apache兼容的密码文件,因此需要用Apache的htpasswd命令来生成密码文件,例如要添加一个webadmin用户,可以使用下面方式生成密码文件:
/usr/local/apache/bin/htpasswd -c /opt/nginx/conf/htpasswd webadmin
会得到以下提示信息:
New password:
输入密码之后,系统会要求再次输入密码。确认之后添加用户成功。

要查看Nginx的运行状态,可以输入http://ip/ NginxStatus,然后输入刚刚创建的用户名和密码就可以看到如下信息:

Active connections: 1
server accepts handled requests
 393411 393411 393799
Reading: 0 Writing: 1 Waiting: 0

Active connections表示当前活跃的连接数,第三行的三个数字表示 Nginx当前总共处理了393411个连接, 成功创建393411次握手, 总共处理了393799个请求。最后一行的Reading表示Nginx读取到客户端Header信息数, Writing表示Nginx返回给客户端的Header信息数,“Waiting”表示Nginx已经处理完,正在等候下一次请求指令时的驻留连接数。

在最后这段设置中,设置了虚拟主机的错误信息返回页面,通过error_page指令可以定制各种错误信息的返回页面。在默认情况下,Nginx会在主目录的html目录中查找指定的返回页面,特别需要注意的是,这些错误信息的返回页面大小一定要超过512K,否者会被ie浏览器替换为ie默认的错误页面。

    error_page 404       /404.html;
    error_page  500 502 503 504 /50x.html;
    location = /50x.html {
      root  html;
    }
}
}

Nginx 代理

Nginx是一款自由的、开源的、高性能的HTTP服务器和反向代理服务器;同时也是一个IMAP、POP3、SMTP代理服务器;Nginx可以作为一个HTTP服务器进行网站的发布处理,另外Nginx可以作为反向代理进行负载均衡的实现。

关于代理

说到代理,首先我们要明确一个概念,所谓代理就是一个代表、一个渠道;

此时就涉及到两个角色,一个是被代理角色,一个是目标角色,被代理角色通过这个代理访问目标角色完成一些任务的过程称为代理操作过程;如同生活中的专卖店~客人到adidas专卖店买了一双鞋,这个专卖店就是代理,被代理角色就是adidas厂家,目标角色就是用户。

正向代理

说反向代理之前,我们先看看正向代理,正向代理也是大家最常接触的到的代理模式,我们会从两个方面来说关于正向代理的处理模式,分别从软件方面和生活方面来解释一下什么叫正向代理。

在如今的网络环境下,我们如果由于技术需要要去访问国外的某些网站,此时你会发现位于国外的某网站我们通过浏览器是没有办法访问的,此时大家可能都会用一个代理进行访问,代理的方式主要是找到一个可以访问国外网站的代理服务器,我们将请求发送给代理服务器,代理服务器去访问国外的网站,然后将访问到的数据传递给我们!

上述这样的代理模式称为正向代理,正向代理最大的特点是客户端非常明确要访问的服务器地址;服务器只清楚请求来自哪个代理服务器,而不清楚来自哪个具体的客户端;正向代理模式屏蔽或者隐藏了真实客户端信息。

总结来说:正向代理,“它代理的是客户端”,是一个位于客户端和原始服务器(origin server)之间的服务器,为了从原始服务器取得内容,客户端向代理发送一个请求并指定目标(原始服务器),然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。

正向代理的用途:
(1)访问原来无法访问的资源,如Google
(2) 可以做缓存,加速访问资源
(3)对客户端访问授权,上网进行认证
(4)代理可以记录用户访问记录(上网行为管理),对外隐藏用户信息

反向代理

明白了什么是正向代理,我们继续看关于反向代理的处理方式,举例如我大天朝的某宝网站,每天同时连接到网站的访问人数已经爆表,单个服务器远远不能满足人民日益增长的购买欲望了,此时就出现了一个大家耳熟能详的名词:分布式部署;也就是通过部署多台服务器来解决访问人数限制的问题;某宝网站中大部分功能也是直接使用Nginx进行反向代理实现的,并且通过封装Nginx和其他的组件之后起了个高大上的名字:Tengine,有兴趣的童鞋可以访问Tengine的官网查看具体的信息:http://tengine.taobao.org/。

多个客户端给服务器发送的请求,Nginx服务器接收到之后,按照一定的规则分发给了后端的业务处理服务器进行处理了。此时~请求的来源也就是客户端是明确的,但是请求具体由哪台服务器处理的并不明确了,Nginx扮演的就是一个反向代理角色。

客户端是无感知代理的存在的,反向代理对外都是透明的,访问者并不知道自己访问的是一个代理。因为客户端不需要任何配置就可以访问。

反向代理,“它代理的是服务端”,主要用于服务器集群分布式部署的情况下,反向代理隐藏了服务器的信息。

反向代理的作用:
(1)保证内网的安全,通常将反向代理作为公网访问地址,Web服务器是内网
(2)负载均衡,通过反向代理服务器来优化网站的负载

项目场景

一般在项目中正向代理和反向代理都是同时出现的,正向代理代理客户端的请求去访问目标服务器,目标服务器是一个反向代理服务器,反向代理了多台真实的业务处理服务器:

多个客户端请求		----->		正向代理		----->		反向代理		----->		多个服务器

在正向代理中,Proxy和Client同属于一个LAN(图中方框内),隐藏了客户端信息;

在反向代理中,Proxy和Server同属于一个LAN(图中方框内),隐藏了服务端信息;

实际上,Proxy在两种代理中做的事情都是替服务器代为收发请求和响应,不过从结构上看正好左右互换了一下,所以把后出现的那种代理方式称为反向代理了。

Nginx 负载均衡

负载均衡

我们已经明确了所谓代理服务器的概念,那么接下来,Nginx扮演了反向代理服务器的角色,它是以依据什么样的规则进行请求分发的呢?不同的项目应用场景,分发的规则是否可以控制呢?

这里提到的客户端发送的、Nginx反向代理服务器接收到的请求数量,就是我们说的负载量。

请求数量按照一定的规则进行分发到不同的服务器处理的规则,就是一种均衡规则。

所以~将服务器接收到的请求按照规则分发的过程,称为负载均衡。

负载均衡在实际项目操作过程中,有硬件负载均衡和软件负载均衡两种,硬件负载均衡也称为硬负载,如F5负载均衡,相对造价昂贵成本较高,但是数据的稳定性安全性等等有非常好的保障,如中国移动中国联通这样的公司才会选择硬负载进行操作;更多的公司考虑到成本原因,会选择使用软件负载均衡,软件负载均衡是利用现有的技术结合主机硬件实现的一种消息队列分发机制。

Nginx支持的负载均衡调度算法方式如下:

  1. weight轮询(默认):接收到的请求按照顺序逐一分配到不同的后端服务器,即使在使用过程中,某一台后端服务器宕机,Nginx会自动将该服务器剔除出队列,请求受理情况不会受到任何影响。 这种方式下,可以给不同的后端服务器设置一个权重值(weight),用于调整不同的服务器上请求的分配率;权重数据越大,被分配到请求的几率越大;该权重值,主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的。
  2. ip_hash:每个请求按照发起客户端的ip的hash结果进行匹配,这样的算法下一个固定ip地址的客户端总会访问到同一个后端服务器,这也在一定程度上解决了集群部署环境下session共享的问题。
  3. fair:智能调整调度算法,动态的根据后端服务器的请求处理到响应的时间进行均衡分配,响应时间短处理效率高的服务器分配到请求的概率高,响应时间长处理效率低的服务器分配到的请求少;结合了前两者的优点的一种调度算法。但是需要注意的是Nginx默认不支持fair算法,如果要使用这种调度算法,请安装upstream_fair模块。
  4. url_hash:按照访问的url的hash结果分配请求,每个请求的url会指向后端固定的某个服务器,可以在Nginx作为静态服务器的情况下提高缓存效率。同样要注意Nginx默认不支持这种调度算法,要使用的话需要安装Nginx的hash软件包。

参考:

http://blog.360converter.com/archives/1005

https://www.cnblogs.com/fengchong/p/10230266.html

https://blog.csdn.net/a3192048/article/details/89737337

https://blog.51cto.com/ixdba/790611

https://blog.51cto.com/ixdba/778469

https://blog.51cto.com/ixdba/778462

https://blog.51cto.com/ixdba/793571

https://blog.51cto.com/ixdba/798913

https://blog.51cto.com/ixdba/803475


本文链接: http://www.dtmao.cc/news_show_100050.shtml

附件下载

相关教程

    暂无相关的数据...

共有条评论 网友评论

验证码: 看不清楚?