趁着年轻

HTTP 的Content-Range支持对于一般的网页处理没啥重要的作用，但是对于大文件的下载，CDN回源，点续传功能的作用是非常重要的。

Content-Range允许一次只下载一个文件的一部分，后面再分批次下载文件的其他部分，或者并发下载，提高下载速度，这样如果在下载一个文件的过程中，网络断开了，恢复后不需要重新下载。

nginx 对Content-Range的支持包括header处理和body处理，分别用来解析客户端发送过来的Range header 和裁剪返回给客户端的请求数据Body。其实现分别由2个filter过滤模块完成，分别是ngx_http_range_header_filter_module和ngx_http_range_body_filter_module。下面分别介绍。 阅读全文...

上篇文章“Nginx upstream原理分析【1】给后端FastCGI发送数据”讲到了给PHP等FCGI程序发送数据了，也就是ngx_http_upstream_send_request函数，下面接着写。

ngx_http_upstream_send_request调用输出的过滤器，发送数据到后端，前面已经介绍过，ngx_http_proxy_create_request函数会将客户端发送过来的HEADER，以及body部分的数据组成一块块的FCGI协议的buffer，放到u->request_bufs成员上面，因此在发送数据的时候，就需要吧这块数据发送给后端的PHP或者其他模块。send_request函数完成的任务有如下几个：

1. 连接状态诊断，调用ngx_http_upstream_test_connect();
2. 调用ngx_output_chain函数将需要发送的数据发送出去(不一定真的发送出了，可能留在缓冲链表里面)；
3. 设置定时器send_timeout，ngx_tcp_push标志位等；
4. 如果连接可读，则调用ngx_http_upstream_process_header()尝试读取FCGI的返回数据。

下面分2部分介绍这个函数： 阅读全文...

在前一篇文章“Nginx upstream原理分析【1】新连接的处理过程”中我们介绍了一个连接从accept到ngx_http_core_run_phases过程处理所发生的事情，后面剩下的就是FCGI的相关处理了，留在这里进行介绍。

0、写在前面的话

ngx_http_core_run_phases函数会不断调用cmcf->phase_engine.handlers上面的checker，从而调用rewrite模块，find_config模块等的函数进行相应的处理，对于我们今天要介绍的FCGI模块的处理，其checker调用的是ngx_http_core_content_phase，后者调用了ngx_http_fastcgi_handler进行相关的处理。 阅读全文...

在上一篇“Nginx upstream原理分析【0】指令解析”中介绍了nginx对于upstream的指令解析，初始化的逻辑。这里介绍一个请求从一开始到后面是怎么处理的。

0、Accept接收新连接：

首先，nginx在ngx_init_cycle解析完配置后，就已经打开了所有的监听端口，然后会调用各个进程初始化函数，这样event模块的进程初始化函数为ngx_event_process_init，这个函数会将所有的listening端口结构跟ngx_connection_t结构进行关联，互相指向，并且为这个连接注册了读写监控事件，这个事件的句柄正式：ngx_event_accept函数，这样，当listen端口有新连接到来的时候会调用ngx_event_accept函数。

下面来简单看一下ngx_event_accept函数的逻辑，函数首先循环最多5次调用accept（）系统函数去接收这个连接，并计算一下本进程的负载，来进行简单的负载均衡： 阅读全文...

熟悉nginx的同学都知道upstream的重要作用，当nginx接收到一个连接后，读取完客户端发送出来的Header，然后就会进行各个处理过程的调用。

之后就是upstream发挥作用的时候了，upstream在客户端跟后端比如FCGI/PHP之间，接收客户端的HTTP body，发送给FCGI，然后接收FCGI的结果，发送给客户端。作为一个桥梁的作用。同时，upstream为了充分显示其灵活性，至于后端具体是什么协议，什么系统他都不care，我只实现主体的框架，具体到FCGI协议的发送，接收，解析，这些都交给后面的插件来处理，比如有fastcgi,memcached,proxy等插件，我之前也做过一个简单的跟公司内部系统的module，其实他们都是一种回调形式的模块，跟upstream模块配合从而完成整个请求。如无特殊说明，后面都已FCGI作为后端模块为例说明。 阅读全文...

之前介绍过Nginx的FCGI模块，upstream模块的解析，今晚扫了一下mecached模块的代码，下面记录一下。

总的来说，mecached 模块是继proxy模块外的一个很简单的content模块了，非常简单，就500多行代码，也没有处理一次发送多个KEY给mecached的情况，也没有像FCGI那样做buffering处理，这样mecached返回一点点数据，nginx就发送一点数据给客户端，比较简单。

阅读全文...

上一篇Nginx upstream原理分析【2】-带buffering读取upstream数据 我们介绍了nginx在带buffering的情况下是如何读取FCGI数据的，这里我们介绍他是怎么给客户端返回数据的。

从上篇文章我们知道ngx_event_pipe这个函数一句参数不同，既可以读取upstream数据，也可以给客户端返回数据。其调用的功能函数分别为：ngx_event_pipe_read_upstream 和ngx_event_pipe_write_to_downstream。nginx读取upstream的数据后，会把数据放在p->in链表里面，当然如果缓存不够等原因，写入了磁盘的话，nginx总是将p->in的前面部分写入磁盘，因此会记录在p->out链表上面。在发送时就围绕这2个成员进行了。
发送数据时，客户端的连接结构存放在p->downstream。先来看一下缓存结构：
阅读全文...

上篇文章Nginx upstream原理分析【1】-无缓冲模式发送数据 讲到了nginx upstream在不带buffer的情况下，是如何接收upstream数据然后把它们发送给客户端的。这里讲一下带缓存的情况下nginx是怎么巧妙的完成这一任务的。

回到ngx_http_upstream_send_response函数，这个函数发送请求数据给客户端。里面会分别发送header,body，这个在上篇文章已经介绍过了，对于FCGI这种带buffering的数据处理，这里nginx是用所谓的event_pipe方式处理的，pipe为管子的意思，顾名思义就是读写事件的管道。

其所有的处理都集中在ngx_event_pipe_s这个结构体上，结构体包含指向upstream连接，指向客户端的连接的指针，以及尽心各个缓冲区管理的指针，还有input_filter、output_filter等函数回调，以及一堆标志位。这里先看一下这个结构的内容：
阅读全文...

今天花了点时间学习nginx rewrite模块的代码，其跟脚本解析是紧密相连的。
老毛病，贴个代码，以后补图，脑袋快撑不住了····
其他注释的代码在这里：https://github.com/kulv2012/ReadNginxSrc 阅读全文...

此处记录一下在看ngx_times.c时的随手写下的注释。 阅读全文...