Nginx 구성에 대한 자세한 설명(코드 포함)

이 글은 Nginx 구성에 대한 자세한 설명을 제공합니다(코드 포함). 필요한 친구가 참고할 수 있기를 바랍니다.

자주 사용하는 구성 항목

직장에서는 주로 구성 파일을 통해 Nginx를 처리합니다. 그런 다음 이러한 구성 항목의 각 기능을 이해해야 합니다.

우선, nginx.conf의 내용은 일반적으로 다음과 같습니다.

...              
...            #核心摸块

events {        #事件模块
 
   ...
}

http {     # http 模块

    server {      # server块
     
        location [PATTERN] {  # location块
        
            ...
        }
        location [PATTERN] {
        
            ...
        }
    }
    server {
      ...
    }
    
}

mail {     # mail 模块
     
     server {    # server块
          ...
    }

}

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

Core 모듈

user admin; #配置用户或者组。

worker_processes 4; #允许生成的进程数，默认为1 

pid /nginx/pid/nginx.pid; #指定 nginx 进程运行文件存放地址 

error_log log/error.log debug; #错误日志路径，级别。

Event 모듈

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의 작업 코어를 각 프로세스에 할당하는 데 사용됩니다. 각 그룹은 프로세스의 각 비트를 나타냅니다. , 0은 사용되지 않음을 의미합니다. 따라서 우리는 프로세스를 다른 코어에 바인딩하기 위해 작업자_cpu_affinity 0001 0010 0100 1000을 사용합니다. 기본적으로 작업자 프로세스는 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이 없는 기존 네트워크 전송 프로세스:

  하드 디스크 >> 커널 버퍼 >> 커널 소켓 버퍼 >> 네트워크 전송 프로세스에는 sendfile()을 사용하세요.

  하드 디스크>> 커널 버퍼(커널 소켓 버퍼에 빠른 복사) >>프로토콜 스택

  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 중국어 웹사이트의 기타 관련 기사를 참조하세요!