Nginx配置文件解析详解

Nginx的配置解析相关的部分比较绕,比如为何要有4重指针,比如NGX_MAIN_CONF , loc_conf,NGX_DIRECT_CONF有什么区别呢?这些我前面的blog都有些涉及,这次主要是把配置这块完全拿出来然后来分析下。

首先来看配置解析时的数据结构,这里主要是ngx_conf_t,这个结构保存了解析配置文件所需要的一些域,这个是非常重要的一个数据结构,我们详细来看这个结构:

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
  
struct ngx_conf_s {

//当前解析到的命令名

char *name;

//当前命令的所有参数

ngx_array_t *args;

//使用的cycle

ngx_cycle_t *cycle;

//所使用的内存池

ngx_pool_t *pool;

//这个pool将会在配置解析完毕后释放。

ngx_pool_t *temp_pool;

//这个表示将要解析的配置文件

ngx_conf_file_t *conf_file;

//配置log

ngx_log_t *log;

//主要为了提供模块的层次化(后续会详细介绍)

void *ctx;

//模块类型

ngx_uint_t module_type;

//命令类型

ngx_uint_t cmd_type;

//模块自定义的handler

ngx_conf_handler_pt handler;

//自定义handler的conf

char *handler_conf;

};

阅读全文

hotwheels源码剖析

在霸爷的推荐下,看了hotwheels的代码,接下来我就来分析下hotwheels的代码(主要是server端代码),hotwheels是干吗的呢,介绍在这里:

https://github.com/tolbrino/hotwheels

Janus is a messaging server optimized to unicast over TCP to thousands of clients subscribed to topics of interest.

The ultimate goal is to maintain a latency of less than 2 seconds for 20 thousand clients on Amazon EC2 (small instance).

首先来看janus.app:

[erlang]

{application, janus,

[{description, “Janus”},

{vsn, “0.0.1”},

{id, “janus”},

{modules, [barrier,

bin,

bot,

client_proxy,

common,

flashbot,

histo,

janus,

janus_acceptor,

janus_admin,

janus_app,

janus_flash,

launcher,

mapper,

pubsub,

topman,

t,

transport,

util

]},

{registered, [janus_sup,

janus_topman_sup,

janus_proxy_mapper_sup,

janus_transport_sup,

janus_listener]},

{applications, [kernel,

stdlib,

mnesia,

inets

]},

{mod, {janus_app, []}},

{env, []}

]

}.

[/erlang]

阅读全文

nginx中cache的设计和实现(一)

Nginx的cache实现比较简单,没有使用内存,全部都是使用文件来对后端的response进行cache,因此nginx相比varnish以及squid之类的专门做cache的server,可能效果不会那么好。特别如果cache内容比较大的话。不过还有一种折衷的处理,那就是挂载一个内存盘,然后让nginx cache到这个盘。

我这里的看的代码是1.1.17.

首先来看Nginx中如何开启cache,http cache主要是应用在upstream中的,因此upstream对应的两个命令来启用cache,一个是xxx_cache_path(比如proxy_cache_path),它主要是用来创建管理cache的共享内存数据结构(红黑树和队列).一个是xxx_cache,它主要是使用前面创建的zone。

先来看第一个命令,xxx_cache_path,它会调用ngx_http_file_cache_set_slot函数,在看这个函数之前,先来看ngx_http_file_cache_t这个数据结构,它主要用来管理所有的cache文件,它本身不保存cache,只是保存管理cache的数据结构。每一个xxx_cache_path都会创建一个ngx_http_file_cache_t.

阅读全文

c reference manual读书笔记(五)

这次主要是介绍一些c语言中的类型转换。

1 在c语言里面,除了位域之外所有的数据对象都是表示为一堆抽象的存储单元,每一个存储单元都是由很多位组成的,每位的值不是1就是0,并且每一个存储单元都必须有唯一的地址,并且他们的每一个的大小都是和char的大小一致。每个存储单元有多少位,c语言并没有要求,可是每个存储单元必须能够存储基本字符集的每一个字符。 在标准c中也称存储单元为byte。

2 c程序员一般来说不需要在意一些机器的对齐限制,因为编译器会做对齐操作,但是,c也给了程序员忽略对齐限制的能力,比如cast一个指针到另外的类型。不过这里要注意,假设你要将一个类型为S的指针转换成类型T的指针,此时如果S的对齐因子如果不小于T的对齐因子,那么这个转换就是安全的(也就是说此时你取T的值,是没问题的). 可是如果S的对齐因子如果小于T的对齐因子,此时会出现两种情况,第一种就是当使用转换后的指针时,直接出错。第二种就是硬件或者编译器来帮你找到一个合适的指针来使用这个地址。

3 c99中定义了指针类型uintptr_t和intptr_t这两个值并不是指针的大小,而是指针类型不会超过这两个值, 这里要注意,很多实现中函数指针和数据指针大小是不一样的。而NULL只是数据空指针。对象的值和对象类型的值是不一样的,因为会有一些padding,而这些padding是没有定义的,

阅读全文

nginx的upstream分享

今天给同事做的分享.

阅读全文

SPDY协议介绍

SPDY的主页: http://www.chromium.org/spdy

我主要看的是SPDY Protocol Drafts 3,这个草稿现在还没完成,google的人将它放在github上面: http://mbelshe.github.com/SPDY-Specification/

阅读全文

c reference manual读书笔记(四)

主要是介绍c语言中的类型

1 c语言里面分为数值类型(Arithmetic,包括整数,浮点.enum 等),指针类型,数组类型,结构类型,联合类型,函数类型以及void类型。c99中添加了_Bool _Complex _Imaginary三种新的类型。

2 标准c只定义了整数类型的最小精度。char至少8位,short/int至少16位,long至少32位。 long long至少64位。所有的范围都保存在limits.h中。

3 一个有符号的整数所能表示的范围,不仅依赖于位数,还依赖于2进制编码,比如现在的计算机一般都是使用2进制补码的表示(two’s complement)。这里要注意整数类型默认都是signed.

4 一个有符号的整数和无符号的混合的表达式(四则运算,比较等),都会先将有符号的整数转为无符号整数再进行。而所有的无符号的算术运算,最后都会把结果对2的n次方取摸。

阅读全文

linux下tcp选项TCP_DEFER_ACCEPT详解

TCP_DEFER_ACCEPT这个选项可能大家都知道,不过我这里会从源码和数据包来详细的分析这个选项。要注意,这里我所使用的内核版本是3.0.

首先看man手册中的介绍(man 7 tcp):

TCP_DEFER_ACCEPT (since Linux 2.4)

Allow a listener to be awakened only when data arrives on the socket. Takes an integer value (seconds), this can bound the maximum number of attempts TCP will make to complete the connection. This option should not be used in code intended to be portable.

我先来简单介绍下,这个选项主要是针对server端的服务器,一般来说我们三次握手,当客户端发送syn,然后server端接收到,然后发送syn + ack,然后client接收到syn+ack之后,再次发送ack(client进入establish状态),最终server端收到最后一个ack,进入establish状态。

而当正确的设置了TCP_DEFER_ACCEPT选项之后,server端会在接收到最后一个ack之后,并不进入establish状态,而只是将这个socket标记为acked,然后丢掉这个ack。此时server端这个socket还是处于syn_recved,然后接下来就是等待client发送数据, 而由于这个socket还是处于syn_recved,因此此时就会被syn_ack定时器所控制,对syn ack进行重传,而重传次数是由我们设置TCP_DEFER_ACCEPT传进去的值以及TCP_SYNCNT选项,proc文件系统的tcp_synack_retries一起来决定的(后面分析源码会看到如何来计算这个值).而我们知道我们传递给TCP_DEFER_ACCEPT的是秒,而在内核里面会将这个东西转换为重传次数.

这里要注意,当重传次数超过限制之后,并且当最后一个ack到达时,下一次导致超时的synack定时器还没启动,那么这个defer的连接将会被加入到establish队列,然后通知上层用户。这个也是符合man里面所说的(Takes an integer value (seconds), this can bound the maximum number of attempts TCP will make to complete the connection.) 也就是最终会完成这个连接.

阅读全文

nginx中upstream的设计和实现(五)

这次主要来分析upstream中的发送数据给client, 以及当buf不足,将一部分写到temp file的部分,他们对应的函数分别是ngx_event_pipe_write_to_downstream和ngx_event_pipe_write_chain_to_temp_file.

先来看ngx_event_pipe_write_to_downstream,这个函数顾名思义,就是写buf到临时文件。而所写的buf就是p->in,也就是将要发送给client的数据。

这个函数,它会处理两类的情况,一类是cache打开,一类是cache未打开。我们这里主要来分析cache关闭的情况。

首先来看这个函数的第一部分的代码,这部分代码主要是遍历p->in,然后计算能写多少buf到文件(temp file的size是有限制的).

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
  
//out就是将要保存到file的数据

if (p->buf_to_file) {

//cache打开的情况

fl.buf = p->buf_to_file;

fl.next = p->in;

out = &fl;

} else {

//得到数据

out = p->in;

}

//如果cache没有打开

if (!p->cacheable) {

size = 0;

cl = out;

ll = NULL;

ngx_log_debug1(NGX_LOG_DEBUG_EVENT, p->log, 0,

"pipe offset: %O", p->temp_file->offset);

//开始遍历out

do {

//计算大小

bsize = cl->buf->last – cl->buf->pos;

……………………………………………..

//看是否超过限制限制

if ((size + bsize > p->temp_file_write_size)

|| (p->temp_file->offset + size + bsize > p->max_temp_file_size))

{

break;

}

size += bsize;

ll = &cl->next;

cl = cl->next;

} while (cl);

ngx_log_debug1(NGX_LOG_DEBUG_EVENT, p->log, 0, "size: %z", size);

if (ll == NULL) {

return NGX_BUSY;

}

//cl存在则说明只有一部分buf能够写入到temp file,此时p->in保存剩下的chain

if (cl) {

p->in = cl;

*ll = NULL;

} else {

//否则说明所有的buf都写入到了temp file,此时p->in则设置为空

p->in = NULL;

p->last_in = &p->in;

}

} else {

//cache打开的情况,可以看到和上面类似.

p->in = NULL;

p->last_in = &p->in;

}

阅读全文

nginx中upstream的设计和实现(四)

这此主要是分析发送数据到客户端的部分以及buffering状态下,nginx接收upstream数据的部分,这也是upstream的最复杂的部分,这里我还是忽略了cache部分,以后我会专门写blog来分析nginx的cache部分。

这部分的函数入口是ngx_http_upstream_send_response,这里有一个很重要的标记,那就是u->buffering,这个标记的含义就是nginx是否会尽可能多的读取upstream的数据。如果关闭,则就是一个同步的发送,也就是接收多少,发送给客户端多少。默认这个是打开的。也就是nginx会buf住upstream发送的数据。

不管buffering是否打开,后端发送的头都不会被buffer,首先会发送header,然后才是body的发送,而body的发送就需要区分buffering选项了。如下图所示:

upstream_ac

阅读全文