이 기사에서는 nginx HTTP 처리 프로세스가 무엇인지 살펴보겠습니다. 도움이 필요한 친구들이 참고할 수 있기를 바랍니다.
server 명령은 일반적으로 하나의 시스템에 여러 가상 서버를 구성하고, 다른 포트 번호를 수신하고, nginx는 사용자 구성을 구문 분석하고 소켓을 생성하는 데 사용됩니다. 모든 포트에서 모니터링을 시작합니다.
nginx 구문 분석 구성 파일은 각 모듈에서 공유되고 처리됩니다. 각 모듈은 ngx_command_t *모듈 구조 ngx_module_t의 명령을 통해 구현되는 구성을 등록하고 처리합니다. , 해당 명령 필드는 다음과 같이 정의됩니다.
struct ngx_command_s { ngx_str_t name; ngx_uint_t type; char *(*set)(ngx_conf_t *cf, ngx_command_t *cmd, void *conf); }; static ngx_command_t ngx_http_commands[] = { { ngx_string("http"), NGX_MAIN_CONF|NGX_CONF_BLOCK|NGX_CONF_NOARGS, ngx_http_block, }, };
static char * ngx_http_block(ngx_conf_t *cf, ngx_command_t *cmd, void *conf) { //解析main配置 //解析server配置 //解析location配置 //初始化HTTP处理流程所需的handler //初始化listening if (ngx_http_optimize_servers(cf, cmcf, cmcf->ports) != NGX_OK) { return NGX_CONF_ERROR; } }
ngx_http_optimize_servers 메소드는 모든 구성 포트를 반복하고 ngx _listening_t 객체를 생성하여 conf->cycle->listening에 추가합니다(후속 작업은 이 배열을 통과하여 소켓을 생성하고 수신합니다). 메소드의 주요 동작은 아래와 같습니다.
ngx_listening_t의 핸들러가 ngx_http_init_connection으로 설정되어 있다는 점에 유의하세요. 소켓 연결 요청이 수신되면 이 핸들러가 호출됩니다.
그럼 모니터링은 언제 시작되나요? 글로벌 검색어 순환->청취를 만나보실 수 있습니다. 기본 메서드는 수신 시작(ngx_open_listening_sockets)을 포함하여 대부분의 서버 초기화 작업을 완료하는 ngx_init_cycle을 호출합니다.
nginx가 epoll을 사용하여 모든 소켓 이벤트를 처리한다고 가정하면 청취 이벤트는 언제 epoll에 추가됩니까? 글로벌 검색어 순환->청취를 만나보실 수 있습니다. ngx_event_core_module 모듈은 이벤트 처리의 핵심 모듈로, 이 모듈을 초기화하면 ngx_event_process_init 함수가 실행되며, 여기서 청취 이벤트가 epoll에 추가됩니다.
static ngx_int_t ngx_event_process_init(ngx_cycle_t *cycle) { ls = cycle->listening.elts; for (i = 0; i listening.nelts; i++) { //设置读事件处理handler rev->handler = ngx_event_accept; ngx_add_event(rev, NGX_READ_EVENT, 0); } }
클라이언트 소켓 연결 요청 이벤트를 수신하기 위한 처리 함수는 ngx_event_accept입니다.
2. HTTP 요청 분석
worker_connections 명령은 연결 풀의 최대 연결 수를 구성하는 데 사용됩니다. 이는 이벤트 명령 블록에서 구성되고 ngx_event_core_module에 의해 구문 분석됩니다.
vents { use epoll; worker_connections 60000; }
nginx를 HTTP 서버로 사용하는 경우 최대 클라이언트 수는 maxClient=worker_processes
worker_connections/2입니다. nginx를 역방향 프록시 서버로 사용하는 경우 최대 클라이언트 수는 maxClient=worker_processesworker_connections/4입니다. 해당 Worker_processes는 사용자가 구성한 작업자 프로세스 수입니다. ngx_connection_t 구조는 다음과 같이 정의됩니다.
struct ngx_connection_s { //空闲连接池中,data指向下一个连接,形成链表;取出来使用时,data指向请求结构体ngx_http_request_s void *data; //读写事件结构体,两个关键字段:handler处理函数、timer定时器 ngx_event_t *read; ngx_event_t *write; ngx_socket_t fd; //socket fd ngx_recv_pt recv; //socket接收数据函数指针 ngx_send_pt send; //socket发送数据函数指针 ngx_buf_t *buffer; //输入缓冲区 struct sockaddr *sockaddr; //客户端地址 socklen_t socklen; ngx_listening_t *listening; //监听的ngx_listening_t对象 struct sockaddr *local_sockaddr; //本地地址 socklen_t local_socklen; ………… }
ngx_http_request_t 구조는 전체 HTTP 요청 처리 프로세스에 필요한 모든 정보를 저장합니다. 다음은 간략한 설명입니다.
struct ngx_http_request_s { ngx_connection_t *connection; //读写事件处理handler ngx_http_event_handler_pt read_event_handler; ngx_http_event_handler_pt write_event_handler; //请求头缓冲区 ngx_buf_t *header_in; //解析后的请求头 ngx_http_headers_in_t headers_in; //请求体结构体 ngx_http_request_body_t *request_body; //请求行 ngx_str_t request_line; //解析后请求行若干字段 ngx_uint_t method; ngx_uint_t http_version; ngx_str_t uri; ngx_str_t args; ………… }
요청 라인 및 요청 본문입니다. 구문 분석은 비교적 간단합니다. 여기서는 요청 헤더 구문 분석에 중점을 둡니다. 구문 분석된 요청 헤더 정보는 ngx_http_headers_in_t 구조에 저장됩니다.
모든 HTTP 헤더는 ngx_http_request.c 파일에 정의되어 있으며 ngx_http_headers_in 배열에 저장됩니다. 배열의 각 요소는 주로 헤더 이름과 구문 분석된 헤더 필드가 ngx_http_headers_in_t에 저장되는 ngx_http_header_t 구조입니다. 헤더를 파싱하기 위한 오프셋, 처리 기능입니다.
ngx_http_header_t ngx_http_headers_in[] = { { ngx_string("Host"), offsetof(ngx_http_headers_in_t, host), ngx_http_process_host }, { ngx_string("Connection"), offsetof(ngx_http_headers_in_t, connection), ngx_http_process_connection }, ………… } typedef struct { ngx_str_t name; ngx_uint_t offset; ngx_http_header_handler_pt handler; } ngx_http_header_t;
요청 헤더를 파싱할 때 ngx_http_headers_in 배열에서 요청 헤더 ngx_http_header_t 객체를 검색하고 처리 함수 핸들러를 호출하여 r->headers_in의 해당 필드에 저장합니다. Connection 헤더를 구문 분석하는 경우 ngx_http_process_connection은 다음과 같이 구현됩니다.
static ngx_int_t ngx_http_process_connection(ngx_http_request_t *r, ngx_table_elt_t *h, ngx_uint_t offset) { if (ngx_strcasestrn(h->value.data, "close", 5 - 1)) { r->headers_in.connection_type = NGX_HTTP_CONNECTION_CLOSE; } else if (ngx_strcasestrn(h->value.data, "keep-alive", 10 - 1)) { r->headers_in.connection_type = NGX_HTTP_CONNECTION_KEEP_ALIVE; } return NGX_OK; }
입력 매개변수 오프셋은 여기서 아무런 영향을 미치지 않습니다. 두 번째 입력 매개변수 ngx_table_elt_t는 현재 요청 헤더의 키-값 쌍 정보를 저장합니다.
typedef struct { ngx_uint_t hash; //请求头key的hash值 ngx_str_t key; ngx_str_t value; u_char *lowcase_key; //请求头key转为小写字符串(可以看到HTTP请求头解析时key不区分大小写) } ngx_table_elt_t;
또 다른 문제를 생각해 보세요. ngx_http_headers_in 배열에서 요청 헤더에 해당하는 ngx_http_header_t 객체를 검색할 때, 각 요소는 문자로 코딩되어야 합니다. 문자열 비교는 비효율적입니다. 따라서 nginx는 ngx_http_headers_in 배열을 해시 테이블로 변환합니다. ngx_http_init_headers_in_hash 메소드는 변환된 해시 테이블을 cmcf-에 저장합니다. >headers_in_hash 필드입니다.
第1节提到,在创建socket启动监听时,会添加可读事件到epoll,事件处理函数为ngx_event_accept,用于接收socket连接,分配connection连接,并调用ngx_listening_t对象的处理函数(ngx_http_init_connection)。
void ngx_event_accept(ngx_event_t *ev) { s = accept4(lc->fd, (struct sockaddr *) sa, &socklen, SOCK_NONBLOCK); //客户端socket连接成功时,都需要分配connection连接,如果分配失败则会直接关闭此socket。 //而每个worker进程连接池的最大连接数目是固定的,当不存在空闲连接时,此worker进程accept的所有socket都会被拒绝; //多个worker进程通过竞争执行epoll_wait;而当ngx_accept_disabled大于0时,会直接放弃此次竞争,同时ngx_accept_disabled减1。 //以此实现,当worker进程的空闲连接过少时,减少其竞争epoll_wait次数 ngx_accept_disabled = ngx_cycle->connection_n / 8 - ngx_cycle->free_connection_n; c = ngx_get_connection(s, ev->log); ls->handler(c); }
socket连接成功后,nginx会等待客户端发送HTTP请求,默认会有60秒的超时时间,即60秒内没有接收到客户端请求时,断开此连接,打印错误日志。函数ngx_http_init_connection用于设置读事件处理函数,以及超时定时器。
void ngx_http_init_connection(ngx_connection_t *c) { c->read = ngx_http_wait_request_handler; c->write->handler = ngx_http_empty_handler; ngx_add_timer(rev, c->listening->post_accept_timeout); }
全局搜索post_accept_timeout字段,可以查找到设置此超时时间的配置指令,client_header_timeout,其可以在http、server指令块中配置。
函数ngx_http_wait_request_handler为解析HTTP请求的入口函数,实现如下:
static void ngx_http_wait_request_handler(ngx_event_t *rev) { //读事件已经超时 if (rev->timedout) { ngx_log_error(NGX_LOG_INFO, c->log, NGX_ETIMEDOUT, "client timed out"); ngx_http_close_connection(c); return; } size = cscf->client_header_buffer_size; //client_header_buffer_size指令用于配置接收请求头缓冲区大小 b = c->buffer; n = c->recv(c, b->last, size); //创建请求对象ngx_http_request_t,HTTP请求整个处理过程都有用; c->data = ngx_http_create_request(c); rev->handler = ngx_http_process_request_line; //设置读事件处理函数(此次请求行可能没有读取完) ngx_http_process_request_line(rev); }
函数ngx_http_create_request创建并初始化ngx_http_request_t对象,注意这赋值语句r->header_in =c->buffer。
解析请求行与请求头的代码较为繁琐,终点在于读取socket数据,解析字符串,这里不做详述。HTTP请求解析过程主要函数调用如下图所示:
注意,解析完成请求行与请求头,nginx就开始处理HTTP请求,并没有等到解析完请求体再处理。处理请求入口为ngx_http_process_request。
nginx将HTTP请求处理流程分为11个阶段,绝大多数HTTP模块都会将自己的handler添加到某个阶段(将handler添加到全局唯一的数组phases中),注意其中有4个阶段不能添加自定义handler,nginx处理HTTP请求时会挨个调用每个阶段的handler;
typedef enum { NGX_HTTP_POST_READ_PHASE = 0, //第一个阶段,目前只有realip模块会注册handler,但是该模块默认不会运行(nginx作为代理服务器时有用,后端以此获取客户端原始ip) NGX_HTTP_SERVER_REWRITE_PHASE, //server块中配置了rewrite指令,重写url NGX_HTTP_FIND_CONFIG_PHASE, //查找匹配的location配置;不能自定义handler; NGX_HTTP_REWRITE_PHASE, //location块中配置了rewrite指令,重写url NGX_HTTP_POST_REWRITE_PHASE, //检查是否发生了url重写,如果有,重新回到FIND_CONFIG阶段;不能自定义handler; NGX_HTTP_PREACCESS_PHASE, //访问控制,比如限流模块会注册handler到此阶段 NGX_HTTP_ACCESS_PHASE, //访问权限控制,比如基于ip黑白名单的权限控制,基于用户名密码的权限控制等 NGX_HTTP_POST_ACCESS_PHASE, //根据访问权限控制阶段做相应处理;不能自定义handler; NGX_HTTP_TRY_FILES_PHASE, //只有配置了try_files指令,才会有此阶段;不能自定义handler; NGX_HTTP_CONTENT_PHASE, //内容产生阶段,返回响应给客户端 NGX_HTTP_LOG_PHASE //日志记录 } ngx_http_phases;
nginx使用结构体ngx_module_s表示一个模块,其中字段ctx,是一个指向模块上下文结构体的指针(上下文结构体的字段都是一些函数指针);nginx的HTTP模块上下文结构体大多都有字段postconfiguration,负责注册本模块的handler到某个处理阶段。11个阶段在解析完成http配置块指令后初始化。
static char * ngx_http_block(ngx_conf_t *cf, ngx_command_t *cmd, void *conf) { //解析http配置块 //初始化11个阶段的phases数组,注意多个模块可能注册到同一个阶段,因此phases是一个二维数组 if (ngx_http_init_phases(cf, cmcf) != NGX_OK) { return NGX_CONF_ERROR; } //遍历索引HTTP模块,注册handler for (m = 0; ngx_modules[m]; m++) { if (ngx_modules[m]->type != NGX_HTTP_MODULE) { continue; } module = ngx_modules[m]->ctx; if (module->postconfiguration) { if (module->postconfiguration(cf) != NGX_OK) { return NGX_CONF_ERROR; } } } //将二维数组转换为一维数组,从而遍历执行数组所有handler if (ngx_http_init_phase_handlers(cf, cmcf) != NGX_OK) { return NGX_CONF_ERROR; } }
以限流模块ngx_http_limit_req_module模块为例,postconfiguration方法简单实现如下:
static ngx_int_t ngx_http_limit_req_init(ngx_conf_t *cf) { h = ngx_array_push(&cmcf->phases[NGX_HTTP_PREACCESS_PHASE].handlers); *h = ngx_http_limit_req_handler; //ngx_http_limit_req_module模块的限流方法;nginx处理HTTP请求时,都会调用此方法判断应该继续执行还是拒绝请求 return NGX_OK; }
GDB调试,断点到ngx_http_block方法执行所有HTTP模块注册handler之后,打印phases数组
p cmcf->phases[*].handlers p *(ngx_http_handler_pt*)cmcf->phases[*].handlers.elts
11个阶段注册的handler如下图所示:
上面提到HTTP的11个处理阶段handler存储在phases数组,但由于多个模块可能注册handler到同一个阶段,使得phases是一个二维数组,因此需要转换为一维数组,转换后存储在cmcf->phase_engine字段,phase_engine的类型为ngx_http_phase_engine_t,定义如下:
typedef struct { ngx_http_phase_handler_t *handlers; //一维数组,存储所有handler ngx_uint_t server_rewrite_index; //记录NGX_HTTP_SERVER_REWRITE_PHASE阶段handler的索引值 ngx_uint_t location_rewrite_index; //记录NGX_HTTP_REWRITE_PHASE阶段handler的索引值 } ngx_http_phase_engine_t; struct ngx_http_phase_handler_t { ngx_http_phase_handler_pt checker; //执行handler之前的校验函数 ngx_http_handler_pt handler; ngx_uint_t next; //下一个待执行handler的索引(通过next实现handler跳转执行) }; //cheker函数指针类型定义 typedef ngx_int_t (*ngx_http_phase_handler_pt)(ngx_http_request_t *r, ngx_http_phase_handler_t *ph); //handler函数指针类型定义 typedef ngx_int_t (*ngx_http_handler_pt)(ngx_http_request_t *r);
数组转换函数ngx_http_init_phase_handlers实现如下:
static ngx_int_t ngx_http_init_phase_handlers(ngx_conf_t *cf, ngx_http_core_main_conf_t *cmcf) { use_rewrite = cmcf->phases[NGX_HTTP_REWRITE_PHASE].handlers.nelts ? 1 : 0; use_access = cmcf->phases[NGX_HTTP_ACCESS_PHASE].handlers.nelts ? 1 : 0; n = use_rewrite + use_access + cmcf->try_files + 1 /* find config phase */; //至少有4个阶段,这4个阶段是上面说的不能注册handler的4个阶段 //计算handler数目,分配空间 for (i = 0; i phases[i].handlers.nelts; } ph = ngx_pcalloc(cf->pool, n * sizeof(ngx_http_phase_handler_t) + sizeof(void *)); //遍历二维数组 for (i = 0; i phases[i].handlers.elts; switch (i) { case NGX_HTTP_SERVER_REWRITE_PHASE: if (cmcf->phase_engine.server_rewrite_index == (ngx_uint_t) -1) { cmcf->phase_engine.server_rewrite_index = n; //记录NGX_HTTP_SERVER_REWRITE_PHASE阶段handler的索引值 } checker = ngx_http_core_rewrite_phase; break; case NGX_HTTP_FIND_CONFIG_PHASE: find_config_index = n; //记录NGX_HTTP_FIND_CONFIG_PHASE阶段的索引,NGX_HTTP_POST_REWRITE_PHASE阶段可能会跳转回此阶段 ph->checker = ngx_http_core_find_config_phase; n++; ph++; continue; //进入下一个阶段NGX_HTTP_REWRITE_PHASE case NGX_HTTP_REWRITE_PHASE: if (cmcf->phase_engine.location_rewrite_index == (ngx_uint_t) -1) { cmcf->phase_engine.location_rewrite_index = n; //记录NGX_HTTP_REWRITE_PHASE阶段handler的索引值 } checker = ngx_http_core_rewrite_phase; break; case NGX_HTTP_POST_REWRITE_PHASE: if (use_rewrite) { ph->checker = ngx_http_core_post_rewrite_phase; ph->next = find_config_index; n++; ph++; } continue; //进入下一个阶段NGX_HTTP_ACCESS_PHASE case NGX_HTTP_ACCESS_PHASE: checker = ngx_http_core_access_phase; n++; break; case NGX_HTTP_POST_ACCESS_PHASE: if (use_access) { ph->checker = ngx_http_core_post_access_phase; ph->next = n; ph++; } continue; //进入下一个阶段 case NGX_HTTP_TRY_FILES_PHASE: if (cmcf->try_files) { ph->checker = ngx_http_core_try_files_phase; n++; ph++; } continue; case NGX_HTTP_CONTENT_PHASE: checker = ngx_http_core_content_phase; break; default: checker = ngx_http_core_generic_phase; } //n为下一个阶段第一个handler的索引 n += cmcf->phases[i].handlers.nelts; //遍历当前阶段的所有handler for (j = cmcf->phases[i].handlers.nelts - 1; j >=0; j--) { ph->checker = checker; ph->handler = h[j]; ph->next = n; ph++; } } }
GDB打印出转换后的数组如下图所示,第一列是cheker字段,第二列是handler字段,箭头表示next跳转;图中有个返回的箭头,即NGX_HTTP_POST_REWRITE_PHASE阶段可能返回到NGX_HTTP_FIND_CONFIG_PHASE;原因在于只要NGX_HTTP_REWRITE_PHASE阶段产生了url重写,就需要重新查找匹配location。
2.2节提到HTTP请求的处理入口函数是ngx_http_process_request,其主要调用ngx_http_core_run_phases实现11个阶段的执行流程;
ngx_http_core_run_phases遍历预先设置好的cmcf->phase_engine.handlers数组,调用其checker函数,逻辑如下:
void ngx_http_core_run_phases(ngx_http_request_t *r) { ph = cmcf->phase_engine.handlers; //phase_handler初始为0,表示待处理handler的索引;cheker内部会根据ph->next字段修改phase_handler while (ph[r->phase_handler].checker) { rc = ph[r->phase_handler].checker(r, &ph[r->phase_handler]); if (rc == NGX_OK) { return; } } }
checker内部就是调用handler,并设置下一步要执行handler的索引;比如说ngx_http_core_generic_phase实现如下:
ngx_int_t ngx_http_core_generic_phase(ngx_http_request_t *r, ngx_http_phase_handler_t *ph) { ngx_log_debug1(NGX_LOG_DEBUG_HTTP, r->connection->log, 0, "rewrite phase: %ui", r->phase_handler); rc = ph->handler(r); if (rc == NGX_OK) { r->phase_handler = ph->next; return NGX_AGAIN; } }
内容产生阶段NGX_HTTP_CONTENT_PHASE是HTTP请求处理的第10个阶段,一般情况有3个模块注册handler到此阶段:ngx_http_static_module、ngx_http_autoindex_module和ngx_http_index_module。
但是当我们配置了proxy_pass和fastcgi_pass时,情况会有所不同;
使用proxy_pass配置上游时,ngx_http_proxy_module模块会设置其处理函数到配置类conf;使用fastcgi_pass配置时,ngx_http_fastcgi_module会设置其处理函数到配置类conf。例如:
static char * ngx_http_fastcgi_pass(ngx_conf_t *cf, ngx_command_t *cmd, void *conf) { ngx_http_core_loc_conf_t *clcf; clcf = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module); clcf->handler = ngx_http_fastcgi_handler; }
阶段NGX_HTTP_FIND_CONFIG_PHASE查找匹配的location,并获取此ngx_http_core_loc_conf_t对象,将其handler赋值给ngx_http_request_t对象的content_handler字段(内容产生处理函数)。
而在执行内容产生阶段的checker函数时,会执行content_handler指向的函数;查看ngx_http_core_content_phase函数实现(内容产生阶段的checker函数):
ngx_int_t ngx_http_core_content_phase(ngx_http_request_t *r, ngx_http_phase_handler_t *ph) { if (r->content_handler) { //如果请求对象的content_handler字段不为空,则调用 r->write_event_handler = ngx_http_request_empty_handler; ngx_http_finalize_request(r, r->content_handler(r)); return NGX_OK; } ngx_log_debug1(NGX_LOG_DEBUG_HTTP, r->connection->log, 0, "content phase: %ui", r->phase_handler); rc = ph->handler(r); //否则执行内容产生阶段handler }
nginx处理HTTP请求的流程较为复杂,因此本文只是简单提供了一条线索:分析了nginx服务器启动监听的过程,HTTP请求的解析过程,11个阶段的初始化与调用过程。至于HTTP解析处理的详细流程,还需要读者去探索。
위 내용은 nginx의 HTTP 처리 프로세스가 무엇인지 살펴보세요.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!