nginx系列--（三）--http
本文主要介绍http模块accept read流程，！！！请求对应的响应直接在read流程里就会返回给用户，而不需要通过write事件，和redis一样，基本都不通过eventloop write事件来发送响应给客户端，除非一次发送不完，nginx write事件则只会写邮件的时候ssl ocsp的时候才会触发，略，
！！！http模块和stream模块的实现原理基本一样，都是通过handler来执行差异化操作，而主eventloop流程用的都是同一套代码
下拉刷新：间歇性奖励
无线上划：人类在没有标识的情况下很容易过量
#访问localhost:10086/hello返回的是nginx/html/hello/index.html
location /hello {
root html; #root表示设置根目录，然后会自动访问hello目录，即要求location 路径对应的目录要一致
index index.html index.htm;
}
#访问localhost:10086/hello返回的是nginx/html/index.html
location /hello {
alias html; #alias表示直接用这个目录
index index.html index.htm;
}
！！！笔记：源码流程第一个断点最好不要用入口点，而是要打在执行流程中，比如你要debug http处理请求流程，那么就不要把第一个断点打在请求分发的地方，因为这个dispatch点是可以接受各种不同类型的请求，后续会因为请求会走不同的调用路线，所以我们最好打在具体流程中，即我们要debughttp流程，那么就把断点打在http_handler中，而不是打在调用httphandler的地方，因为调用者肯定是调用handler，而handler是一个指针，不同请求，handler值不同，所以应该直接打在http_handler中，然后有http_handler再网上。可以在handler中打断点，但这样需要step_into往下走才知道在哪里会走到handler，在哪跳转到http_handler，所以直接在http_handler中打断点然后往上回溯要比handler中打断点，然后一行一行step into要简单的多。反正断点的核心就是关键路径上多打几个断点。
！！！注意：nginx是多进程，需要特殊设置，否则因为处理都是在子进程中而导致我们打的断点不起作用
！！！nginx是每个worker都可以同时处理监听套接字以及客户端套接字，nginx并没有分配一个专门的进程来处理监听套接字，而是每个worker在每一轮事件循环开始前都竞争一次accept_mutex，！！！每一轮都竞争accept_mutex肯定会降低效率的，不过如果启用了linux epoll的epollexclusive，就可以不开启accept_mutex，因为此时只会有一个进程的epoll中的listen fd会触发读事件，这是linux操作系统提供的，此时则不用每次都竞争accept_mutex锁，也就是说accept_mutex锁此时会失效，不过nginx肯定会对这个进行一个封装。
nginx可以关闭后台模式；nginx也可以以单进程多线程的方式运行
笔记：nginx对请求的处理流程是一样的，eventloop_for_死循环+epoll_wait+for_所有fd+handler，然后handler是一个指针，也就是说流程是一样的，只是调用的handler不同而已，注意，handler不止一个，他用一个数组来存，并按顺序调用，因为这个handler是注册制的，就是说如何处理tcp/udp发来的数据，完全由注册的handler决定，也就是说如果要是nginx支持自定义的x协议，那么流程如下：1：把handler数组册到指定的handler中；2：handler中的数组要有序，因为他是按顺序调用的，所以我们只要按顺序来注册，那么就可以保证请求按我们指定的流程来处理。
笔记：自己读完以后再去网上找文章查看对应的文章
！！！笔记：默认nginx应用层只支持http，所以conf里最外层的http{xxx}就告诉nginx这个块对应的是http模块。默认的nginx传输层支持TCP和udp，所以conf里最外层的stream{xxx}就告诉nginx这个块对应的是tcp/udp，也就是说我们的处理函数接触的是传输层的原始字节流，我们可以选择转发也可以选择自己解析成应用层协议进一步处理。原始字节流的含义取决于我们怎么解析。nginx的http模块就相当于在原始的stream模块之上添加了http字节流解析模块，这个模块可以把字节流解析成http协议，nginx的http模块把这一切都实现了，就无须我们自己实现了。
！！！笔记：nginx的http模块把http协议的处理分成了11个阶段，而stream模块则分成了7个阶段
！！！笔记：nginx 根据conf中的分块名来调用对应的模块。nginx中http模块和stream模块在系统中的名字分别是http和stream，如果把http模块注册的名字改成http_abc，那么conf中对应的http{xx}就要改成http_abc{xx}，否则就会报错找不到对应的模块
！！！笔记（猜测）：如果要nginx支持新的应用层协议，那么就只能自己实现新的xx模块，然后配置文件里就能用xx{yy}来定义了，不过这样如果自己实现的话工作量就打了，要自己来解析配置，就很麻烦了
如果要支持
2：http处理流程
直接百度断点ngx_http_handler+搜索epoll_wait打下断点，一共两个断点，就可以抓住主线
2-1：模块启动和listenfd注册到epoll流程
笔记：流程同stream模块一模一样，已经在stream文章的模块启动部分叙述了，这里不再重复，只是简单记录一下
nginx.main
ngx_cycle.ngx_init_cycle
ngx_conf_file.ngx_conf_parse
for ; ;
......
cmd->set #cmd->set就是各个模块对应的set函数，不同的模块对应不同的函数
#比如stream模块就调用ngx_stream_block，http就用ngx_http_block
#！！！也就是说nginx用函数指针来实现了一种多态的效果
#！！！也就是说可以用同一套代码流程来加载http、stream模块
3: http块，这是最顶层的http 块
ngx_http.ngx_http_block
ngx_conf_file.ngx_conf_parse
......
ngx_http.ngx_http_init_phases
ngx_http.ngx_http_init_phase_handlers
ngx_http.ngx_http_optimize_servers
ngx_http.ngx_http_init_listening
ngx_http.ngx_http_add_listening
ls=ngx_create_listening
ls.handler=ngx_http_init_connection #！！！listenfd对新连接的处理函数设置为ngx_http_init_connection
#！！！stream模块中则设置为ngx_stream_init_connection
#！！！再次强调，ngx通过函数指针来模拟了多态，
#！！！也就是同一套代码可以同时处理httpfd和streamfd
#！！！下面的代码不管是http还是stream，都是同一个处理流程：注册到epollfd
#！！！因为nginx中http和strema模块的不同在于处理函数的不同，而nginx把不同的handler封装在event_t结构体中
#！！！而event_t结构体又包含在connection结构体中，clientfd存在epollfd中的就是connection结构，
#！！！也就是说不管是http还是stream，用的都是connection结构，而他们的区别只有字段值的不同
#！！！正因为如此，所以可以用同一个epollfd来同时处理httpserver-listenfd、streamserver-listenfd
#！！！、httpclientfd、streamclientfd、streamupstreamfd上的读写事件
......
ngx_process_cycle.ngx_master_process_cycle
ngx_process_cycle.ngx_start_worker_processes
......
unistd.fork #fork子进程
......
rev->handler = ngx_event_accept; #！！！设置accept事件的处理函数为ngx_event_accept
#！！！nginx把fd、handler都封装在ngx_event_t结构体中
#！！！然后ngx_event_t结构又封装在connection结构中
#！！！connection结构会作为epoll_events的data字段丢到epollfd中
#！！！封装使得epoll_eventloop流程代码可以通用
#！！！即不论是httpfd事件还是streamfd事件还是listenfd事件
ngx_add_event(rev, NGX_READ_EVENT, NGX_EXCLUSIVE_EVENT) #！！！注册listenfd的read事件到epollfd，并且是exclusive模式
#！！！accept_handler为ngx_event_accept
ee.data.ptr = (void *) ((uintptr_t) c | ev->instance) #data字段为c,c是一个connection对象指针
epoll_ctl(ep, op, c->fd, &ee) #这样我们直接从data取出connection对象
#也就是说connection对象保存了一个连接的所有状态
#redis也是一样的操作，所以epoll类型的应该都是一样的操作
......
2：执行eventloop，略，详情见eventloop源码流程
1-2：http listenfd accept流程
ngx_proces_cycle.ngx_worker_process_cycle #这里是子进程里面的流程
1：！！！初始化eventloop（初始化+注册相关fd到eventloop）
......
ngx_add_event(rev, NGX_READ_EVENT, NGX_EXCLUSIVE_EVENT) #！！！注册listenfd的read事件到epollfd，并且是exclusive模式
......
2：！！！执行eventLoop
for ; ; #死循环，即eventloop,事件循环
ngx_event.ngx_process_events_and_timers #处理事件和定时器
ngx_epoll_module.ngx_epoll_process_events #到此处时已经是epoll_wait返回的fd了，所以直接处理fd就行了
#！！！如果触发了读事件就调用rev->handler（rev=connection->read_events）
#！！！如果触发了写事件就调用wev->handler（wev=connection->write_events）
wev = c->write;
if ((revents & EPOLLOUT) && wev->active)
wev->ready = 1;
wev->handler #accept只注册了read事件，没有注册write事件，所以revents&EPOLLOUT=0
#！！！accept事件对应读事件，所以调用rev->handler
if ((revents & EPOLLIN) && rev->active) :
rev->ready = 1;
ngx_event_accept.ngx_event_accept #不管是http还是stream，listenfd注册流程都是一样的以及accept函数都是一样的
#因为所有的不同都封装在handler中，
#即conection里的read_events/write_events对象的handler中
----------------在此之上的流程和stream accept一模一样----------------------------------------------------
ngx_http_request.ngx_http_init_connection #！！！即ls->handler,nginx通过函数指针来实现同一套代码同时处理http和stream
#笔记：listenfd对应的read events handler为ngx_event_accept
#此处的ls->handler是用来处理新建立的连接的
#比如stream模块中对应的ls->handler就是与upsteam建立连接
#同样的，ngx_http_init_connenction和
#ngx_stream_init_connection的逻辑基本是一样的
#只不过ngx_http_init_connection少了个连接upstream的操作
#笔记：stream_init_connection中设置了clientfd.rev.handler=ngx_stream_session_handler;
#但是在cscf->handler即ngx_stream_proxy_handler中
#会重新设置为ngx_stream_proxy_downstream_handler;
#笔记：clientfd放在session中，然后传递session给这个函数
rev = c->read;
rev->handler = ngx_http_wait_request_handler; #！！！设置http clientfd的read_events_handler
#ngx_http_finalize_request中调用ngx_http_finalize_connection时
#会根据是否开启keepalive选项来决定是否把rev->handler设置为ngx_http_keepalive_handler
#默认是会的，也就是第一次是走wait_request_handler
#但是第二个请求就会走keepalive_handler了
c->write->handler = ngx_http_empty_handler;
ngx_event.ngx_handle_read_event #把clientfd注册到epollfd中
#笔记：http模块中accept时就注册到epollfd中了
#而stream模块则是等到upstream处理第一次write时才会注册到epollfd中
#！！！#define NGX_CLEAR_EVENT EPOLLET 就是说nginx默认是边缘触发
ngx_event_accept.ngx_reorder_accept_events #处理accept公平问题，略
1-3：eventloop过程中，http clientfd对应的读事件处理流程
nginx.main
ngx_process_cycle.ngx_master_process_cycle
......
unistd.fork #fork子进程
......
ngx_proces_cycle.ngx_worker_process_cycle #这里是子进程里面的流程
1：！！！初始化eventloop（初始化+注册相关fd到eventloop）
......
2：！！！执行eventLoop
for ; ; #死循环，即eventloop,事件循环
ngx_event.ngx_process_events_and_timers #处理事件和定时器
ngx_epoll_module.ngx_epoll_process_events
unistd.epoll_wait
#本次处理clientfd read events
ngx_http_request.ngx_http_keepalive_handler #ngx_http_request.ngx_http_wait_request_handler处理新连接，这个处理旧连接
#处理流程很简单，就是一个http协议解析器，先解析请求，然后再调用handler处理请求
#解析过程很简单：先解析请求行，然后解析header，解析完header后调用handler处理请求
#解析的过程中会从conn中取出历史数据，如果不是一个完整行，就标记，等待下一次读取
#直到解析完整个请求。
ngx_recv.ngx_unix_recv #c->rev，这是个函数指针，实际是ngx_unix_recv
#没有数据可读取时就会返回NGX_AGAIN
socket2.recv #调用linux系统调用从网络缓冲区读取数据到nginx内存缓冲区,肯定是for循环+非阻塞读取
if (n == NGX_AGAIN) : #如果是NGX_AGAIN，则会把读事件重新注册到对应的监听fd中
ngx_event.ngx_handle_read_event #把读事件重新注册到对应的监听fd中。因为不同os中支持的模型不同，
#不同模型的处理不同，所以需要这个函数，比如如果是linxu的epoll，
#就是把fd+读事件重新注册到epollfd中，如果已存在就什么也不做
return #这里重新注册读事件后就返回了
ngx_connection.ngx_reusable_connection #暂不清楚
ngx_http_request.ngx_http_process_request_line #！！！rev->handler()，调用handler函数来处理事件
#！！！再次强调，nginx通过函数指针来实现同一套
#！！！eventloop代码同时可以处理http和stream请求
#这里就开始解析http请求，就是状态机，一边读取一边解析
for: #状态机，直到处理完请求或者没数据可读或者出错
if rc == NGX_AGAIN: #不完整的一行，需要继续读取
ngx_http_request.ngx_http_read_request_header #读取
rc=ngx_http_request.ngx_http_parse_request_line #解析请求行，即从字节流中解析出请求行
if rc=NGX_OK:
ngx_http_request.ngx_http_process_request_uri #根据解析出的请求行处理uri
ngx_http_request.ngx_http_set_virtual_server #
ngx_http_request.ngx_http_process_request_headers #解析headers，和解析请求行一样的流程，边读边解析
#即如果rc==NGX_AGAIN就继续读取一行，然后解析
#笔记：他不是一个外置函数(ngx_http_keepalive_handler )，
#然后在这个外置函数里第一步解析请求行，然后第二步解析header
#而是一种尾调用的关系，即是嵌套的，即外置函数调用函数解析请求行，
#然后在请求行解析函数的最后一行调用解析headers的函数，
#然后在解析headers的函数最后一行又调用handler处理函数
#！！！http只需要解析http头部，而data部分则是由handler来处理
#因为数据部分是对用户有意义，而无关于http协议，handler就是来处理具体数据的
ngx_http_request.ngx_http_read_request_header #读取一行
ngx_http_request.ngx_http_parse_header_line #解析一行
if rc == NGX_OK:
continue: #header有多行，所以NGX_OK表示成功解析一行
if rc == NGX_HTTP_PARSE_HEADER_DONE: #NGX_HTTP_PARSE_HEADER_DONE表示请求头解析完了，就要处理请求了
#这里再次说明http解析的过程就是就是一个状态机，就是边读边解析
ngx_http_request.ngx_http_process_request_header #处理全部请求头
ngx_http_request.ngx_http_process_request #处理完请求头后这里处理请求
c->read->handler = ngx_http_request_handler; #nginx_http_request_handler就是
#在收完请求头但是还没有收完整个请求之间起作用
#！！！再次强调，http协议中读完请求头和请求体就可以处理请求了
#！！！不必等到收到body部分，比如get
c->write->handler = ngx_http_request_handler; #ngx_http_request_handler就是根据事件类型来调用对应的event_handler
if (ev->write) {
r->write_event_handler(r);
} else {
r->read_event_handler(r);
}
r->read_event_handler = ngx_http_block_reading; #！！！对于同一个连接上的请求，nginx是顺序处理的，
#处理一个请求nginx只会调用一次ngx_http_process_request
#而nginx在处理完header后就调用ngx_http_process_request了
#如果不重置clientfd的read->handler和write->handler，
#那么如果还没处理完，下一个请求来了
#比如tcp粘包，缓冲区数据为body+下一个request，
#那么就会再次触发clientfd的读取事件，读取到下一个请求
#，然后就会再次调用ngx_http_process_reqeust
#我猜测（是我猜的）：ngx_http_process_reqeust不是无状态的函数
#导致对于同一个连接必须处理完当前请求才能继续处理下一个请求
#为了避免嵌套，所以nginx选择的解决办法是：
#读取到一个完整的请求头即代表开始处理一个请求后
#就会重置读取写入事件的handler，来避免再次调用http_process_request，
#ngx_http_request_handler只是简单地根据事件类型来
#调用对应的event_handler，简单地读取、读取丢弃、或者直接不读取，
#就算读取了也不会解析数据，这样也就不会再次调用http_process_reqeust，
#所以我们设置对应的read_event_handler=block_reading,
#block_reading：如果是边缘触发则本次调用相当于空操作即不读取任何数据
#如果是水平触发，就从epoll中移除clientfd，更简单暴力
#！！！注意：在当前请求的处理过程中也许会重置read_event_handelr
#比如在static_handler中如果不需要请求体（比如get /index.html）
#那么就会重置read_event_handler=ngx_http_discard_request_body，
#就是读取body，然后丢弃body
ngx_http_core_module.ngx_http_handler
if !r->internal: #如果是外部请求，那么就要调用所有handler
r->keepalive=r->headers_in.connection_type #header中会有keepalive的设置
r->phase_handler=0 #handler是一个数组,phase_handler表示当前handler的下表
#phase_handler=0表示从第一个handler开始处理，
#因为handler是一个接一个调用的
else:
r->phase_handler=server_rewrite_index #如果是内部请求(即内部的请求重定向等)则从server_rewrite_index开始
#！！！就是说不必所有请求都走完http处理的所有阶段
ngx_http_core_module.ngx_http_core_run_phases #循环调用phase_handler数组中的所有handler来处理请求
while (ph[r->phase_handler].checker): #checker是对handler的包装,ph是phase_handler数组，
#phase_handler就是数组下标
#handler有好多，不过都是按顺序来的即一个handler对应一个处理步骤
#这个phase_handler数组是在nginx_http_block中填充的，
#默认是11个阶段14个handler
rc = ph[r->phase_handler].checker(r, &ph[r->phase_handler]) #handler处理后会自动给phase_handler+1
#！！！发送响应给client这个功能是放在handler中的
#这里仅仅记录发送静态页面给handler，略去了一大堆其他的handler
/*
* ph表示phase_handler，ph是对handler的一个包装，
* checker负责对handler的处理结果进行善后工作比如更新状态
* 发送响应给client也算作一个handler，所以在handler中处理，handler是一个函数指针
* static_handler专门用来处理静态页面，发送响应的时候也分两步，同时也是尾调用
* 第一步执行filter_chain,对数据进行处理，处理完之后再执行output_chain，
* output_chain内也要执行一个filter_chain，也是尾调用，
* 如果没有设置写延迟，那么最终调用writev来把数据写到发送缓冲区，
* 如果设置了就...暂不清楚
*/
ngx_http_core_module.ngx_http_core_content_phase
#注意：有好几个ngx_http_core_content_phase阶段
#其中一个phase阶段的handler就是ngx_http_static_handler
ngx_http_static_module.ngx_http_static_handler #！！！ph->handler，此处是static_handler，负责处理静态页面
#！！！再次强调：nginx通过函数指针来模拟多态
#！！！更广阔一点：c框架都是用函数指针来实现同一套代码处理不同的事件
#！！！就是说框架的骨架是类型无关的，类型差异都封装在一个变量中
#！！！nginx中就是eventloop骨架是描述符类型无关的(httpfd/listenfd/streamfd)
#！！！这些fd的处理差异都封装在event_t结构，event_t封装在connection结构中
#！！！eventloop骨架与connetion打交道即conn结构封装了不同fd事件处理的差异
...deal something and get result metadata...
r->read_event_handler = ngx_http_discarded_request_body_handler;
ngx_http_output_filter #响应数据元信息处理好了，
#这里就调用output_filter对响应数据进行处理
#output_filter是一个链表，同时也是尾调用，
#所以如果链表很长，那么嵌套就会很深
ngx_http_range_body_filter
ngx_http_copy_filter
ngx_output_chain #outputchain也是一个filter_chain
#负责对要写的数据进行处理
ngx_http_trailers_filter
ngx_http_charset_body_filter
ngx_http_ssi_body_filter
ngx_http_postpone_filter
ngx_http_gzip_body_filter
ngx_http_chunked_body_filter
ngx_http_write_filter
ngx_linux_sendfile_chain
if: #nginx会根据实际情况来决定是sendfile还是writev，因为效率不同
ngx_linux_sendfile
sendfile.sendfile #就是调用linux的sendfile来发送数据
else:
ngx_writev
uio.writev #就是调用ubuntu的writev来把数据写到发送缓冲区
ngx_http_request.ngx_http_finalize_request #各个http模块在执行完某个操作都需要调用这个函数，
#来把请求的引用计数减去1，当引用计数为0时才会真正释放一个请求
#有很多if，这里举两个：NGX_DECLINED和r->buffered
if rc == NGX_DECLINED:
ngx_http_core_module.ngx_http_core_run_phases #如果此时请求所有阶段还没有处理完，
#那么继续执行直到所有阶段都走完
if 请求行和请求头收到了但是请求体还没收到&&请求体不可丢弃: #收完请求头后就会设置
#read->handler=ngx_http_reqeust_handler
#这个函数主要用来处理不能一次性读完写完的情况
c->read->handler = ngx_http_request_handler;
c->write->handler = ngx_http_request_handler;
if r->buffered || c->buffered || r->postponed: #如果一次数据没有写完，就向epollfd中注册写事件
#然后就在下一次事件循环中处理，这一点和redis一样
ngx_http_request.ngx_http_set_write_handler
r->http_state = NGX_HTTP_WRITING_REQUEST_STATE #所以说nginx处理http请求就是一个状态机
#nginx就是通过这个状态来记录当前请求处理到哪一步了
#所以即使一个请求的数据还没有全部收到
#即使需要中断当前执行以待下次执行
#nginx都可以正确处理
r->write_event_handler = ngx_http_writer; #fd可写事件的handler。要么异步io，要么直接写发送缓冲区
if wev->delayed || r->aio: #如果是延迟或者异步处理
ngx_event.ngx_handle_write_event
if lowat>0: #lowat：需要低水位发送的字节数
ngx_event.ngx_send_lowat
if !wev->active && !wev->ready: #不一定会再次把write_event放到epollfd中
ngx_epoll_module.ngx_epoll_add_event #define ngx_add_event ngx_event_actions.add
#add函数实际是ngx_epoll_add_event函数
#注意：它是直接初始化一个结构体来初始化actions的所有字段的
epoll_ctl(add,NGX_WRITE_EVENT) #向epollfd注册写事件
else:
ngx_http_core_module.ngx_http_output_filter #不需要延迟处理则通过ngx_http_write就是把数据写到发送缓冲区
ngx_event.ngx_handle_write_event #把event事件注册到epollfd中
ngx_epoll_module.ngx_epoll_add_event
epoll_ctl(add,NGX_WRITE_EVENT)
ngx_http_request.ngx_http_finalize_connection #！！！这个finalize_request和
#！！！finalize_connection有点乱和有些错，但无伤大雅
if 请求处理完了&&keepalive==true:
c->read->handler=ngx_http_keepalive_handler
else if 请求行和请求头收到了但是请求体还没收到&&请求体可丢弃
ngx_add_timer(c->read,time) #http请求收到请求行请求头后就可以开始处理了
#此时read->handler=ngx_http_request_handler
#ngx_add_timer是确保在指定时间内结束整个请求
if rc==NGX_OK: #如果某个handler返回NGX_OK就表示请求处理结束，不再调用后面的handler
return
ngx_http_request.ngx_http_run_posted_requests #请求处理完了，执行请求后的处理
1-3-1：ngx_http_request_handler流程
代码很简单，就直接贴源代码。反正就是对于一个请求，收完请求头之后对应的read->handler就设置成ngx_http_request_handler，一旦整个请求处理完毕，如果keepalive为false,那么该连接就会关闭，下一次新请求到来的时候就要重新走一遍accept、ngx_http_wait_request_handler，如果keepalive为true，那么连接就不会关闭，在ngx_http_finalize_request的时候就会把read->handler设置成ngx_http_keepalive_handler，该连接上的下次请求到来的时候就是走ngx_http_keepalive_handler。至于stream read流程放下了，还有ngx_read/write_event_handler的设置就暂时跳过了，还有ngx_http_finalize_request和ngx_http_finalize_connection的部分的代码流程笔记有些乱以及有些地方是错的，但是大体是对的，暂时先放下了，反正无伤大雅。因为今天还有2分钟就下班了 2024/10/25 17:58
static void
ngx_http_request_handler(ngx_event_t *ev)
{
ngx_connection_t *c;
ngx_http_request_t *r;
c = ev->data;
r = c->data;
ngx_http_set_log_request(c->log, r);
ngx_log_debug2(NGX_LOG_DEBUG_HTTP, c->log, 0,
"http run request: \"%V?%V\"", &r->uri, &r->args);
if (c->close) {
r->main->count++;
ngx_http_terminate_request(r, 0);
ngx_http_run_posted_requests(c);
return;
}
if (ev->delayed && ev->timedout) {
ev->delayed = 0;
ev->timedout = 0;
}
if (ev->write) {
r->write_event_handler(r);
} else {
r->read_event_handler(r); #比如对于某些不需要的请求体，直接丢弃
#即此时的read_event_handler为ngx_http_discard_request_body即丢弃请求体并清除定时器
}
ngx_http_run_posted_requests(c);
}