Nginx 가 역방향 에이전트 (proxy) 일 때의 buffer 명령

Nginx 가 역방향 에이전트 (proxy) 일 때의 buffer 명령
이 는 Nginx 가 반 대 했 을 때의 행동 에 대한 해석 을 설명 할 것 이다.
Nginx 가 요청 한 행동 을 처리 합 니 다.
Nginx 는 설정 한 proxy_pass 만 무조건 실행 ngx_http_read_client_request_body 클 라 이언 트 의 body 를 읽 으 려 고 시도 합 니 다.
body 를 휴대 하지 않 기 를 요청 합 니 다.
흔히 볼 수 있 는 방법.이때 GET/HEAD 에서 Content - length 를 판단 하고 없 거나 값 이 0 이면 백 엔 드 와 연결 하 는 것 ngx_http_read_client_request_body 을 직접 실행 합 니 다.
바디 휴대 요청
POST 방법 에서 흔히 볼 수 있다.이때 Nginx 는 읽 기 ngx_http_upstream_init (즉 읽 기 header 를 마 쳤 을 때 upstream 에 바로 연결 되 지 않 고 client 의 완전한 \r
\r
을 읽 은 후에 야 계속 실행 body 합 니 다. 즉, 이때 에 야 upstream 과 연결 한 다음 에 데 이 터 를 보 냅 니 다.
요청 관련 명령:

proxy_request_buffering off;

Nginx 가 client ngx_http_upstream_init 를 제때에 읽 지 못 했 을 때 upstream 에 바로 연결 할 수 있 습 니 다.다시 말 하면 Nginx 는 client 의 Header 를 받 고 upstream 에 연결 하여 보 낸 것 이다.또한 일부 바디 가 오 면 바로 upstream, 이른바 스 트 리밍 으로 전송 된다.

proxy_pass_request_body off;

요청 한 것 body 을 버 릴 수 있 습 니 다.

client_body_buffer_size 100;

위 에서 말 했 듯 이 Nginx 는 기본적으로 캐 시 요청 body 을 합 니 다. 캐 시 는 어디 에 있 습 니까?처음에는 메모리 에 저 장 됩 니 다. 그러나 현재 캐 시 된 body 이 body 지정 한 크기 보다 크 면 현재 메모리 에 있 는 client_body_buffer_size 을 파일 에 저장 합 니 다.Nginx 가 저장 body 에 대한 데이터 구 조 는 body:

typedef struct {
    ngx_temp_file_t                  *temp_file;/*       */
    ngx_chain_t                      *bufs;/*   bufs,filter      */
    ngx_buf_t                        *buf;/*   client_body_buffer_size      read_buf*/
    off_t                             rest;/**            ， content-length - alreadyread*/
    off_t                             received;
    ngx_chain_t                      *free;
    ngx_chain_t                      *busy;
    ngx_http_chunked_t               *chunked;
    ngx_http_client_body_handler_pt   post_handler;/*      ，        */
} ngx_http_request_body_t;

Nginx 응답 처리
응답
header 는 즉시 client 에 전송 되 고 자신 과 upstream 의 연결 을 끝 냅 니 다. 이것 은 할 말 이 없습니다.
응답 휴대용 바디
기본적으로 요청 과 유사 하 게 Nginx 는 ngx_http_request_body_t 와 header 캐 시 를 완전 부 body 로 받 은 후에 야 함께 응답 을 client 에 전달 합 니 다.
관련 명령 에 응답:

proxy_buffer_size 8k;

Nginx 이 크기 로 read 신청buf, 즉 크기 는 upstream header 의 최대 길 이 를 지정 합 니 다. 응답 헤드 가 이 길 이 를 초과 하면 Nginx 는 body 오 류 를 보고 하고 client 는 502 를 받 습 니 다.

postpone_output 0;

Nginx 는 업무 절차 에서 즉시 send 를 호출 하여 응답 upstream sent too big header 을 보 냅 니 다.그러나 send 의 바 텀 구현: header 에서 ngx_http_write_filter 기본 값 이 있 기 때문에 postpone_output 전송 지연 (이 한도 값 을 초과 하지 않 는 데 이 터 는 캐 시 됩 니 다). header 표지 가 있 는 buf 가 나타 날 때 까지 모든 응답 을 한꺼번에 보 냅 니 다 (예 를 들 어 body 의 마지막 부분 데이터 last 보다 위).last 의 값 은 모든 응답 데이터 에 유효 합 니 다. postpone_output 와 header 를 포함 합 니 다. 그러나 Nginx 업무 절차 에서 body 를 처리 할 때 기본 값 은 바로 send 입 니 다.따라서 설정 body 만 0 으로 하고 응답 postpone_output 을 즉시 client 에 보 냅 니 다. header 을 어떻게 처리 하 는 지 아래 명령 을 보 세 요.

proxy_buffering off;

이 명령 은 Nginx 가 응답 body 에 캐 시 하지 않 고 upstream 데 이 터 를 받 은 후 즉시 send 를 클 라 이언 트 에 보 내 는 응답 스 트림 전송 입 니 다.
그렇다면 기본 적 인 상황 에서 body 열 려 있 습 니 다. body 에 많이 호응 하면 어떻게 합 니까?

proxy_buffers           256 8k;

상기 두 명령 은 proxy_buffering 열 려 있 을 때 만 유효 합 니 다 (기본 값 은 열 려 있 습 니 다). 그 역할 은 캐 시 크기 를 설정 하 는 것 입 니 다.구체 적 으로 256 개의 길이 가 8k 크기 의 read 를 개척 한 다 는 뜻 이다.buf 는 저장 proxy_buffering 에 사 용 됩 니 다. 물론 연결 이 초기 화 될 때 256 개 를 개척 하 는 것 이 아니 라 현재 buf 가 응답 body 에 저장 되 지 않 을 때 만 새로 신청 할 수 있 습 니 다. 최대 256 개의 buf 를 신청 할 수 있 습 니 다.
위의 논 리 를 자세히 읽 으 면 기본적으로 2 차원 으로 나 누 어 read 를 설정 할 수 있 습 니 다.buf, Nginx 설정 자 를 더욱 유연 하 게 하고 자신의 업무 응답 크기 의 분포 에 따라 이 두 개의 값 을 설정 하여 메모 리 를 절약 하고 성능 을 제시 합 니 다.