Nginx VS Apache

Nginx 内容缓存

Nginx 上下文

Nginx指令和上下文

默认情况下，Nginx配置文件可以位于:

/etc/Nginx/Nginx.conf, /usr/local/etc/Nginx/Nginx.conf, 或者 /usr/local/Nginx/conf/Nginx.conf

配置文件的位置会因Nginx的安装过程而异。

这个文件有以下内容:

指令

Nginx 中的配置选项被称为指令。此选项有名称和参数，必须以分号(;) 结尾，否则 Nginx 将无法加载配置并产生错误。

示例:

gzip on;

Context

当我们在文本编辑器中打开核心 Nginx 配置文件时，首先我们会注意到配置被组织成树状结构，由花括号即"{"和"}"。这些被大括号包围的位置称为上下文，用于放置配置指令。此外，配置指令及其参数以分号结尾。

这是我们可以声明指令的部分。它类似于编程语言中的作用域。

上下文可以嵌套在其他上下文中，从而创建上下文层次结构。

示例:

worker_processes 2; # directive in the global context
http {              # http context
    gzip on;        # directive in http context
  server {          # server context
    listen 80;      # directive in server context
  }
}

# 填充的行是注释，Nginx 不解释。

指令类型

由于不同指令的继承模型不同，因此，我们在多个上下文中使用相同的指令时必须注意。共有三种类型的指令，每种类型都有其继承模型。

普通

每个上下文有一个值。我们只能在上下文中定义它一次。子上下文可以覆盖父指令，但此覆盖仅在给定的子上下文中有效。

gzip on;
gzip off; # illegal to have two normal directives in the same context 
server {
  location /downloads {
    gzip off;
  }
  location /assets {
    # gzip is in here
  }
}

Array

在同一上下文中添加太多指令会增加值而不是完全覆盖它们。在子上下文中定义指令将覆盖给定子上下文中父级的所有值。

error_log /var/log/Nginx/error.log;
error_log /var/log/Nginx/error_notive.log notice;
error_log /var/log/Nginx/error_debug.log debug;
server {
  location /downloads {
    # this will override all the parent directives
    error_log /var/log/Nginx/error_downloads.log;
  }
}

动作指令

动作是用于改变事物的指令。它们的继承行为将取决于模块。

例如: 在重写指令的情况下，将执行每个匹配的指令。

server {
  rewrite ^ /foobar;
  location /foobar {
    rewrite ^ /foo;
    rewrite ^ /bar;
  }
}

如果我们尝试获取/sample:

执行服务器重写，重写从 /sample 到 /foobar。
然后匹配位置 /foobar。
执行第一个^st位置重写，从/foobar重写到/foo。
执行第二个^nd位置重写，从/foo重写到/bar。

让我们看看与 return 指令提供的不同的行为:

server {
  location / {
    return 200;
    return 404;
  }
}

从上面的例子来看，200状态立即返回。

上下文类型

来看一个例子。

# Global context ... ... # http context http{ ... ... # Server context server { listen 80; server_name example.com; ... ... # Location context location / { root /var/www/html; try_files $uri $uri/ =404; ... ... } } # Server context server { ... ... # Location context location / { ... ... } } ... ... }

从上面的例子中，我们可以看到 HTTP 上下文声明了 HTTP 协议的设置。虚拟主机设置在服务器上下文中声明，也包含在 http 上下文中。用于存储 URL 设置的位置上下文包含在服务器上下文中。

主上下文

最通用的上下文是主上下文。它也称为全局上下文。主上下文全局设置 Nginx 的设置，并且是唯一不包含在典型上下文块中且不被花括号包围的上下文。

主上下文位于核心 Nginx 配置文件。此上下文的指令不能在任何其他上下文中继承，因此不能被覆盖。

主上下文用于配置在基本级别上影响整个应用程序的细节。在主上下文中配置的一些常见详细信息是运行工作进程的用户和组、工作人员总数以及保存主进程 ID 的文件。可以在主上下文级别设置整个应用程序的默认错误文件。

user Nginx;
worker_processes auto;
pid /run/Nginx.pid;
...
...

事件上下文

事件上下文设置连接处理的全局选项。事件上下文包含在主上下文中。 Nginx 配置中只能定义一个事件上下文。

Nginx 使用基于事件的连接处理模型，因此在此上下文中定义的指令决定了工作进程应如何处理连接。

# main context
events {
        # events context
        worker_connections 768; 
        multi_accept on;
}
...
...

HTTP 上下文

HTTP 上下文用于保存处理 HTTP 或 HTTPS 流量的指令。

HTTP 上下文是事件上下文的兄弟，因此它们必须并排列出，而不是嵌套。它们都是主上下文的子级。

较低的上下文处理请求，并且此级别的指令控制为每个虚拟服务器定义的默认值。

user Nginx;
worker_processes auto;
pid /run/Nginx.pid;
...
...
events {
        # events context
        worker_connections 768; 
        multi_accept on;
        ...
        ...
}
http {
       sendfile on; 
       tcp_nopush on; 
       tcp_nodelay on;  
       keepalive_timeout 65;
       ...
       ...
}

服务器上下文

服务器上下文在http上下文中声明。服务器上下文用于定义 Nginx 虚拟主机设置。 HTTP 上下文中可以有多个服务器上下文。服务器上下文中的指令处理对与特定域或 IP 地址关联的资源请求的处理。

此上下文中的指令可以覆盖许多可能在 http 上下文中定义的指令，包括文档根目录、日志记录、压缩等。除了从 http 上下文中获取的指令外，我们还可以配置文件以尝试响应请求、发出重定向和重写，以及设置任意变量。

user Nginx;
worker_processes auto;
pid /run/Nginx.pid;
...
...
events {
         # events context
         worker_connections 768;  
         multi_accept on;
         ...
         ...
 }
http {
       sendfile on; 
       tcp_nopush on; 
       tcp_nodelay on;  
       keepalive_timeout 65;
       ...
       ...
       server {
                listen 80;
                server_name domain1.com;
                root /var/www/html/wordpress;
                ...
     
       }
       server {
                listen 80;
                server_name domain2.com;
                root /var/www/html/drupal;
                ...
     
       }
}

位置上下文

位置上下文定义指令来处理客户端的请求。当对资源的任何请求到达 Nginx 时，它会尝试将 URI(统一资源标识符)与位置之一匹配并相应地处理它。

可以在服务器块中定义多个位置上下文。此外，一个位置上下文也可以嵌套在另一个位置上下文中。

http { ... ... server { listen 80; server_name domain1.com; root /var/www/html/wordpress; ... location /some_url { # configuration for processing URIs starting with /some_url } location /another_url { # configuration for processing URIs starting with /another_url } } server { listen 80; server_name domain2.com; root /var/www/html/drupal; ... location /some_url { # configuration for processing URIs starting with /some_url } location /some_other_url { # configuration for processing URIs starting with /some_other_url } } }

上游上下文

上游上下文用于配置和定义上游服务器。允许此上下文定义后端服务器池，Nginx 可以代理请求时使用的后端服务器。这个上下文通常是我们在配置各种类型的代理。

上游上下文使 Nginx 能够在代理请求的同时执行负载均衡。此上下文在 HTTP 上下文内部和任何服务器上下文外部定义。

上游上下文在服务器或位置块中按名称引用。然后将某种类型的请求传递给定义好的服务器池。然后上游将使用算法(默认为循环)来确定需要使用哪个特定服务器来处理请求。

http{
     ...
     ...
     upstream backend_servers {
                                server host1.example.com;
                                server host2.example.com;
                                server host3.example.com;
     }
server {
             listen 80;
             server_name example.com;
             location / {
                           proxy_pass http://backend_servers;
             }
  }
}

邮件上下文

虽然 Nginx 最常用作 Web 或反向代理服务器，但它也可以用作高性能邮件代理服务器。用于此类指令的上下文称为邮件上下文。邮件上下文定义在主上下文或全局上下文内或 http 上下文外。

邮件上下文的主要目的是提供一个区域，用于在服务器上配置邮件代理解决方案。 Nginx 可以将身份验证请求重定向到外部身份验证服务器。然后，它可以提供对 POP3、SMTP 和 IMAP 邮件服务器的访问，以提供实际邮件数据。

通常，邮件上下文如下所示:

# main context
mail {
       server_name mail.example.com;
       auth_http   localhost:9000/cgi-bin/Nginxauth.cgi;
       proxy_pass_error_message on;
       ...
}
http {
}
...
...

If 上下文

if 上下文用于允许有条件地执行其中定义的指令。如果上下文就像任何其他编程语言的"if 语句"。如果给定的条件返回真，if 上下文将执行包含的指令。

由于它的一些限制，应该尽可能避免if 上下文。使用此链接了解更多关于为什么应该避免使用 Nginx 的信息，讨论了这里。

http {
        server {
                     location /some_url {
                     if (test_condition) {
                          # do some stuff here
                   }
         }
    }
}

Limit_except 上下文

limit_except 上下文用于防止在位置上下文中使用除我们明确允许的方法之外的所有 HTTP 方法。例如，如果某些客户端应该有权访问POST 内容，并且每个人都应该能够阅读内容，那么我们可以为此使用limit_except 上下文。

...
...
location /wp-admin/ { 
    limit_except GET { 
      allow 127.0.0.1; 
      deny all; 
    } 
}
...
...

以上示例允许所有访问者使用位置/wp-admin 中的 GET 标头。如果其他 HTTP 标头仅源自本地地址，则允许使用其他 HTTP 标头。

杂项上下文

除了上述上下文之外，Nginx 中还有一些其他上下文可用，如下所述。这些上下文依赖于可选模块，很少使用。

split_clients: split_client 上下文将客户端的请求分成两个或多个类别。该上下文定义在 HTTP 上下文中，主要用于 A/B 测试。
geo: 地理上下文对客户端 IP 地址进行分类。它用于根据连接的 IP 地址映射变量的值。
charset_map: 此上下文用于将特定字符集添加到"Content-Type"响应标头字段。此外，使用上下文，可以使用一些 lim 将数据从一个字符集转换为另一个字符集
map: map 上下文用于创建变量，其值取决于其他变量的值，并在 http 上下文中定义。
perl/perl_set: 用于在 Perl 中实现位置和变量处理程序，并将 Perl 调用插入 SSI。此外，借助 perl_set 上下文，我们可以为特定变量安装 Perl 处理程序。
类型: 类型上下文映射具有正确文件扩展名的 MIME 类型。此上下文可能出现在 http 上下文、服务器上下文或位置上下文中。

Nginx VS Apache

Nginx 内容缓存