nginx中处理http header详解(2)

然后是charset filter,这个主要是处理nginx内部的charset命令,转换为设置的编码。这个filter就不介绍了,主要是一个解码的过程。

再接下来是chunk filter,它主要是生成chunk数据,这里要注意nginx只支持服务端生成chunk,而不支持客户端发送的chunk数据。chunk的格式很简单,简单的来说就是大小+数据内容。

先来看chunk的header filter,在filter中,主要是用来判断是否需要chunk数据,然后设置相关标记位,以便于后面的body filter处理.

阅读全文

nginx中处理http header详解(1)

这里主要的头的处理是放在filter中做的,我们首先来看config(默认情况)后,nginx的obj目录下的ngx_modules.c这个文件中的关于filter的部分:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
     
ngx_module_t *ngx_modules[] = {

…………………………………………

&ngx_http_write_filter_module,

&ngx_http_header_filter_module,

&ngx_http_chunked_filter_module,

&ngx_http_range_header_filter_module,

&ngx_http_gzip_filter_module,

&ngx_http_postpone_filter_module,

&ngx_http_ssi_filter_module,

&ngx_http_charset_filter_module,

&ngx_http_userid_filter_module,

&ngx_http_headers_filter_module,

&ngx_http_copy_filter_module,

&ngx_http_range_body_filter_module,

&ngx_http_not_modified_filter_module,

NULL

};

阅读全文

nginx中处理stale event

man 7 epoll会发现这个东西,就是使用epoll中会遇到的问题:

o If using an event cache… If you use an event cache or store all the file descriptors returned from epoll_wait(2), then make sure to provide a way to mark its closure dynamically (i.e., caused by a previous event’s processing). Suppose you receive 100 events from epoll_wait(2), and in event #47 a condition causes event #13 to be closed. If you remove the structure and close(2) the file descriptor for event #13, then your event cache might still say there are events waiting for that file descriptor causing confusion.

这种事件也可以叫做stale event,而下面是man手册提出的解决方法:

One solution for this is to call, during the processing of event 47, epoll_ctl(EPOLL_CTL_DEL) to delete file descriptor 13 and close(2), then mark its associated data structure as removed and link it to a cleanup list. If you find another event for file descriptor 13 in your batch process‐ ing, you will discover the file descriptor had been previously removed and there will be no confusion.

问题很简单,由于大部分的服务器都会有一个连接池。而连接池是通过fd来进行定位,前面处理的事件会影响后面的事件,比如关闭掉了后面的事件,而后关闭掉的事件在当前的循环中还是会被处理,这种情况很好处理,比如设置fd为-1,就可以检测,可是还有一种情况,就是当你关闭了fd,然后设置-1之后,恰好接收到的新的连接的fd刚好和刚才close的fd的值是一样的。此时就会引起混乱了,也就是说我们需要区分事件是不是stale event,或者说是我们方才释放掉的fd被重新使用,而nginx中并没有按照上面man手册里面的方法,它的做法很巧妙,我们来看nginx如何做的。 首先要知道在nginx中是存在一个连接池的,所有的连接的获取和释放都是通过连接池来进行的,nginx中连接池很简单,就是一个简单的数组,有一个free_connections变量保存了所有可以使用的连接,它是一个链表,它的构造是这样子的,每个连接都有一个域data,如果释放一个连接,则这个连接的data就指向当前的free_connects,然后当前的释放的连接直接指向free_connections,也就是一个将连接加入free链表的 动作。

阅读全文

mac下编译linux kernel

这里我的gcc是4.5.1 binutils 是2.20.1 ,内核是2.6.35.3.

首先需要交叉编译gcc和binutils

port安装 gcc编译依赖的库gpm,mpfr和mpc.

然后开始编译gcc,这里有个要注意的就是需要指定gmp的include和lib路径,下面是我的config:

阅读全文

lua源码分析

这个是以前blog上写的一些,不过只是分析了一部分,以后会把代码分析完的,这里我把前面分析的做成了pdf供大家 下载

阅读全文

nginx源码剖析

下面的电子书是我以前的blog写的一些nginx源码的文章的合辑,上传到了google doc,欢迎大家下载

阅读全文

linux内核的tcp/ip协议栈分析

由于协议栈的分析大部分都是放在以前的blog,可是由于导入太麻烦,所以我做了个电子书,然后上传到google doc上,欢迎大家下载:

下载

阅读全文