NGINX源码之：子请求与请求后置处理ngx_http_finalize_request

在开始解读ngx_http_finalize_request，先来看看NGINX中子请求的概念：
在NGINX中，当用户请求的页面有设置ssi,即通过include方式引入其他若干页面，或者通过upstream和proxy_pass做负载转发并开启proxy_cache，都会触发通过创建子请求。

在客户端请求进来的时候，通过epoll事件机制处理，然后在ngx_http_create_request()中创建请求，并通过ngx_http_alloc_request()为新请求分配内存空间并初始化，此时会将当前请求r的main属性指向自身，后续会通过这个设置判断当前请求是主请求还是子请求。
通过ngx_http_subrequest()创建子请求：

子请求结构如下：

在处理主请求时，会通过ngx_http_run_posted_requests()遍历处理所有子孙请求。

为什么这里先解读子请求呢，因为后面finalize处理的时候，会涉及到子请求的判断情况，如count的计数，当前是否为main等。
接下来进入实际的ngx_http_finalize_request();

ngx_http_finalize_connection

keepalive和so_linger这里就不多解读了，有兴趣再来
最后看下ngx_http_close_request（）主要调用ngx_http_free_request()、ngx_http_close_connection()

ngx_http_free_request中，主要释放request所占用的内存池。
ngx_http_close_connection()->ngx_close_connection（）

关于ngx_reusable_connection，可参考NGINX源码之：event与epoll最后面的补充说明