nginx 기본 개념 - 연결

nginx에서 연결은 연결된 소켓, 읽기 이벤트 및 쓰기 이벤트를 포함하여 TCP 연결을 캡슐화한 것입니다. nginx로 캡슐화된 연결을 사용하면 nginx를 사용하여 연결 설정, 데이터 전송 및 수신 등과 같은 연결 관련 문제를 쉽게 처리할 수 있습니다. nginx의 http 요청 처리는 연결을 기반으로 하므로 nginx는 웹 서버뿐만 아니라 메일 서버로도 사용할 수 있습니다. 물론 nginx가 제공하는 연결을 사용하면 모든 백엔드 서비스를 처리할 수 있습니다. TCP 연결의 수명주기와 결합하여 nginx가 연결을 처리하는 방법을 살펴보겠습니다. 먼저 nginx가 시작되면 구성 파일을 구문 분석하여 모니터링해야 하는 포트와 IP 주소를 가져온 다음 nginx 마스터 프로세스에서 먼저 모니터링 소켓을 초기화합니다(소켓 생성, addrreuse 및 기타 옵션 설정, 바인딩). 지정된 IP 주소 포트를 수신한 다음 수신) 여러 하위 프로세스를 분기하면 하위 프로세스가 새 연결을 수락하기 위해 경쟁합니다. 이 시점에서 클라이언트는 nginx에 대한 연결을 시작할 수 있습니다. 클라이언트와 서버가 3방향 핸드셰이크를 통해 연결을 설정하면 nginx의 하위 프로세스가 성공적으로 수락하고 설정된 연결의 소켓을 얻은 다음 nginx의 연결 캡슐화, 즉 ngx_connection_t 구조를 생성합니다. 다음으로 읽기 및 쓰기 이벤트 처리 기능을 설정하고 읽기 및 쓰기 이벤트를 추가하여 클라이언트와 데이터를 교환합니다. 마지막으로 nginx 또는 클라이언트가 연결을 적극적으로 닫습니다. 이 시점에서 연결이 종료됩니다. 물론, nginx를 클라이언트로 사용하여 다른 서버(예: 업스트림 모듈)에 데이터를 요청할 수도 있습니다. 이때 다른 서버와 생성된 연결도 ngx_connection_t에 캡슐화됩니다. 클라이언트로서 nginx는 먼저 ngx_connection_t 구조를 얻은 다음 소켓을 생성하고 소켓의 속성(예: 비차단)을 설정합니다. 그런 다음 읽기 및 쓰기 이벤트를 추가하고 연결/읽기/쓰기를 호출하여 연결을 호출한 다음 마지막으로 연결을 닫고 ngx_connection_t를 해제합니다. nginx에서는 각 프로세스마다 최대 연결 수 제한이 있는데, 이는 시스템의 fd 제한과 다릅니다. 운영 체제에서는 ulimit -n을 통해 프로세스가 열 수 있는 최대 fd 수(nofile)를 얻을 수 있습니다. 각 소켓 연결은 하나의 fd를 차지하므로 프로세스의 최대 연결 수도 제한됩니다. 물론 이는 우리 프로그램이 지원할 수 있는 최대 동시성 수에도 직접적인 영향을 미칩니다. fd가 모두 사용되면 소켓 생성이 실패합니다. nginx는 Worker_connectons를 설정하여 각 프로세스에서 지원하는 최대 연결 수를 설정합니다. 값이 nofile보다 크면 실제 최대 연결 수는 nofile이고 nginx에서 경고합니다. nginx가 구현되면 연결 풀을 통해 관리됩니다. 각 작업자 프로세스는 독립적인 연결 풀을 가지며 연결 풀의 크기는 Worker_connections입니다. 여기서 연결 풀에 저장되는 것은 실제로 실제 연결이 아니며, 단지 Worker_connections 크기의 ngx_connection_t 구조 배열일 뿐입니다. 또한, nginx는 연결된 목록 free_connections를 통해 모든 사용 가능한 ngx_connection_t를 저장합니다. 연결을 얻을 때마다 사용 가능한 연결 목록에서 하나를 가져오고 사용 후 다시 사용 가능한 연결 목록에 넣습니다. 여기서 많은 사람들은 Worker_connections 매개변수의 의미를 이 값이 nginx가 연결을 설정할 수 있는 최대값이라고 오해할 것입니다. 실제로 이 값은 각 작업자 프로세스에서 설정할 수 있는 최대 연결 수를 나타냅니다. 따라서 nginx에서 설정할 수 있는 최대 연결 수는 작업자_연결 * 작업자_프로세스입니다. 물론 여기서 말하는 것은 최대 연결 수입니다. 로컬 리소스에 대한 HTTP 요청의 경우 지원될 수 있는 최대 동시성 수는 작업자_연결 * 작업자_프로세스입니다. 동시성은 작업자_연결이어야 합니다. * 작업자_프로세스/2. 역방향 프록시 서버로서 각 동시 연결은 클라이언트와의 연결 및 백엔드 서비스와의 연결을 설정하며 두 개의 연결을 차지합니다. 앞서 말했듯이 클라이언트가 연결되면 여러 유휴 프로세스가 연결을 위해 경쟁하게 됩니다. 이 경쟁이 프로세스가 승인될 확률이 높아지면 쉽게 알 수 있습니다. 유휴 연결은 곧 소진될 것입니다. 사전에 일부 제어가 수행되지 않으면 유휴 연결을 얻을 수 없고 연결을 다른 프로세스로 전송할 수 없기 때문에 새로운 TCP 연결이 허용될 때 이 TCP가 결국 발생하게 됩니다. 연결을 처리할 수 없어 중단되었습니다. 분명히 이것은 불공평합니다. 일부 프로세스에는 무료 연결이 있지만 이를 처리할 기회가 없습니다. 일부 프로세스는 무료 연결이 없기 때문에 연결을 인위적으로 삭제합니다. 그렇다면 이 문제를 해결하는 방법은 무엇입니까? 먼저 nginx 처리에서는 accept_mutex 옵션을 켜야 합니다. 이때 accept_mutex를 획득한 프로세스만 accept 이벤트를 추가합니다. 즉, nginx는 프로세스가 accept 이벤트를 추가할지 여부를 제어합니다. nginx는 ngx_accept_disabled라는 변수를 사용하여 accept_mutex 잠금을 놓고 경쟁할지 여부를 제어합니다. 첫 번째 코드에서 ngx_accept_disabled 값을 계산합니다. 이 값은 단일 nginx 프로세스의 총 연결 수의 1/8입니다. 결과 ngx_accept_disabled에 패턴이 있을 때. 남은 연결 수는 다음보다 작습니다. 전체 연결 수의 1/8이 존재할 때만 0보다 큰 값을 가지며, 남은 연결 수가 적을수록 값이 커집니다. 두 번째 코드를 보면 ngx_accept_disabled가 0보다 크면 accept_mutex 잠금 획득을 시도하지 않고 ngx_accept_disabled는 1씩 감소하게 됩니다. 따라서 여기에서 실행될 때마다 1씩 감소하게 됩니다. 0보다 작습니다. accept_mutex 잠금을 획득하지 않는 것은 연결을 획득할 기회를 포기하는 것과 같습니다. 사용 가능한 연결이 적을수록 ngx_accept_disable이 커지므로 더 많은 기회가 주어지므로 다른 프로세스가 획득할 수 있는 기회가 발생합니다. 잠금도 더 커집니다. 수락하지 않으면 자신의 연결이 제어되고 다른 프로세스의 연결 풀이 사용됩니다. 이러한 방식으로 nginx는 여러 프로세스 간의 연결 균형을 제어합니다. ngx_accept_disabled = ngx_cycle->connection_n / 8 - ngx_cycle->free_connection_n; if (ngx_accept_disabled > 0) { ngx_accept_disabled--; } else { if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) { return; } if (ngx_accept_mutex_held) { flags |= NGX_POST_EVENTS; } else { if (timer == NGX_TIMER_INFINITE || timer > ngx_accept_mutex_delay) { timer = ngx_accept_mutex_delay; } } }

위에서는 nginx의 기본 개념인 연결에 대한 내용을 소개했으며, PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.