Nginx 연결이란 무엇입니까?

connection

Nginx에서 연결은 연결된 소켓, 읽기 이벤트 및 쓰기 이벤트를 포함하여 TCP 연결을 캡슐화한 것입니다. Nginx로 캡슐화된 연결을 사용하면 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는 작업자 연결을 설정하여 각 프로세스에서 지원하는 최대 연결 수를 설정합니다. 이 값이 nofile보다 크면 실제 최대 연결 수는 nofile이고 Nginx는 경고합니다.

Nginx는 구현 시 연결 풀을 통해 관리됩니다. 각 작업자 프로세스는 독립적인 연결 풀을 가지며 연결 풀의 크기는 Worker_connections입니다. 여기서 연결 풀에 저장되는 것은 실제로 실제 연결이 아니며, 작업자_연결 크기의 ngx_connection_t 구조 배열일 뿐입니다.

그리고 Nginx는 연결된 목록 free_connections를 통해 모든 무료 ngx_connection_t를 저장합니다. 연결이 얻어질 때마다 무료 연결 목록에서 하나를 가져오고 이를 사용한 후 다시 무료 연결 목록에 넣습니다.

여기서 많은 사람들은 Worker_connections 매개변수의 의미를 이 값이 Nginx가 설정할 수 있는 연결의 최대값이라고 오해할 것입니다. 실제로 이 값은 각 작업자 프로세스에서 설정할 수 있는 최대 연결 수를 나타냅니다. 따라서 Nginx에서 설정할 수 있는 최대 연결 수는 작업자_연결 * 작업자_프로세스입니다.

물론, 여기서 말하는 것은 최대 연결 수입니다. 로컬 리소스에 대한 HTTP 요청의 경우 지원 가능한 최대 동시성 수는 작업자_연결 * 작업자_프로세스입니다. 동시성 수는 작업자_연결 * 작업자_프로세스여야 합니다.

역방향 프록시 서버이기 때문에 각 동시 연결은 클라이언트와의 연결과 백엔드 서비스와의 연결을 설정하며 이는 두 개의 연결을 차지합니다.

앞서 말했듯이 클라이언트가 연결되면 여러 유휴 프로세스가 연결을 위해 경쟁하게 됩니다. 이 경쟁이 특정 프로세스가 승인될 확률이 더 높을 경우 유휴 상태가 된다는 것을 쉽게 알 수 있습니다. 연결이 곧 소진됩니다. 사전에 일부 제어가 수행되지 않으면 새 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에서 연결이 무엇인지 아는 것만으로도 충분하며, 연결은 비교적 고급 사용법입니다.

위 내용은 Nginx 연결이란 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!