nginx的源码分析--间接回调机制的使用和类比

Myth丶恋晨 2022-07-24 04:27 74阅读 0赞

nginx使用了间接回调机制，结合upstream机制的使用来说明一下，首先明确几个事实：

1）其实ngxin和下游客户端的连接使用的是ngx\_http\_connection\_t，每个连接对应着一个读事件、一个写事件，epoll监听队列监听的是事件（ngx\_event\_t），但是**事件的data字段对应于这个事件所属的连接（ngx\_connection\_t）**。但是nginx和上游服务器之间的连接使用的ngx\_peer\_connection\_t，其实ngx\_peer\_connection\_t是ngx\_connection\_t结构体的封装，前者包括了后者，算是后者的高级应用

2）ngx\_connection\_t对应nginx和客户端的连接，**每个这样的连接都有一个请求（ngx\_http\_request\_t）与之相对应，同时请求中有两个字段，write\_event\_handler和read\_event\_handler，这连个字段属于请求的读写回调**，但是他很显然不能被激活，能激活的就是读写事件（ngx\_event\_t）

3）在HTTP请求的后期阶段，**nginx通过连接上的读写事件回调（这个已经被epoll监控）来间接调用请求上的读写回调，这么一来，如果想该变请求上的流程，只需要修改ngx\_http\_request\_t上的read\_event\_handler和write\_event\_handler即可**，这样的实现可以在ngx\_http\_handler函数中体现

4）nginx在处理upstream和上游的连接时，每一个upstream连接（ngx\_peer\_connection\_t）对应一个upstream机制(ngx\_http\_upstream\_t)，因为upstream的连接也可以看成ngx-connection\_t,所以和ngx\_connection\_t类似，ngx\_http\_upstream\_t中也有两个字段read\_event\_handler和write\_event-handler,这样在处理和上游的连接上的读写回调时也是间接调用了ngx\_http\_upstream\_t的读写回调函数 这个在ngx\_http\_upstream\_connection中可以看到 c=u->peer.connection，这里的c(ngx-connection\_t)是和上游服务器之间的连接c->write->hanlder = ngx\_http\_upstream\_handler，在这一行和接下来的几行，认真阅读，会发现ngx\_http\_upstream\_handler和ngx\_http\_handler有相似之处

5）这么一来，在接下来的处理中只需关注ngx\_http\_upstream\_t上的读写（write\_event\_handler & read\_event\_handler）即可完成nginx和上游服务器之间的交互，只需关系ngx\_http\_request\_t中的读写（write\_event\_handler & read\_event\_handler）即可完成nginx和客户端之间的监护

（总结：在连诶http请求和经过upstream机制的请求时，一定要明白当前的ngx\_connection\_t是指nginx和谁之间的连接）