Nginx（一）初认识

Nginx

  对于Nginx不进行过多的介绍，只需要知道：Nginx是一个高性能的web服务器，其可以作为HTTP服务器，亦可作为反向代理服务器以及邮件服务器。
  延续上面的解释，需要了解一下什么是正向代理以及反向代理。

 正/反向代理

   所谓的正向代理，就是客户端让一个中介来充当自己的角色，向目标服务器发送请求，而这个中介则是代理服务器，即如下图所示：

   那么由于是代理服务器去向目标服务器发送请求，在代理服务器未公开的情况下，目标服务器并不知道真正的访问者是谁，提高安全性。并且，通过代理服务器还可以提前缓存请求的内容，以此来提高访问速度。

   而反向代理服务器其实也是一个连接客户端和目标服务器的中介，只不过这个中介是充当目标服务器的角色，即如下图所示：

   由于这个中介是代表了服务器，那么就不会暴露实际访问的目标服务器，也就是说，可以相应地提高目标服务器的安全性。并且这个中介还可以充当一个负载均衡的服务器，即可以根据目标服务器的工作负荷情况，将请求发送到合适的服务器。

  在了解完正向代理和反向代理的概念以后，再来讲讲Nginx的应用场景。

 Nginx应用场景

   Nginx应用场景一般分为：静态资源服务、反向代理服务。

   所谓的静态资源服务实际上是通过本地系统提供服务，比如说：访问图片、CSS、JS等静态资源文件时，是没有必要从应用服务上来访问，而是直接用Nginx从本地文件提供访问即可。

   而反向代理服务实际上是Nginx高性能的一种体现，比如说：当一个web请求时，需要经过一个服务器集群，再进入到应用服务层（如Tomcat等）进行处理，然后再去访问数据库服务层（如Mysql等），最后返回所响应的内容。

   但是这里却有一个问题：为了保证应用服务的高效率开发性，相应地就会降低其运行效率。换句话来说，应用服务的并发效率是有限度的。那么为了解决这样的问题，就需要把这一类应用服务组成为一个集群。

   因此，基于反向代理的功能，Nginx就可以把动态的请求发送给应用服务。但是这里又产生了一个问题：有些服务出问题时，就需要进行容灾技术的实现。换句话来说，Nginx在反向代理下还需要具备负载均衡功能。

  了解完Nginx大致的应用场景后，接下来就可以学习Nginx相关的配置，这里以Linux系统为例。

 Nginx配置

   对于Vmware中配置Linux相关设置这里不过多讲述。首先需要知道的是，Nginx是由C语言编写的，因此非常的高效以及在使用其之前需要安装相应的依赖包，安装指令如下所示：

	yum install gcc-c++
	yum install -y pcre pcre-devel
	yum install -y zlib zlib-devel
	yum install -y openssl openssl-devel

   这里对几个依赖库解释一下：
    1.gcc-c++是一个平台编译工具；
    2.PCRE（Perl Compatible Regular Expressions）库是一个表达式库，Nginx的http模块使用该库来解析正则表达式；
    3.Zlib库用于压缩和解压缩，Nginx使用该库对http包的内容进行压缩；
    4.OpenSSL（Open Secure Sockets Layer）库是一个安全套接子层密码库，其用于提供Nginx的https协议的保障。

   当安装完依赖库以后，使用wget指令获取安装包，如下所示：

	wget http://nginx.org/download/nginx-1.16.1.tar.gz

   通过Nginx官网找到相应的下载地址，可以是直接下载tar.gz导入到linux里也可以直接在linux使用wget指令获取相应的Nginx。

   在这里将其下载到/usr/local/server目录下，如下所示：

   对其进行解压（tar -xvzf nginx-1.16.1.tar.gz），结果如下所示：

   进入解压后的目录，其目录结构如下所示：

   相应的目录解释如下所示：

文件/文件夹名	含义
auto	包含了很多在执行configure脚本时调用的检测代码
conf	Nginx自带的默认配置文件
configure脚本	用于生成中间文件
contrib	自定义脚本，默认提供两个脚本和vim工具
html	默认提供了两个html文件
man	Linux系统的Nginx的帮助文件
src	Nginx源代码目录

   对其进行安装前的编译，如下所示：

	./configure --prefix=/usr/local/server/nginx

   其中，prefix表示当前nginx需安装的目录。如果想要添加第三方的模块，则通过–add-module配置，即如下所示：

	--add-module=/usr/local/.../file

   当配置完毕以后，会发现在当前目录下会产生一个Makefile文件，并且会形成一堆中间文件存放在objs目录下。其中，在这个目录下最主要的文件就是ngx_modules.c文件，决定了执行编译的时候会有哪些模块被编译到nginx中。

   接着通过以下指令进行编译以及安装：

	make && make install

   安装完成后，进入安装的Nginx目录下可以看到以下文件结构：

   相应的解释如下所示：

文件夹名	含义
conf	含有nginx配置文件
html	含有html文件
logs	存储日志文件
sbin	nginx主程序应用入口

   Nginx安装完成以后，为了使本机访问到虚拟机的服务器，需要在防火墙开放80端口，如下所示：

	firewall-cmd --zone=public --add-port=80/tcp --permanent
	firewall-cmd --reload

   当设置完访问端口的权限后，进入到安装的Nginx目录下的sbin目录下，执行以下命令：

	./nginx

   打开浏览器访问192.168.0.211（自行配置的Linux的IP地址），结果如下所示：

   以上，对Nginx的初步配置以及安装到此结束。

 示例演示

   在讲示例之前，先稍微了解一下Nginx的配置文件的基本语法

  Nginx配置文件

   Nginx中的配置文件中包含了很多模块，而每一个模块都具有独自语法规则，而这些规则又遵循着一套既定的规则。接下来对这一套既定的规则进行阐述，如下所示：

• 配置文件由指令与指令块构成
• 每条指令以;（英文分号）结尾，指令与参数间以空格符号分隔
• 指令块以｛｝大括号将多条指令组织在一起
• 部分指令的参数支持正则表达式
• include指令允许组合多个配置文件以提升可维护性
• 指令块是否拥有名字取决于提供该指令的Nginx模块
• 使用#符号添加注释，提高可读性
• 使用$符号使用变量

   进入到解压好的Nginx目录下的conf下，查看nginx.conf文件。这里需要注意的是，直接用vim是无法识别出Nginx的语法，即如下所示：

   为了解决这个问题，需要将contrib目录中的vim文件夹里的所有文件拷贝出来到vim的vimfiles中，如下所示：

   接下来再用vim打开nginx.conf文件，会发现当前的vim已经可以识别出nginx的语法。

   接下来抽取一部分指令块来讲解，如下所示：

   在上图中，http是一个指令，在指令块{}里又可以包含其他指令。在注释的部分，其实可以看到remote_addr等字符都是变量。其他指令里也可以包含一个指令块，这里以http指令块里的server指令为例，如下所示：

   在http块里包含了一个server，其对应了一个域名亦或者一组域名，而location则只是一个url表达式。特别注意的是，在下方的注释中，可以看到location指令后的参数其实就是一组正则表达式。

   Nginx配置文件的基本语法规则讲到这里，而配置文件中每一个指令模块在后续会进一步讲解。

   讲完了配置文件的基本语法之后，接下来通过搭载静态资源服务器示例来加深对Nginx的认识。

  静态资源服务器

   在上面介绍Nginx的应用场景时介绍过何为静态资源服务器，在网上找了一个小demo，将其下载到安装好的nginx目录下，如下所示：

   接下来进入配置文件，来配置相关的访问设置，如下所示：

   在这里修改了默认的监听端口以及location的对应请求处理。其中，需要注意的是，在location里面有一个和alias指令差不多作用的root指令，但是root指令是会将url路径带入到访问的文件目录中，即如下所示：

   在配置完毕后，重启Nginx。接着打开浏览器F12，访问配置好的静态资源页面。从Internet选项卡里我们可以看到传输的大小和文件的大小相同，如下所示：

   实际上我们可以通过Gzip技术来压缩静态资源，在Nginx的配置文件中的http模块里有相应的gzip指令，如下所示：

   相应的解释如下所示：

    1.gzip_min_length:大于多少字节的内容就压缩，默认值为20字节
    2.gzip_comp_level:是指压缩级别，级别越低压缩速度越快，则文件压缩比越小，反之速度越慢则文件压缩比越大；
    3.gzip_types:是指针对MIME类型的文件进行gzip压缩

   再次访问该静态资源，可以发现传输的字节数大大减少了，提高了传输效率，变相地提高了用户的访问速度。如图所示：

  在讲完这个示例以后，我们最后再来看一下Nginx的内部，来稍微了解一下Nginx的请求处理流程。

 Nginx请求处理流程

   我们先来看一下Nginx内部的处理机制，如图所示：

   首先从上图可知，Nginx内部有三个状态机：处理TCP/UDP的四层的传输层的状态机、处理应用层的HTTP状态机以及处理邮件的MAIL状态机。实际上，状态机的本质是对Nginx操作的一组指令，即指示Nginx怎么处理请求的指令。

   再者，需要关注的地方是：非阻塞的事件驱动处理引擎。这里以军旗来举例说明阻塞和非阻塞的区别。

   比如说，在军旗的规则（状态机）下，我们将每一次的HTTP连接当做每一局对弈。一边是一个web服务器进程，一边是客户端，web服务器进程和客户端根据规则（状态机）来下棋，那么实际上状态机就是这样的作用。

   当客户端发起一局对弈（建立连接）时，一个web服务器进程得到请求（监听连接），就开始启动，每下一次棋就进入等待状态（即阻塞），即等待客户端的选择。当客户端选择完后，再轮到web服务器进程处理。

   那么当一局结束后，web服务器进程就会去询问客户端是否要开启新的一轮对弈（即连接是否关闭）。如果连接已经被关闭，这个web服务器进程就会回到一个监听连接的状态。

   而非阻塞呢？如果当我们把客户端发起每一局对弈（建立新连接）以及客户端移动棋子分别作为事件来看，当只要客户端触发这其中一个事件，就让web服务器进程去处理。也就是说，当web服务器进程处理完一个事件，就去处理下一个事件，有可能是新启对弈，也有可能是处理另一个对弈。

   这样，就不会出现移动一个棋，就得在棋盘上等待客户端的下一步操作的阻塞情况。

   那么基于这样的理论，静态资源访问就是一个连接，而当这个连接发生的时候，Nginx就会根据状态机来处理这个连接中的事件。但是在访问静态资源的过程中，如果当内存已经不足以去支撑缓存所有的内容的时候，那么就有可能会变回阻塞式的处理，如磁盘IO，那么在这里就会需要一个线程池来处理这个操作。

   而当每一次连接处理完毕后，Nginx就会记录access以及error日志，将相关的连接信息记录到服务器上。需要注意的是，这个服务器不一定就是本地服务器，也有可能是远程服务器。

   而在这张图的最右边，其实就是反向代理亦或者负载均衡的处理过程。换句话来说，将请求通过右边的这两类协议分别传输到另一个web服务器或者代理的服务器。

  以上，就是Nginx对请求的处理流程大致介绍。

结束语

	'''
		在这一章示例只提到了静态资源的配置，在后续的章节会慢慢讲反向代理
		这一章主要讲了如何配置一个Nginx以及对Nginx的使用
		然后对Nginx的配置文件和其处理请求的流程进行了介绍和讲解
		在下一章主要对Nginx的进程结构以及进程管理的详解
	'''

  下一章链接：Nginx进程管理