nginx 기본 구성에 대한 자세한 설명-PHP 튜토리얼-php.cn

1. 아파치 서버와 nginx의 장점과 단점:
우리는 이전에 Apache를 HTTPServer로 광범위하게 사용해 왔습니다.
Apache는 성능이 뛰어나며 모듈을 통해 다양하고 풍부한 기능을 제공할 수 있습니다.
1) 우선, 클라이언트에 대한 Apache의 응답은 httpd 데몬 프로세스를 실행한 후 동시에 여러 하위 프로세스/스레드를 생성하고 각 하위 프로세스/스레드는 각각 클라이언트의 요청에 응답합니다. 2) 또한 Apache는 정적 및 동적 서비스를 제공할 수 있습니다. 예를 들어 PHP의 구문 분석은 성능이 좋지 않은 CGI를 통해 구현되지 않고 PHP를 지원하는 모듈(보통 mod_php5 또는 apxs2)을 통해 구현됩니다.
3) 단점:
따라서 일반적으로 Apache라고 불리는 이러한 유형의 서버는 각 사용자 요청에 응답하기 위해 하위 프로세스/스레드를 생성해야 하기 때문에 다중 프로세스 HTTP 서버인 프로세스 기반 서버입니다. 단점은 동시 요청이 많은 경우(대형 포털에서 매우 일반적임) 많은 스레드가 필요하게 되어 많은 시스템 리소스, CPU 및 메모리를 차지하게 된다는 점입니다. 따라서 동시 처리는 Apache의 장점이 아닙니다.
4)해결책:
현재 비동기 서버라고 하는 동시성 측면에서 더 나은 성능을 발휘하는 또 다른 WebServer가 있습니다. 가장 유명한 것은 Nginx와 Lighttpd입니다. 소위 비동기 서버는 이벤트 중심 프로그래밍 모델에서 이벤트 중심입니다. 단, 사용자의 동시 요청에는 일반적으로 단일 또는 여러 스레드만 필요합니다. 따라서 시스템 리소스를 거의 차지하지 않습니다. 이러한 유형을 경량 웹 서버라고도 합니다.
예를 들어, 10,000개의 동시 연결 요청의 경우 nginx는 몇 MB의 메모리만 사용할 수 있지만 Apache는 수백 MB의 메모리 리소스를 사용해야 할 수 있습니다.
2. 실제 일회용 사용:
1) Apache를 HTTP 서버로만 사용하는 방법에 대해서는 더 이상 소개할 필요가 없습니다. 이는 매우 일반적인 애플리케이션입니다.
위에서 PHP와 같은 서버사이드 스크립트에 대한 Apache의 지원은 자체 모듈을 통해 구현되며 성능이 우수하다고 소개했습니다.
2) nginx나 lighttpd만 HTTPServer로 사용할 수도 있습니다.
Apache와 마찬가지로 nginx 및 lighttpd는 다양한 모듈을 통해 서버 기능을 강화할 수 있으며 conf 구성 파일을 통해 다양한 옵션을 구성합니다.
PHP 등의 경우 nginx나 lighttpd 모두 PHP를 지원하는 모듈이 내장되어 있지 않지만 FastCGI를 통해 지원합니다.
Lighttpd는 모듈을 통해 CGI, FastCGI 및 SCGI 서비스를 제공할 수 있습니다. Lighttpd는 FastCGI 백엔드를 자동으로 생성할 수 있을 뿐만 아니라 외부에서 생성된 프로세스를 사용할 수도 있습니다.
nginx는 PHP 자체를 처리하는 기능을 제공하지 않으며 타사 모듈을 통해 PHP의 FastCGI 통합을 제공해야 합니다.

------------------ http://bbs.it-home.org/ Visits=> 이외의 모든 항목을 다시 작성합니다. ; http://bbs.it-home.org/
서버_이름 web90.***.com;

if ($host = "web90.***.com") {
다시 작성 ^(.*)$ http://bbs.it-home.org/$1 영구;
}

----------------------------------nginx 중지/부드러운 재시작#p#페이징 제목#e#

nginx 신호 제어

TERM,INT 빠르게 종료
QUIT 정상적으로 종료
HUP 원활한 재시작, 구성 파일 다시 로드
USR1은 로그 파일을 다시 엽니다. 이는 로그를 잘라낼 때 더 유용합니다.
USR2 원활한 실행프로그램 업그레이드
WINCH가 작업과정을 정상적으로 종료합니다

1) 침착하게 멈추세요:

kill -QUIT Nginx 기본 프로세스 번호

kill -QUIT '/usr/local/webserver/nginx/logs/nginx.pid'

2) 급정지:

kill -TERM Nginx 기본 프로세스 번호

kill -TERM '/usr/local/webserver/nginx/logs/nginx.pid'

kill -INTN ginx 기본 프로세스 번호

kill -INT '/usr/local/webserver/nginx/logs/nginx.pid'

3) 모든 nginx 프로세스를 강제 종료합니다

pkill -9 nginx

1) 원활한 재시작

kill -HUP nginx 기본 프로세스 번호

kill -HUP '/usr/local/webserver/nginx/logs/nginx.pid'

-------------nginx.conf
#p#페이지 제목#e#

작업자_프로세스 8;

작업 생성 프로세스 수 지정

일반적으로 CPU의 총 코어 수와 같거나 총 코어 수의 두 배입니다. 예를 들어 쿼드 코어 CPU가 2개인 경우 총 코어 수는 8

events

use epoll; //사용된 네트워크 I/O 모델, Linux 시스템에서는 epoll을 권장하고 freebsd에서는 kqueue를 권장합니다
Worker_connections 65535; 링크
}
위치 ~ .*.(gif|jpg|jpeg|png|bmp|swf)$ { access_log off; 로그 만료 30d; // 패스 만료 이 명령은 로컬 캐싱을 구현하기 위한 헤더 헤더를 출력합니다. 30일} 위치 ~ .*.(js|css)$ { access_log off; 로그 만료 1h; =========== ====모든
{
access_log off; 로그 끄기
expires 30d;//expires 명령을 통해 헤더 헤더를 출력하여 로컬 캐싱 구현, 30일
}
위치 ~ .*.(js|css)$
{
access_log off; 로그 닫기
1시간 만료;
}

코드 복사

===================== 매일 정기적으로 nginx 로그 스크립트 자르기

vim /usr/local/webserver/nginx/sbin/cut_nginx_log.sh
#!/bin/bash
# 이 00:00에 스크립트 실행
# Nginx 로그 경로
logs_path="/usr/local/webserver/nginx/logs/";
mkdir -p ${logs_path}$(date -d "어제" "%Y")/$(date -d "어제" "%m")/#p#페이지 제목#e#
mv ${logs_path}access.log ${logs_path}$(date -d "어제" "%Y")/$(date -d "어제" "%m")/access_$(date - d "어제" "%Y%m%d").log
kill -USR1 'cat /usr/local/webserver/nginx/nginx.pid'
chown -R www:www cut_nginx_log.sh
chmod x cut_nginx_log.sh
crontab -e
00 * * * /bin/bash /usr/local/webserver/nginx/sbin/cut_nginx_log.sh
#/sbin/service crond restart

코드 복사

--------------- nginx 구성 gzip 압축

일반적인 상황에서 압축된 html, css, js, php, jhtml 및 기타 파일의 크기는 원래 크기의 25%로 줄어들 수 있습니다. 즉, 원래 100k html은 압축 후 25k만 남게 됩니다. 이렇게 하면 의심할 여지 없이 많은 대역폭이 절약되고 서버의 로드도 줄어듭니다.
nginx에서 gzip을 구성하는 것은 비교적 간단합니다

일반적인 상황에서는 nginx.conf의 http 섹션에 다음 구성 줄을 추가하기만 하면 됩니다

견적
압축을 푼다;
gzip_min_length 1000;
gzip_buffers 4 8k;
gzip_types 텍스트/일반 애플리케이션/x-javascript 텍스트/css 텍스트/html 애플리케이션/xml;

nginx 다시 시작
웹페이지 gzip 감지 도구를 사용하여 웹페이지에서 gzip이 활성화되어 있는지 감지할 수 있습니다
http://gzip.zzbaike.com/

---------------nginx 오류 페이지를 리디렉션하는 방법

error_page 404 /404.html;

이 404.html은 nginx 홈 디렉터리 아래의 html 디렉터리에 있음이 보장됩니다. 404 오류가 발생한 후 다른 주소로 직접 이동해야 하는 경우 다음과 같이 직접 설정할 수 있습니다.

error_page 404 http://bbs.it-home.org/ ;

공통 403, 500 및 기타 오류도 동일한 방식으로 정의할 수 있습니다. #p#페이지 제목#e#

404.html 파일의 페이지 크기가 512k를 초과해야 한다는 사실에 특별한 주의를 기울여야 합니다. 그렇지 않으면 IE 브라우저의 기본 오류 페이지로 대체됩니다.

---------------------가상 호스트 구성

서버 {
수신 80;
server_name localhost;
access_log /var/log/nginx/localhost.access.log;
위치 / {
사용 사용 사용 사용 사용 통해 통해 통해 통해 통해 통해 ’s ’부터 ’까지 - to -n -, to 🎜 >
위치 /doc {
루트 /usr/share;
자동 색인 켜짐;
127.0.0.1 허용;
모두 거부; 🎜>
}
위치 /images {
root /usr/share;
autoindex on;
}
위치 ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_para m SCRIPT_FILENAME /var/www/ nginx-default$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
}
}
서버 {
수신 80;
server_name sdsssdf.localhost.com;
access_log /var/log/nginx/localhost.access.log;
위치 / {
루트 /var/www/nginx-default/console;
index index.php index.html index.htm } 위치 /doc; { 루트 /usr/share; 127.0.0.1 허용; } 위치 /images { 루트 /usr/share } 위치 ~ .php$ { fastcgi_pass 127.0.0.1:9000;
#p#페이지 제목#e#
}
위치 /doc {
루트 / usr/share;
자동 색인 켜짐;
127.0.0.1 허용;
모두 거부;
}
위치 /이미지 {
루트 /usr/share;
autoindex on;
}
위치 ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/nginx-default$fastcgi_script _name;
include /etc/ nginx /fastcgi_params;
}
}
코드 복사
-----------------------모니터링

위치 ~ ^/NginxStatus/ {

stub_status on #Nginx 상태 모니터링 구성
}

이런 방법으로 http://localhost/NginxStatus/를 통해 Nginx의 실행 정보를 모니터링할 수 있습니다. (마지막 /는 삭제할 수 없습니다.)

활성 연결: 1
서버가 처리된 요청을 수락합니다
1 5
읽기 : 0 쓰기 : 1 대기 : 0

NginxStatus에 의해 표시되는 내용은 다음과 같습니다: #p#Paging title#e#

활성 연결 – Nginx에서 현재 처리 중인 활성 연결 수입니다.
서버가 처리된 요청 수락 -- 총 14553819개의 연결이 처리되었고, 14553819개의 핸드셰이크가 성공적으로 생성되었으며(중간 실패가 없었다는 증거), 총 19239266개의 요청이 처리되었습니다(핸드셰이크당 평균 1.3개의 데이터 요청이 처리되었습니다). ).
읽기 - nginx가 클라이언트에서 읽는 헤더 정보 수입니다.
쓰기 - nginx가 클라이언트에 반환하는 헤더 정보의 수입니다.
대기 - 연결 유지가 켜져 있으면 이 값은 활성 -(읽기 쓰기)과 같습니다. 이는 Nginx가 다음 요청 명령을 기다리는 상주 연결 처리를 완료했음을 의미합니다.

----------------------------------정적 파일 처리

정규식을 통해 Nginx가 다양한 정적 파일을 식별하도록 할 수 있습니다

위치 ~ .(htm|html|gif|jpg|jpeg|png|bmp|ico|css|js|txt)$ {

루트 /var/www/nginx-default/html;
access_log off;
24시간 만료;
       }

이미지, 정적 HTML 파일, js 스크립트 파일 및 CSS 스타일 파일 등의 경우 Nginx가 이를 직접 처리하여 브라우저에 반환하므로 웹 탐색 속도가 크게 향상될 수 있기를 바랍니다. 따라서 이러한 유형의 파일에 대해서는 루트 지시문을 사용하여 파일의 저장 경로를 지정해야 합니다. 동시에 이 유형의 파일은 자주 수정되지 않으므로 만료 지시문을 사용하여 캐시를 제어합니다. 불필요한 요청을 줄이기 위한 브라우저입니다. 만료 지시문은 HTTP 응답(페이지 캐싱 제어)에서 "Expires" 및 "Cache-Control" 헤더를 제어할 수 있습니다. 예를 들어 다음 형식을 사용하여 만료를 작성할 수 있습니다.

1970년 1월 1일 GMT 00:00:01에 만료;
만료 시간은 60초입니다.
30분 후에 만료됩니다.
24시간 만료;
1일 만료;
최대 만료;
만료됩니다.

이런 식으로 http://192.168.200.100/1.html을 입력하면 자동으로 var/www/nginx-default/html/1.html
으로 이동됩니다.
예를 들어 이미지 경로 아래의 모든 요청은 다음과 같이 작성할 수 있습니다.

#p#페이지 제목#e#

위치 ~ ^/images/ {
루트 /opt/webapp/images;
}

-----------동적 페이지 요청 처리 [클러스터]

Nginx 자체는 JSP, ASP, PHP, PERL 등과 같은 널리 사용되는 동적 페이지를 지원하지 않지만 Tomcat, Apache, IIS 등과 같은 역방향 프록시를 통해 백엔드 서버에 요청을 보내 요청을 완료할 수 있습니다. 동적 페이지 처리. 이전 구성 예에서는 먼저 Nginx에서 직접 처리할 일부 정적 파일 요청을 정의한 다음 다른 모든 요청은 Proxy_pass 지시문을 통해 백엔드 서버(위 예에서는 Tomcat)로 전송되었습니다. 가장 간단한 Proxy_pass 사용법은 다음과 같습니다.
위치 / {proxy_pass http://localhost:8080;
Proxy_pass http://localhost:8080;
Proxy_set_header X-Real-IP $remote_addr;
}

여기서는 클러스터를 사용하지 않고 포트 8080에서 실행되는 Tomcat 서비스에 직접 요청을 보내 JSP 및 Servlet과 같은 요청 처리를 완료합니다.

페이지 방문 수가 매우 많으면 동적 페이지 실행을 공동으로 수행하기 위해 여러 애플리케이션 서버가 필요한 경우가 많습니다. 이때 클러스터 아키텍처를 사용해야 합니다. Nginx는 upstream 지시문을 사용하여 서버 클러스터를 정의합니다. 위의 전체 예에서는 tomcats라는 클러스터를 정의했습니다. 이 클러스터에는 3개의 서버와 총 6개의 Tomcat 서비스가 포함되어 있습니다. Proxy_pass 지시어는 다음과 같이 작성됩니다:

# 클러스터 내 모든 백엔드 서버의 구성 정보
업스트림 Tomcat {
서버 192.168.0.11:8080 가중치=10;
서버 192.168.0.11:8081 가중치=10;
서버 192.168.0.12:8080 가중치=10;
서버 192.168.0.12:8081 가중치=10;
서버 192.168.0.13:8080 가중치=10;
서버 192.168.0.13:8081 가중치=10;#p#페이지 제목#e#
}
위치 / {
          proxy_pass http://tomcats;# 역방향 프록시
proxy.conf 포함;
       }

----------스트레스 테스트
1. wget http://bbs.it-home.org//soft/linux/webbench/webbench-1.5.tar.gz
2. tar zxvf webbench-1.5.tar.gz
3. cd webbench-1.5
4. make && make install
6. #webbench -c 100 -t 10 http:/ /192.168.200.100/info.php
8. 매개변수 설명: -c는 동시성 수를 나타내고, -t는 기간(초)을 나타냅니다.
10. root @ubuntu-desktop:/etc/nginx/sites-available# webbench -c 100 -t 10 http://192.168.200.100/info.php
11. Webbench - 간단한 웹 벤치마크 1.5
12. 저작권 (c) Radim Kolar 1997-2004, GPL 오픈 소스 소프트웨어.
14. 벤치마킹: GET http://192.168.200.100/info.php
15. 클라이언트 , 10초 실행
17. 속도=19032페이지/분, 18074373바이트/초
18. 요청: 3172 지속, 0 실패
코드 복사
--------------PPC는 nginx 세부 구성 지침을 제공합니다
3. #Run user
4. user none;
5. #프로세스 시작
6. worker_processes 2;#p#Paging title #e#
7. #전역 오류 로그 및 PID 파일
8. error_log 로그/error.log 공지;
9. pid 로그/nginx.pid;
10. #작업 모드 및 최대 연결 수
11. 이벤트{epoll 사용;
12. worker_connections 1024;}#http 서버를 설정하고 역방향 프록시 기능을 사용하여 로드 밸런싱 지원 제공
15. http{#Mime 유형 설정
16. ' "$request" $status $bytes_sent ''"$http_referer" "$http_user_agent" ''" $gzip_ratio"' ;
17. Log_format 다운로드'$remote_addr - $remote_user [$time_local] ''"$request" $status $bytes_sent ''"$http_referer" "$http_user_agent" ''"$http_range" " $sent_http_content_range"' ;
18. |
  gzip on;
19. gzip_min_length 1100;
21. gzip_buffers 4 8k 🎜> gzip_types text/plain;
22. output_buffers 1 32k;
23. Postpone_output 1460;
25. #액세스 로그 설정
26. access_log log s/access.log main;
27. client_header_timeout 3분 ;
28. client_body_timeout 3분;
29. send_timeout 3분;
30. sendfile on;
31. tcp_nopush on;
32. tcp_nodelay 켜기;
33. ~ > 🎜 > 서버 192.168.8.1:3128 가중치 = 5;
34. 서버 192.168.8.2.2 :80 가중치=1;
35. 서버 192.168.8.3:80 가중치=6;
36. }
37. 🎜> #가상호스트 설정
38. 서버{listen 80;
40. using using using charset gb2312; through through to through through over''' through out's' to‐‐‐‐‐‐‐‐‐ 192.168.8.1 192.168.8.1 be the #이 항목의 액세스 로그를 설정합니다. 가상 호스트
41. > squid
42. #이러한 경우에는 파일이 많아 Squid를 통한 캐싱 효과가 더 좋기 때문에 이 방법은 권장하지 않습니다. 위치 ~ ^/(img|js|css)/ /data3/Html;
  24시간 만료;
43. } #{{proxy_pass http: // mysvr; proxy_redirect off; >>
44. '' s s 통해 ‐ ‐ ‐ ‐ ‐ 헤더 호스트 $host;
45. Proxy_set_header $ Proxy_add_x_Forwardeded_For;
46. Client_max_body_size 10M; > Client_body_buffer_size 90;#P#9 9#E#
47. Proxy_send_timeout 90;
48. s ’ s s ’ s ’ s s ’ ‐ to ’ ’ s ’ ‐ ‐ r t 🎜>
49. > >
50. Proxy_busy_buffers_size 64k;
51. Proxy_temp_file_write_size 64k;
52. }
53. #
56. /htpasswd 파일의 내용은 apache 가 제공하는 htpasswd 도구를 사용하여 생성 할 수 있습니다.