求解nginx源代码问题

plc1989 · 2014-04-02T22:00:08+00:00

我有个应用，也是用的 magick 库，原图大小约 200，&...

求解nginx源代码问题

plc1989

章老师,你好,最近在看nginx源代码,有一个问题没搞明白,在这想向你请教下:

nginx是基于事件驱动模型的,也就是说每个回调的执行都是由事件触发的,那么,针对同一个连接,即同一个fd上,只可能有两种事件,要么可读要么可写,所以一次可读事件只能触发一次回调的执行,我这边碰到的问题如下(以下代码做了精简):

content_handler() {

......

rc = ngx_http_discard_request_body(r);

......

ngx_http_upstream_init(r);

......

}

ngx_http_discard_request_body()这个函数在整个请求体未被完整接受的情况下会设置r->read_event_handler为ngx_http_discarded_request_body_handler,然后这个函数返回了,继续执行下面的ngx_http_upstream_init()函数,而这个函数又会将r->read_event_handler设置为

ngx_http_upstream_rd_check_broken_connection,所以下一个可读事件到来时,就去执行后面这个回调了,前面这个回调需要完成的任务又在哪被执行呢?很是疑惑

谢谢

agentzh

Hello!

2014-04-02 7:00 GMT-07:00 aCayF:
> ngx_http_discard_request_body()这个函数在整个请求体未被完整接受的情况下会设置r->read_event_handler为ngx_http_discarded_request_body_handler,然后这个函数返回了,继续执行下面的ngx_http_upstream_init()函数,而这个函数又会将r->read_event_handler设置为
> ngx_http_upstream_rd_check_broken_connection,所以下一个可读事件到来时,就去执行后面这个回调了,前面这个回调需要完成的任务又在哪被执行呢?很是疑惑
>

r->read_event_handler 会在请求结束时重置回
ngx_http_discarded_request_body_handler. 具体位置是在
ngx_http_finalize_connection 函数中，特别地，是下面这一段代码：

    if (r->main->count != 1) {

        if (r->discard_body) {
            r->read_event_handler = ngx_http_discarded_request_body_handler;
            ngx_add_timer(r->connection->read, clcf->lingering_timeout);

            if (r->lingering_time == 0) {
                r->lingering_time = ngx_time()
                                      + (time_t) (clcf->lingering_time / 1000);
            }
        }

        ngx_http_close_request(r, 0);
        return;
    }

Regards,
-agentzh

plc1989

好的,谢谢章老师指点,我看了一下相应源码,又发现了一个问题:

上封邮件里提到的content_handler函数,它的返回值会直接传给ngx_http_finalize_request,如下

ngx_http_finalize_request(r, r->content_handler(r));

又因为我的content_handler的返回值是NGX_DONE,所以根据ngx_http_finalize_requset函数的逻辑,他会直接调用ngx_http_finalize_connection,在这个函数里又将r->read_event_handler重置回ngx_http_discarded_request_body_handler,所以r->read_event_handler就被修改了三次.....

问题就变成了ngx_http_upstream_rd_check_broken_connection回调又是在哪被调用的呢?r->read_event_handler已经不存在这个信息了呀

2014/04/02 20:11:02 [debug] 22800#0: timer delta: 5

2014/04/02 20:11:02 [debug] 22800#0: posted events 00000000

2014/04/02 20:11:02 [debug] 22800#0: worker cycle

2014/04/02 20:11:02 [debug] 22800#0: epoll timer: 5000

2014/04/02 20:11:02 [debug] 22800#0: epoll: fd:7 ev:0005 d:08D76544

2014/04/02 20:11:02 [debug] 22800#0: *1 http run request: "/foo?"

2014/04/02 20:11:02 [debug] 22800#0: *1 http read discarded body

2014/04/02 20:11:02 [debug] 22800#0: *1 recv: fd:7 4096 of 4096

2014/04/02 20:11:02 [debug] 22800#0: *1 recv: fd:7 92 of 92

2014/04/02 20:11:02 [debug] 22800#0: *1 http finalize request: -4, "/foo?" a:1, c:2

2014/04/02 20:11:02 [debug] 22800#0: *1 http request count:2 blk:0

2014/04/02 20:11:02 [debug] 22800#0: *1 http run request: "/foo?"

2014/04/02 20:11:02 [debug] 22800#0: *1 http upstream check client, write event:1, "/foo"

2014/04/02 20:11:02 [debug] 22800#0: *1 http upstream recv(): -1 (11: Resource temporarily unavailable)

从上述信息可以看出ngx_http_upstream_rd_check_broken_connection回调确实被执行了.而且是在ngx_http_discarded_request_body_handler回调之后,由同一个事件触发,非常疑惑

谢谢

2014-04-03 2:33 GMT+08:00 Yichun Zhang (agentzh) <age...@gmail.com>:

Hello!

2014-04-02 7:00 GMT-07:00 aCayF:
> ngx_http_discard_request_body()这个函数在整个请求体未被完整接受的情况下会设置r->read_event_handler为ngx_http_discarded_request_body_handler,然后这个函数返回了,继续执行下面的ngx_http_upstream_init()函数,而这个函数又会将r->read_event_handler设置为
> ngx_http_upstream_rd_check_broken_connection,所以下一个可读事件到来时,就去执行后面这个回调了,前面这个回调需要完成的任务又在哪被执行呢?很是疑惑
>

r->read_event_handler 会在请求结束时重置回
ngx_http_discarded_request_body_handler. 具体位置是在
ngx_http_finalize_connection 函数中，特别地，是下面这一段代码：

if (r->main->count != 1) {

if (r->discard_body) {
r->read_event_handler = ngx_http_discarded_request_body_handler;
ngx_add_timer(r->connection->read, clcf->lingering_timeout);

if (r->lingering_time == 0) {
r->lingering_time = ngx_time()
+ (time_t) (clcf->lingering_time / 1000);
}
}

ngx_http_close_request(r, 0);
return;
}

Regards,
-agentzh

--

agentzh

Hello!

2014-04-02 19:28 GMT-07:00 aCayF:
> 上封邮件里提到的content_handler函数,它的返回值会直接传给ngx_http_finalize_request,如下
> ngx_http_finalize_request(r, r->content_handler(r));
>
> 又因为我的content_handler的返回值是NGX_DONE,所以根据ngx_http_finalize_requset函数的逻辑,他会直接调用ngx_http_finalize_connection,在这个函数里又将r->read_event_handler重置回ngx_http_discarded_request_body_handler,所以r->read_event_handler就被修改了三次.....
>
> 问题就变成了ngx_http_upstream_rd_check_broken_connection回调又是在哪被调用的呢?r->read_event_handler已经不存在这个信息了呀
>

是的，ngx_http_discarded_request_body_handler 会改写掉
ngx_http_upstream_rd_check_broken_connection.

所以需要希望启用 upstream check broken connection，就不应过早调用 ngx_http_discard_request_body.

> 2014/04/02 20:11:02 [debug] 22800#0: *1 http upstream check client, write
> event:1, "/foo"
> 2014/04/02 20:11:02 [debug] 22800#0: *1 http upstream recv(): -1 (11:
> Resource temporarily unavailable)
>
> 从上述信息可以看出ngx_http_upstream_rd_check_broken_connection回调确实被执行了.而且是在ngx_http_discarded_request_body_handler回调之后,由同一个事件触发,非常疑惑
>

你日志里的那一行“http upstream check client”那一行是“写事件”触发的，注意那一行中的“write event:1”这一块。

Regards,
-agentzh

plc1989

你日志里的那一行“http upstream check client”那一行是“写事件”触发的，注意那一行中的“write event:1”这一块。

谢谢章老师指正,确实是同一个连接上触发的两个回调,可读事件触发ngx_http_discarded_request_body_handler,可写事件触发ngx_http_upstream_wr_check_broken_connection

那想问一下,如果想实现我这样的功能(丢弃请求体,连接upstream),该如何调用这两个API呀?有现有的模块可以参考吗?

agentzh

Hello!

2014-04-03 21:39 GMT-07:00 aCayF:
>
> 那想问一下,如果想实现我这样的功能(丢弃请求体,连接upstream),该如何调用这两个API呀?有现有的模块可以参考吗?
>

你的 nginx upstream 模块真的需要 check client abort 吗？比如标准的 ngx_memcached
模块根本就不支持 check client abort，它直接就调用 ngx_http_discard_request_body 了事。

如果你想二者兼得，最简单的做法是先同步地完成 discard request body 的全过程，然后再调用
ngx_http_upstream_init，就像 ngx_http_read_client_request_body 函数那样。

Regards,
-agentzh

plc1989

你的 nginx upstream 模块真的需要 check client abort 吗？

原本我以为每个对r->read_event_handler设置的回调都是必须要再次执行的,您的意思是还是要看相应回调的功能是吧?

就像这里的两个回调:

ngx_http_discarded_request_body_handler,接收请求体但直接丢弃,接收完后删除可读事件(通过ngx_http_block_reading)

ngx_http_upstream_rd_check_broken_connection,直接删除可读事件,同时如果client端断开连接就结束upstream请求

所以就要看我们需不需要检测client端断开的功能了,这里有个疑问就是为什么不把这个功能放到ngx_http_upstream_wr_check_broken_connection这个回调里呢?现在这个功能是放在rd且也只是执行了一次嘛(可读事件和定时事件都被删除了),如果放在wr里岂不是可以多次检测?

agentzh

Hello!

2014-04-05 8:19 GMT-07:00 aCayF:
>
> 原本我以为每个对r->read_event_handler设置的回调都是必须要再次执行的,您的意思是还
> 是要看相应回调的功能是吧?

r->read_event_handler 只是一个函数指针，并不是一个处理程序队列。

> 就像这里的两个回调:
> ngx_http_discarded_request_body_handler,接收请求体但直接丢弃,接收完后删除可读事件(通过ngx_http_block_reading)

你在这里的描述是有问题的。nginx 只在 level trigger（LT）的事件模式下才会 delete 对应的 event，因为在
LT 模式下，如果有读事件，但又不想消耗掉系统读取缓冲区内的所有数据，就必须解除对“读事件”的监听，否则会陷入热循环，因为缓冲区里一直有未读完的数据。而在
ET 事件模式下（比如启用 epoll 时），nginx 并不会删除对应的事件。你应该注意到相关代码的这个条件：

   if ((ngx_event_flags & NGX_USE_LEVEL_EVENT)
        && r->connection->read->active)

> ngx_http_upstream_rd_check_broken_connection,直接删除可读事件,同时如果client端断开连接就结束upstream请求
>

这里的描述也是有问题的，见上。删除事件只是为了避免在 LT 模式下陷入热循环而浪费 CPU 资源。

> 所以就要看我们需不需要检测client端断开的功能了,这里有个疑问就是为什么不把这个功能放到ngx_http_upstream_wr_check_broken_connection这个回调里呢?

注意，大多数情况下客户端提前断开连接引发的是读事件，而不是写事件。

> 现在这个功能是放在rd且也只是执行了一次嘛(可读事件和定时事件都被删除了),如果放在wr里岂不是可以多次检测?
>

这种说法也不对，因为

1. 在 ET 模式下，ngx_http_upstream_rd_check_broken_connection 经常会被执行多次。
2. ngx_http_upstream 的 check client abort 功能其实要求当前请求的请求体已经读取完毕（无论是
discard 了还是 buffer 起来了）。

Regards,
-agentzh

plc1989

你在这里的描述是有问题的。nginx 只在 level trigger（LT）的事件模式下才会 delete 对应的 event，因为在
LT 模式下，如果有读事件，但又不想消耗掉系统读取缓冲区内的所有数据，就必须解除对“读事件”的监听，否则会陷入热循环，因为缓冲区里一直有未读完的数据。而在
ET 事件模式下（比如启用 epoll 时），nginx 并不会删除对应的事件。你应该注意到相关代码的这个条件：

if ((ngx_event_flags & NGX_USE_LEVEL_EVENT)
&& r->connection->read->active)

实在是抱歉,自己犯了个低级错误(把epoll默认是level还是edge模式给记反了),耽搁章老师的时间了,请见谅:)谢谢章老师的指正

2. ngx_http_upstream 的 check client abort 功能其实要求当前请求的请求体已经读取完毕（无论是
discard 了还是 buffer 起来了）。

不知道这句话该怎么理解?还望章老师指教

谢谢

plc1989

还想到一个问题就是,如何判断我的upstream模块需不需要check client abort的功能呢?

2014-04-07 16:09 GMT+08:00 aCayF <plc...@gmail.com>:

你在这里的描述是有问题的。nginx 只在 level trigger（LT）的事件模式下才会 delete 对应的 event，因为在
LT 模式下，如果有读事件，但又不想消耗掉系统读取缓冲区内的所有数据，就必须解除对“读事件”的监听，否则会陷入热循环，因为缓冲区里一直有未读完的数据。而在
ET 事件模式下（比如启用 epoll 时），nginx 并不会删除对应的事件。你应该注意到相关代码的这个条件：

if ((ngx_event_flags & NGX_USE_LEVEL_EVENT)
&& r->connection->read->active)

实在是抱歉,自己犯了个低级错误(把epoll默认是level还是edge模式给记反了),耽搁章老师的时间了,请见谅:)谢谢章老师的指正

2. ngx_http_upstream 的 check client abort 功能其实要求当前请求的请求体已经读取完毕（无论是
discard 了还是 buffer 起来了）。

不知道这句话该怎么理解?还望章老师指教

谢谢