nginx 기초 개념 (100%) 의 connection

nginx 에서 connection 은 tcp 연결 에 대한 패키지 입 니 다. 연 결 된 socket, 읽 기 이벤트, 쓰기 이 벤트 를 포함 합 니 다.nginx 로 포 장 된 connection 을 이용 하여 우 리 는 nginx 를 사용 하여 연결 과 관련 된 일 을 편리 하 게 처리 할 수 있 습 니 다. 예 를 들 어 연결 을 구축 하고 데 이 터 를 보 내 고 받 아들 이 는 등 입 니 다.nginx 의 http 요청 처 리 는 connection 위 에 세 워 진 것 이기 때문에 nginx 는 웹 서버 일 뿐만 아니 라 메 일 서버 로 도 사용 할 수 있 습 니 다.물론 nginx 가 제공 하 는 connection 을 이용 하여 저 희 는 모든 백 엔 드 서비스 와 접촉 할 수 있 습 니 다.
tcp 연결 의 수명 주 기 를 결합 하여 nginx 가 연결 을 어떻게 처리 하 는 지 봅 시다.먼저, nginx 는 시작 할 때 설정 파일 을 분석 하고 감청 이 필요 한 포트 와 ip 주 소 를 얻 은 다음 nginx 의 master 프로 세 스 에서 이 모니터링 의 socket (socket 생 성, addrreuse 설정 등 옵션 을 초기 화하 고 지정 한 ip 주소 포트 에 연결 한 다음 에 listen) 을 한 다음 에 fork 에서 여러 개의 키 프로 세 스 를 내 고 하위 프로 세 스 는 accept 새로운 연결 을 경쟁 합 니 다.이때 클 라 이언 트 는 nginx 에 연결 할 수 있 습 니 다.클 라 이언 트 와 서버 가 세 번 의 악 수 를 통 해 연결 을 만 든 후에 nginx 의 한 키 프로 세 스 는 accept 에 성공 하여 이 연결 을 만 든 socket 을 얻 은 다음 에 nginx 가 연결 에 대한 패 키 지 를 만 듭 니 다. 즉, ngxconnection_t 구조 체.이 어 읽 기와 쓰기 이벤트 처리 함 수 를 설정 하고 읽 기와 쓰기 이 벤트 를 추가 하여 클 라 이언 트 와 데 이 터 를 교환 합 니 다.마지막 으로 nginx 나 클 라 이언 트 가 자발적으로 연결 을 끄 면 연결 하나 가 죽 습 니 다.
물론 nginx 도 클 라 이언 트 로 서 다른 server 의 데 이 터 를 요청 할 수 있 습 니 다 (예 를 들 어 upstream 모듈). 이 때 다른 server 와 만 든 연결 도 ngx 에 봉 인 됩 니 다.connection_t 중.클 라 이언 트 로 서 nginx 는 먼저 ngx 를 가 져 옵 니 다.connection_t 구조 체 를 만 든 다음 socket 을 만 들 고 socket 의 속성 을 설정 합 니 다 (예 를 들 어 비 차단).그 다음 에 읽 기와 쓰기 이 벤트 를 추가 하고 connect / read / write 를 호출 하여 연결 을 호출 하고 마지막 으로 연결 을 끄 고 ngx 를 방출 합 니 다.connection_t。
nginx 에 서 는 프로 세 스 마다 연결 수의 최대 상한 선 이 있 습 니 다. 이 상한 선 은 시스템 이 fd 에 대한 제한 과 다 릅 니 다.운영 체제 에서 ulimit - n 을 통 해 우 리 는 하나의 프로 세 스 가 열 수 있 는 fd 의 최대 수, 즉 nofile 을 얻 을 수 있 습 니 다. 모든 socket 연결 이 하나의 fd 를 차지 하기 때문에 이것 은 우리 프로 세 스 의 최대 연결 수 를 제한 할 수 있 습 니 다. 물론 우리 프로 세 스 가 지원 할 수 있 는 최대 병발 수 에 직접적인 영향 을 줄 수 있 습 니 다. fd 가 다 쓴 후에 socket 을 만 들 때 실패 합 니 다.그러나 여기 서 제 가 말 하고 자 하 는 nginx 는 연결 수 에 대한 제한 은 nofile 과 직접적인 관계 가 없고 nofile 보다 클 수도 있 고 nofile 보다 작 을 수도 있 습 니 다.nginx 설정 을 통 해 workerconnectons 는 모든 프로 세 스 가 사용 할 수 있 는 연결 최대 치 를 설정 합 니 다.nginx 가 실 현 될 때 하나의 연결 탱크 를 통 해 관리 합 니 다. 모든 worker 프로 세 스 는 하나의 독립 된 연결 탱크 가 있 고 연결 탱크 의 크기 는 worker 입 니 다.connections。이곳 의 연결 탱크 안에 저 장 된 것 은 사실 실제 연결 이 아니 라 워 커 일 뿐 입 니 다.connections 크기 의 ngxconnection_t 구조의 배열.그리고 nginx 는 하나의 링크 를 통 해 freeconnections 는 모든 남 은 ngx 를 저장 합 니 다.connection_t. 연결 을 가 져 올 때마다 남 은 연결 링크 에서 하 나 를 가 져 오고 다 쓴 후에 남 은 연결 링크 에 넣 습 니 다.
이곳 에 서 는 많은 사람들 이 워 커 를 오해 합 니 다connections 라 는 매개 변 수 는 nginx 가 연결 할 수 있 는 최대 값 이 라 고 생각 합 니 다.그렇지 않 습 니 다. 이 값 은 모든 워 커 프로 세 스 가 연결 할 수 있 는 최대 값 을 나타 내 는 것 입 니 다. 따라서 하나의 nginx 가 만 들 수 있 는 최대 연결 수 는 워 커 일 것 입 니 다.connections * worker_processes。물론, 여기 서 말 하 는 것 은 최대 연결 수 입 니 다. HTTP 가 로 컬 자원 을 요청 하 는 데 지원 할 수 있 는 최대 병발 수 는 worker 입 니 다.connections * worker_processes, HTTP 가 역방향 에이전트 라면 최대 병발 수량 은 workerconnections * worker_processes/2。역방향 프 록 시 서버 로 서 모든 병발 은 클 라 이언 트 와 의 연결 과 백 엔 드 서비스 와 의 연결 을 구축 하고 두 개의 연결 을 차지 하기 때 문 입 니 다.
그러면 앞에서 말 했 듯 이 한 클 라 이언 트 가 연결 되면 여러 개의 남 은 프로 세 스 가 이 연결 을 경쟁 할 것 입 니 다. 쉽게 볼 수 있 습 니 다. 이런 경쟁 은 불공평 합 니 다. 만약 에 특정한 프로 세 스 가 accept 를 받 을 기회 가 비교적 많 으 면 그 남 은 연결 은 곧 소 진 됩 니 다. 만약 에 미리 통 제 를 하지 않 으 면 accept 가 새로운 tcp 연결 을 받 으 면남 은 연결 을 받 을 수 없고 이 연결 을 다른 프로 세 스에 전달 할 수 없 기 때문에 이 tcp 연결 이 처리 되 지 않 고 중 단 됩 니 다.이것 은 불공평 한 것 이 분명 하 다. 어떤 프로 세 스 는 남 은 연결 이 있 지만 처리 할 기회 가 없다. 어떤 프로 세 스 는 남 은 연결 이 없 기 때문에 인위적으로 연결 을 버린다.그렇다면 이 문 제 를 어떻게 해결 할 것 인가?우선, nginx 의 처 리 는 accept 를 먼저 열 어야 합 니 다.mutex 옵션, 이때 accept 만 획득mutex 프로 세 스 가 accept 이 벤트 를 추가 할 수 있 습 니 다. 즉, nginx 는 프로 세 스 가 accept 이 벤트 를 추가 할 지 여 부 를 제어 합 니 다.nginx 는 ngx 라 는 이름 을 사용 합 니 다.accept_disabled 변 수 는 accept 경쟁 여 부 를 제어 합 니 다.mutex 자물쇠.첫 번 째 코드 에서 ngx 를 계산 합 니 다.accept_disabled 의 값 입 니 다. 이 값 은 nginx 단일 프로 세 스 의 모든 연결 총수 의 8 분 의 1 입 니 다. 남 은 연결 수량 을 빼 고 얻 은 이 ngxaccept_disabled 는 하나의 규칙 이 있 습 니 다. 나머지 연결 수가 전체 연결 수의 8 분 의 1 보다 적 을 때 그 값 은 0 보다 크 고 나머지 연결 수가 작 을 수록 이 값 이 큽 니 다.두 번 째 코드 를 다시 보 세 요.accept_disabled 가 0 이상 이면 accept 를 가 져 오 려 고 시도 하지 않 습 니 다.mutex 자물쇠, 그리고 ngxaccept_disabled 는 1 을 줄 이기 때문에 이 곳 에 실 행 될 때마다 0 보다 작 을 때 까지 1 을 줄 입 니 다.받 지 않 기 acceptmutex 자 물 쇠 는 연결 을 얻 을 기 회 를 주 는 것 과 같 습 니 다. 남 은 연결 이 적 을 수록 ngxaccept_disable 이 클 수록 다른 프로 세 스 가 자 물 쇠 를 가 져 올 기회 가 많 습 니 다.accept 를 하지 않 으 면 자신의 연결 이 제어 되 고 다른 프로 세 스 의 연결 탱크 가 이 용 됩 니 다. 그러면 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 에서 연결 하 는 것 이 무엇 인지 알 면 됩 니 다. 그리고 연결 은 비교적 고 급 스 러 운 용법 에 속 합 니 다. 뒤의 모듈 에서 고급 편 을 개발 하면 연결 과 사건 의 실현 과 사용 을 설명 할 수 있 습 니 다.