关于nginx body filter

316953425 · 2014-07-23T10:54:19+00:00

Hello! 2014-07-22 2:46 GMT-07:00 冰河: > 我现在想学习一下nginx body filter机制&#x...

关于nginx body filter

316953425

大家好，请教一个问题：
当我写body filter的时候，假设in是body filter函数的第二个参数
这样做不可以吗？

for ( chain_link = in; chain_link != NULL; chain_link = chain_link->next ) {

直接在这里遍历所有buf不可以吗，

如果需要修改buf里的内容时，如果原本buf指向的内存足够大，就先对buf进行赋值，
然后完成pos和last的赋值；如果原本buf指向的内存不是足够大，就在r->pool上分配新的一大块
内存给buf，然后把buf->shadow 指向原来buf指向的内存。

如果发现buf->last_buf 为1，就跳出，表示所有的响应体都已经操作完成

为什么大家都不是这样做的，而是按照sub filter中那样做啊
}

agentzh

Hello!

2014-07-22 19:51 GMT-07:00 冰河:
> 当我写body filter的时候，假设in是body filter函数的第二个参数
> 这样做不可以吗？
>
>    for ( chain_link = in; chain_link != NULL; chain_link = chain_link->next
> ) {
>
>         直接在这里遍历所有buf不可以吗，
>

直接遍历本身自然是可以的。nginx 核心里有很多这样的遍历。关键是你在遍历时做什么，特别是修改什么。

>         如果需要修改buf里的内容时，如果原本buf指向的内存足够大，就先对buf进行赋值，
> 然后完成pos和last的赋值；如果原本buf指向的内存不是足够大，就在r->pool上分配新的一大块
> 内存给buf，然后把buf->shadow 指向原来buf指向的内存。
>

这就不行了，因为创建这些 ngx_buf_t 的模块（比如
ngx_proxy）需要对它自己的缓冲区有绝对的控制权，比如缓冲区的循环回收利用，以及追踪数据已经实际写到什么位置了（会有“写不动”的情况）。关于这一点，可以参见
nginx 核心中的 ngx_chain_update_chains 函数的实现，以及 ngx_proxy 模块里对缓冲区的管理逻辑（特别是
busy bufs 的概念）。

其他输出过滤器模块不能直接修改 start/pos 指针指向的内存块里的数据，更不能直接改变 ngx_buf_t 的 start/pos
指针指向的内存块。因为这是不安全的。输出过滤器不应对创建这些输入 ngx_buf_t 的模块作任何假设，毕竟这些输入 buf
并不是输出过滤器自己创建和管理的。

当然，输出过滤器并不是完全不能对 ngx_buf_t 进行修改。输出过滤器唯一需要并且唯一允许做的事情是：在它决定不把某个输入 buf
继续传递给下一个输出过滤器时，该输出过滤器需要在恰当的时候标记该输入 buf 为“消耗掉”的状态。标记为“消耗掉”的具体做法是将
b->pos 置为 b->last. 关于这么做的原因，请参见 ngx_chain_update_chains 函数的实现。

buf->shadow 只是用来建立新创建的 ngx_buf_t 与它替换掉的输入 ngx_buf_t 之间的对应关系，这样当新的
ngx_buf_t 被“消耗”掉时（即被实际写出时），也可以把它对应的输入 ngx_buf_t 也标记为“消耗掉”（即设置 b->pos =
b->last），这样上游可以回收这些输入 buf. 在这里我们也可以看到，输入 buf 也是不能直接改写掉的。

> 为什么大家都不是这样做的，而是按照sub filter中那样做啊
>

见上。

出于效率方面的考虑，内存缓存区的管理一般都是比较复杂的。这在输出过滤器的实现中体现得尤为明显。

Regards,
-agentzh

316953425



在nginx自带的chunked的body filter中我发现在调用ngx_chain_update_chains时，把上次没发完的chain放到了ctx->busy中，应该就是您说的“写不动的情况吧”，但是这个body
filter中我并没有看到，什么时候处理该ctx->busy,也就是上次没发完的数据啊 ？

而其他的一些body filter例如sub filter中，在该body filter下次被调用的时候，都会处理ctx->busy,也就是上次没写到客户端的数据啊？

agentzh

Hello!

2014-07-22 22:54 GMT-07:00  <3169...@qq.com>:
> 在nginx自带的chunked的body filter中我发现在调用ngx_chain_update_chains时，把上次没发完的chain放到了ctx->busy中，应该就是您说的“写不动的情况吧”，但是这个body
> filter中我并没有看到，什么时候处理该ctx->busy,也就是上次没发完的数据啊 ？
>

“写不动”是指操作系统的 socket send buffer（一般是网络协议栈实现的一部分）满了，用户态一时不能向该 socket 发送更多的数据。

“busy buffer”是 nginx 自己的概念，而且是一个相对于 buffer 创建者的概念。当 buffer 的创建者 A（可以是
content handler 或者是某一级 output body filter）发现它创建并发送给下游过滤器的一个 buffer
还没有被标记为“消耗掉”，则 A 就认为该 buffer 是一个“busy buffer”。我之前已经讲到标记为“消耗掉”其实就是
b->pos == b->last，而且不一定是它的数据真的被写到系统 socket send buffer 中（因为某个下游 socket
可能会拦截并替换掉它，如我们之前一直在讨论的情形）。

换言之，每一个 buffer 生产者一般都会在调用完下游输出过滤器（链）之后，通过 ngx_chain_update_chains()
函数对它*自己的* buffer 进行 busy/free 标记和回收。当然只有标记为 free 的 buf 才能回收。这也是 busy
buf 的全部意义所在。kw

> 而其他的一些body filter例如sub filter中，在该body filter下次被调用的时候，都会处理ctx->busy,也就是上次没写到客户端的数据啊？
>

ctx 是各个模块自己的，是独立的。它们各自进行 buf 的回收利用，同时避免对自己的 busy buf 进行回收。

建议在阅读 nginx 源码时一定要仔细和有耐心，同时要避免断章取义。

Regards,
-agentzh

316953425

不得不佩服章老师的技术品质，无论多忙都能及时回复邮件，真是我等程序员学习的楷模

------------------ 原始邮件 ------------------

发件人: "agentzh";<age...@gmail.com>;

发送时间: 2014年7月26日(星期六) 凌晨3:32

收件人: "openresty"<openresty@googlegroups.com>;

主题: Re: [openresty] 关于nginx body filter

Hello!

2014-07-22 22:54 GMT-07:00 <3169...@qq.com>:
> 在nginx自带的chunked的body filter中我发现在调用ngx_chain_update_chains时，把上次没发完的chain放到了ctx->busy中，应该就是您说的“写不动的情况吧”，但是这个body
> filter中我并没有看到，什么时候处理该ctx->busy,也就是上次没发完的数据啊？
>

“写不动”是指操作系统的 socket send buffer（一般是网络协议栈实现的一部分）满了，用户态一时不能向该 socket 发送更多的数据。

“busy buffer”是 nginx 自己的概念，而且是一个相对于 buffer 创建者的概念。当 buffer 的创建者 A（可以是
content handler 或者是某一级 output body filter）发现它创建并发送给下游过滤器的一个 buffer
还没有被标记为“消耗掉”，则 A 就认为该 buffer 是一个“busy buffer”。我之前已经讲到标记为“消耗掉”其实就是
b->pos == b->last，而且不一定是它的数据真的被写到系统 socket send buffer 中（因为某个下游 socket
可能会拦截并替换掉它，如我们之前一直在讨论的情形）。

换言之，每一个 buffer 生产者一般都会在调用完下游输出过滤器（链）之后，通过 ngx_chain_update_chains()
函数对它*自己的* buffer 进行 busy/free 标记和回收。当然只有标记为 free 的 buf 才能回收。这也是 busy
buf 的全部意义所在。kw

> 而其他的一些body filter例如sub filter中，在该body filter下次被调用的时候，都会处理ctx->busy,也就是上次没写到客户端的数据啊？
>

ctx 是各个模块自己的，是独立的。它们各自进行 buf 的回收利用，同时避免对自己的 busy buf 进行回收。

建议在阅读 nginx 源码时一定要仔细和有耐心，同时要避免断章取义。

Regards,
-agentzh

--
--
邮件来自列表“openresty”,专用于技术讨论!
订阅: 请发空白邮件到 openresty+subscribe@googlegroups.com
发言: 请发邮件到 openresty@googlegroups.com
退订: 请发邮件至 openresty+unsubscribe@googlegroups.com
归档: http://groups.google.com/group/openresty
官网: http://openresty.org/
仓库: https://github.com/agentzh/ngx_openresty
教程: http://openresty.org/download/agentzh-nginx-tutorials-zhcn.html