zoukankan      html  css  js  c++  java
  • Nginx服务器配置详解

    Nginx配置文件的整体结构

    从图中可以看出主要包含以下几大部分内容:

    1. 全局块

    该部分配置主要影响Nginx全局,通常包括下面几个部分:

    • 配置运行Nginx服务器用户(组)
    • worker process数
    • Nginx进程PID存放路径
    • 错误日志的存放路径
    • 配置文件的引入

    2. events块

    该部分配置主要影响Nginx服务器与用户的网络连接,主要包括:

    • 设置网络连接的序列化
    • 是否允许同时接收多个网络连接
    • 事件驱动模型的选择
    • 最大连接数的配置

    3. http块

    • 定义MIMI-Type
    • 自定义服务日志
    • 允许sendfile方式传输文件
    • 连接超时时间
    • 单连接请求数上限

    4. server块

    • 配置网络监听
    • 基于名称的虚拟主机配置
    • 基于IP的虚拟主机配置

    5. location块

    • location配置
    • 请求根目录配置
    • 更改location的URI
    • 网站默认首页配置

     

    location配置

    参考:

    https://blog.csdn.net/zwl18210851801/article/details/81699977

    https://www.cnblogs.com/paokaiyiqie/p/7873283.html

    指令格式为:location [ = | ~ | ~* | ^~ ] uri {...}

    • 这里的uri分为标准uri和正则uri,两者的唯一区别是uri中是否包含正则表达式

    uri前面的方括号中的内容是可选项,解释如下:

    • “=”:用于标准uri前,要求请求字符串与uri严格匹配,一旦匹配成功则停止

    • “~”:用于正则uri前,并且区分大小写

    • “~*”:用于正则uri前,但不区分大小写

    • “^~”:用于标准uri前,要求Nginx找到标识uri和请求字符串匹配度最高的location后,立即使用此location处理请求,而不再使用location块中的正则uri和请求字符串做匹配

    匹配规则举例

    location = / {
              #规则A
          }
    location = /login {
              #规则B
          }
    location ^~ /static/ {
              #规则C
          }
    location ~ .(gif|jpg|png|js|css)$ {
              #规则D
          }
    location ~* .(gif|jpg|png|js|css)$ {
              #规则E
          }
    location !~ .xhtml$ {
              #规则F
          }
    location !~* .xhtml$ {
              #规则G
          }
    location / {
              #规则H
          }

    作用如下:

    1. 访问根目录/,比如http://localhost/将匹配规则A
    
    2. 访问 http://localhost/login 将匹配规则B,http://localhost/register则匹配规则H
    
    3. 访问 http://localhost/static/a.html 将匹配规则C
    
    4. 访问 http://localhost/a.gif 将匹配规则D和规则E,但是规则D顺序优先,规则E不起作用,而http://localhost/static/c.png则优先匹配到规则C
    
    5. 访问 http://localhost/a.PNG 则匹配规则E,而不会匹配规则D,因为规则E不区分大小写。
    
    6. 访问 http://localhost/a.xhtml 不会匹配规则F和规则G,http://localhost/a.XHTML不会匹配规则G,因为不区分大小写。规则F,规则G属于排除法,符合匹配规则但是不会匹配到。
    
    7. 访问 http://localhost/category/id/1111 则最终匹配到规则H,因为以上规则都不匹配。

    基本思路:

    1先判断精准命中,如果命中,立即返回结果并结束解析过程。
    
    2判断普通命中,如果有多个命中,“记录”下来“最长”的命中结果(记录但不结束,最长的为准)。
    
    3继续判断正则表达式的解析结果,按配置里的正则表达式顺序为准,由上至下开始匹配,一旦匹配成功1个,立即返回结果,并结束解析过程。
    
    4普通命中顺序无所谓,是因为按命中的长短来确定。正则命中,顺序有所谓,因为是从前入往后命中的。

    常用规则:

    #处理静态文件请求,这是nginx作为http服务器的强项
    #1,目录匹配
    location ^~ /static/ {
           # 请求/static/a.txt 将被映射到实际目录文件:/webroot/res/static/a.txt
           root /webroot/res/;
        }
    #2,后缀匹配
    location ~* .(gif|jpg|jpeg|png|css|js|ico)${
           root /webroot/res/;
    }
    
    #后端应用服务器转发
     location / {
           proxy_pass http://tomcat:8080/
        }

    解析过程:

    全局配置

    配置运行Nginx服务器用户(组)

    指令格式:user user [group];

    • user:指定可以运行Nginx服务器的用户
    • group:可选项,可以运行Nginx服务器的用户组

    如果user指令不配置或者配置为 user nobody nobody ,则默认所有用户都可以启动Nginx进程

    worker process数配置

    Nginx服务器实现并发处理服务的关键,指令格式:worker_processes number | auto;

    • number:Nginx进程最多可以产生的worker process数
    • auto:Nginx进程将自动检测

    按照上文中的配置清单的实验,我们给worker_processes配置的数目是:3,启动Nginx服务器后,我们可以后台看一下主机上的Nginx进程情况:

    ps -aux | grep nginx

    很明显,理解 worker_processes 这个指令的含义就很容易了

    Nginx进程PID存放路径

    Nginx进程是作为系统守护进程在运行,需要在某文件中保存当前运行程序的主进程号,Nginx支持该保存文件路径的自定义

    指令格式:pid file;

    • file:指定存放路径和文件名称

    • 如果不指定默认置于路径 logs/nginx.pid

    错误日志的存放路径

    指定格式:error_log file | stderr;

    • file:日志输出到某个文件file
    • stderr:日志输出到标准错误输出
    • 自定义服务日志

      指令格式:

      access_log path [format];
      • path:自定义服务日志的路径 + 名称

      • format:可选项,自定义服务日志的字符串格式。其也可以使用 log_format 定义的格式

    配置文件的引入

    指令格式:include file;

    • 该指令主要用于将其他的Nginx配置或者第三方模块的配置引用到当前的主配置文件中

    设置网络连接的序列化

    指令格式:accept_mutex on | off;

    • 该指令默认为on状态,表示会对多个Nginx进程接收连接进行序列化,防止多个进程对连接的争抢。

    说到该指令,首先得阐述一下什么是所谓的 “惊群问题”,可以参考 WIKI百科的解释。就Nginx的场景来解释的话大致的意思就是:当一个新网络连接来到时,多个worker进程会被同时唤醒,但仅仅只有一个进程可以真正获得连接并处理之。如果每次唤醒的进程数目过多的话,其实是会影响一部分性能的。

    所以在这里,如果accept_mutex on,那么多个worker将是以串行方式来处理,其中有一个worker会被唤醒;反之若accept_mutex off,那么所有的worker都会被唤醒,不过只有一个worker能获取新连接,其它的worker会重新进入休眠状态

    这个值的开关与否其实是要和具体场景挂钩的。

    是否允许同时接收多个网络连接

    指令格式:multi_accept on | off;

    • 该指令默认为off状态,意指每个worker process 一次只能接收一个新到达的网络连接。若想让每个Nginx的worker process都有能力同时接收多个网络连接,则需要开启此配置

    事件驱动模型的选择

    指令格式:use model;

    • model模型可选择项包括:select、poll、kqueue、epoll、rtsig等......

    最大连接数的配置

    指令格式:worker_connections number;

    • number默认值为512,表示允许每一个worker process可以同时开启的最大连接数

    定义MIME-Type

    指令格式:

    include mime.types;
    default_type mime-type;
    • MIME-Type指的是网络资源的媒体类型,也即前端请求的资源类型

    • include指令将mime.types文件包含进来

    允许sendfile方式传输文件

    指令格式:

    sendfile on | off;
    sendfile_max_chunk size;
    • 前者用于开启或关闭使用sendfile()传输文件,默认off
    • 后者指令若size>0,则Nginx进程的每个worker process每次调用sendfile()传输的数据了最大不能超出此值;若size=0则表示不限制。默认值为0

    连接超时时间配置

    指令格式:keepalive_timeout timeout [header_timeout];

    • timeout 表示server端对连接的保持时间,默认75秒

    • header_timeout 为可选项,表示在应答报文头部的 Keep-Alive 域设置超时时间:“Keep-Alive : timeout = header_timeout”

    配置网络监听

    指令格式:

    • 第一种:配置监听的IP地址:listen IP[:PORT];

    • 第二种:配置监听的端口:listen PORT;

    实际举例:

    listen 192.168.31.177:8080; # 监听具体IP和具体端口上的连接
    listen 192.168.31.177;      # 监听IP上所有端口上的连接
    listen 8080;                # 监听具体端口上的所有IP的连接

    基于名称和IP的虚拟主机配置

    指令格式:server_name name1 name2 ...

    • name可以有多个并列名称,而且此处的name支持正则表达式书写

    实际举例:

    server_name ~^wwwd+.myserver.com$

    此时表示该虚拟主机可以接收类似域名 www1.myserver.com 等的请求而拒绝 www.myserver.com 的域名请求,所以说用正则表达式可以实现更精准的控制

    至于基于IP的虚拟主机配置比较简单,不再太赘述:

    指令格式:server_name IP地址

     

  • 相关阅读:
    Codeforces Round #604(Div. 2,
    简单的三层框架以及使用dbutils进行数据库操作(入门)
    DBUtil数据库工具封装
    GUI 中监听 文本框实时改变的实例
    java基础教程GUI
    Dao层通用化,Spring3.0+Hibernate3.3.2通用Dao层整合
    计算器代码
    记事本应用程序java源代码
    GUI
    dbutils开源项目用法
  • 原文地址:https://www.cnblogs.com/tkzc2013/p/10951811.html
Copyright © 2011-2022 走看看