关于upstream的八种回调方法

1 creat_request

调用背景：

用于创建自己模板与第三方服务器的第一次连接

步骤

1） 在Nginx主循环（ngx_worker_process_cycle方法） 中，会定期地调用事件模块， 以检查是否有网络事件发生。

2） 事件模块在接收到HTTP请求后会调用HTTP框架来处理。 假设接收、 解析完HTTP头部后发现应该由mytest模块处理， 这时会调用mytest模块的ngx_http_mytest_handler来处理。

3） 这里mytest模块此时会完成

3.1设置upstream的限制性参数

3.2设置需要访问的第三方服务器地址

3.3设置回调方法 具体细节参照如何使用ngxin的 upstream_编程界的谢菲尔德的博客-CSDN博客

4） 调用ngx_http_upstream_init方法启动upstream。

5） upstream模块会去检查文件缓存， 如果缓存中已经有合适的响应包， 则会直接返回缓存（ 当然必须是在使用反向代理文件缓存的前提下） 。 为了让读者方便地理解upstream机制， 将不再提及文件缓存。

6） 回调mytest模块已经实现的create_request回调方法。

7） mytest模块通过设置r->upstream->request_bufs已经决定好发送什么样的请求到上游服务器。

8） upstream模块将会检查的resolved成员， 如果有resolved成员的话， 就根据它设置好上游服务器的地址r->upstream->peer成员。

9） 用无阻塞的TCP套接字建立连接。

10） 无论连接是否建立成功， 负责建立连接的connect方法都会立刻返回。

11） ngx_http_upstream_init返回。

12） mytest模块的ngx_http_mytest_handler方法返回NGX_DONE。

13） 当事件模块处理完这批网络事件后， 将控制权交还给Nginx主循环。

2. reinit_request回调方法

调用背景：

reinit_request可能会被多次回调。 它被调用的原因只有一个， 就是在第一次试图向上游服务器建立连接时， 如果连接由于各种异常原因失败， 那么会根upstream中conf参数的策略要求再次重连上游服务器， 而这时就会调用reinit_request方法

了

步骤

1） Nginx主循环中会定期地调用事件模块， 检查是否有网络事件发生。

2） 事件模块在确定与上游服务器的TCP连接建立成功后， 会回调upstream模块的相关方法处理。

3） upstream模块这时会把r->upstream->request_sent标志位置为1， 表示连接已经建立成功

了， 现在开始向上游服务器发送请求内容。

4） 发送请求到上游服务器。

5） 发送方法当然是无阻塞的（使用了无阻塞的套接字） ， 会立刻返回。

6） upstream模块处理第2步中的TCP连接建立成功事件。

7） 事件模块处理完本轮网络事件后， 将控制权交还给Nginx主循环。

8） Nginx主循环重复第1步， 调用事件模块检查网络事件。

9） 这时， 如果发现与上游服务器建立的TCP连接已经异常断开， 那么事件模块会通知upstream模块处理它。

10） 在符合重试次数的前提下， upstream模块会毫不犹豫地再次用无阻塞的套接字试图建立连接。

11） 无论连接是否建立成功都立刻返回。

12） 这时检查r->upstream->request_sent标志位， 会发现它已经被置为1了。

13） 如果mytest模块没有实现reinit_request方法， 那么是不会调用它的。 而如果reinit_request不为NULL空指针， 就会回调它。

14） mytest模块在reinit_request中处理完自己的事情。

15） 处理完第9步中的TCP连接断开事件， 将控制权交还给事件模块。

16） 事件模块处理完本轮网络事件后， 交还控制权给Nginx主循环

3 finaliza_request回调方法

调用背景

当调用ngx_http_upstream_init启动upstream机制后， 在各种原因（ 无论成功还是失败） 导致该请求被销毁前都会调用finalize_request方法

4 process_header 回调方法

调用背景：

process_header是用于解析上游服务器返回的基于TCP的响应头部的， 因此，

process_header可能会被多次调用， 它的调用次数与process_header的返回值有关如果process_header返回NGX_AGAIN， 这意味着还没有接收到完整的响应头部， 如果再次接收到上游服务器发来的TCP流， 还会把它当做头部， 仍然调用process_header处理，而在下图中， 如果process_header返回NGX_OK（ 或者其他非NGX_AGAIN的值） ， 那么在这次连接的后续处理中将不会再次调用process_header。

步骤：

1） Nginx主循环中会定期地调用事件模块， 检查是否有网络事件发生。

2） 事件模块接收到上游服务器发来的响应时， 会回调upstream模块处理。

3） upstream模块这时可以从套接字缓冲区中读取到来自上游的TCP流。

4） 读取的响应会存放到r->upstream->buffer指向的内存中。 注意： 在未解析完响应头部前， 若多次接收到字符流， 所有接收自上游的响应都会完整地存放到r->upstream->buffer缓冲区中。 因此， 在解析上游响应包头时， 如果buffer缓冲区全满却还没有解析到完整的响应头部（ 也就是说， process_header一直在返回NGX_AGAIN） ， 那么请求就会出错。

5） 调用mytest模块实现的process_header方法。

6） process_header方法实际上就是在解析r->upstream->buffer缓冲区， 试图从中取到完整的响应头部（ 当然， 如果上游服务器与Nginx通过HTTP通信， 就是接收到完整的HTTP头

7） 如果process_header返回NGX_AGAIN， 那么表示还没有解析到完整的响应头部， 下次还会调用process_header处理接收到的上游响应。

8） 调用无阻塞的读取套接字接口。

9） 这时有可能返回套接字缓冲区已经为空。

10） 当第2步中的读取上游响应事件处理完毕后， 控制权交还给事件模块。

11） 事件模块处理完本轮网络事件后， 交还控制权给Nginx主循环。

5.rewrite_redirect

调用背景：

在重定向URL阶段， 如果实现了rewrite_redirect回调方法， 那么这时会调用

rewrite_redirect.如果upstream模块接收到完整的上游响应头部，

而且由HTTP模块的process_header回调方法将解析出的对应于Location的头部设置到了ngx_http_upstream_t中的headers_in成员时，ngx_http_upstream_process_headers方法将会最终调用rewrite_redirect方法

url重定向：url 重定向，也称为 URL 转发，是一种当实际资源，如单个页面、表单或者整个 Web 应用被迁移到新的 URL 下的时候，保持（原有）链接可用的技术。HTTP 协议提供了一种特殊形式的响应—— HTTP 重定向（HTTP redirects）来执行此类操作

6.input_filter_init与input_filter回调方法

调用背景：

input_filter_init与input_filter这两个方法都用于处理上游的响应包体， 因为处理包体前HTTP模块可能需要做一些初始化工作。 例如， 分配一些内存用于存放解析的中间状态等，这时upstream就提供了input_filter_init方法。 而input_filter方法就是实际处理包体的方法。 这两个回调方法都可以选择不予实现， 这是因为当这两个方法不实现时， upstream模块会自动设置它们为预置方法（上文讲过， 由于upstream有3种处理包体的方式， 所以upstream模块准备了3input_filter_init、 input_filter方法）