Nginx 学习笔记

安装步骤

第一步 安装依赖软件

• 
  
• GCC编译器
  

GCC(GNU Compiler Collection)用来编译C语言程序

yum install -y gcc

• 
  
• G++编译器
  

用来编译C++程序

yum install -y gcc-c++

• 
  
• PCRE库
  

支持正则表达式

yum install -y pcre pcre-devel

• 
  
• zlib库
  

用来对HTTP包的内容做gzip格式的压缩

yum install -y zlib zlib-devel

• 
  
• OpenSSL开发库
  

支持SSL协议上传输HTTP、使用MD5、SHA1等散列函数

yum install -y openssl openssl-devel

第二步 编译安装

1. 解压源码

tar -zxvf nginx-x.x.x.tar.gz

1. configure命令做了大量的“幕后”工作，包括检测操作系统内核和已经安装的软件，参数的解析，中间目录的生成以及根据各种参数生成一些C源码文件、Makefile文件等

./configure

1. make命令根据configure命令生成的Makefile文件编译Nginx工程，并生成目标文件、最终的二进制文件

make

1. make install命令根据configure执行时的参数将Nginx部署到指定的安装目录，包括相关目录的建立和二进制文件、配置文件的复制

make install

第三步 启动和关闭

默认情况下，Nginx被安装在目录/usr/local/nginx/中，其二进制文件路径为/usr/local/nginx/sbin/nginx，配置文件路径为/usr/local/nginx/conf/nginx.conf

1. 默认方式启动

/usr/local/nginx/sbin/nginx

1. 另行指定配置文件的启动方式

/usr/local/nginx/sbin/nginx -c nginx.conf

1. 另行指定安装目录的启动方式

/usr/local/nginx/sbin/nginx -p usr/local/nginx/

1. 另行指定全局配置项的启动方式

/usr/local/nginx/sbin/nginx -g "pid nginx/test.pid"

1. 测试配置信息是否有错误
   在不启动Nginx的情况下，测试配置文件是否有错误

/usr/local/nginx/sbin/nginx -t

1. 显示编译阶段的参数
   可以显示Nginx的版本信息，显示编译阶段的信息，如GCC编译器的版本、操作系统的版本、执行configure时的参数等

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

1. 强制停止Nginx服务

/usr/local/nginx/sbin/nginx -s stop

1. 等待处理完当前所有请求再停止服务

/usr/local/nginx/sbin/nginx -s quit

1. 使运行中的Nginx重读配置项并生效

/usr/local/nginx/sbin/nginx -s reload

基本配置

由于配置项较多，所以把它们按照用户使用时的预期功能分成了以下4类：
1. 用于调式、定位问题的配置项
2. 正常运行的必备配置项
3. 优化性能的配置项
4. 事件类配置项

用于调试进程和定位问题的配置项

1. 是否以守护进程方式运行Nginx

语法：daemon on|off
默认：daemon on

1. 是否以master/worker方式工作

语法：master_process on|off
默认：master_process on

1. error日志的设置

语法：error_log pathfile level
默认：error_log logs/error.log error

pathfile可以是一个具体的文件；也可以是/dev/null，这样就不会输出任何日志了，这是关闭error日志的唯一的手段

level是日志的输出级别，取值范围是debug、info、notice、warn、error、crit、alert、emerg

注意：如果日志级别设定到debug，必须要在configure时加入–with-debug配置项

正常运行的配置项

1. 定义环境变量

语法：env VAR|VAR=VALUE

1. 嵌入其它配置文件

语法：include pathfile
示例1：include mime.types
实例2：vhost/*.conf

1. pid文件的路径

语法：pid pathfile
默认：pid logs/nginx.pid

4.Nginx worker进程运行的用户和用户组

语法：user username[groupname]
默认：user nobody nobody

user用户设置master进程启动后，fork出的worker进程运行在哪个用户和用户组下。

优化性能的配置项

1. Nginx worker进程个数

语法：worker_processes number
默认：worker_processes 1

每个worker进程都是单线程的进程，它们会调用各个模块以实现多种多样的功能。如果这些模块确认不会阻塞式的调用，那么，有多少个CPU内核就应该配置多少个进程；反之，如果有可能出现阻塞式调用，那么需要配置稍多一些的worker进程。

多worker进程可以充分利用多核系统架构，但若worker进程的数量多于CPU内核数，那么会增大进程间切换带来的消耗（Linux式抢占式内核）。一般情况下，用户要配置与CPU内核数相等的worker进程，并且使用下面的worker_cpu_affinity配置来绑定CPU内核。

1. 绑定Nginx worker进程到指定的CPU内核

语法：worker_cpu_affinity cpumask[cpumask...]
示例：worker_cpu_affinity 1000 0100 0010 0001

注意：：worker_processes和worker_cpu_affinity都有一个特殊值“auto”，它允许将工作进程自动绑定到可用的CPU

事件类配置项

1. 是否打开accept锁

语法：accept_mutex on|off
默认：accept_mutex on

accept_mutex是Nginx的负载均衡锁，可以让多个worker进程轮流地、序列化地与新的客户端建立TCP连接。当某个worker进程建立的连接数达到worker_connections配置的最大连接数的7/8式，会大大地减小该worker进程试图建立新TCP连接的机会，以此实现所有woerker进程之上处理的客户端请求数尽量接近。

1. lock文件的路径

语法：lock_file pathfile
默认：lock_file logs/nginx.lock

accept锁可能需要这个lock文件，如果accept锁关闭，lock_file配置完全不生效。如果打开了accept锁，并且由于编译程序、操作系统架构等因素导致Nginx不支持原子锁，这时才会用文件锁是实现accept锁，这样lock_file指定的lock文件才会生效。

1. 使用accept锁后真正建立之间的延迟时间

语法：accpet_mutex_delay Nms
默认：accpet_mutex_delay 500ms

在使用accept锁后，同一时间只有一个worker进程能够取到accept锁，这个accept锁不是阻塞锁，如果取不到不会立刻返回，至少要等到accept_mutex_delay定义的时间间隔后才能再次试图取锁。

1. 批量建立新连接

语法：multi_accept on|off
默认：multi_accept off

1. 选择事件模型

语法：use [kqueue|rtsig|epoll|/dev/poll|select|poll|eventport]
默认：Nginx会自动使用最合适的事件模型

1. 每个worker的最大连接数

语法：worker_connections number

用HTTPh核心模块配置一个静态Web服务器

静态Web服务器的主要功能由ngx_http_core_module模块实现。

虚拟主机与请求的转发

由于IP地址的数量有限，因此经常存在多个主机域名对应着同一个IP地址的情况，这时在nginx.conf中就可以按照server_name并通过server块来定义虚拟主机，每个server块就是一个虚拟主机，它只处理与之对应的主机域名请求。

1. 监听端口

语法:listen address:port[defualt_server|ssl|...]
默认：listen 80
配置块：server

1. 主机名称

语法：server_name name[name...]
默认：server_name ""
配置块：server

在开始处理一个HTTP请求时，Nginx会取出header头中的Host，与每个server中的server_name进行匹配，一次决定由哪个server块来处理这个请求，如果都没有匹配选择默认的虚拟主机（由default_server定义，或者第一个虚拟主机），如果匹配多个根据如下匹配优先级进行选择：

由强到弱	示例
所有字符串完全匹配	www.testweb.com
通配符在前面	*.testweb.com
通配符在后面	www.testweb.*
正则表达式	~^\.testweb\.com&

3. 重定向主机名称的处理

语法：server_name_in_redirect on|off
默认：server_name_in_redirect on
配置块：http、server或location

该配置要配置server_name使用。在使用on打开时，表示在重定向请求时会使用server_name里配置的第一个主机名代替原先请求中的Host头部，而使用off关闭时，表示在重定向请求时使用请求本身的Host头部

1. location

语法：location[=|~|~*|^~|@]/uri/{...}
配置块：server

location会尝试根据用户请求中的URI来匹配上面的/uri/表达式，如果可以匹配就选择location{}块中的配置来处理用户请求

匹配规则	说明
=	完全匹配
~	大小写敏感
~*	忽略大小写
^~	配置前半部分
@	用于Nginx服务内部请求之间的重定向
正则表达式
/	匹配所有

文件路径的定义

1. 以root方式设置资源路径

语法：root path
默认：root html
配置块：http、server、location、if

示例：

location /download/ {
    root optwebhtml;
}

在上面的配置中，如果有一个请求的URI是/download/index/test.html,那么Web服务器将会返回服务器上optwebhtml/download/index/test.html文件的内容

1. 以alias方式设置资源路径

语法：alias path
配置块：location

示例：
如果上面的示例采用alias配置如下：

location /download/ {
    alias optwebhtml/download/;
}

1. 访问首页

语法：index file[file...]
默认：index index.html
配置块：http、server、location

1. 根据HTTP返回码重定向页面

语法：error_page code[code...][=|=answer-code]uri|@named_location
配置块：http、server、location、if

示例：

error_page 404 404.html;
error_page 502 503 504 50x.html;
error_page 403 http://example.com/forbidden.html;

修改错误码
error_page 404 =200 empty.gif
error_page 404 =/empty.gif

重定向
location /{
    error_page 404 @fallback;
}
location @fallback {
    proxy_pass http://backend
}

网络连接的设置

1. 读取HTTP头部的超时时间

语法：client_header_timeout time(默认单位：秒)
默认：client_header_timeout 60
配置块：http、server、location

2.读取HTTP包体的超时时间

语法：client_body_timeout time(默认单位：秒)
默认：client_body_timeout 60
配置块：http、server、location

1. 发送响应的超时时间

语法：send_timeout time(默认单位：秒)
默认：send_timeout 60
配置块：http、server、location

1. keepalive超时时间

语法：keepalive_timeout time(默认单位：秒)
默认：keepalive_timeout 75;
配置块：http、server、location

HTTP请求中的keepalive功能是为了让多个请求复用一个HTTP长连接，这个功能对服务器的性能提高是很有帮助的。一个keepalive连接在闲置超过一定时间后(默认的是75秒)，服务器和浏览器都会去关闭这个连接。

1. 一个keepalive长连接上允许承载的请求最大数

语法：keepalive_requests n
默认：keepalive_requests 100
配置块：http、server、location

用HTTP proxy module配置一个反向代理服务器

反向代理(reverse proxy)方式是指代理服务器来接受Internet上的请求，然后将请求转发给内部网络中的上游服务器，并将从上游服务器上得到的结果返回给Internet上请求的客户端，此时代理服务器对外的表现就是一个Web服务器。

Nginx的这种工作方式可以降低上游服务器的负载：通常，客户端与代理服务器之间的网络环境会比较复杂，多半是“走”公网，网速平均下来可能比较慢，因此一个请求可能要持续很久才能完成。而代理服务器与上游服务器之间一般是“走”内网，传输速度较快。Squid等反向代理服务器在与客户端建立连接且还没有开始接收HTTP包体时，就已经向上有服务器建立了连接。例如，某个请求要上传一个1GB文件，那么每次Squid在收到一个TCP分包时，就会即时向上有服务器转发。在接收客户端完整HTTP包体的漫长过程中，上游服务器始终要维持这个连接，这直接对上游服务器的并发处理能力提出了挑战。

Nginx则在接收到完整的客户端请求后，才会与上游服务器建立连接转发请求，由于时内网，所以这个转发过程会执行得很快，这样，一个客户端请求占用上游服务器的连接时间会比较短，也就是说，Nginx这种反向代理方案主要是为了降低上游服务器的并发压力。

负载均衡的基本配置

1. upstream块

语法：upstream name {...}
配置块：http

upstream块定义了一个上游服务器的集群，便于反向代理中的proxy_pass使用

示例

upstream backend {
    server backend1.example.com;
    server backenf2.example.com;
}
server {
    location / {
        proxy_pass http://backend;
    }
}

1. server

语法：server name[parameters]
配置：upstream

server配置指定了一台上游服务器的名字，这个名字可以是域名、IP地址端口、UNIX句柄等，在其后还可以跟下列参数：

参数	说明
weight=number	设置转发的权重，默认为1
max_fails=number	超过失败次数后认为该服务器不可用，默认为1，设置为0表示不检查失败次数
fail_timeout=time	超过时间算失败，默认为10s
down	该服务器下线，只在使用ip_hash配置项时才有用
backup	备份服务器，所有非备份服务器失效后使用，在配置ip_hash后无效

3. ip_hash

语法：ip_hash
配置块：upstream

ip_hash与weight配置不可同时使用，如果upstream集群中有一台上游服务器暂时不可用，不能直接删除，而是要down参数标识，确保转发策略的一贯性。

在有些场景下，ip_hash可以保证某一个用户的请求始终落到固定的一台上游服务器中。ip_hash首先根据客户端的IP计算出一个key，将key按照upstream集群里的上游服务器数量进行取模，然后按照结果转发到相应的上游服务器。

反向代理的基础配置

1. proxy_pass

语法：proxy_pass URI
配置块：location、if

默认情况下反向代理时不会转发请求中的Host头部的，如果需要转发必须加上配置

proxy_set_header Host $host;

1. proxy_mothod

语法：proxy_method method
配置块：http、server、location

示例：

proxy_method POST

1. proxy_pass_request_headers
   是否转发HTTP头部

语法：proxy_pass_request_headers on|off
默认：proxy_pass_request_headers on
配置块：http、server、location

1. proxy_redirect

语法：proxy_redirect[default|off|redirect replacement]
默认：proxy_redirect default
配置：http、server、location

当上游服务器返回的响应式重定向或刷新请求时，proxy_redirect可以重设HTTP头部的location或refresh字段。

1. proxy_next_upstream

语法：proxy_next_upstream[error|timeout|invalid_header|http_500|http_502|http_504|http_404|off]
默认：proxy_next_upstream timeout
配置块：http、server、location

此配置项表示当向一台上游服务器转发请求出现错误时，继续换一台上游服务器处理这个请求。

proxy_next_upstream的参数用来说明哪些情况下会继续选择下一台上游服务器转发请求

参数	说明
error	当向上游服务器发起连接、发送请求、读取响应时出错
timeout	发送请求或读取响应时发生超时
invalid_header	上游服务器发送的响应是不合法的
http_xxx	上游服务器返回的HTTP响应码是xxx
off	关闭proxy_next_upstream功能，一旦出错就选择另一台上游服务器再次转发