nginx 요청을 처리하는 방법은 무엇입니까?

오늘은 요청에 대해 이야기하겠습니다. Nginx에서는 http 요청을 참조합니다. Nginx의 특정 데이터 구조는 ngx_http_request_t입니다. ngx_http_request_t는 http 요청을 캡슐화한 것입니다. 우리는 http 요청에 요청 라인, 요청 헤더, 요청 본문, 응답 라인, 응답 헤더 및 응답 본문이 포함된다는 것을 알고 있습니다.

http 요청은 일반적인 요청-응답 유형의 네트워크 프로토콜이고 http는 텍스트 프로토콜이므로 요청 라인과 요청 헤더를 분석하고 응답 라인과 응답 헤더를 출력하며 종종 한 줄씩 처리합니다. (추천 학습:nginx 사용)

http 서버를 직접 작성하면 일반적으로 연결이 설정된 후 클라이언트가 요청을 보냅니다. 그런 다음 데이터 라인을 읽고 요청 라인에 포함된 메서드, uri 및 http_version 정보를 분석합니다.

그런 다음 요청 헤더를 한 줄씩 처리하고 요청 방법과 요청 헤더 정보를 기반으로 요청 본문이 있는지 여부와 요청 본문의 길이를 확인한 다음 요청 본문을 읽습니다.

요청을 받은 후 요청을 처리하여 출력해야 하는 데이터를 생성한 다음 응답 라인, 응답 헤더 및 응답 본문을 생성합니다.

클라이언트에게 응답을 보낸 후 완전한 요청이 처리됩니다. 물론 이것은 가장 간단한 웹서버 처리 방법이지만 Nginx도 이 작업을 수행합니다. 예를 들어 요청 헤더를 읽으면 요청 처리가 시작됩니다. Nginx는 ngx_http_request_t를 사용하여 요청 구문 분석 및 응답 출력과 관련된 데이터를 저장합니다.

그 다음에는 Nginx가 완전한 요청을 처리하는 방법에 대해 간략하게 이야기하겠습니다.Nginx의 경우 요청은 ngx_http_init_request에서 시작됩니다. 이 함수에서는 읽기 이벤트가 ngx_http_process_request_line으로 설정됩니다. 즉, 다음 네트워크 이벤트는 ngx_http_process_request_line에 의해 실행됩니다.

ngx_http_process_request_line이라는 함수명을 보면 앞서 언급한 것처럼 요청 라인을 처리하는 일이 가장 먼저 이루어지는 것을 알 수 있습니다.

ngx_http_read_request_header를 통해 요청 데이터를 읽습니다. 그런 다음 ngx_http_parse_request_line 함수가 호출되어 요청 라인을 구문 분석합니다. 효율성을 높이기 위해 Nginx는 상태 머신을 사용하여 메서드를 비교할 때 문자열 비교를 직접 사용하지 않고 4개의 문자를 정수로 변환한 후 한 번 비교하여 CPU 명령 수를 줄입니다. . 이것은 이전에 말한 적이 있습니다.

요청 라인에 요청 메서드, URI, 버전이 포함되어 있다는 것은 많은 사람들이 알지만, 호스트도 포함될 수 있다는 사실은 모릅니다. 예를 들어 GET http://www.taobao.com/uri HTTP/1.0과 같은 요청도 합법적이며 호스트는 www.taobao.com입니다. 이때 Nginx는 요청 헤더의 호스트 필드를 무시합니다. 요청 라인에서 이것을 사용하여 가상 호스트를 찾으십시오.

또한 http0.9 버전의 경우 요청 헤더가 지원되지 않으므로 여기서 특별한 처리가 필요합니다. 따라서 나중에 요청 헤더를 구문 분석할 때 프로토콜 버전은 1.0 또는 1.1이 됩니다. 전체 요청 라인에서 파싱된 매개변수는 ngx_http_request_t 구조에 저장됩니다.

요청 라인을 구문 분석한 후 Nginx는 읽기 이벤트의 핸들러를 ngx_http_process_request_headers로 설정하고 후속 요청은 ngx_http_process_request_headers에서 읽고 구문 분석합니다.

ngx_http_process_request_headers 함수는 요청 헤더를 읽는 데 사용됩니다. 요청 헤더를 읽으려면 ngx_http_read_request_header를 호출하고, 요청 헤더 라인을 구문 분석하려면 ngx_http_parse_header_line을 호출하세요. ngx_http_request_t.headers_in은 모든 요청 헤더를 저장하는 A 연결 목록 구조입니다.

HTTP의 일부 요청에는 특별한 처리가 필요합니다. 이러한 요청 헤더와 요청 처리 기능은 ngx_http_headers_in이라는 매핑 테이블에 저장됩니다. 요청 헤더가 구문 분석되면 먼저 검색됩니다. 이 해시 테이블에서 발견되면 해당 처리 함수가 호출되어 요청 헤더를 처리합니다. 예를 들어 Host 헤더의 처리 기능은 ngx_http_process_host입니다.

Nginx가 두 개의 캐리지 리턴과 라인 피드를 구문 분석하면 요청 헤더의 끝을 나타내며 요청을 처리하기 위해 ngx_http_process_request가 호출됩니다.

ngx_http_process_request는 현재 연결의 읽기 및 쓰기 이벤트 핸들러 기능을 ngx_http_request_handler로 설정한 다음 ngx_http_handler를 호출하여 실제로 완전한 http 요청 처리를 시작합니다.

이상할 수 있습니다. 읽기 및 쓰기 이벤트 처리 함수는 모두 ngx_http_request_handler입니다. 실제로 이 함수에서는 현재 이벤트가 읽기 이벤트인지 쓰기 이벤트인지에 따라 ngx_http_request_t의 read_event_handler 또는 write_event_handler가 각각 호출됩니다.

이번에 요청 헤더를 읽었으므로 앞서 언급했듯이 Nginx는 요청 본문을 먼저 읽지 않으므로 여기에서는 read_event_handler를 ngx_http_block_reading으로 설정합니다. 즉, 데이터를 읽지 않습니다.

지금 언급한 것처럼 데이터 처리의 실제 시작은 ngx_http_handler 함수에 있습니다. 이 함수는 write_event_handler를 ngx_http_core_run_phases로 설정하고 ngx_http_core_run_phases 함수를 실행합니다.

ngx_http_core_run_phases 이 함수는 다단계 요청 처리를 수행합니다. Nginx는 http 요청 처리를 여러 단계로 나눈 다음 이 함수는 이러한 단계를 실행하여 데이터를 생성합니다.

ngx_http_core_run_phases는 결국 데이터를 생성하기 때문에 쓰기 이벤트 처리 기능이 ngx_http_core_run_phases로 설정된 이유를 쉽게 이해할 수 있습니다.

여기서는 함수의 호출 로직을 간략하게 설명합니다. 생성된 응답 헤더는 ngx_http_request_t의 headers_out에 배치됩니다. 요청 처리 과정을 살펴보세요. Nginx의 다양한 단계에서는 요청을 처리하고 마지막으로 필터를 호출하여 데이터를 필터링하고 잘린 전송, gzip 압축 등과 같은 데이터를 처리합니다.

여기의 필터에는 응답 헤더 또는 응답 본문을 처리하는 헤더 필터와 본문 필터가 포함됩니다. 필터는 헤더 필터와 바디 필터가 각각 있는 연결 리스트 구조입니다. 헤더 필터의 모든 필터가 먼저 실행되고 바디 필터의 모든 필터가 실행됩니다.

헤더 필터의 마지막 필터, 즉 ngx_http_header_filter 이 필터는 모든 응답 헤더를 순회하며 출력해야 하는 최종 응답 헤더는 연속 메모리에 있으며 출력을 위해 ngx_http_write_filter를 호출합니다.

ngx_http_write_filter는 본문 필터의 마지막 항목이므로 Nginx의 첫 번째 본문 정보는 일련의 본문 필터를 거친 후 최종적으로 출력을 위해 ngx_http_write_filter를 호출합니다(설명할 그림이 있습니다).

여기서 Nginx는 전체 요청 헤더를 버퍼에 넣습니다. 이 버퍼의 크기는 구성 항목 client_header_buffer_size를 통해 설정됩니다. 사용자의 요청 헤더가 너무 커서 버퍼가 맞지 않으면 Nginx가 다시 시작됩니다. 요청 헤더를 보관할 새로운 더 큰 버퍼를 할당합니다. 이 큰 버퍼는 Large_client_header_buffers를 통해 설정할 수 있습니다. 예를 들어 48k를 구성하는 것은 4개의 8k 버퍼를 사용할 수 있음을 의미합니다.

요청 라인 또는 요청 헤더의 무결성을 유지하려면 전체 요청 라인 또는 요청 헤더가 연속 메모리에 배치되어야 합니다. 따라서 전체 요청 라인 또는 요청 헤더는 하나의 버퍼에만 저장됩니다. . 안에.

이런 방식으로 요청 라인이 버퍼 크기보다 크면 414 오류가 반환됩니다. 요청 헤더 크기가 버퍼 크기보다 크면 400 오류가 반환됩니다. 애플리케이션 시나리오에서 이러한 매개변수의 값과 Nginx의 실제 사례를 이해한 후 프로그램을 최적화하기 위해 실제 필요에 따라 이러한 매개변수를 조정해야 합니다.

처리 흐름도:

위는 Nginx의 http 요청 수명 주기입니다.

위 내용은 nginx 요청을 처리하는 방법은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!