심층적인 Nginx 구성 기사

자주 사용하는 구성 항목

직장에서는 Nginx의 구성 파일을 통해 주로 Nginx를 처리합니다. 그런 다음 이러한 구성 항목의 각 기능을 이해해야 합니다. (관련 권장 사항: Linux 튜토리얼)

우선 nginx.conf 의 내용은 대개 다음과 같습니다.

...              
...            #核心摸块
events {        #事件模块
   ...
}
http {     # http 模块
    server {      # server块
        location [PATTERN] {  # location块
            ...
        }
        location [PATTERN] {
            ...
        }
    }
    server {
      ...
    }
}
mail {     # mail 模块
     server {    # server块
          ...
    }
}

각 모듈이 일반적으로 어떤 구성 항목을 가지고 있는지 살펴보겠습니다.

코어 모듈

user admin; #配置用户或者组
worker_processes 4; #允许生成的进程数，默认为1 
pid /nginx/pid/nginx.pid; #指定 nginx 进程运行文件存放地址 
error_log log/error.log debug; #错误日志路径，级别

이벤트 모듈

events { 
    accept_mutex on; #设置网路连接序列化，防止惊群现象发生，默认为on 
    multi_accept on; #设置一个进程是否同时接受多个网络连接，默认为off 
    use epoll; #事件驱动模型select|poll|kqueue|epoll|resig
    worker_connections 1024; #最大连接数，默认为512
}

http 모듈

http {
    include       mime.types;   #文件扩展名与文件类型映射表
    default_type  application/octet-stream; #默认文件类型，默认为text/plain
    access_log off; #取消服务日志    
    sendfile on;   #允许 sendfile 方式传输文件，默认为off，可以在http块，server块，location块
    sendfile_max_chunk 100k;  #每个进程每次调用传输数量不能大于设定的值，默认为0，即不设上限
    keepalive_timeout 65;  #连接超时时间，默认为75s，可以在http，server，location块
    server 
    {
            keepalive_requests 120; #单连接请求上限次数
            listen 80; #监听端口
            server_name  127.0.0.1;   #监听地址      
            index index.html index.htm index.php;
            root your_path;  #根目录
            location ~ \.php$
            {
                  fastcgi_pass unix:/var/run/php/php7.1-fpm.sock;
                  #fastcgi_pass 127.0.0.1:9000;
                  fastcgi_index index.php;
                  include fastcgi_params;
            }
    }
}

구성 항목 분석

worker_processes

worker_processes는 다음과 같은 용도로 사용됩니다. Nginx가 제공하는 프로세스 수를 설정합니다. 이 값은 권장되는 CPU 코어 수입니다.

worker_cpu_affinity*

worker_cpu_affinity는 각 프로세스에 CPU 작업 코어를 할당하는 데 사용됩니다. 매개변수는 여러 이진 값으로 표시되며 각 그룹의 각 비트는 프로세스의 CPU 사용량을 나타냅니다. . , 1은 사용을 의미하고, 0은 사용하지 않음을 의미합니다. 따라서 우리는 프로세스를 다른 코어에 바인딩하기 위해 작업자_cpu_affinity0001001001001000을 사용합니다. 기본적으로 작업자 프로세스는 CPU에 바인딩되지 않습니다.

worker_rlimit_nofile

각 프로세스에 대해 최대 열린 파일 수를 설정합니다. 설정하지 않은 경우 상한은 시스템 ulimit-n 번호(일반적으로 65535)입니다.

worker_connections

이론적으로 프로세스에서 허용하는 최대 연결 수를 설정합니다. 이론적으로는 클수록 좋지만 작업자_rlimit_nofile의 값을 초과할 수는 없습니다.

epoll 사용

이벤트 기반 모델에서 epoll을 사용하도록 설정하세요. epoll은 Nginx에서 지원하는 고성능 이벤트 중심 라이브러리 중 하나입니다. 매우 뛰어난 이벤트 드리븐 모델로 인정받고 있습니다.

accept_mutex off

네트워크 연결 직렬화를 끕니다. on으로 설정하면 여러 Nginx 프로세스가 직렬화를 위한 연결을 허용하여 여러 프로세스가 연결을 위해 경쟁하는 것을 방지합니다. 서버 연결 수가 많지 않은 경우 이 매개변수를 켜면 부하가 어느 정도 줄어듭니다. 그러나 서버의 처리량이 매우 높을 경우 효율성을 위해 이 매개변수를 끄십시오. 이 매개변수를 끄면 요청이 여러 작업자에게 더욱 균등하게 분산될 수도 있습니다. 그래서 우리는 accept_mutex를 off;로 설정했습니다.

multi_accept on

여러 네트워크 연결을 동시에 허용하는 프로세스를 설정하세요.

Sendfile on

Sendfile은 Linux 2.0 이후에 출시된 시스템 호출로, 네트워크 전송 프로세스의 단계를 단순화하고 서버 성능을 향상시킬 수 있습니다.

sendfile을 사용하지 않는 기존 네트워크 전송 프로세스:

硬盘 >> kernel buffer >> user buffer >> kernel socket buffer >> 协议栈

네트워크 전송 프로세스에 sendfile() 사용:

硬盘 >> kernel buffer (快速拷贝到 kernelsocket buffer) >>协议栈

tcp_nopush on;

데이터 패킷을 축적하여 함께 전송하도록 설정하면 전송 효율성이 어느 정도 향상될 수 있습니다. tcp_nopush는 sendfile과 함께 사용해야 합니다.

tcp_nodelay on;

작은 패킷은 기다리지 않고 바로 전송됩니다. 기본값은 켜져 있습니다. tcp_nopush의 반대 기능인 것 같지만 양쪽이 모두 켜져 있으면 nginx도 이 두 기능의 사용을 균형 있게 유지할 수 있습니다.

keepalive_timeout

HTTP 연결 기간입니다. 너무 길게 설정하면 쓸모없는 스레드가 너무 많아집니다. 이는 서버 접속 횟수, 처리 속도, 네트워크 상태 등을 고려하여 고려됩니다.

send_timeout

Nginx 서버가 클라이언트에 응답하는 시간 제한을 설정합니다. 이 시간 제한은 두 클라이언트가 서버와 연결을 설정한 후 특정 활동 사이의 시간 동안만 적용됩니다. 이번에는 Nginx 서버가 연결을 닫습니다.

gzip on

gzip을 활성화하면 온라인에서 응답 데이터를 실시간으로 압축하고 데이터 전송량을 줄일 수 있습니다.

gzip_disable "msie6"

Nginx 서버는 이러한 유형의 클라이언트 요청에 응답할 때 Gzip 기능을 사용하여 애플리케이션 데이터를 캐시하지 않습니다. gzip_disable "msie6"은 IE6 브라우저의 데이터에 대해 GZIP 압축을 수행하지 않습니다.

일반적으로 사용되는 구성 항목은 대략 다음과 같습니다. 다양한 비즈니스 시나리오의 경우 일부에는 추가 구성 항목이 필요하며 여기서는 확장하지 않습니다.

Others

http 구성에는 요청의 URI를 기반으로 해당 처리 규칙을 일치시키는 데 사용되는 위치 항목이 있습니다.

위치 검색 규칙

location  = / {
  # 精确匹配 / ，主机名后面不能带任何字符串
  [ config A ]
}
location  / {
  # 因为所有的地址都以 / 开头，所以这条规则将匹配到所有请求
  # 但是正则和最长字符串会优先匹配
  [ config B ]
}
location /documents/ {
  # 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索
  # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条
  [ config C ]
}
location ~ /documents/Abc {
  # 匹配任何以 /documents/Abc 开头的地址，匹配符合以后，还要继续往下搜索
  # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条
  [ config CC ]
}
location ^~ /images/ {
  # 匹配任何以 /images/ 开头的地址，匹配符合以后，停止往下搜索正则，采用这一条
  [ config D ]
}
location ~* \.(gif|jpg|jpeg)$ {
  # 匹配所有以 gif,jpg或jpeg 结尾的请求
  # 然而，所有请求 /images/ 下的图片会被 config D 处理，因为 ^~ 到达不了这一条正则
  [ config E ]
}
location /images/ {
  # 字符匹配到 /images/，继续往下，会发现 ^~ 存在
  [ config F ]
}
location /images/abc {
  # 最长字符匹配到 /images/abc，继续往下，会发现 ^~ 存在
  # F与G的放置顺序是没有关系的
  [ config G ]
}
location ~ /images/abc/ {
  # 只有去掉 config D 才有效：先最长匹配 config G 开头的地址，继续往下搜索，匹配到这一条正则，采用
    [ config H ]
}

일반 검색 우선순위는 높음에서 낮음으로 다음과 같습니다.

" = "는 정확한 일치로 시작합니다. 예를 들어 A는 루트 디렉터리 끝에 있는 요청만 일치합니다. 뒤에는 문자열이 올 수 없습니다.

"^~"의 시작은 URI가 일반 문자열이 아닌 일반 문자열로 시작한다는 의미입니다.

시작 부분의 "~"는 대소문자를 구분하는 일반 일치를 나타냅니다.

시작 부분의 "~*"는 대소문자를 구분하지 않는 일반 일치를 나타냅니다.

" / " 범용 일치, 다른 일치 항목이 없으면 모든 요청이 일치됩니다.

로드 밸런싱 구성

Nginx 的负载均衡需要用到 upstream 模块，可通过以下配置来实现：

upstream test-upstream {
    ip_hash; # 使用 ip_hash 算法分配
    server 192.168.1.1; # 要分配的 ip
    server 192.168.1.2;
}
server {
    location / {       
        proxy_pass http://test-upstream;
    }
}

上面的例子定义了一个 test-upstream 的负载均衡配置，通过 proxy_pass 反向代理指令将请求转发给该模块进行分配处理。

위 내용은 심층적인 Nginx 구성 기사의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!