nginx 超时机制
2014-07-20 10:09
337 查看
nginx,读法engine X,事件机制尤如nginx的引擎了.
服务器无非就是,监听、请求、接受、响应,包括超时处理.nginx虽然设计的很复杂,但是刨根究底,无非也是这些东西.
连接和事件的定义
只要能产生fd的(不管是监听，还是请求)，都是连接，一个fd对应一个连接（connection）。
每个连接有两个事件(event),可以读(read)和写(write)结构体为：
监听listen
当处理完配置文件解析（针对listen指令）时，nginx开始处理这些listen。将它们放在
ngx_cycle->listening里。监听是有读事件，而没有写事件的，epoll有两个模式LT和ET，监听采用LT，监听的read事件的处理函数为ngx_event_accept.
接受accept
这个产生的fd(已连接套接字)，有读和写事件，对读事件的处理函数为ngx_http_init_request。因此一个连接请求一旦发送完，就从这个函数开始执行
。这也是request开始的生命周期，这里的结构体为：
超时 机制
超时机制用了红黑树，ngx_event_timer_rbtre。初始化:ngx_single_process_cycle->ngx_event_process_init
->ngx_event_timer_init(cycle->log);
事件操作：
ngx_epoll_add_event
ngx_epoll_del_event
这段代码巧妙的运用数据结构的偏移来找到对应的事件。
假设fd已经有了，可能是你通过socket函数产生的。
获取连接：
c = ngx_get_connection(fd);
处理read,write：
c->read->handler = ngx_http_init_request;
c->write->handler = ngx_http_empty_handler;
定时器处理：定时器是针对事件的
ngx_add_timer(c->read, c->listening->post_accept_timeout);
ngx_add_timer(c->write, ...);
注册事件：即加入epoll，这里一般采用ET模式。
ngx_handle_read_event(c->read, 0);
ngx_handle_read_event(c->write, 0);
上面的例子将read，write都处理了，实际情况不一定得这样，看你要不要处理读或写事件，哪个需要，启用哪个。
＃＃参考http://my.oschina.net/fqing/blog/83516
服务器无非就是,监听、请求、接受、响应,包括超时处理.nginx虽然设计的很复杂,但是刨根究底,无非也是这些东西.
只要能产生fd的(不管是监听，还是请求)，都是连接，一个fd对应一个连接（connection）。
每个连接有两个事件(event),可以读(read)和写(write)结构体为：
struct ngx_connection_s {
/*
连接未使用时，data成员用于充当连接池中空闲连接链表中的next指针。当连接被使用时，data的意义由使用它的nginx模块而定，
如在HTTP框架中，data指向ngx_http_request_t请求
*/
void *data;
// 连接对应的读事件
ngx_event_t *read;
// 连接对应的写事件
ngx_event_t *write;
// 套接字句柄
ngx_socket_t fd;
// 直接接受网络字符流的方法
ngx_recv_pt recv;
// 直接发送网络字符流的方法
ngx_send_pt send;
// 以ngx_chain_t链表为参数来接收网络字符流的方法
ngx_recv_chain_pt recv_chain;
// 以ngx_chain_t链表为参数来发送网络字符流的方法
ngx_send_chain_pt send_chain;
// 这个连接对应的ngx_listening_t监听对象，此连接由listening 监听端口的事件建立
ngx_listening_t *listening;
// 这个连接上已经发送出去的字节数
off_t sent;
// 可以记录日志的ngx_log_t对象
ngx_log_t *log;
/*
内存池，一般在accept一个新连接时，会创建一个内存池，而在这个连接结束时会销毁内存池。
*/
ngx_pool_t *pool;
//连接客户端的socketaddr结构体
struct sockaddr *sockaddr;
// socketaddr结构体的长度
socklen_t socklen;
// 连接客户端字符串形式的IP地址
ngx_str_t addr_text;
#if (NGX_SSL)
ngx_ssl_connection_t *ssl;
#endif
// 本机的监听端口对应的socketaddr结构体，也就是listening监听对象中的sockaddr成员
struct sockaddr *local_sockaddr;
/*
用于接收、缓存客户端发来的字符流，每个事件消费模块可自由决定从连接池中分配多大的空间给 buffer这个接收缓存字段。
例如，在HTTP模块中，它的大小决定于client_header_buffer_size配置项
*/
ngx_buf_t *buffer;
/*
该字段用于将当前连接以双向链表元素的形式添加到ngx_cycle_t核心结构体的reusable_connections_queue双向链表中，表示可重用的连接
*/
ngx_queue_t queue;
/*
连接使用次数。ngx_connection_t结构体每次建立一条来自客户端的连接，或者用于主动向后端服务器发起连接时 （ngx_peer_connection_t也使用它）
number都会加1
*/
ngx_atomic_uint_t number;
// 处理的请求次数
ngx_uint_t requests;
/*
缓存中的业务类型。任何事件消费模块都可以自定义需要的标志位。
这个buffered字段有8位，最多可以同时表示8个不同的业务。第三方模块在自定义buffered标志位时注意不要与可能使用的模块定义的标志位冲突。
*/
unsigned buffered:8;
/*
本连接记录日志时的级别，它占用了3位，取值范围是0～7，但实际上目前只定义了5个值，由ngx_connection_log_error_e枚举表示，如下：
typedef enum{
NGX_ERROR_ALERT = 0,
NGX_ERROR_ERR,
NGX_ERROR_INFO,
NGX_ERROR_IGNORE_ECONNRESET,
NGX_ERROR_IGNORE_EINVAL,
} ngx_connection_log_error_e;
*/
unsigned log_error:3; /* ngx_connection_log_error_e */
/*
标志位，为1表示独立的连接，如从客户端发起的连接；
为0表示依靠其他连接的行为而建立起来的非独立连接，如使用upstream机制向后端服务器建立起来的连接
*/
unsigned single_connection:1;
// 标志位，为1表示不期待字符流结束，目前无意义
unsigned unexpected_eof:1;
// 标志位，为1表示连接已超时
unsigned timedout:1;
// 标志位，为1表示连接处理过程中出现错误
unsigned error:1;
// 标志位，为1表示连接已经销毁。这里的连接指的是TCP连接，而不是ngx_connection_t结构体。
// 当destroy为1时，ngx_connection_t结构体仍然存在，但其对应的套接字，内存池已经不可用。
unsigned destroyed:1;
// 标志位，为1表示连接处于空闲状态，如keepalive请求中两次请求之间的状态
unsigned idle:1;
// 标志位，为1表示连接可重用，它与上面的queue字段是对应使用的
unsigned reusable:1;
// 标志位，为1表示连接关闭
unsigned close:1;
// 标志位，为1表示正在将文件中的数据发往连接的另一端
unsigned sendfile:1;
/*
标志位，如果为1， 则表示只有在连接套接字对应的发送缓冲区必须满足最低设置的大小阀值，事件驱动模型才会分发该事件。
*/
unsigned sndlowat:1;
// 标志位，表示如何使用TCP的nodelay特性。它的取值范围是ngx_connection_tcp_nodelay_e
unsigned tcp_nodelay:2; /* ngx_connection_tcp_nodelay_e */
// 标志位，表示如何使用TCP的nopush特性，它的取值范围是ngx_connection_tcp_nopush_e
unsigned tcp_nopush:2; /* ngx_connection_tcp_nopush_e */
#if (NGX_HAVE_IOCP)
unsigned accept_context_updated:1;
#endif
#if (NGX_HAVE_AIO_SENDFILE)
// 标志位，为1时表示使用异步I/O的方式将磁盘上文件发送给网络连接的另一端
unsigned aio_sendfile:1;
// 使用异步 I/O 方式发送的文件，busy_sendfile缓冲区保存待发送文件的信息
ngx_buf_t *busy_sendfile;
#endif
#if (NGX_THREADS)
ngx_atomic_t lock;
#endif
};struct ngx_event_s {
// 事件相关的对象。通常data都是指向ngx_connection_t连接对象。开启文件异步I/O时，它可能会指向ngx_event_aio_t结构体
void *data;
/*
标志位，为1时表示事件是可写的。通常情况下，它表示对应的TCP连接目前状态是可写的，也就是连接处于可以发送网络包的状态。
*/
unsigned write:1;
// 标志位，为1时表示为此事件可以建立新的连接。通常情况下，在ngx_cycle_t中的listening动态数组中，每一个监听对象ngx_listening_t
// 对应的读事件中的accept标志位才会是1
unsigned accept:1;
/* used to detect the stale events in kqueue, rtsig, and epoll */
/*
这个标志位用于区分当前事件是否过期，它仅仅是给事件驱动模块使用的，而事件消费模块可不用关心。
为什么需要这个标志位呢？当开始处理一批事件时，处理前面的事件可能会关闭一些连接，而这些连接有可能影响这批事件中还未处理到的后面的事件。
这时，可通过instance标志位来避免处理后面的已经过期的事件。
*/
unsigned instance:1;
/*
* the event was passed or would be passed to a kernel;
* in aio mode - operation was posted.
*/
/*
标志位，为1表示当前事件是活跃的，为0表示事件是不活跃的。
这个状态对应着事件驱动模块处理方式的不同。例如，在添加事件，删除事件和处理事件时，active标志位的不同都会对应着不同的处理方式。
在使用事件时，一般不会直接改变active标志位。
*/
unsigned active:1;
/*
标志位，为1表示禁用事件，仅在kqueue或者rtsig事件驱动模块中有效，而对于epoll事件驱动模块则没有意义。
*/
unsigned disabled:1;
/* the ready event; in aio mode 0 means that no operation can be posted */
// 标志位，为1表示当前事件已经准备就绪，也就是说，允许这个事件的消费模块处理这个事件。在HTTP框架中，经常会检查事件的ready标志位，
// 以确定是否可以接收请求或者发送相应
unsigned ready:1;
// 该标志位仅对kqueue,eventport等模块有意义，而对于linux上的epoll事件驱动模块则是无意义的。
unsigned oneshot:1;
/* aio operation is complete */
// 该标志位用于异步AIO事件的处理
unsigned complete:1;
// 标志位，为1时表示当前处理的字符流已经结束
unsigned eof:1;
// 标志位，为1表示事件在处理过程中出现错误
unsigned error:1;
// 标志位，为1表示这个事件已经超时，用以提示事件的消费模块做超时处理，它与timer_set都用了定时器
unsigned timedout:1;
// 标志位，为1表示这个事件存在于定时器中
unsigned timer_set:1;
// 标志位，delayed为1表示需要延迟处理这个事件，它仅用于限速功能
unsigned delayed:1;
// 标志位目前没有使用
unsigned read_discarded:1;
// 目前没有使用
unsigned unexpected_eof:1;
// 标志位，为1表示延迟建立TCP连接，也就是说，经过TCP三次握手后并不建立连接，而是要等到真正受到数据包后才会建立TCP连接
unsigned deferred_accept:1;
/* the pending eof reported by kqueue or in aio chain operation */
// 标志位，为1表示等待字符流结束，它只与kqueue和aio事件驱动机制有关
unsigned pending_eof:1;
#if !(NGX_THREADS)
// 标志位，如果为1，表示在处理post事件时，当前事件已经准备就绪
unsigned posted_ready:1;
#endif
#if (NGX_WIN32)
/* setsockopt(SO_UPDATE_ACCEPT_CONTEXT) was successful */
unsigned accept_context_updated:1;
#endif
#if (NGX_HAVE_KQUEUE)
unsigned kq_vnode:1;
/* the pending errno reported by kqueue */
int kq_errno;
#endif
/*
* kqueue only:
* accept: number of sockets that wait to be accepted
* read: bytes to read when event is ready
* or lowat when event is set with NGX_LOWAT_EVENT flag
* write: available space in buffer when event is ready
* or lowat when event is set with NGX_LOWAT_EVENT flag
*
* iocp: TODO
*
* otherwise:
* accept: 1 if accept many, 0 otherwise
*/
#if (NGX_HAVE_KQUEUE) || (NGX_HAVE_IOCP)
int available;
#else
// 标志位，在epoll事件驱动机制下表示一次尽可能多建立TCP连接，它与mulit_accept配置项对应
unsigned available:1;
#endif
// 这个事件发生时的处理方法，每个事件消费模块都会重新实现它
ngx_event_handler_pt handler;
#if (NGX_HAVE_AIO)
#if (NGX_HAVE_IOCP)
// Windows系统下的一种事件驱动模型
ngx_event_ovlp_t ovlp;
#else
// Linux aio机制中定义的结构体
struct aiocb aiocb;
#endif
#endif
// 由于epoll 事件驱动方式不使用index，所以这里不再说明
ngx_uint_t index;
// 可用于记录error_log日志的ngx_log_t对象
ngx_log_t *log;
// 定时器节点，用于定时器红黑树中,<span style="font-family: Consolas, 'Bitstream Vera Sans Mono', 'Courier New', Courier, monospace; font-size: 12.800000190734863px; line-height: 13.75px; white-space: pre;">加入红黑树时需要的辅助节点</span>
ngx_rbtree_node_t timer;
// 标志位，为1时表示当前事件已经关闭，epoll模块没有使用它
unsigned closed:1;
/* to test on worker exit */
// 无实际意义
unsigned channel:1;
// 无实际意义
unsigned resolver:1;
#if (NGX_THREADS)
unsigned locked:1;
unsigned posted_ready:1;
unsigned posted_timedout:1;
unsigned posted_eof:1;
#if (NGX_HAVE_KQUEUE)
/* the pending errno reported by kqueue */
int posted_errno;
#endif
#if (NGX_HAVE_KQUEUE) || (NGX_HAVE_IOCP)
int posted_available;
#else
unsigned posted_available:1;
#endif
ngx_atomic_t *lock;
ngx_atomic_t *own_lock;
#endif
/* the links of the posted queue */
/*
post事件将会构成一个队列，再统一处理，这个队列以next和prev作为链表指针，以此构成一个简易的双向链表，
其中next指向后一个事件的地址，prev指向前一个事件的地址。
*/
ngx_event_t *next;
ngx_event_t **prev;
#if 0
/* the threads support */
/*
* the event thread context, we store it here
* if $(CC) does not understand __thread declaration
* and pthread_getspecific() is too costly
*/
void *thr_ctx;
#if (NGX_EVENT_T_PADDING)
/* event should not cross cache line in SMP */
uint32_t padding[NGX_EVENT_T_PADDING];
#endif
#endif
};当处理完配置文件解析（针对listen指令）时，nginx开始处理这些listen。将它们放在
ngx_cycle->listening里。监听是有读事件，而没有写事件的，epoll有两个模式LT和ET，监听采用LT，监听的read事件的处理函数为ngx_event_accept.
<span style="font-size:14px;font-weight: normal;">struct ngx_cycle_s {
...
ngx_array_t listening; // 动态数组，每个数组元素储存着ngx_listening_t成员，表示监听端口及相关的参数
...
}
struct : {
// socket套接字句柄
ngx_socket_t fd;
// 监听socketaddr地址
struct sockaddr *sockaddr;
// socketaddr地址长度
socklen_t socklen; /* size of sockaddr */
...
};</span>这个产生的fd(已连接套接字)，有读和写事件，对读事件的处理函数为ngx_http_init_request。因此一个连接请求一旦发送完，就从这个函数开始执行
。这也是request开始的生命周期，这里的结构体为：
<span style="font-size:14px;">//这个结构定义了一个HTTP请求。
struct ngx_http_request_s {
uint32_t signature; /* "HTTP" */
// 这个请求对应的客户端连接
ngx_connection_t *connection; //当前request的连接
// 指向存放所有HTTP模块的上下文结构体的指针数组
void **ctx; //上下文
// 指向请求对应的存放main级别配置结构体的指针数组
void **main_conf; //main配置
// 指向请求对应的存放srv级别配置结构体的指针数组
void **srv_conf; //srv配置
// 指向请求对应的存放loc级别配置结构体的指针数组
void **loc_conf; //loc配置
/*
在接收完HTTP头部，第一次在业务上处理HTTP请求时，HTTP框架提供的处理方法是ngx_http_process_request。
但如果该方法无法一次处理完该请求的全部业务，在归还控制权到epoll事件模块后，该请求再次被回调时，将通过ngx_http_request_handler方法来处理，
而这个方法中对于可读事件的处理就是调用read_event_handler处理请求。也就是说，HTTP模块希望在底层处理请求的读事件，重新实现read_evet_handler方法。
*/
ngx_http_event_handler_pt read_event_handler;
/*
与read_event_handler回调方法类似，如果ngx_http_request_handler方法判断当前事件是可写事件，则调用write_event_handler处理请求。
*/
ngx_http_event_handler_pt write_event_handler;
#if (NGX_HTTP_CACHE)
ngx_http_cache_t *cache;
#endif
// upstream机制用到的结构体
ngx_http_upstream_t *upstream; //load-balance，如果模块是load-balance的话设置这个
ngx_array_t *upstream_states;
/* of ngx_http_upstream_state_t */
/*
表示这个请求的内存池，在ngx_http_free_request 方法中销毁。它与ngx_connection_t中的内存池意义不同，当请求释放时，
TCP连接可能并没有关闭，这时请求的内存池会销毁，但ngx_connection_t的内存池不会销毁
*/
ngx_pool_t *pool; //连接池
// 用于接收HTTP请求内容的缓冲区，主要用于接收HTTP头部
ngx_buf_t *header_in;
/*
ngx_http_prcess_request_headers 方法在接收，解析完HTTP请求的头部后，会把解析完的每个HTTP头部加入到headers_in的headers连表中，
同时会构造headers_in中的其他成员
*/
ngx_http_headers_in_t headers_in; //request的header
/*
HTTP模块会把想要发送到HTTP相应信息放到headers_out中，期望HTTP框架将headers_out中的成员序列化为HTTP相应包发送给用户
*/
ngx_http_headers_out_t headers_out; //response的header，使用ngx_http_send_header发送
// 接收HTTP请求中包体的数据结构
ngx_http_request_body_t *request_body; //response的body
// 延迟关闭连接的时间
time_t lingering_time;
/*
当前请求初始化时的时间。如果这个请求是子请求，则该时间是自请求的生成时间；如果这个请求是用户发来的请求，则是建立起TCP连接后，第一次接收到可读事件时的时间
*/
time_t start_sec;
// 与start_sec配合使用，表示相对于start_sec秒的毫秒偏移量
ngx_msec_t start_msec;
ngx_uint_t method;
ngx_uint_t http_version; //http的版本
ngx_str_t request_line;
ngx_str_t uri; //请求的路径 eg '/query.php'
ngx_str_t args; //请求的参数 eg 'name=john'
ngx_str_t exten;
ngx_str_t unparsed_uri;
ngx_str_t method_name;
ngx_str_t http_protocol;
/*
表示需要发送给客户端的HTTP相应。out中保存着由headers_out中序列化后的表示HTTP头部的TCP流。在调用ngx_http_output_filter方法后，
out中还会保存待发送的HTTP包体，它是实现异步发送的HTTP相应的关键
*/
ngx_chain_t *out; //输出的chain
/*
当前请求既可能是用户发来的请求，也可能是派生出的子请求，而main则标识一系列相关的派生子请求的原始请求，
我们一般可以通过main和当前请求的地址是否相等来判断当前请求是否为用户发来的原始请求。
*/
ngx_http_request_t *main;
// 当前请求的父请求。注意，父请求未必是原始请求
ngx_http_request_t *parent;
// 与subrequest子请求相关的功能。
ngx_http_postponed_request_t *postponed;
ngx_http_post_subrequest_t *post_subrequest;
/*
所有自请求都是通过posted_requests这个单链表来链接起来的，执行post子请求时调用的ngx_http_run_posted_requests
方法就是通过遍历该单链表来执行子请求的。
*/
ngx_http_posted_request_t *posted_requests;
ngx_http_virtual_names_t *virtual_names;
/*
全局的ngx_http_phase_engine_t结构体中定义了一个ngx_http_phase_handler_t 回调方法组成的数组，
而phase_handler成员则与该数组配合使用，表示请求下次应当执行以phase_handler作为序号指定的数组中的回调方法。
HTTP框架正是以这种方式把各个HTTP模块集成起来处理请求的。
*/
ngx_int_t phase_handler;
/*
表示NGX_HTTP_CONTENT_PHASE阶段提供给HTTP模块处理请求的一种方式，content_handler指向HTTP模块实现的请求处理方法。
*/
ngx_http_handler_pt content_handler;
/*
在NGX_HTTP_ACCESS_PHASE阶段需要判断请求是否具有访问权限时，通过access_code来传递HTTP模块的handler回调方法的返回值，
如果access_code为0，则表示请求具备访问权限，反之则说明请求不具备访问权限
*/
ngx_uint_t access_code;
ngx_http_variable_value_t *variables;
#if (NGX_PCRE)
ngx_uint_t ncaptures;
int *captures;
u_char *captures_data;
#endif
size_t limit_rate;
/* used to learn the Apache compatible response length without a header */
size_t header_size;
// HTTP请求的全部长度，包括HTTP包体
off_t request_length;
ngx_uint_t err_status;
ngx_http_connection_t *http_connection;
ngx_http_log_handler_pt log_handler;
// 在这个请求中，如果打开了某些资源，并需要在请求结束时释放，那么都需要在把定义的释放资源方法添加到cleanup成员中。
ngx_http_cleanup_t *cleanup;
unsigned subrequests:8;
/*
表示当前请求的引用次数。例如，在使用subrequest功能时，依附在这个请求上的自请求数目会返回到count上，每增加一个子请求，
count数就要加1。其中任何一个自请求派生出新的子请求时，对应的原始请求（main指针指向的请求）的count值都要加1.又如，
当我们接收HTTP包体的时候，由于这也是一个异步调用，所以count上也需要加1，这样在结束请求时，就不会在count引用计数未清零时销毁请求。
*/
unsigned count:8;
// 标志位，目前仅由aio使用
unsigned blocked:8;
// 标志位，为1表示当前请求正在使用异步文件IO
unsigned aio:1;
unsigned http_state:4;
/* URI with "/." and on Win32 with "//" */
unsigned complex_uri:1;
/* URI with "%" */
unsigned quoted_uri:1;
/* URI with "+" */
unsigned plus_in_uri:1;
/* URI with " " */
unsigned space_in_uri:1;
unsigned invalid_header:1;
unsigned add_uri_to_alias:1;
unsigned valid_location:1;
unsigned valid_unparsed_uri:1;
// 标志位，为1表示URL发生过rewrite重写
unsigned uri_changed:1;
/*
表示使用rewrite重写URL的次数。因为目前最多可以更改10次，所以uri_changes初始化为11，而每重写URL一次就把uri_changes减1，
一旦uri_changes等于0，则向用户返回失败
*/
unsigned uri_changes:4;
unsigned request_body_in_single_buf:1;
unsigned request_body_in_file_only:1;
unsigned request_body_in_persistent_file:1;
unsigned request_body_in_clean_file:1;
unsigned request_body_file_group_access:1;
unsigned request_body_file_log_level:3;
unsigned subrequest_in_memory:1;
unsigned waited:1;
#if (NGX_HTTP_CACHE)
unsigned cached:1;
#endif
#if (NGX_HTTP_GZIP)
unsigned gzip_tested:1;
unsigned gzip_ok:1;
unsigned gzip_vary:1;
#endif
unsigned proxy:1;
unsigned bypass_cache:1;
unsigned no_cache:1;
/*
* instead of using the request context data in
* ngx_http_limit_zone_module and ngx_http_limit_req_module
* we use the single bits in the request structure
*/
unsigned limit_zone_set:1;
unsigned limit_req_set:1;
#if 0
unsigned cacheable:1;
#endif
unsigned pipeline:1;
unsigned plain_http:1;
unsigned chunked:1;
unsigned header_only:1;
// 标志位，为1表示当前请求是keepalive请求
unsigned keepalive:1;
// 延迟关闭标志位，为1表示需要延迟关闭。例如在接收完HTTP头部时如果发现包体存在，该标志位会设置1，而放弃接收包体会设为0
unsigned lingering_close:1;
// 标志位，为1表示正在丢弃HTTP请求中的包体
unsigned discard_body:1;
// 标志位，为1表示请求的当前状态是在做内部跳转
unsigned internal:1;
unsigned error_page:1;
unsigned ignore_content_encoding:1;
unsigned filter_finalize:1;
unsigned post_action:1;
unsigned request_complete:1;
unsigned request_output:1;
// 标志位，为1表示发送给客户端的HTTP相应头部已经发送。在调用ngx_http_send_header方法后，若已经成功地启动相应头部发送流程，
// 该标志位就会置1，用来防止反复地发送头部。
unsigned header_sent:1;
unsigned expect_tested:1;
unsigned root_tested:1;
unsigned done:1;
unsigned logged:1;
// 表示缓冲中是否有待发送内容的标志位
unsigned buffered:4;
unsigned main_filter_need_in_memory:1;
unsigned filter_need_in_memory:1;
unsigned filter_need_temporary:1;
unsigned allow_ranges:1;
#if (NGX_STAT_STUB)
unsigned stat_reading:1;
unsigned stat_writing:1;
#endif
/* used to parse HTTP headers */
// 状态机解析HTTP时使用stats来表示当前的解析状态。
ngx_uint_t state;
ngx_uint_t header_hash;
ngx_uint_t lowcase_index;
u_char lowcase_header[NGX_HTTP_LC_HEADER_LEN];
u_char *header_name_start;
u_char *header_name_end;
u_char *header_start;
u_char *header_end;
/*
* a memory that can be reused after parsing a request line
* via ngx_http_ephemeral_t
*/
u_char *uri_start;
u_char *uri_end;
u_char *uri_ext;
u_char *args_start;
u_char *request_start;
u_char *request_end;
u_char *method_end;
u_char *schema_start;
u_char *schema_end;
u_char *host_start;
u_char *host_end;
u_char *port_start;
u_char *port_end;
unsigned http_minor:16;
unsigned http_major:16;
};
</span>超时机制用了红黑树，ngx_event_timer_rbtre。初始化:ngx_single_process_cycle->ngx_event_process_init
->ngx_event_timer_init(cycle->log);
ngx_event_expire_timers(void)
{
...
for ( ;; ) {
node = ngx_rbtree_min(root, sentinel);
/* node->key <= ngx_current_time，很简单巧妙的设计，怎么视为超时 */
if ((ngx_msec_int_t) (node->key - ngx_current_msec) <= 0) {
ev = (ngx_event_t *) ((char *) node - offsetof(ngx_event_t, timer));
ngx_rbtree_delete(&ngx_event_timer_rbtree, &ev->timer);
ev->timer_set = 0; // 重置timer_set
ev->timedout = 1; // 标记为超时
ev->handler(ev); // 马上处理，注意这里没有处理成如果超时就关闭连接，这是由handler自行处理的
// 后面会再解释这个设计
continue;
}
break; // 如果没有超时的事件，结束退出
}
}ngx_epoll_add_event
ngx_epoll_del_event
ev = (ngx_event_t *) ((char *) node - offsetof(ngx_event_t, timer));
这段代码巧妙的运用数据结构的偏移来找到对应的事件。
梳理
如果我们自己写业务逻辑，如何处理一个事件呢？假设fd已经有了，可能是你通过socket函数产生的。
获取连接：
c = ngx_get_connection(fd);
处理read,write：
c->read->handler = ngx_http_init_request;
c->write->handler = ngx_http_empty_handler;
定时器处理：定时器是针对事件的
ngx_add_timer(c->read, c->listening->post_accept_timeout);
ngx_add_timer(c->write, ...);
注册事件：即加入epoll，这里一般采用ET模式。
ngx_handle_read_event(c->read, 0);
ngx_handle_read_event(c->write, 0);
上面的例子将read，write都处理了，实际情况不一定得这样，看你要不要处理读或写事件，哪个需要，启用哪个。
＃＃参考http://my.oschina.net/fqing/blog/83516
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- nginx超时转发机制
- Nginx一直报504超时，配置相关参数好了
- Android超时机制的处理（很不错）
- python脚本设置超时机制系统时间的方法
- nginx 健康检查和负载均衡机制分析
- 深入理解PHP之：Nginx 与 FPM 的工作机制
- java利用Condition做超时机制
- Netty的超时机制
- Nginx 与 PHP-FPM 的协作机制
- 泛型委托+异步回调+超时机制
- NGINX 健康检查和负载均衡机制分析
- 一个带冲突率检查、超时机制的哈希表
- 三分钟看懂Nginx服务器的缓存原理和机制
- nginx android app 慢网络请求超时
- Nginx 利用Linux 的PAM 机制整合各种登录
- nginx超时
- Dubbo超时机制导致的雪崩连接
- nginx后端服务器返回给nginx502、504、404、执行超时等错误状态的解决方法
- [译]Go net/http 超时机制完全手册