Nginx 빠른 시작 예시 분석

왜 nginx를 사용하나요?

현재 nginx의 주요 경쟁자는 apache입니다. 여기서는 모두가 nginx의 장점을 더 잘 이해할 수 있도록 두 가지를 간단하게 비교해 보겠습니다.

1. 웹 서버로서:

apache에 비해 nginx는 더 적은 리소스를 사용하고 더 많은 동시 연결을 지원하며 더 높은 효율성을 반영합니다. 이로 인해 nginx는 특히 가상 호스트 공급자에게 인기가 있습니다. 연결 동시성이 높은 경우 nginx는 아파치 서버의 좋은 대안입니다. nginx는 미국 가상 호스트 사업의 상사가 자주 선택하는 소프트웨어 플랫폼 중 하나입니다. 최대 50,000개의 동시 연결에 대한 응답을 지원할 수 있습니다. 우리는 epoll과 kqueue를 개발 모델로 선택했습니다.

로드 밸런싱 서버로서의 nginx: nginx는 외부 서비스를 제공하기 위해 내부적으로 레일 및 PHP 프로그램을 직접 지원할 수도 있고, http 프록시 서버로서 외부 서비스를 지원할 수도 있습니다. nginx는 C로 작성되었으며 시스템 리소스 오버헤드와 CPU 사용 효율성이 Perlbal보다 훨씬 좋습니다.

2. nginx 구성은 간단하지만 Apache는 복잡합니다.

nginx는 특히 시작하기 쉽고 중단 없이 거의 7*24를 실행할 수 있으며 다시 시작할 필요가 없습니다. 중단 없이 서비스를 이용할 수도 있습니다. 이 경우 소프트웨어 버전을 업그레이드할 수 있습니다.

nginx의 정적 처리 성능은 apache보다 3배 이상 높습니다. Apache의 PHP 지원은 상대적으로 간단합니다. nginx는 nginx보다 더 많은 구성 요소를 가지고 있습니다.

3. 핵심 차이점은 다음과 같습니다.

apache는 동기식 다중 프로세스 모델이며, 하나의 연결은 하나의 프로세스에 해당합니다. nginx는 비동기식이며, 여러 연결(10,000개 수준)이 하나의 프로세스에 해당할 수 있습니다.

4 두 사람의 전문 분야는 다음과 같습니다.

nginx의 장점은 낮은 CPU 메모리 사용량으로 정적 요청을 처리하는 것이며, Apache는 동적 요청을 처리하는 데 적합하므로 이제 프런트엔드는 일반적으로 nginx를 다음과 같이 사용합니다. 압력에 저항하는 역방향 프록시는 동적 요청을 처리하는 백엔드 역할을 합니다.

nginx 기본 사용법

시스템 플랫폼: centos 릴리스 6.6(최종) 64비트.

1. 컴파일 도구 및 라이브러리 파일 설치

2. 먼저 pcre

1을 설치하면 nginx가 다시 쓰기 기능을 지원합니다. pcre 설치 패키지 다운로드, 다운로드 주소:

2. 설치 패키지 압축 풀기:

3. 설치 패키지 디렉터리

4를 입력합니다.

5. pcre 버전 보기

3. nginx 설치

1. nginx 다운로드, 다운로드 주소:

2. 설치 패키지 압축 풀기

3. 설치 패키지 디렉터리

4를 입력하고

5.nginx 버전을 확인합니다.

이 시점에서 nginx 설치가 완료됩니다.

4. nginx 구성

nginx 실행을 위한 사용자 www를 만듭니다.

nginx.conf를 구성하고 /usr/local/webserver/nginx/conf/nginx.conf를 다음 콘텐츠로 바꿉니다

구성 파일 ngnix.conf 명령의 정확성을 확인하십시오:

5. nginx 시작

nginx 시작 명령은 다음과 같습니다.

6. 구성된 사이트에 액세스합니다. 브라우저의 사이트 IP:

nginx 공통 지침 설명

1. 주요 전역 구성

nginx 실행 시 특정 비즈니스 기능(예: http 서비스 또는 이메일 서비스 프록시)과 관련이 없는 일부 매개변수(예: 숫자) 작업 프로세스, 실행 ID 등

woker_processes 2

구성 파일의 최상위 메인 섹션에는 작업자 역할의 작업자 프로세스 수, 마스터 프로세스가 요청을 받아 작업자에게 할당하여 처리합니다. 이 값은 단순히 CPU grep ^processor /proc/cpuinfo | wc -l의 코어 수로 설정할 수 있으며, 이는 또한 auto 값이기도 합니다. ssl과 gzip이 켜져 있으면 동일하거나 짝수로 설정해야 합니다. 논리 CPU 수를 두 배로 늘려 i/o 작업을 줄일 수 있습니다. nginx 서버에 다른 서비스가 있는 경우 해당 서비스를 적절하게 줄이는 것을 고려할 수 있습니다.
worker_cpu_affinity

메인 부분에도 적혀있습니다. 동시성이 높은 상황에서 멀티 CPU 코어 전환으로 인한 레지스터의 현장 재구성 등으로 인한 성능 손실은 CPU 고착성을 설정함으로써 감소됩니다. 예: 작업자_cpu_affinity 0001 0010 0100 1000(쿼드 코어)
worker_connections 2048

이 이벤트 섹션에 기록되어 있습니다. 각 작업자 프로세스가 동시에 처리(시작)할 수 있는 최대 연결 수입니다(클라이언트 또는 백엔드 프록시 서버와의 연결 수 포함). nginx는 역방향 프록시 서버 역할을 합니다. 계산 공식은 최대 연결 수 = 작업자_프로세스 * 작업자_연결/4이므로 여기서 최대 클라이언트 연결 수는 1024입니다. 다음에 따라 8192까지 늘릴 수 있는지 여부는 중요하지 않습니다. 상황에 따라 다르지만 후속 작업자_rlimit_nofile을 초과할 수는 없습니다. nginx를 http 서버로 사용하는 경우 계산식은 2로 나누어집니다.
worker_rlimit_nofile 10240

메인 부분에 적혀있습니다. 기본값은 설정 없음이며 최대 운영 체제 제한인 65535로 제한될 수 있습니다.
이벤트란에 써있는 epoll

을 이용해 보세요. Linux 운영 체제에서 nginx는 기본적으로 epoll 이벤트 모델을 사용합니다. 덕분에 nginx는 Linux 운영 체제에서 매우 효율적입니다. 동시에 nginx는 openbsd 또는 freebsd 운영 체제의 epoll과 유사한 효율적인 이벤트 모델 kqueue를 사용합니다. 운영 체제가 이러한 효율적인 모델을 지원하지 않는 경우에만 select를 사용하십시오.
2. http 서버

http 서비스 제공과 관련된 일부 구성 매개변수입니다. 예: keepalive 사용 여부, 압축에 gzip 사용 여부 등.

sendfile on

은 효율적인 파일 전송 모드를 활성화합니다. sendfile 명령어는 nginx가 파일을 출력하기 위해 sendfile 함수를 호출할지 여부를 지정하여 사용자 공간에서 커널 공간으로의 컨텍스트 전환을 줄입니다. 일반적인 응용 프로그램의 경우 켜기로 설정합니다. 다운로드와 같은 디스크 IO 부하가 많은 응용 프로그램에 사용되는 경우 디스크와 네트워크 I/O 처리 속도의 균형을 맞추고 시스템 부하를 줄이기 위해 끄기로 설정할 수 있습니다.
keepalive_timeout 65

: 긴 연결 시간 초과(초) 이 매개변수는 매우 민감하며 브라우저 유형, 백엔드 서버의 시간 초과 설정 및 운영 체제 설정과 관련됩니다. 긴 연결이 많은 수의 작은 파일을 요청하는 경우 연결을 다시 설정하는 비용을 줄일 수 있지만, 큰 파일을 업로드하는 경우 65초 이내에 업로드를 완료하지 못하면 실패하게 됩니다. 설정 시간이 너무 길고 사용자가 많은 경우 오랫동안 연결을 유지하면 많은 리소스를 차지하게 됩니다.

send_timeout:

클라이언트에 응답하기 위한 제한 시간을 지정하는 데 사용됩니다. 이 시간 초과는 두 연결 활동 사이의 시간으로 제한됩니다. 클라이언트의 활동 없이 이 시간이 초과되면 nginx는 연결을 닫습니다.

client_max_body_size 10m

클라이언트가 요청할 수 있는 단일 파일의 최대 바이트 수입니다. 더 큰 파일을 업로드하는 경우 제한 값을 설정하세요
client_body_buffer_size 128k

버퍼 프록시가 클라이언트 요청을 버퍼링하는 최대 바이트 수모듈 http_proxy:

이 모듈은 nginx를 역방향 프록시 서버로 구현합니다. 캐싱 기능 포함(문서 참조)

proxy_connect_timeout 60

nginx 백엔드 서버와의 연결 시간 초과(프록시 연결 시간 초과)

proxy_read_timeout 60
연결 성공 후 백엔드 서버와의 성공적인 두 응답 작업 간 시간 초과(프록시 수신 시간 초과)

proxy_buffer_size 4k
백엔드 실제 서버에서 사용자 헤더 정보를 읽고 저장하기 위한 프록시 서버(nginx)의 버퍼 크기를 설정합니다. 기본값은 Proxy_buffers와 동일한 크기입니다. 실제로 이 명령 값을 더 작게 설정할 수 있습니다.BProxy_buffers 4 32K

proxy_buffers 버퍼, 단일 연결 캐시에 대한 백엔드 RealServer의 Nginx 응답, 웹페이지가 32K 미만이므로

Proxy_busy_Size 64K

크기 가져오기(proxy_buffers*2) rProxy_max_temp_file_size

수용하다 백엔드 서버의 응답 내용 중 일부를 하드 디스크의 임시 파일에 저장합니다. 이 값은 최대 임시 파일 크기를 설정하는 데 사용됩니다. 기본값은 1024m입니다. 이보다 큰 값은 업스트림 서버에서 반환됩니다. 비활성화하려면 0으로 설정합니다.

proxy_temp_file_write_size 64k

임시 파일에 응답하기 위해 서버가 캐시를 프록시하는 경우 이 옵션은 매번 작성되는 임시 파일의 크기를 제한합니다. Proxy_temp_path(컴파일 중에 지정할 수 있음)에 쓸 디렉터리입니다.

proxy_pass, proxy_redirect 위치 섹션을 참조하세요.

모듈 http_gzip:

gzip 켜기: gzip 압축 출력을 켜서 네트워크 전송을 줄입니다.

gzip_min_length 1k: 압축이 허용되는 페이지의 최소 바이트 수를 설정합니다. 페이지 바이트 수는 헤더의 콘텐츠 길이에서 가져옵니다. 기본값은 20입니다. 바이트 수는 1k보다 크게 설정하는 것이 좋습니다. 1k보다 작으면 점점 더 압축될 수 있습니다.
gzip_buffers 4 16k: gzip 압축 결과 데이터 스트림을 저장하기 위해 여러 단위의 캐시를 얻도록 시스템을 설정합니다. 4 16k는 16k 단위로 메모리를 신청한다는 의미인데, 이는 16k 단위로 설치한 원래 데이터 크기의 4배입니다.
gzip_http_version 1.0: http 프로토콜의 버전을 식별하는 데 사용됩니다. 초기 브라우저는 gzip 압축을 지원하지 않았으므로 사용자에게 잘못된 문자가 표시됩니다. 따라서 nginx reverse를 사용하는 경우 이 옵션이 추가되었습니다. 프록시를 사용하고 gzip 압축도 활성화하려면 최종 통신이 http/1.0이므로 1.0으로 설정하세요.
gzip_comp_level 6: gzip 압축 비율, 1은 압축 비율이 가장 작고 처리 속도가 가장 빠릅니다. 9는 압축 비율이 가장 크지만 처리 속도가 가장 느립니다(전송은 빠르지만 CPU를 더 많이 소모합니다)
gzip_types: 다음과 일치합니다. 압축을 위한 MIME 유형은 지정 여부에 관계없이 "text/html" 유형이 항상 압축됩니다.
gzip_proxied any: nginx가 역방향 프록시로 사용될 때 활성화되며 백엔드 서버에서 반환된 결과의 압축을 활성화할지 여부를 결정합니다. 일치의 전제는 백엔드 서버가 다음을 반환해야 한다는 것입니다. "via"를 포함하는 헤더입니다.
gzip_vary on: http 헤더와 관련되어 있습니다. 응답 헤더에 prepare-encoding을 추가하여 프런트 엔드 캐시 서버가 gzip으로 압축된 페이지를 캐시할 수 있도록 합니다. nginx 압축 데이터.

3. 서버 가상 호스트

http 서비스는 여러 가상 호스트를 지원합니다. 각 가상 호스트에는 가상 호스트와 관련된 구성을 포함하는 해당 서버 구성 항목이 있습니다. 메일 서비스에 대한 프록시를 제공할 때 여러 서버를 만들 수도 있습니다. 각 서버는 수신 주소나 포트로 구별됩니다.

listen

수신 포트는 기본적으로 80입니다. 1024 미만인 경우 루트로 시작해야 합니다. Listen *:80, Listen 127.0.0.1:80 등의 형식일 수 있습니다.

server_name

localhost, www.example.com과 같은 서버 이름은 정규식으로 일치될 수 있습니다.

모듈 http_stream

이 모듈은 간단한 스케줄링 알고리즘을 사용하여 클라이언트 IP에서 백엔드 서버로의 로드 밸런싱을 달성합니다. 업스트림 뒤에는 로드 밸런서 이름이 오고 백엔드 실제 서버는 다음과 같은 형식으로 {}로 구성됩니다. 호스트:포트 옵션 중간. 하나의 백엔드만 프록시되는 경우 이를 Proxy_pass에 직접 작성할 수도 있습니다.

4. location

http 서비스에는 특정 특정 URL에 해당하는 일련의 구성 항목이 있습니다.

root /var/www/html

서버의 기본 웹사이트 루트 위치를 정의합니다. locationurl이 하위 디렉터리나 파일과 일치하는 경우 루트는 아무런 영향을 미치지 않으며 일반적으로 서버 지시문이나 / 아래에 배치됩니다.

index index.jsp index.html index.htm

경로 아래에 기본적으로 액세스되는 파일 이름을 정의합니다. 일반적으로 루트가 뒤에 옵니다.

proxy_pass http:/backend

요청은 백엔드에서 정의한 서버 목록으로 전달됩니다. , 업스트림 로드 이퀄라이저에 해당하는 역방향 프록시입니다. http://ip:port를 Proxy_pass할 수도 있습니다.

proxy_redirect off;

proxy_set_header 호스트 $host;

proxy_set_header x-real-ip $remote_addr;
proxy_set_header x-forwarded-for $proxy_add_x_forwarded_for;


이 네 가지는 당분간 이렇게 설정됩니다. , 각각이 관련되어 있습니다. 매우 복잡한 내용은 다른 기사에서도 설명됩니다.

위치 일치 규칙 작성은 특히 중요하고 기본적이라고 할 수 있습니다. nginx 구성 위치 요약 및 다시 작성 규칙 작성을 참조하세요.

5.1 액세스 제어 허용/ 거부

nginx 액세스 제어 모듈은 기본적으로 설치되며 작성 방법도 매우 간단합니다. 특정 IP 또는 IP 세그먼트에 대한 액세스를 허용하거나 금지하는 방법도 매우 간단합니다. 돌리면 매칭이 중단됩니다. 예:

또한 일반적으로 httpd-devel 도구의 htpasswd를 사용하여 액세스 경로에 대한 로그인 비밀번호를 설정합니다.

기본적으로 crypt로 암호화된 비밀번호 파일을 생성합니다. 위의 nginx-status에서 두 줄의 주석을 열고 nginx를 다시 시작하면 적용됩니다.

5.2 목록 디렉터리 autoindex

nginx는 기본적으로 전체 디렉터리 목록을 허용하지 않습니다. 이 기능이 필요한 경우 nginx.conf 파일을 열고 위치, 서버 또는 http 섹션에 autoindex on을 추가하는 것이 가장 좋습니다.

1. autoindex_exact_size off; 파일의 정확한 크기, 단위는 바이트입니다. off로 변경하면 대략적인 파일 크기가 표시되며 단위는 kb 또는 mb 또는 gb입니다. autoindex_localtime on; 기본값은 off이며 표시되는 파일 시간은 gmt 시간입니다. ON으로 변경 후 표시되는 파일 시간은 해당 파일의 서버 시간입니다

위 내용은 Nginx 빠른 시작 예시 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!