fjs的专栏

这个应该是要分析的第一个模块吧，首先看该模块的定义(src/core/nginx.c)：static ngx_core_module_t ngx_core_module_ctx = { ngx_string("core"), ngx_core_module_create_conf, //创建配置的函数 ngx_core_module_init_conf //初

想要理解nginx服务器的源码，那么首先就必须理解它的模块化的思想，因为nginx是master加worker的方式进行运行的，因而在master进程以及worker进程中都会涉及到许多模块的初始化的地方，例如创建配置，读取配置等。在模块内又会提供许多的回调函数，这样在合适的地方调用这些回调函数就可以了。首先来看nginx模块化的最基本结构ngx_module_t，它的定义是在Src/Core

其实经过前面文章的分析，我们已经知道在Nginx启动的时候会先进行core类型模块的处理。在Nginx的每一部分都会有一个core类型的模块与之对应，在解析配置文件的时候，这些core类型的模块便是这些他们所代表的部分的入口。例如event部分，ngx_events_module模块就是一个core类型的模块，因而我们可以看到event部分的初始化其实是从ngx_events_module模块的命

刚开始我们要介绍一下http模块的定义：typedef struct { ngx_int_t (*preconfiguration)(ngx_conf_t *cf); //在解析配置文件http{}之前调用 ngx_int_t (*postconfiguration)(ngx_conf_t *cf); //在解析配置文件http{}之前调用 void

嗯，一个http服务器，起码得要有http的监听socket吧，嗯，这篇文章就讲nginx是如何初始化http监听socket的。首先我们先来看几个十分重要的配置结构：//监听的配置信息，在ngx_http_core_main_conf_t结构的ports数组中将会保存所有的端口监听配置信息typedef struct { ngx_int_t famil

这里先插入一张我找到的很好的一张图，描述了request初始化的整个过程：从这篇文章开始正式进入http部分了，首先应该着手的是nginx是如何初始化http request的，我们在前面的文章，我们知道当接收到一个connection后，nginx首先会调用ngx_listening_t的handler来处理这个connection，这个handler函数是ngx_http_init_con

在前面的文章，我们知道当Nginx获取到连接后，会首先对连接的请求进行处理，例如读取请求的uri，参数等，然后会调用ngx_http_core_run_phases函数对于该请求跑一遍phase，当所有的phase都跑完了以后，那么这个请求也就处理完成了。好，我们首先来看一下Nginx的phase的定义吧：//Nginx定义的11个phasetypedef enum { NGX_HT

前面的文章已经说了，Nginx把整个http的请求分为11个phase，每个phase都会有其对应的handler，有的phase只有一个handler，有的phase则会有多个handler，而且nginx将他们的handler组织成了类似于链表的结构，方便在调用的时候可以按照phase的顺序进行调用。这篇文章就来详细心的讲如何来调用这些handler的。在前面的文章我们也已经说过，当ngi

看到了后面才发现其实自己在server块命令这一部分并没有搞的太清楚，因而会影响到以后对代码的理解，因而从头又来看一遍，一定要把它搞明白。首先我们来看ngx_http_core_module的main_conf结构：typedef struct { /** * 存储所有的ngx_http_core_srv_conf_t，元素的个数等于server块的个数。 ，因为同一个http

其实看nginx的主要目的就是想要搞清楚它高并发是如何实现的，然后能够在它的基础上自己写一个静态文件服务器。我们知道nginx对request的处理分为phase来处理的，最终产生输出的phase为NGX_HTTP_CONTENT_PHASE，对静态文件的处理将会由ngx_http_static_module来处理，它将会在NGX_HTTP_CONTENT_PHASE注册一个handler函数

其实最开始想要看nginx的源代码的初衷就是为了搞懂它的nginx的事件驱动到底是怎么回事。。。到现在为止nginx代码的大体结构部分已经看的差不多了，对它的事件驱动也算是有了一个较为全面的了解，终于可以写这篇文章了。。。首先用一张图来描述整个event的结构：首先最高层的是epoll自己定义的事件结构：typedef union epoll_data { void

很早就该写这篇了，没想到一拖就是差不多半年。。。今天把它补上，不然的话，这部分的内容总是觉得差点什么。。。。前面的文章已经说过了，在nginx对http的request处理完成后，会对每一个request都走一遍phase，最后真正向请求方发送返回则是调用filter来实现的。。。首先来看filter的结构。。。。在nginx中利用单链表将各种filter组织起来，首先在Ngx_htt

已经看了一段时间的nginx的源代码了，但其实启动的过程一直感觉弄得不是很清楚，因为自己一直在回避配置文件的解析过程，以及具体是如何根据配置文件中的命令来回调相应模块所定义的回调函数。如果这个不弄清楚的话，其实很多地方都容易一知半解。好吧，这次决定把这部分弄清楚。首先我们先看看模块的命令的定义：//模块的命令定义struct ngx_command_s { ngx_str_t

在前面的文章我们已经知道，worker进程会调用所有模块的init process 函数，在ngx_event_core_module模块中，如果使用的是epoll模块的话，那么该函数会将epoll模块定义的方法关联起来，那么以后就可以直接使用epoll模块了。然后究竟是如何与epoll模块关联起来的呢？嗯，先看ngx_event_core_module模块的ngx_event_process

在前面的文章中，其实很多代码就涉及到加锁释放锁的动作了，但是自己一直避免去深究他们，好了这篇文章就讲Nginx是如何实现锁的吧，然后还要讲Nginx是如何使用锁来避免惊群的发生。在Nginx的锁的实现中，要分为两种情况，分别为支持原子操作以与不支持原子操作。其定义在Ngx_shmtx.h当中：//锁的定义typedef struct {#if (NGX_HAVE_ATOMIC_OPS)

前面的文章已经分析了nginx的模块化结构，下面开始进入nginx的初始化过程，要了解一个程序，那么首先应该从main函数开始，nginx的初始化也不例外：（1）调用ngx_get_options函数解析传进来的命令参数（2）调用ngx_time_init初始化时间相关的数据（3）调用ngx_log_init初始化日志相关（4）初始化全局变量ngx_cycle，将其置0，并为其创建

前面的的文章，我们已经知道在ngx初始化的时候，会将listening数组中的监听端口全部打开，那么这里就有问题，这些socket的信息是在哪里获取的呢？这篇文章将会对此进行分析。首先先看监听端口的定义：（src/core/ngx_connection.h）struct ngx_listening_s { ngx_socket_t fd; //int类型，sock

应该可以说ngx_cycle变量应该是nginx最重要的变量之一的，在源码的很多地方都会用到这个变量，首先看该变量结构体的定义：（src/core/Ngx_cycle.h）struct ngx_cycle_s { void ****conf_ctx; //一些配置上下文 ngx_pool_t *pool; //内

一般情况下nginx都是采用worker与master的方式启动的，这里我们将分析master进程，我们知道在nginx的main函数的最后会调用ngx_master_process_cycle函数，开始启动worker-master模式，那么我们就从这个函数开始，该函数的定义在src/os/unix/Ngx_process_cycle.c当中： sigemptyset(&set); //

嗯，这篇文章主要讲worker进程，从哪里开始讲呢，在上面的文章我们已经知道在master进程中会调用start_worker_process函数开启worker进程，在该函数中会调用ngx_spawn_process函数真正的创建worker进程，那么就从ngx_spawn_process函数开始吧（src/os/unix/Ngx_process.c）：其实函数还是比较简单的，首先是：//找

在了解Nginx进程之间通信的方法之前，首先要了解的一个结构是ngx_process_t，该结构用来保存fork出来的worker进程的信息（src/os/unix.process.h）：//对worker进程的一些数据的封装typedef struct { ngx_pid_t pid; //进程ID int status;

在讲Nginx的事件驱动之前，得先弄明白ngx_connection_t这个结构。（定义在Ngx_connection.h）他是nginx事件驱动的基础，每一个监听在worker进程中都会为其分配一个connection，每一个监听接收到的连接，worker进程也会用connection来维护它，直到连接的终止，该connection才被回收。额，由于它的定义实在太长了，所以这里就不列出来了，

终于可以写比较有意思的地方了，Nginx之所以性能很高的原因应该采用事件驱动的模式处理连接，而不是采用多线程或者多进程的方式应该算是很重要的原因吧。这篇文章先讲Nginx的事件驱动的初始化吧，其实底层只不过是用I/O复用的方式来实现的。首先我们应该知道两个非常重要的模块：ngx_events_module模块与ngx_event_core_module模块，ngx_events_module模

这篇文章讲Nginx是如何进行时间循环的，首先事件循环的起点就是监听端口获取连接，我们可以在ngx_event_core_module模块的ngx_event_process_init函数中看到如下的代码： /* for each listening socket */ /*为每个监听套接字从connection数组中分配一个连接，即一个slot*/ ls = cycle->li

在前面的文章里面就说到了在事件循环中除了要处理所有的从epoll中获取的事件之外，还要处理一些timer事件，这篇文章就讲讲Nginx的timer是如何实现的。在讲Nginx的实现之前，我们可以先回顾一下linux的定时器的实现。在linux中通过每次系统定时器时钟的中断的中断处理程序来设置相应的软中断位，该软中断的中断处理程序目的就是为了扫描系统中所有挂起的定时器，如果他们已经超时的话，那么

还是早就想写这篇了，只不过被老板安排写网站去了，一直没有腾出时间。。。在nginx中有两种事件类型，其中一种的引发点是epoll，也就是通过epoll来获取事件的源头，另外一种就是定时时间。。在前面的代码中就已经遇到过了，例如当nginx获取到一个客户端的连接时，需要对该连接进行初始化，同时还要给这个连接增加一个定时器，如果都超时了请求的数据都还没有接收完整，那么就直接断开这个连接。。。