乐趣区

关于nginx:nginx心得

jiezi

nginx 简介(参考百度)

Nginx (engine x) 是一个高性能的 HTTP 和反向代理 web 服务器，同时也提供了 IMAP/POP3/SMTP 服务。Nginx 是由伊戈尔·赛索耶夫为俄罗斯访问量第二的 Rambler.ru 站点（俄文：Рамблер）开发的，第一个公开版本 0.1.0 公布于 2004 年 10 月 4 日。

其将源代码以类 BSD 许可证的模式公布，因它的稳定性、丰盛的功能集、示例配置文件和低系统资源的耗费而闻名。2011 年 6 月 1 日，nginx 1.0.4 公布。

Nginx 是一款轻量级的 Web 服务器 / 反向代理服务器及电子邮件（IMAP/POP3）代理服务器，在 BSD-like 协定下发行。其特点是占有内存少，并发能力强，事实上 nginx 的并发能力在同类型的网页服务器中体现较好，中国大陆应用 nginx 网站用户有：百度、京东、新浪、网易、腾讯、淘宝
等。

nginx 装置

  • 1. 装置编译工具及库文件
yum -y install make zlib zlib-devel gcc-c++ libtool  openssl openssl-devel
  • 2. 装置 PCRE
cd /usr/local/src/
wget http://downloads.sourceforge.net/project/pcre/pcre/8.35/pcre-8.35.tar.gz
  • 3. 装置 Nginx
cd /usr/local/src/
wget http://nginx.org/download/nginx-1.6.2.tar.gz

参考（https://www.runoob.com/linux/…）

nginx 根本构造

高度模块化的设计是 Nginx 的架构根底。Nginx 服务器被合成为多个模块，每个模块就是一个功能模块，只负责本身的性能，模块之间严格遵循“高内聚，低耦合”的准则

  • 外围模块

外围模块是 Nginx 服务器失常运行必不可少的模块，提供谬误日志记录、配置文件解析、事件驱动机制、过程治理等外围性能。

  • 规范 HTTP 模块

规范 HTTP 模块提供 HTTP 协定解析相干的性能，如：端口配置、网页编码设置、HTTP 响应头设置等。

  • 可选 HTTP 模块

可选 HTTP 模块次要用于扩大规范的 HTTP 性能，让 Nginx 能解决一些非凡的服务，如：Flash 多媒体传输、解析 GeoIP 申请、SSL 反对等。

  • 邮件服务模块

邮件服务模块次要用于反对 Nginx 的邮件服务，包含对 POP3 协定、IMAP 协定和 SMTP 协定的反对。

  • 第三方模块

第三方模块是为了扩大 Nginx 服务器利用，实现开发者自定义性能，如：Json 反对、Lua 反对等。
参考（https://www.sohu.com/a/230364…）

nginx 基本功能

  • web 服务器、反向代理服务器
  • 负载平衡
  • 动静拆散

nginx 长处

  • 1. 能够高并发连贯

官网测试 Nginx 可能撑持 5 万并发连贯，理论生产环境中能够撑持 2~4 万并发连接数。

起因，次要是 Nginx 应用了最新的 epoll（Linux2.6 内核）和 kqueue（freeBSD）网路 I / O 模型，而 Apache 应用的是传统的 Select 模型，其比较稳定的 Prefork 模式为多过程模式，须要常常派生子过程，所以耗费的 CPU 等服务器资源，要比 Nginx 高很多。

  • 2. 内存耗费少

Nginx+PHP（FastCGI）服务器，在 3 万并发连贯下，开启 10 个 Nginx 过程耗费 150MB 内存，15MB*10=150MB，开启的 64 个 PHP-CGI 过程耗费 1280 内存，20MB*64=1280MB，加上零碎本身耗费的内存，总共耗费不到 2GB 的内存。

如果服务器的内存比拟小，齐全能够只开启 25 个 PHP-CGI 过程，这样 PHP-CGI 耗费的总内存数才 500MB。

+3. 老本低廉
购买 F5BIG-IP、NetScaler 等硬件负载平衡交换机，须要十多万到几十万人民币，而 Nginx 为开源软件，采纳的是 2 -clause BSD-like 协定，能够收费试用，并且可用于商业用途。

BSD 开源协定是一个给使用者很大自在的协定，协定指出能够自在应用、批改源代码、也能够将批改后的代码作为开源或专用软件再公布。

  • 4. 配置文件非常简单

网络和程序一样通俗易懂，即便，非专用系统管理员也能看懂。

  • 5. 反对 Rewrite 重写

可能依据域名、URL 的不同，将 http 申请分到不同的后端服务器群组。

  • 6. 内置的健康检查性能

如果 NginxProxy 后端的某台 Web 服务器宕机了，不会影响前端的拜访。

  • 7. 节俭带宽

反对 GZIP 压缩，能够增加浏览器本地缓存的 Header 头。

  • 8. 稳定性高

用于反向代理，宕机的概率微不足道。

  • 9. 反对热部署

Nginx 反对热部署，它的主动特地容易，并且，简直能够 7 天 *24 小时不间断的运行，即便，运行数个月也不须要重新启动，还可能在不间断服务的状况下，对软件版本进行降级。

nginx 毛病

  • 1. 动静解决差：nginx 解决动态文件好, 消耗内存少，然而解决动静页面则很鸡肋，当初个别前端用 nginx 作为反向代理抗住压力，apache 作为后端解决动静申请。
  • 2.rewrite 弱：尽管 nginx 反对 rewrite 性能，然而相比于 Apache 来说，Apache 比 nginx 的 rewrite 弱小。
  • 3.Nginx 仅能反对 http、https 和 Email 协定，这样就在适用范围下面小些，这个是它的毛病
  • 4. 对后端服务器的健康检查，只反对通过端口来检测，不反对通过 url 来检测不反对 Session 的间接放弃，但能通过 ip_hash 来解决

nginx 配置

  • 全局
#Nginx 的 worker 过程运行用户以及用户组
#user  nobody nobody;
#Nginx 开启的过程数
worker_processes  1;
#worker_processes auto;
#以下参数指定了哪个 cpu 调配给哪个过程，一般来说不必非凡指定。如果肯定要设的话，用 0 和 1 指定调配形式.
#这样设就是给 1 - 4 个过程调配独自的核来运行，呈现第 5 个过程是就是随机调配了。eg:
#worker_processes 4     #4 核 CPU 
#worker_cpu_affinity 0001 0010 0100 1000;
nets    
#定义全局谬误日志定义类型，[debug|info|notice|warn|crit]
#error_log  logs/error.log  info;
#指定过程 ID 存储文件地位
#pid        logs/nginx.pid;
#一个 nginx 过程关上的最多文件描述符数目，理论值应该是最多关上文件数（ulimit -n）与 nginx 过程数相除，然而 nginx 调配申请并不是那么平均，所以最好与 ulimit - n 的值保持一致。#vim /etc/security/limits.conf
#  *                soft    nproc          65535
#  *                hard    nproc          65535
#  *                soft    nofile         65535
#  *                hard    nofile         65535
worker_rlimit_nofile 65535;
  • events 事件配置
events {#use [ kqueue | rtsig | epoll | /dev/poll | select | poll]; epoll 模型是 Linux 2.6 以上版本内核中的高性能网络 I / O 模型，如果跑在 FreeBSD 下面，就用 kqueue 模型。use epoll;
    #每个过程能够解决的最大连接数，实践上每台 nginx 服务器的最大连接数为 worker_processes*worker_connections。理论值：worker_rlimit_nofile/worker_processes
    #留神：最大客户数也由零碎的可用 socket 连接数限度（~ 64K），所以设置不切实际的高没什么益处
    worker_connections  65535;    
    #worker 工作形式：串行（肯定水平升高负载，但服务器吞吐量大时，敞开应用并行形式）#multi_accept on; 
}
  • http 参数
   #文件扩展名与文件类型映射表
    include mime.types;
    #默认文件类型
    default_type application/octet-stream;
 
#日志相干定义
    #log_format  main  '$remote_addr - $remote_user [$time_local]"$request" '
    #                  '$status $body_bytes_sent"$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';
    #定义日志的格局。前面定义要输入的内容。#1.$remote_addr 与 $http_x_forwarded_for 用以记录客户端的 ip 地址；#2.$remote_user：用来记录客户端用户名称；#3.$time_local：用来记录拜访工夫与时区；#4.$request：用来记录申请的 url 与 http 协定；#5.$status：用来记录申请状态；#6.$body_bytes_sent：记录发送给客户端文件主体内容大小；#7.$http_referer：用来记录从那个页面链接拜访过去的；#8.$http_user_agent：记录客户端浏览器的相干信息
    #连贯日志的门路，指定的日志格局放在最初。#access_log  logs/access.log  main;
    #只记录更为严重的谬误日志，缩小 IO 压力
    error_log logs/error.log crit;
    #敞开日志
    #access_log  off;
 
    #默认编码
    #charset utf-8;
    #服务器名字的 hash 表大小
    server_names_hash_bucket_size 128;
    #客户端申请单个文件的最大字节数
    client_max_body_size 8m;
    #指定来自客户端申请头的 hearerbuffer 大小
    client_header_buffer_size 32k;
    #指定客户端申请中较大的音讯头的缓存最大数量和大小。large_client_header_buffers 4 64k;
    #开启高效传输模式。sendfile on;
    #防止网络阻塞
    tcp_nopush on;
    tcp_nodelay on;    
    #客户端连贯超时工夫，单位是秒
    keepalive_timeout 60;
    #客户端申请头读取超时工夫
    client_header_timeout 10;
    #设置客户端申请主体读取超时工夫
    client_body_timeout 10;
    #响应客户端超时工夫
    send_timeout 10;
 
#FastCGI 相干参数是为了改善网站的性能：缩小资源占用，进步访问速度。fastcgi_connect_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_read_timeout 300;
    fastcgi_buffer_size 64k;
    fastcgi_buffers 4 64k;
    fastcgi_busy_buffers_size 128k;
    fastcgi_temp_file_write_size 128k;
 
#gzip 模块设置
    #开启 gzip 压缩输入
    gzip on; 
    #最小压缩文件大小
    gzip_min_length 1k; 
    #压缩缓冲区
    gzip_buffers 4 16k;
    #压缩版本（默认 1.1，前端如果是 squid2.5 请应用 1.0）gzip_http_version 1.0;
    #压缩等级 1-9 等级越高，压缩成果越好，节约宽带，但 CPU 耗费大
    gzip_comp_level 2;
    #压缩类型，默认就曾经蕴含 text/html，所以上面就不必再写了，写上去也不会有问题，然而会有一个 warn。gzip_types text/plain application/x-javascript text/css application/xml;
    #前端缓存服务器缓存通过压缩的页面
    gzip_vary on;
  • server（虚拟主机根底设置）
# 虚拟主机定义
    server {
        #监听端口
        listen       80;
        #拜访域名
        server_name  localhost;
        #编码格局，若网页格局与此不同，将被主动转码
        #charset koi8-r;
        #虚拟主机拜访日志定义
        #access_log  logs/host.access.log  main;
        #对 URL 进行匹配
        location / {
            #拜访门路，可绝对也可绝对路径
            root   html;
            #首页文件。以下按程序匹配
            index  index.html index.htm;
        }
  • 负载平衡
# 负载平衡服务器池
upstream my_server_pool {
    #调度算法
    #1. 轮循（默认）（weight 轮循权值）#2.ip_hash：依据每个申请拜访 IP 的 hash 后果调配。（会话放弃）#3.fair: 依据后端服务器响应工夫最短申请。（upstream_fair 模块）#4.url_hash: 依据拜访的 url 的 hash 后果调配。（需 hash 软件包）#参数：#down：示意不参加负载平衡
    #backup: 备份服务器
    #max_fails: 容许最大申请谬误次数
    #fail_timeout: 申请失败后暂停服务工夫。server 192.168.1.109:80 weight=1 max_fails=2 fail_timeout=30;
    server 192.168.1.108:80 weight=2 max_fails=2 fail_timeout=30;
}
#负载平衡调用
server {
    ...
    location / {proxy_pass http://my_server_pool;}
}
  • location 定位
# 依据不同的浏览器 URL 重写
if($http_user_agent ~ Firefox){rewrite ^(.*)$  /firefox/$1 break; 
}
if($http_user_agent ~ MSIE){rewrite ^(.*)$  /msie/$1 break; 
}
 
#实现域名跳转
location / {rewrite ^/(.*)$ https://web8.example.com$1 permanent;
}
  • IP 限度
# 限度 IP 拜访
location / {
    deny 192.168.0.2；allow 192.168.0.0/24;
    allow 192.168.1.1;
    deny all;
}

nginx 内置变量


nginx 常用命令

  • 启动进入 sbin ./nginx
  • 查看 ngix 语法测试是否通过 ./nginx -t
  • 重启 ./nginx -s reload
  • 查看 nginx 是否启动 ps -ef | grep nginx
  • 敞开 nginx ./nginx -s stop
  • 关联配置 ./nginx -c xx.conf

nginx 注意事项

1.Nginx 在上传文件时呈现 413 Request Entity Too Large，怎么办？

因为 Nginx 默认反对上传 1MB 的文件，所以超过 1MB 则会报错。#nginx 上传文件大小限度配置语法  
Syntax: client\_max\_body\_size size;  
Default: client\_max\_body\_size 1m;  
Context: http, server, location  
容许该 server 能反对上传 200m 的文件，也能够其配置放入 http 层，所有 server 都失效。server {  
...  
 client\_max\_body\_size 200m;  
...  
}

2.Nginx 指定门路时，root 与 alias 区别在哪？

root 与 alias 门路匹配次要区别在于 nginx 如何解释 location 前面的 uri，这会使两者别离以不同的形式将申请映射到服务器文件上，alias 是一个目录别名的定义，root 则是最上层目录的定义。

root 的处理结果是：root 门路+location 门路
alias 的处理结果是：应用 alias 门路替换 location 门路

1.root 门路配置实例: 用户拜访 www.xuliangwei.com/image/test.gif，实际上 Nginx 会上 /code/image/ 目录下找去找 test.gif 文件

server {  
 listen 80;  
 server\_name www.xuliangwei.com;  
 location /image/ {root /code;}  
}

3.400 bad request

个别起因: 申请的 Header 过大。解决办法：配置 nginx.conf 相干设置

`client_header_buffer_size 16k;`
`large_client_header_buffers 4 64k;`

4.403 forbiden
个别是拜访文件权限不够

5.413 Request Entity Too Large

个别起因: 个别呈现在上传文件。解决办法：配置 nginx.conf 相干设置，配置 php.ini 如下(必须和 nginx.conf 配置统一)

client_max_body_size 10m;

post_max_size=10M

upload_max_filesize=2M

 499 Client Closed Request

个别起因: 客户端在为等到服务器相应返回前就敞开了客户端描述符。个别呈现在客户端设置超时后，被动敞开 socket.

解决办法：依据理论 Nginx 后端服务器的解决工夫批改客户端超时工夫。

 > 6.500 Internal Server Rrror

个别起因：脚本谬误，（php 语法错误、lua 语法错误）

拜访量过大，系统资源限度，不能关上过多文件
磁盘空间有余。（access log 开启可能导致磁盘满溢 敞开）

 > 7.502 Bad Gateway、503 Serveice Unavailable

个别起因: 后端服务无奈解决，业务中断。
解决办法：从后端日志获取谬误起因，解决后端服务器问题。

 > 8.504 Gateway Timeout

个别起因: 后端服务器在超时工夫内，未响应 Nginx 代理申请
解决办法：依据后端服务器理论解决状况，调正后端申请超时工夫。
proxy_read_timeout 90;
proxy_send_timeout 90;

参考（https://www.cnblogs.com/johnn…）
参考（https://blog.csdn.net/lzghxjt…）

退出移动版