lighttpd服务器源代码分析

短命女 2022-07-12 14:12 238阅读 0赞

在server.c文件里，一直在寻找那里是服务器套接字监听函数的入口，又仔细的翻看了遍代码，终于在network.c里面找到 network\_server\_handle\_fdevents函数，该函数用来accept新建立的套接字。它同时被封装在 network\_register\_fdevents函数里面，在server.c文件里面，当主watcher进程把各个进程都fork出来以后，每个 子进程都会把服务器的监听套接字加入到自己的epoll事件监听队列中去,这样整个服务器的初始化过程才比较完整。出了监听线程的epoll事件处理函数 为network\_server\_handle\_fdevents外，其他连接的epoll事件处理函数都是根据实际的服务不同而加载不同的服务插件。  
lighttpd服务器在实现上比较值得借鉴的方面，它把关于状态相关的转移操作完全通过有限状态机来实现，状态转移和相应的事件处理分开执行的。状态转移的主要函数为  
connection\_state\_machine  
  
下面介绍相关的跟插件有关的设计和调用，与插件相关的代码主要在plugins.h plugins.c这两个文件。插件所涉及的主要数据结构为struct plugin, 在该结构中，包含了插件进行初始化和卸载，进行插件相关的处理操作的所有操作的函数指针，在lighttpd中插件的加载方式有两种，第一种是静态加载， 是在编译时进行的，第二种是动态加载，是在运行时进行加载的（当插件需要在运行时进行加载时，就需要把该插件相关的函数编译成动态链接库的形式，通过系统 调用dlopen, dlsym把该插件的相关代码和相关符号加载到lighttpd的进程内存地址里。引起对插件相关的函数的调用发生在server.c:1445 行 plugins\_call\_handle\_joblist, 由此函数实现对各个插件相关的调用，但具体相关的函数代码一直未在源码中找到。又仔细阅读了代码终于搞清楚插件相关的那些个函数 了，plugins\_call\_handle\_joblist是由PLUGIN\_TO\_SLOT宏生成的函数，在plugin.c文件中有三个 PLUGIN\_TO\_SLOT宏定义，这三个宏定义的是各不同，下面由出现在代码中的顺序来依次对这几个宏进行解释  
plugin.c: 228  
\#define PLUGIN\_TO\_SLOT(x, y) /  
 handler\_t plugins\_call\_\#\#y(server \*srv, connection \*con) \{/  
 plugin \*\*slot;/  
 size\_t j;/  
 if (!srv->plugin\_slots) return HANDLER\_GO\_ON;/  
 slot = ((plugin \*\*\*)(srv->plugin\_slots))\[x\];/  
 if (!slot) return HANDLER\_GO\_ON;/  
 for (j = 0; j < srv->plugins.used && slot\[j\]; j++) \{ /  
 plugin \*p = slot\[j\];/  
 handler\_t r;/  
 switch(r = p->y(srv, con, p->data)) \{/  
 case HANDLER\_GO\_ON:/k  
 break;/  
 case HANDLER\_FINISHED:/  
 case HANDLER\_COMEBACK:/  
 case HANDLER\_WAIT\_FOR\_EVENT:/  
 case HANDLER\_WAIT\_FOR\_FD:/  
 case HANDLER\_ERROR:/  
 return r;/  
 default:/  
 log\_error\_write(srv, \_\_FILE\_\_, \_\_LINE\_\_, "sbs", \#x, p->name, "unknown state");/  
 return HANDLER\_ERROR;/  
 \}/  
 \}/  
 return HANDLER\_GO\_ON;/  
 \}  
这个宏定义用来生成以plugins\_call\_开头的函数体，两个参数分别是对应的服务器对象和连接对象，  
以下面的宏调用来具体分析PLUGIN\_TO\_SLOT(PLUGIN\_FUNC\_HANDLE\_JOBLIST, handle\_joblist)  
把宏进行展开就会生成如下的代码  
handler\_t plugins\_call\_handle\_joblist(server \*srv, connection \*con)  
\{   
 plugin \*\*slot;  
 size\_t j;  
 if (!srv->plugin\_slots) return HANDLER\_GO\_ON;  
 slot = ((plugin \*\*\*)(srv->plugin\_slots))\[PLUGIN\_FUNC\_HANDLE\_JOBLIST\];  
 if (!slot) return HANDLER\_GO\_ON;  
 for (j = 0; j < srv->plugins.used && slot\[j\]; j++) \{   
 plugin \*p = slot\[j\];  
 handler\_t r;  
//回调函数的参数为三个  
 switch(r = p->handle\_joblist(srv, con, p->data)) \{   
 case HANDLER\_GO\_ON:  
 break;  
 case HANDLER\_FINISHED:  
 case HANDLER\_COMEBACK:  
 case HANDLER\_WAIT\_FOR\_EVENT:  
 case HANDLER\_WAIT\_FOR\_FD:  
 case HANDLER\_ERROR:  
 return r;  
 default:  
 log\_error\_write(srv, \_\_FILE\_\_, \_\_LINE\_\_, "sbs", \#x, p->name, "unknown state");  
 return HANDLER\_ERROR;  
 \}  
 \}  
 return HANDLER\_GO\_ON;  
\}  
plugin\_call\_handle\_joblist用来遍历整个plugin的链表，如果该插件的链表上存在任务，调用对应的回调处理函数  
handle\_joblist对任务进行处理  
第二个PLUGIN\_TO\_SLOT与上面的宏非常类似，唯一的区别是所调用的回调函数的参数只有两个。  
地三个PLUGIN\_TO\_SLOT宏, 参数分别为回调函数下标，回调函数  
plugin \* p = ps\[i\];  
\#define PLUGIN\_TO\_SLOT(x, y) /  
 if (p->y) \{ /  
 plugin \*\*slot = ((plugin \*\*\*)(srv->plugin\_slots))\[x\]; /  
 if (!slot) \{ /  
 slot = calloc(srv->plugins.used, sizeof(\*slot));/  
 ((plugin \*\*\*)(srv->plugin\_slots))\[x\] = slot; /  
 \} /  
 for (j = 0; j < srv->plugins.used; j++) \{ /  
 if (slot\[j\]) continue;/  
 slot\[j\] = p;/  
 break;/  
 \}/  
 \}  
分析时也以一个小例子进行下代码展开，  
PLUGIN\_TO\_SLOT(PLUGIN\_FUNC\_HANDLE\_URI\_CLEAN, handle\_uri\_clean);  
代码展开后：  
if(p->handle\_uri\_clean)\{   
 plugin \*\*slot = ((plugin\*\*\*)(srv->plugin\_slots)\[x\];  
//若在映射表上尚未存在该插件所对应的项，创建新条目  
 if(!slot)\{   
 slot = calloc(srv->plugins.used, sizeof(\*slot));  
 ((plugin\*\*\*)(srv->plugin\_slots))\[x\] = slot;  
 ｝  
//找到第一个未使用的表项，指向目前的插件  
 for(j = 0; j < srv->plugins.used; j++)\{   
 if(slot\[j\])continue;  
 slot\[j\] = p;  
 break;  
 \}  
\}  
  
如果现在初始化的插件有handle\_uri\_clean这个回调函数，那麽把插件映射表里面的指针指向相应的插件  
此函数的目的是用来在初始化插件。这个实现的有些技巧性存在，tricky hack!  
  
下面分析一下主文件server.c的执行流程，分析server.c文件就必须对lighttpd里面的事件模型进行了解，所有的相关网络方面的处理都是与事件模型为基础来实现。在struct server结构中，有下面几个比较重要的,其中异步事件相关的有  
fdevents \*ev, \*ev\_ins;  
与服务器监听socket相关的域  
server\_socket\_array srv\_sockets;//该域中存放监听套接字的信息  
客户请求相关连接的域  
connections \*conns, \*joblist, \*fdwaitqueue;  
上面这三个域存在如下关系，对监听套接字会 在fdevents的数组中注册network\_server\_handle\_fdevent为事件的处理函数，该处理函数在接受一个新的客户端连接后， 会在conns中插入一个新的连接，并在fdevents中注册connection\_handle\_fdevent作为该连接的处理函数。在 connection\_handle\_fdevent中，根据不同的插件，把相应的插件服务信息插入到待处理任务列表中，然后在worker进程中对待处 理任务列表中的项调用对应的插件相关的处理函数。  
  
/\*\*  
 \*  
 \* with EPOLLET we don't get a FDEVENT\_HUP  
 \* if the close is delay after everything has  
 \* sent.  
 \*  
 \*/  
  
在使用epoll方面，　lighttpd并没有使用edge triggered的事件类型，而是使用level triggered的事件类型,上面的注释可能是选用level triggerd的方式的原因，自己没有搞清楚。  
  
查阅了apache的源代码，apache有关模块结构和相关的操作部分的声明在http\_config.h文件中，在该文件中有关于模块的结构 module\_struct结构，该结构里面包含了模块的一些必要属性，和相关的入口函数等性质。静态模块和动态模块的加载方式应该与lighttpd中 大致相同。apache中设计比较好的是，可以为每个模块动态注册相应的回调函数，该函数的名称与相应的入口地址之间的映射关系被保存在 apr\_hook\_global\_pool这一哈西表中，每个模块结构中有一个相应的register\_hooks函数指针，用来向对应的模块注册相应的 回调函数