nginx 핵심 아키텍처 개요

졸업 전과 프로젝트 완료 후 한동안 소켓 프로그래밍에 빠져 C++의 Qt 프레임워크를 사용하여 장난감 같은 TCP 및 UDP 통신 클라이언트를 작성했습니다. 직속 선배와 통화할 때 소켓을 좀 더 깊이 파고들어 백엔드나 아키텍트 루트를 시도해 보라고 조언을 받았습니다. 어떻게 더 깊게 파고들느냐고 물으면 소스코드를 공부하라는 대답이 나온다. 소켓 관련 지식을 배우고 싶다면 서버 소스코드를 공부하는 것이 가장 적합하다. 어떤 서버를 선택할지 신중하게 고민하고 조사한 결과, 무겁고 부피가 큰 Apache에 비해 nginx가 더 작고 우수하다는 사실을 발견했습니다. 그래서 정식으로 소스코드를 먹기 전에 먼저 자체 대중화 작업을 시작했습니다.

1, 프로세스 모델

우선 기본값은 다른 서버와 동일합니다. Unix에서는 nginx도 daemon(데몬 프로세스) 형태로 백그라운드에서 계속 실행됩니다. nginx는 디버깅 목적으로 백그라운드 모드를 끌 수도 있지만 포그라운드 모드를 사용하고 구성을 통해 마스터 프로세스를 취소할 수도 있습니다. (나중에 자세히 설명하겠습니다) nginx가 단일 프로세스로 작동하도록 합니다. 하지만 이는 nginx가 자랑하는 아키텍처와는 거의 관련이 없으므로 여기에 나열하지 않겠습니다. nginx도 멀티스레딩을 지원하지만 우리는 여전히 기본 멀티프로세스 모드를 이해하는 데 중점을 두고 있습니다.

nginx

는 시작 후 마스터 프로세스(기본 프로세스)와 여러 워커를 생성합니다. 프로세스(슬레이브 프로세스). master 프로세스는 주로 worker 프로세스를 관리하는 역할을 담당합니다. 구체적으로 관리자로부터 신호를 받아 해당 프로세스에 전달합니다. worker 프로세스, worker 프로세스의 작업 상태를 모니터링하고 worker 프로세스가 비정상적으로 종료되고 worker 프로세스를 시작합니다. worker 프로세스는 기본 네트워크 이벤트 처리를 담당합니다. 작업자프로세스는 동일한 우선순위를 가지며 서로 독립적입니다. 각 요청은 단 하나의 작업자에 의해 제어됩니다. 프로세스 처리. nginx 프로세스 모델 다이어그램은 그림 1에 나와 있습니다.

그림

1 nginx프로세스 모델 다이어그램

작업자

프로세스 수 일반 설정은 CPU 코어 수와 일치합니다. 이 원칙은 nginx의 이벤트 처리 모델과 관련이 있습니다. 추후 nginx의 이벤트 처리 모델을 계속 소개하겠습니다. 2. 신호 및 요청

nginx

는 관리자의 신호와 클라이언트의 요청이라는 두 가지 인터페이스를 통해 외부 세계와 상호 작용합니다. 아래에는

nginx가 신호와 요청을 처리하는 방법을 보여주는 예가 나와 있습니다. 관리자는 nginx

를 제어하고 마스터 프로세스와 통신하여 master프로세스는 명령 신호만 보내면 됩니다. 예를 들어 nginx는 버전 0.8 이전에 kill -HUP [pid]를 사용했습니다. 재시작 명령 nginx. 이 명령을 사용하여 nginx를 다시 시작하면 서비스 중단 없이 정상적으로 다시 시작 프로세스가 수행됩니다. HUP 명령을 받은 후 master 프로세스는 먼저 구성 파일을 다시 로드한 다음 새 를 시작합니다. Worker 프로세스는 이전 worker 프로세스에 중지 신호를 보냅니다. 이때 새로운 worker 프로세스는 네트워크 요청을 받기 시작하며, 이전 worker 프로세스는 현재까지 새로운 요청 수신을 중지합니다. 요청이 처리된 후 이전 worker 프로세스가 종료되고 삭제됩니다. 버전 0.8 이후 nginx에는 서버 관리를 용이하게 하기 위해 와 같은 일련의 명령줄 매개변수가 도입되었습니다. /nginx -s reload 및 ./nginx -s stop은 각각 nginx를 다시 시작하고 중지하는 데 사용됩니다. . 작업 명령을 실행하면 실제로 새로운 nginx 프로세스가 시작됩니다. 명령의 매개변수를 구문 분석한 후 이 프로세스는 자체 요청을 master 이전에는 수동으로 신호를 보낸 것과 동일한 효과를 얻기 위해 해당 신호를 보내는 프로세스입니다. 3. 요청사항 및 이벤트

서버는 80포트 http 의 요청을 가장 자주 처리합니다. nginx요청을 처리하는 과정입니다. 우선 각 worker 프로세스는 master 프로세스 fork에서 시작됩니다( min. 포크), 마스터 프로세스는 먼저 소켓(소켓, 즉 IP주소+포트 번호) 및 해당 listenfd(듣기 파일 설명자 또는 핸들) . 소켓 통신의 각 프로세스에는 포트 번호가 할당되어야 하며, 작업자소켓프로세스 🎜>배포작업은 마스터프로세스를 거쳐 완성됩니다. 모든 worker 프로세스 중 listenfd는 새 연결이 도착하면 읽을 수 있게 되어 Worker 프로세스가 연결을 처리하며 각 worker 프로세스는 listenfd를 가져와야 합니다. > 이벤트를 읽기 전 accept_mutex(연결 뮤텍스 허용), worker 프로세스가 연결을 성공적으로 등록한 후 요청 읽기를 시작하고 구문 분석합니다. 요청을 처리하고 클라이언트에 대한 피드백 데이터를 처리합니다. 4. 프로세스 모델 분석 nginx는 다중 프로세스 요청 처리 모델(

PPC

을 사용하지만 이를 사용하지 않음) ), 각 작업자 프로세스는 한 번에 하나의 요청만 처리하므로 요청 간의 리소스가 잠기지 않고 독립적이 되며, 프로세스는 서로 영향을 주지 않고 병렬로 요청을 처리할 수 있습니다. 요청 처리가 실패하면 worker 프로세스가 비정상적으로 종료되어 서비스가 중단되지 않습니다. 대신 master 프로세스가 즉시 종료됩니다. restart one 새로운 worker 프로세스는 서버가 직면하는 전반적인 위험을 줄이고 서비스를 더욱 안정적으로 만듭니다. 하지만 멀티 스레드 모델(TPC)에 비해 시스템 오버헤드가 약간 크고 효율성이 약간 떨어지므로 다른 개선 방법이 필요합니다. 5. nginx의 높은 동시성 메커니즘——

비동기 비차단 이벤트 메커니즘 IIS이벤트 처리 메커니즘은 다중 스레드이며 각 요청에는 단독 작업자 스레드가 있습니다. 멀티스레딩은 메모리를 더 많이 차지하기 때문에 스레드 간 컨텍스트 전환(레지스터 그룹을 보호하고 복원하는 반복 작업)으로 인해 발생하는 CPU

오버헤드도 매우 큽니다. 메커니즘이 있는 서버는 수천 개의 동시성을 직면하므로 시스템에 많은 부담을 주게 됩니다. 물론, 하드웨어가 충분히 좋고 충분한 시스템 리소스를 제공할 수 있다면 시스템에 대한 부담은 더 이상 없습니다. 문제. 다중 프로세스와 다중 스레드, 차단 메커니즘과 비차단 메커니즘의 차이점을 논의하기 위해 시스템 수준으로 깊이 들어가 보겠습니다. 운영 체제에 익숙한 학생들은 멀티 스레딩의 출현은 특히 멀티 코어 개선을 위해 리소스가 충분할 때 CPU

를 완전히 예약하고 사용하는 것임을 이해해야 합니다. 🎜>

CPU

활용도가 매우 좋습니다. 그러나 스레드는 시스템 작업의 가장 작은 단위이고 프로세스는 시스템 리소스 할당의 가장 작은 단위입니다. 이는 멀티스레딩이 큰 문제에 직면하게 된다는 것을 의미합니다. 스레드 수가 증가하고 리소스 요구 사항이 증가하면 이러한 부모 프로세스가 발생합니다. 스레드는 한 번에 모든 스레드에 충분한 리소스를 즉시 적용하는 것이 불가능합니다. 시스템에 프로세스를 만족시킬 만큼 리소스가 충분하지 않으면 전체 프로세스를 기다리게 됩니다. 이때 일부 스레드가 정상적으로 작동할 만큼 시스템 리소스가 충분하더라도 상위 프로세스에서는 이러한 리소스를 신청할 수 없으므로 모든 스레드가 함께 대기하게 됩니다. 직설적으로 말하면, 멀티스레딩을 사용하면 프로세스 내의 스레드를 유연하게 예약할 수 있지만(스레드 교착 상태의 위험과 스레드 전환 비용이 증가하기는 하지만) 상위 프로세스가 여전히 시스템에 있을 수 있다는 보장은 없습니다. 더 커지고 무거워지면 합리적인 일정을 잡으십시오. 멀티스레딩은 실제로 CPU 활용도를 향상시킬 수 있지만 높은 동시성 조건은 말할 것도 없고 동시 서버 요청이 많은 문제를 해결하는 이상적인 솔루션은 아닙니다. CPU의 높은 가동률도 유지하기 어렵습니다. 위는 IIS의 다중 스레드 동기 차단 이벤트 메커니즘입니다. nginx의 다중 프로세스 메커니즘은 각 요청이 시스템 리소스에 독립적으로 적용되도록 보장하며, 조건이 충족되면 각 요청을 즉시 처리할 수 있습니다. 즉, 비동기 비차단 처리가 가능합니다. . 그러나 프로세스를 생성하려면 스레드보다 더 많은 리소스 오버헤드가 필요합니다. 프로세스 수를 절약하기 위해 nginx

에서는 일부 프로세스 스케줄링 알고리즘을 사용하여

I/O를 수행합니다. 이벤트 처리는 다중 프로세스 메커니즘뿐만 아니라 비동기식 및 비차단 다중 프로세스 메커니즘에도 의존합니다. 다음으로 nginx의 비동기식 Non-Blocking 이벤트 처리 메커니즘을 자세히 소개하겠습니다. 6.에폴

리눅스에서는 동시성이 높은 고성능 네트워크를 위해서는 epoll이 필요하며, nginx도 사용됩니다epoll 모델은 네트워크 이벤트에 대한 처리 메커니즘 역할을 합니다. 먼저 epoll이 어떻게 탄생했는지 살펴보겠습니다.

가장 초기의 스케줄링 솔루션은 비동기식 바쁜 폴링 방식, 즉 I/O 이벤트의 연속 폴링, 즉 순회 입니다. 소켓컬렉션의 액세스 상태로 인해 이 솔루션은 서버가 유휴 상태일 때 불필요한 CPU 오버헤드를 발생시킵니다.

나중에 선택 및 폴링을 예약 프로세스로 CPU 활용 에이전트는 말 그대로 "select, 또 하나는 로 등장한다. "Poll" 본질은 똑같고, Polling소켓을 수집하여 이전과의 차이점은 I/O 이벤트를 모니터링할 수 있고 유휴 상태에서는 폴링 스레드가 차단되며 하나 이상의 I / O은 이벤트가 도착하면 깨어나 "Busy Polling " 의 "Busy"는 비동기 폴링 방식이 됩니다. select/poll모델은 전체 FD(파일 설명자) 세트, 즉 소켓 수집, 네트워크 이벤트 처리 효율성은 동시 요청 수에 따라 선형적으로 감소하므로 매크로를 사용하여 최대 동시 연결 수를 제한합니다. 동시에 select/poll 모델의 커널 공간과 사용자 공간 간의 통신 방식은 메모리 복사이므로 오버헤드가 높다. 위의 단점으로 인해 새로운 모델이 탄생했습니다. epoll은 event poll

의 약자라고 볼 수 있으며, 은 Linux 커널 대규모 파일 설명자 배치에 대한 개선된 poll은 LinuxI에서 다중화됩니다. 향상된 버전 /O인터페이스select/poll의 기능은 프로그램의 동시 연결 수가 적은 경우 시스템을 크게 향상시킬 수 있습니다. 연결CPU 활용도. 먼저 epoll에는 최대 동시 연결 수에 제한이 없습니다. 상한은 열 수 있는 최대 파일 수이며 이는 하드웨어 메모리 크기와 관련됩니다. , 1GB 머신에서는 10w 정도입니다. 그러면 epoll은 "Active"의소켓 커널에 의해 작동되는 작업만 수행하므로 소켓은 I/O 읽기 및 쓰기 이벤트에 의해 비동기적으로 깨어납니다. ready 대기열에 넣고, Ready to enterworker 프로세스를 처리하여 실제 프로덕션 환경에서 폴링 오버헤드를 많이 절약하고 이벤트 처리 효율성을 크게 향상시킵니다. 마지막으로 epoll 공유 메모리(MMAP)를 사용하여 커널 공간과 사용자 공간 간의 통신을 실현합니다. 메모리 복사의 오버헤드. 또한 ET(edge ​​​​트리거)는 epoll

nginx에서 작동합니다. > 모드는 빠른 작업 모드입니다. ET 모드는 논블로킹 소켓만 지원하며, FD가 준비되어 있습니다. 커널은 epoll을 통해 알림을 보냅니다. 특정 작업 후에는 FD도 더 이상 준비되지 않습니다. I/O 작업으로 인해 FD가 준비되지 않은 경우 알림이 전송되지 않습니다. 일반적으로 nginx는 Linux에서 이벤트 기반이며 epoll을 사용합니다. 네트워크 이벤트. 저작권 안내: 이 글은 해당 블로거의 원본 글이므로 블로거의 허락 없이 복제할 수 없습니다. 위에서는 nginx의 핵심 아키텍처에 대한 개요를 그 측면을 포함하여 소개했습니다. PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.