초보 자의 관점 에서 Nginx 를 엿보다
#user nobody;
worker_processes 1;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/nginx.pid;
events {
worker_connections 1024;
}
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"';
#access_log logs/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location / {
root html;
index index.html index.htm;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
# proxy_pass http://127.0.0.1;
#}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
# root html;
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
# include fastcgi_params;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}
# another virtual host using mix of IP-, name-, and port-based configuration
#
#server {
# listen 8000;
# listen somename:8080;
# server_name somename alias another.alias;
# location / {
# root html;
# index index.html index.htm;
# }
#}
# HTTPS server
#
#server {
# listen 443 ssl;
# server_name localhost;
# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;
# ssl_session_cache shared:SSL:1m;
# ssl_session_timeout 5m;
# ssl_ciphers HIGH:!aNULL:!MD5;
# ssl_prefer_server_ciphers on;
# location / {
# root html;
# index index.html index.htm;
# }
#}
}
Nginx 프로필 상세 설명
전체 Nginx 프로필 은 6 개 부분 으로 구성 되 어 있 습 니 다.
main
events {
...
}
http {
...
upstream project_name {
...
}
server {
...
location {
...
}
include /path/of/nginx/conf.d/*.conf;
}
}
메 인 모듈
전역 설정 은 Nginx 의 전역 설정 을 작성 합 니 다.이 지역 에서 작성 한 콘 텐 츠 회원 은 Nginx 의 전역 에 적 용 됩 니 다.
일반적인 전역 설정:
예 는 다음 과 같다.
# Nginx
user nobody root;
# Nginx ( CPU , auto)
worker_precesses 8;
#
error_log /var/log/nginx/error.log info;
#
pid /var/run/nginx.pid;
# Nginx ( ulimit -n )
worker_rlimit_nofile 65535;
주:일반적으로 이 전역 설정 은 기본 설정 을 유지 할 수 있 습 니 다(즉,아무것도 쓰 지 않 아 도 됩 니 다).
이벤트 모듈
Nginx 의 작업 모드 와 단일 프로 세 스 의 연결 수 상한 선 을 지정 합 니 다.예 는 다음 과 같다.
events {
# , :kqueue、rtsing、epoll、/dev/poll、select、poll
# epoll Linux 2.6 I/O
# FreeBSD macOS , kqueue
use epoll;
# ( 1024 , = x )
worker_connections 65535;
}
주:상기 프로 세 스 의 최대 연결 수 는 리 눅 스 시스템 프로 세 스 의 최대 열 린 파일 수의 제한 을 받 습 니 다.운영 체제 명령[\#ulimit-n 65536]을 실행 한 후에 만 workerconnections 설정 이 유효 합 니 다.
http 모듈
http 부분 은 설정 파일 의 가장 핵심 부분 으로 대부분의 HTTP 서버 관련 속성 설정 을 포함 합 니 다.
http {
#
include mime.types;
#
default_type application/octet-stream;
#
charset utf-8;
# hash
server_name_hash_bucket_size 128;
#
client_body_buffer_size 128k;
#
client_max_body_size 10m;
# , Nginx sendfile
# I/O , off, I/O ,
sendfile on;
# ( )
autoindex on;
#
tcp_nopush on;
tcp_nodelay on;
# ,
keepalive_timeout 120;
# gzip
# gizp
gzip on
#
gizp_min_length 1k;
#
gzip_buffers 4 16k;
#
gzip_http_version 1.1;
#
gzip_comp_level 2;
# , text/html,
gzip_types text/plain application/x-javacript text/css application/xml;
# Vary:Accept-Encodeing, gzip
gizp_vary on;
# IP
limit_zone crawler $binary_remote_addr 10m;
upstream project_name {
...
}
server {
...
}
}
서버 모듈
server 모듈 은 http 의 하위 모듈 로 가상 호스트 를 정의 할 수 있 습 니 다.server{}은 가상 호스트 의 설정 범 위 를 표시 합 니 다.예 는 다음 과 같다.
server {
#
listen 8081;
# IP ,
server_name localhost www.nginx.com;
# server Web
root /nginx/www/path/;
#
index index.html index.htm;
#
charset utf-8;
# ,
access_log usr/local/var/log/host.access.log main;
access_log usr/local/var/log/host.error.log error;
location {
...
}
}
위치 모듈
location 모듈 은 Nginx 에서 사용자 정의 수준 이 가장 높 은 모듈 입 니 다.location 은 이름 처럼 URL 을 분석 하 는 데 사 용 됩 니 다.정규 매 칭 을 통 해 사용 자 는 location 명령 을 통 해 웹 페이지 에 대한 각종 처 리 를 실현 할 수 있 습 니 다.예 는 다음 과 같다.
location / {
root /nginx/www/path;
index index.html index.htm;
}
구체 적 으로 볼 수 있 는 것:Nginx 간단 한 설정 과 사용
upstream 모듈
upstream 모듈 은 부하 균형 모듈 이 라 고도 부른다.예 는 다음 과 같다.
upstream example.com {
fair;
server 172.17.1.1:80;
server 172.17.1.2:8080 down;
server 172.17.1.3:9999 max_fails=3 fail_timeout=20s max_conns=1000;
server 172.17.1.4:2333 backup;
}
example.com 은 upstream 명령 을 통 해 부하 균형 이름 을 정의 했다 고 밝 혔 다.(도 메 인 이름 이 아 닌 이름 을 임의로 지정 할 수 있 습 니 다)
fair 는 부하 균형 스케줄 링 알고리즘 이다.
다운 은 이 server 가 부하 균형 에 참여 하지 않 음 을 나타 낸다.
backup 은 미리 남 겨 둔 백업 기 계 를 표시 합 니 다.다른 모든 비 backup 기기 가 고장 나 거나 매우 바 쁠 때 만 backup 기 계 를 요청 할 수 있 기 때문에 이 기계 의 부하 압력 은 매우 적 습 니 다.
max_fails 는 요청 실패 횟수(기본 값 은 1 회)를 허용 하고 최대 횟수 를 초과 하면 proxy 를 되 돌려 줍 니 다.next_upstream 모듈 정의 오류 입 니 다.
fail_timeout 는 maxfails 회 실패 후 서 비 스 를 중단 하 는 시간 입 니 다.
max_conns 는 백 엔 드 서버 처리 의 최대 연결 수량 을 제한 하고 이 수량 을 초과 하면 새로운 연결 을 할당 하지 않 을 것 이 라 고 밝 혔 다.
홈 페이지 설정 설명 문서:https://nginx.org/en/docs/http/ngx_http_core_module.html
Nginx 부하 균형
현재 Nginx 부하 균형 모듈 에는 총 4 개의 스케줄 링 알고리즘 이 있다.
가중치 폴 링
weight 폴 링 은 요청 한 시간 순서에 따라 각각 다른 백 엔 드 서버 에 배 치 됩 니 다.백 엔 드 의 한 서버 가 지연 되면 Nginx 폴 링 목록 은 자동 으로 이 서버 를 제거 하여 사용자 의 접근 에 영향 을 받 지 않도록 합 니 다.
weight 는 폴 링 가중치 를 지정 하 는 데 사 용 됩 니 다.weight 값 이 클 수록 방문 할 확률 이 높 습 니 다.주로 백 엔 드 서버 의 성능 이 고 르 지 않 은 경우 에 사 용 됩 니 다.
weight 폴 링 은 Nginx 의 기본 스케줄 링 알고리즘 입 니 다.
예제 설정 은 다음 과 같 습 니 다.
upstream upstream.example.com {
server 172.17.1.1:80 weight=1;
server 172.17.1.2:8080 weight=1;
server 172.17.1.3:9999 weight=10;
server 172.17.1.4:2333 backup;
}
server {
listen 80;
server_name example.com;
access_log /usr/local/var/log/nginx/access.log main;
access_log /usr/local/var/log/nginx/error.log error;
location / {
proxy_pass http://upstream.exaple.com;
proxy_set_header X-Real-IP $remote_addr;
}
}
이 부하 균형 설정 의 역할:(Nginx:nginx-s reload 를 다시 시작 합 니 다)페이지 를 새로 고 칠 때마다 페이지 의 요청 은 각각 세 번 째 서버 로 전 송 됩 니 다.네 번 째 는 백업 서버 입 니 다.그 중에서 세 번 째 처리 요청 이 가장 많 습 니 다.가중치 가 가장 크기 때 문 입 니 다.
IP 해시
ip_hash 는 hash 알고리즘 에 따라 모든 요청 의 접근 IP 를 처리 합 니 다.같은 IP 에서 온 방문객 을 백 엔 드 서버 에 고정 적 으로 접근 하도록 합 니 다.
이런 방식 은 동적 웹 페이지 에 존재 하 는 세 션(session)공유 문 제 를 간단 하고 효과적으로 해결 할 수 있다.
예제 설정 은 다음 과 같 습 니 다.
upstream upstream.example.com {
ip_hash;
server 172.17.1.1:80;
server 172.17.1.2:8080;
server 172.17.1.3:9999;
server 172.17.1.4:2333;
}
공정 한 관리
페 어 는 앞의 두 가지 보다 더 스마트 하 다.이 알고리즘 은 페이지 의 크기 와 로드 시간의 장단 에 따라 스마트 하 게 부하 균형 을 이 룰 수 있다.
쉽게 말 하면 백 엔 드 서버 의 응답 시간 에 따라 요청 을 할당 하고 응답 시간 이 짧 은 우선 배분 입 니 다.
Nginx 는 기본적으로 fair 를 지원 하지 않 습 니 다.사용 자 는 Nginx 를 설치 한 upstream 을 수 동 으로 컴 파일 해 야 합 니 다.fair 모듈.다운로드 주소:https://github.com/gnosek/nginx-upstream-fair
[root@VM_0_6_centos local]# wget https://github.com/gnosek/nginx-upstream-fair/archive/master.zip
[root@VM_0_6_centos local]# unzip master.zip
Nginx 의 설치 디 렉 터 리 에 들 어가 fair 모듈 소스 코드 를 다운로드 하고 압축 을 푼 디 렉 터 리 이름 은 nginx-upstream-fair-master 입 니 다.
Nginx 를 다시 컴 파일 하고 fair 모듈 을 컴 파일 인자 에 추가 합 니 다.Nginx 원본 디 렉 터 리 로 들 어가 기
URL 해시
url_hash 알고리즘 에 따라 모든 요청 에 접근 하 는 url 을 처리 하여 같은 url 에서 온 요청 을 같은 백 엔 드 서버 로 고정 시 키 면 백 엔 드 캐 시 서버 의 효율 을 높 일 수 있 습 니 다.
예제 설정 은 다음 과 같 습 니 다.
upstream upstream.example.com {
hash $request_uri;
server 172.17.1.1:80;
server 172.17.1.2:8080;
server 172.17.1.3:9999;
server 172.17.1.4:2333;
}
==미 완성 계속==
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
다양한 언어의 JSONJSON은 Javascript 표기법을 사용하여 데이터 구조를 레이아웃하는 데이터 형식입니다. 그러나 Javascript가 코드에서 이러한 구조를 나타낼 수 있는 유일한 언어는 아닙니다. 저는 일반적으로 '객체'{}...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.