nginx代码分析之转载

r囧r小猫 2022-08-27 11:39 1阅读 0赞

导读：  
  
　　nginx代码分析之（一）——初探  
  
　　不知道原创，作者联系下我吧。  
  
　　他的代码我全看过了，感觉是高层模型下做的最优精简指令。效果还是不错的。  
  
　　发现nginx是无意间在浏览器中看到新浪的一个错误页面“nginx ...”，不由起了好奇心，google了一把，发现这是一个支持负载均衡的反向代理服务器，俄罗斯人开发的，虽然没有走GNU或BSD的License，但是也算是一个开源软件。  
  
　　开源代理服务器最熟悉的还是Squid和Apache，但这两者都是正反向代理通吃的，而作为反向代理，实际上和正向代理有较大的差别。我想既然新浪也用它，那自然有它的独到之处。查了一下，中文的网页上说它的HTTP性能可以达到13000TPS以上，但是没有说明数据的出处，国外的网站上暂时找不到相应的数据，但很多人拿它和lighttpd相比。  
  
　　很快下载了nginx 0.5.32版本的代码，代码不多，才8万多行，在openssl的基础上支持HTTPS。和Apache的30多万行相比，精简了很多，  
  
　　作为web server或反向代理，要的就是一个快，要做到快，除了精简的代码之外，更关键的一点就是并发模型。  
  
　　Apache的弱点就在于它的并发模型是普通的进程/线程池，连接数和进程/线程数是1：1的，因此无论是prefork还是worker模式，都将每一个连接对应到一个独立的进程/线程。  
  
　　这样的并发模型在连接数不太多（1000以内）时还算可以，但在大规模并发时，其进程/线程总数会非常多。由于Apache本身也比较吃内存，所以到了1000以上的并发时，服务器的内存基本上也就被吃的差不多了，操作系统也在频繁地做进程/线程的切换，非常吃力。  
  
　　相比之下，更高级的大型网络服务系统（如电信的智能网系统）一般采用进程/线程池+状态机的模型——也即接数和进程/线程数是m：n的，这样进程/线程总数就不会由于连接的增多而增多，避免了内存和调度切换的开销，但这种做法对程序逻辑的要求较高，需要一个连接拆分为多个逻辑状态（创建，读，写，关闭等，根据实际业务还可以更加细化）每个进程/线程处理完某一种状态后，需要改变该连接的状态值，后续状态由下一个空闲的进程/线程处理。  
  
　　nginx就采用了这样的并发模型，对于连接状态的存储，nginx主要采用了这样一个复杂结构。  
  
　　struct ngx\_connection\_s \{  
  
　　void \*data;  
  
　　ngx\_event\_t \*read;  
  
　　ngx\_event\_t \*write;  
  
　　...  
  
　　\};  
  
　　结构ngx\_event\_t存储了连接IO状态的详细信息，同时所有的ngx\_event\_t组成了两个全局的链表，以便进行存取操作。  
  
　　在这两个数据结构的基础上，nginx使用了下面这两个函数来完成每个进程/线程的循环  
  
　　1. ngx\_locked\_post\_event  
  
　　这个函数负责更新某一个连接的状态，在检查到连接IO状态改变（比如通过select）后被调用。  
  
　　nginx以module的方式提供了select语义的多种实现：  
  
　　poll  
  
　　devpoll  
  
　　epoll  
  
　　eventport  
  
　　kqueue  
  
　　rtsig  
  
　　后面4种，都是BSD/Linux为加速IO操作而提供的异步IO模型  
  
　　2. ngx\_event\_thread\_process\_posted  
  
　　这个函数检查event表，并调用event对应的handler函数，每次处理1个event。  
  
　　这两个函数组合使用，就实现了最基本的m:n并发模型。  
  
　　nginx代码分析之（二）——Empty Gif是如何工作的  
  
　　访问新浪时，时常会有一些网页返回空白（但不是“此页无法显示”），从浏览器的信息中可以知道此时服务器返回了一个1×1的空白gif图片。  
  
　　这实际上是nginx实现的，nginx有一个名为Empty Gif的module，专门负责此项工作。  
  
　　由于这个module比较简单，我们就先从它入手，来看看nginx的模块实现。  
  
　　  
  
　　模块注册Empty Gif这个module只有一个文件——ngx\_http\_empty\_gif\_module.c  
  
　　这个文件比较简单，一开始定义并初始化了3个变量。  
  
　　static ngx\_command\_t ngx\_http\_empty\_gif\_commands\[\] = \{...\};  
  
　　static ngx\_http\_module\_t ngx\_http\_empty\_gif\_module\_ctx = \{...\};  
  
　　ngx\_module\_t ngx\_http\_empty\_gif\_module = \{...\};  
  
　　其中只有ngx\_http\_empty\_gif\_module是非静态的，我将暂时将其称为module主结构变量，  
  
　　而其余两个变量都可以由它访问到。  
  
　　但是如果继续查看nginx的源码，会发现没有其他地方引用ngx\_http\_empty\_gif\_module，  
  
　　那这个module是怎么注册并应用起来的呢？  
  
　　如果熟悉Apache的代码，会发现这和Apache 2.0的module机制非常类似——每个module都对应到一个module主结构变量，通过这个主结构变量可以访问到这个module的其他内容，该module所有的函数也用函数指针的方式存放在这些结构变量中。  
  
　　而且Apache同样没有其他地方的代码引用到module主结构变量。这是因为module不是必须的，该module在某一个特定的编译版本里是可以不存在的。因此一个module是否有效，不是通过代码来决定，而是通过编译选项来实现。  
  
　　在nginx代码的auto目录中，有一个名为sources的文件，根据编译选项（configure的参数）的不同，m4宏变量HTTP\_MODULES的值会发生变化：  
  
　　如果指定了使用empty gif模块（默认就是使用了），则最终m4宏变量HTTP\_MODULES的值可能如下：  
  
　　HTTP\_MODULES="ngx\_http\_module /  
  
　　ngx\_http\_core\_module /  
  
　　ngx\_http\_log\_module /  
  
　　ngx\_http\_upstream\_module /  
  
　　ngx\_http\_empty\_gif\_module "  
  
　　注意：这里的ngx\_http\_empty\_gif\_module字符串对应了ngx\_http\_empty\_gif\_module.c文件中的Module主结构变量名。  
  
　　编译之前的configure结束后，会在objs目录下生成一个名为ngx\_modules.c的文件，此文件的内容如下：  
  
　　\#include  
  
　　\#include  
  
　　extern ngx\_module\_t ngx\_core\_module;  
  
　　extern ngx\_module\_t ngx\_errlog\_module;  
  
　　extern ngx\_module\_t ngx\_conf\_module;  
  
　　...  
  
　　extern ngx\_module\_t ngx\_http\_empty\_gif\_module;  
  
　　...  
  
　　ngx\_module\_t \*ngx\_modules\[\] = \{  
  
　　&ngx\_core\_module,  
  
　　&ngx\_errlog\_module,  
  
　　&ngx\_conf\_module,  
  
　　...  
  
　　&ngx\_http\_empty\_gif\_module,  
  
　　...  
  
　　NULL  
  
　　\};  
  
　　在此生成了对ngx\_http\_empty\_gif\_module变量的引用，并将其放到了ngx\_modules表中，  
  
　　通过相关函数可以进行存取。  
  
　　这样，在编译时就完成了Empty Gif模块注册的过程。  
  
　　模块的初始化和应用初始化一般都是根据配置文件的内容来进行，但和我们一般写程序的做法不同——nginx并没有在一个统一的地方处理所有的配置，而是让每个模块负责处理自己的配置项，如果没有编译这个模块，则其对应的配置项就无法处理，这也是又一个和Apache的相似之处。  
  
　　nginx使用了ngx\_command\_t结构来描述某一个模块对应的配置项及处理函数。  
  
　　以Empty Gif模块为例：  
  
　　static ngx\_command\_t ngx\_http\_empty\_gif\_commands\[\] = \{  
  
　　\{ ngx\_string("empty\_gif"),  
  
　　NGX\_HTTP\_LOC\_CONF|NGX\_CONF\_NOARGS,  
  
　　ngx\_http\_empty\_gif,  
  
　　0,  
  
　　0,  
  
　　NULL \},  
  
　　0);"> ngx\_null\_command  
  
　　\};  
  
　　上面的定义表明：  
  
　　1. Empty Gif模块只处理一个配置项——“empty\_gif”  
  
　　2. 这个配置是一个Location相关的配置（NGX\_HTTP\_LOC\_CONF），  
  
　　即只有在处理某一个URL子集，如 /test\_\[0-9\]\*.gif时才生效。  
  
　　  
  
　　实际的配置文件可能如下：  
  
　　location ~ /test\_\[0-9\].gif \{  
  
　　empty\_gif;  
  
　　\}  
  
　　3. 这个配置项不带参数（NGX\_CONF\_NOARGS）  
  
　　4. 配置处理函数是ngx\_http\_empty\_gif  
  
　　ngx\_http\_empty\_gif函数的实现很简单：  
  
　　static char \*  
  
　　ngx\_http\_empty\_gif(ngx\_conf\_t \*cf, ngx\_command\_t \*cmd, void \*conf)  
  
　　\{  
  
　　ngx\_http\_core\_loc\_conf\_t \*clcf;  
  
　　clcf = ngx\_http\_conf\_get\_module\_loc\_conf(cf, ngx\_http\_core\_module);  
  
　　clcf->handler = ngx\_http\_empty\_gif\_handler;  
  
　　return NGX\_CONF\_OK;  
  
　　\}  
  
　　ngx\_http\_conf\_get\_module\_loc\_conf是一个宏，用于获得Location相关的配置表cf中ngx\_http\_core\_module对应的项，获取之后，Empty Gif模块将自己的处理函数挂到了ngx\_http\_core\_module对应的handler上。  
  
　　这样，nginx在处理HTTP请求时，如果发现其URL匹配到Empty Gif所属的Location，  
  
　　如URL(/test\_1.gif)匹配到Location(/test\_\[0-9\].gif)，  
  
　　则使用ngx\_http\_empty\_gif作为处理函数，这个函数直接向浏览器写回一幅1×1的空白gif图片。  
  
  
  
本文转自  
  
[http://www.sameparty.com/x/?action=show&id=626][http_www.sameparty.com_x_action_show_id_626]

[http_www.sameparty.com_x_action_show_id_626]: http://www.sameparty.com/x/?action=show&id=626