nginx에서 요청-PHP 튜토리얼-php.cn

이 섹션에서는 nginx에서 http 요청에 대해 설명합니다. nginx의 특정 데이터 구조는 ngx_http_request_t입니다. ngx_http_request_t는 http 요청을 캡슐화한 것입니다. 우리는 http 요청에 요청 라인, 요청 헤더, 요청 본문, 응답 라인, 응답 헤더 및 응답 본문이 포함된다는 것을 알고 있습니다.

http 요청은 일반적인 요청-응답 유형 네트워크 프로토콜이고 http는 파일 프로토콜이므로 요청 라인과 요청 헤더를 분석하고 응답 라인과 응답 헤더를 한 줄씩 출력하는 경우가 많습니다. 와 함께. 우리가 직접 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 필드에 저장됩니다. . headers_in은 연결된 목록 구조이므로 모든 요청 헤더를 저장합니다. 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_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가 전체 요청 헤더를 버퍼에 넣는다는 것입니다. 이 버퍼의 크기는 사용자의 요청 헤더가 너무 커서 이 버퍼에 맞지 않을 경우 구성 항목을 통해 설정됩니다. 그러면 nginx는 요청 헤더를 보관하기 위해 더 큰 새 버퍼를 재할당합니다. 이 큰 버퍼는 Large_client_header_buffers를 통해 설정할 수 있습니다. 예를 들어 4 8k 구성은 4개의 8k 버퍼를 사용할 수 있음을 의미합니다. 요청 라인이나 헤더의 무결성을 유지하려면 전체 요청 라인이나 헤더를 연속 메모리에 배치해야 합니다. 따라서 전체 요청 라인이나 헤더는 하나의 버퍼에만 저장됩니다. 이렇게 하면 요청 라인이 버퍼 크기보다 크면 414 오류가 반환되고, 요청 헤더 크기가 버퍼 크기보다 크면 400 오류가 반환됩니다. 애플리케이션 시나리오에서 이러한 매개변수의 값과 nginx의 실제 사례를 이해한 후 프로그램을 최적화하기 위해 실제 필요에 따라 이러한 매개변수를 조정해야 합니다.

처리 흐름도: