nginx 관련 지식 포인트 요약 및 공유
- 小云云원래의
- 2018-03-31 13:59:251508검색
Nginx 자체는 PHP를 구문 분석하지 않습니다. PHP 페이지에 대한 터미널 요청은 Nginx에 의해 FastCGI 프로세스가 모니터링하는 IP 주소와 포트로 전달되며, 이는 php-fpm에 의해 동적 구문 분석 서버로 처리됩니다. 처리 결과는 nginx로 반환됩니다. 실제로 Nginx는 역방향 프록시 서버입니다. Nginx는 역방향 프록시 기능을 통해 동적 요청을 백엔드 php-fpm으로 전달함으로써 PHP 구문 분석 지원을 실현합니다. 이것이 PHP 동적 구문 분석을 구현하는 Nginx의 원칙입니다.
Nginx는 외부 프로그램의 직접 호출이나 구문 분석을 지원하지 않습니다. 모든 외부 프로그램(PHP 포함)은 FastCGI 인터페이스를 통해 호출되어야 합니다. FastCGI 인터페이스는 Linux의 소켓입니다(이 소켓은 파일 소켓 또는 IP 소켓일 수 있습니다). CGI 프로그램을 호출하려면 FastCGI 래퍼도 필요합니다(래퍼는 다른 프로그램을 시작하는 데 사용되는 프로그램으로 이해될 수 있음). 이 래퍼는 포트나 파일 소켓과 같은 고정 소켓에 바인딩됩니다. Nginx가 이 소켓에 CGI 요청을 보내면 래퍼는 FastCGI 인터페이스를 통해 요청을 받은 다음 새 스레드를 생성합니다. 이 스레드는 인터프리터나 외부 프로그램을 호출하여 스크립트를 처리하고 반환 데이터를 읽습니다. 반환된 데이터는 FastCGI 인터페이스를 통해 고정 소켓을 따라 Nginx로 전달됩니다. 마지막으로 Nginx는 반환된 데이터를 클라이언트에 보냅니다.
클래식 모델은 Nginx에서 사용되는 Master-Worker 다중 프로세스 비동기 드라이버 모델입니다.
상위 프로세스가 소켓을 생성하고 바인딩하고 수신한 후 포크를 통해 여러 하위 프로세스를 생성합니다. 각 하위 프로세스는 상위 프로세스의 소켓을 상속하고 accpet을 호출하여 수신을 시작하고 네트워크 연결을 기다립니다. 이때 동시에 네트워크 연결 이벤트를 기다리는 여러 프로세스가 있는데, 이 이벤트가 발생하면 이러한 프로세스가 동시에 깨어나는 현상이 발생합니다. 프로세스가 활성화되면 각 프로세스가 동시에 이 이벤트에 응답하도록 커널을 다시 예약해야 합니다. 결국 하나의 프로세스만 이벤트를 성공적으로 처리할 수 있고 다른 프로세스는 다시 절전 모드로 전환되거나 처리에 실패합니다. 이벤트.
실제로 Linux 버전 2.6 이후 커널은 accept() 함수의 "충격" 문제를 해결했습니다. 커널은 고객 연결을 수신하면 대기 중인 대기열의 첫 번째 프로세스나 스레드만 깨웁니다.
Nginx는 이 문제를 해결하기 위해 accept_mutexmutex 잠금을 사용합니다. 특정 조치에는 epoll_wait() 전에 잠금이 적용됩니다. , 각 프로세스의 작업 볼륨 균형을 맞추기 위해 로드 밸런싱 알고리즘(특정 하위 프로세스의 작업 볼륨이 전체 설정 볼륨의 7/8에 도달하면 더 이상 잠금 적용을 시도하지 않음)을 대기하고 설정합니다. .
이제 천둥 그룹과 Nginx의 처리를 다음과 같이 요약합니다.
accept는 천둥 그룹을 유발하지 않지만 epoll_wait는 발생합니다.
Nginx의 accept_mutex는 accept 패닉 문제를 해결하지 않지만 epoll_wait 패닉 문제는 해결합니다.
Nginx가 epoll_wait 패닉 문제를 해결한다고 말하는 것도 잘못된 것입니다. epoll에 청취 소켓을 추가할지 여부만 제어합니다. 청취 소켓은 한 하위 프로세스의 epoll에만 있습니다. 새로운 연결이 오면 다른 하위 프로세스는 확실히 깨어나지 않습니다.
간단히 말하면, 단 한 명의 nginx 작업자만이 자체 epoll에서 청취 핸들을 동시에 처리할 수 있습니다. 로드 밸런싱도 매우 간단합니다. 최대 연결의 7/8에 도달하면 작업자는 승인 잠금을 얻으려고 시도하지 않으며 새 연결도 처리하지 않으므로 다른 nginx 작업자 프로세스는 잠금을 처리할 수 있는 더 많은 기회를 갖게 됩니다. 청취 핸들이 새로 설정되었습니다. 또한, 타임아웃 설정으로 인해 잠금을 획득하지 못한 작업자 프로세스는 잠금을 획득하는 빈도가 높아집니다.
nginx 다중 프로세스 모델에는 실제로 잠금이 없나요? 실제로 ngx_accept_mutex라는 것이 아직 남아 있습니다.
nginx는 다중 프로세스 프로그램이며 포트 80은 각 작업자 프로세스에서 공유됩니다. 연결이 올 때마다 여러 작업자 프로세스가 응답하기 위해 경쟁하게 됩니다.
커널이 링크를 수락하면 대기 중인 모든 프로세스가 깨어납니다. 그러나 실제로는 하나의 프로세스만 연결을 얻을 수 있으며 다른 프로세스는 유효하지 않게 깨어나게 됩니다. 이는 의심할 여지 없이 애플리케이션의 오버헤드를 증가시킵니다. 이를 위해 nginx는 9명의 아들이 상속인을 물려받는 비극을 피하기 위해 승인 잠금을 제공합니다.
ngx_accept_mutex의 기능은 현재 과부하가 걸린
작업자 프로세스가 새로 들어오는 요청 처리를 적극적으로 포기하고
애플리케이션의 전반적인 절전 모드 해제 효율성을 향상시켜 애플리케이션의 전반적인 성능을 향상시킬 수 있도록 하는 것입니다. .
proxy_cache
upstream
fastcgi_pass
location
비표준 상태 코드 444는 연결을 닫고 클라이언트에 응답 헤더를 보내지 않음을 의미합니다.
nginx -s reload 명령은 수정된 구성 파일을 로드합니다.
1. Nginx의 마스터 프로세스는 구성 파일의 정확성을 확인하고 오류 메시지가 반환되고 nginx는 계속됩니다. 원본 구성 파일을 사용하여 작업합니다(작업자는 영향을 받지 않기 때문에)
2. Nginx는 새 작업자 프로세스를 시작하고 새 구성 파일을 채택합니다
3. Nginx는 새 작업자 프로세스에 새 요청을 할당합니다. 이전 작업자 프로세스의 모든 요청이 반환될 때까지 기다립니다. 모두 반환된 후 해당 작업자 프로세스를 닫습니다
5. 이전 작업자 프로세스가 모두 닫힐 때까지 위 과정을 반복합니다
위 프로세스는 nginx 관련 공식 문서를 기반으로 합니다.
proxy_next_upstream을 예로 들어 보겠습니다.
proxy_next_upstream http_504 timeout;
이 명령에는 두 가지 기능이 있습니다.
- nginx에게 연결 시간 초과가 발생하고 업스트림이 504를 반환해야 한다고 알려줍니다.
- nginx에게 http 504, 연결 시간 초과는 요청 실패라고 말하세요
- 일반적으로 nginx는 기본적으로 오류, 시간 초과, valid_header로 인해 실패합니다. 클래스 지시어에 Proxy_next_upstream과 같은 것을 추가하세요. 그 중 http_403, http_404가 인식되지 않으면 실패입니다.
서버 오류의 정의와 오류 이후 서버의 동작이라는 두 가지 사항에 대해 토론해 보세요.
- 서버 오류 정의: 위의 모듈 오류 정의는 주로 어떤 상황에서 요청이 실패하는지 설명하는 데 사용되지만 서버를 오류로 정의하는 것은 무엇입니까? nginx는 주로 max_fails 및 failure_timeout이라는 두 가지 매개변수를 사용하여 제어합니다. 간단히 말해서, 요청이 실패 시간 내에 max_fails번 실패하면 서버가 현재 다운되었음을 의미합니다.
- 실패 후 동작: 주로:
- fail_timeout 기간에는 서버가 선택되지 않습니다.
- fail_timeout 시간이 지나면 서버는 정상으로 표시되어 기존 작업을 반복합니다. 논리.
- Ngxin은 클라이언트 요청 처리를 11단계로 나눕니다
#1 NGX_HTTP_POST_READ_PHASE: 요청 내용 읽기 단계
#2 NGX_HTTP_SERVER_REWRITE_PHASE: 서버 요청 주소 다시 쓰기 단계
#3 NGX_ HTTP_FIND_CONFIG_PHA SE: 구성 검색 단계
#4 NGX_HTTP_REWRITE_PHASE : 위치 요청 주소 재작성 단계
#5 NGX_HTTP_POST_REWRITE_PHASE : 주소 재작성 요청 제출 단계
#6 NGX_HTTP_PREACESS_PHASE : 접근 권한 확인 준비 단계
#7 NGX_HTTP_ACCESS_PHASE : 접근 권한 확인 단계
#8 NGX_HTTP_POST_ACCESS_PHASE : 접근 권한 확인 제출 단계
#9 NGX_HTTP_TRY_FILES_PHASE: 구성 항목 try_files 처리 단계
#10 NGX_HTTP_CONTENT_PHASE: 콘텐츠 생성 단계
#11 NGX_HTTP_LOG_PHASE: 로그 모듈 처리 단계
Nginx 요청 처리 과정
#1 Nginx 확인 방법 어떤 서버가 요청을 처리합니까?
1. IP + 포트를 사용하여 IP와 포트를 수신하는 서버를 확인합니다.
2. 요청의 호스트 헤더를 기반으로 요청을 처리하기 위해 선택된 서버를 확인합니다.
3. 일치하는 서버가 없으면 요청은 처리를 위해 기본 서버로 전송됩니다.
일반적으로 아무런 설정 없이 구성 파일에 순차적으로 나타나는 첫 번째 서버는
기본 서버입니다.
4 Listen 명령에 default_server 플래그를 사용하여 서버를
기본 서버로 설정할 수 있습니다.
#2 Nginx는 호스트 헤더를 기반으로 서버와 어떻게 일치합니까?
Nginx는 주로 서버의 server_name과 호스트 헤더를 비교하여 서버를 일치시킵니다.
비교 순서는 다음과 같습니다.
1. 정확한 이름
2. 가장 긴 일치하는 와일드카드 이름(예: *.zhidao.baidu.com)
3. 예: zhidao.baidu.*);
#3 http 요청 초기화, http 요청 11단계
위치 일치 명령
~ 물결선은 대소문자를 구분하여 일반 일치의 실행을 나타냅니다.
~*는 대소문자를 구분하지 않고 일반 일치를 수행함을 의미합니다.
^~ ^~는 일반 문자 일치를 의미합니다. 이 옵션이 일치하면 이 옵션만 일치하고 다른 옵션은 일치하지 않습니다. 일반적으로 디렉터리를 일치하는 데 사용됩니다.
= 일반 문자의 정확한 일치를 수행합니다.
@ "@"은 error_page, try_files와 같이 내부 방향에 사용되는 명명된 위치를 정의합니다.
예:
요청 URI 예:
/ -> 구성 A
/documents/document.html ->
- /images /1.gif -> 구성 C 준수
- /documents/1.jpg -> 구성 D
nginx 역방향 프록시 메커니즘은 프런트엔드 크로스 도메인 문제
위 내용은 nginx 관련 지식 포인트 요약 및 공유의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!