nweb服务器源码剖析,uhttpd源码分析-CSDN博客

uhttpd是openwrt上默认的Web服务器，支持CGI，lua脚本，以及静态文件的服务。它是一个精简的服务器，一般适合作为路由器这样的嵌入式设备使用，或者Web服务器的入门学习。

uhttpd的源码可以用svn到下载。

概述

uhttpd.png

首先，在uhttpd启动的时候，它会先读取参数，进行服务器的配置。参数可以由命令行输入，其中port参数必须制定，其他都有默认值。

配置完参数之后，服务器会进入uh_mainloop，等待请求。

在主循环中，uhttpd采用select进行轮询，而不是采用fork进行并发，一定程度上降低了并发能力，但是很适合这样的小型服务器。

当select检测到有客户端请求，uhttpd就会先接受请求，再进行解析，之后再调用uh_dispatch_request去分发请求。其中，lua请求比较特殊，不由uh_dispatch_request分发。

在分发过程(不包括lua请求)当中，会根据path的前缀来判断是CGI请求还是静态文件请求，默认的CGI前缀是/cgi-bin。CGI请求进入uh_cgi_request，文件请求进入uh_file_request，lua请求则会进入lua_request。

在三种handler中，就会进行请求的处理了。lua_request会调用lua解释器进行处理，file_request直接读取文件并且返回，CGI请求比较复杂，之后会详细说明。

在三种request处理之后，都会返回给客户端。一次循环到此结束。

启动

服务器配置

启动入口的main函数位于uhttpd.c，它接受命令行参数，进行服务器配置，并且启动服务器。让我们先来看看它有哪些配置。

help

其中port必须指定，别的都有默认值。一般情况下我们可以用这样的参数来启动服务器：

./uhttpd -p 8080

服务器默认是运行在后台的，可以使用“ps -A | grep uhttp”看到它的运行情况，用nmap扫描一下本地端口也可以看到它已经在监听8080端口了。

nmap

uhttpd的配置用“struct config”存储，成员也很丰富：

struct config {

char docroot[PATH_MAX];

char *realm;

char *file;

char *index_file;

char *error_handler;

int no_symlinks;

int no_dirlists;

int network_timeout;

int rfc1918_filter;

int tcp_keepalive;

#ifdef HAVE_CGI

char *cgi_prefix;

#endif

#ifdef HAVE_LUA

char *lua_prefix;

char *lua_handler;

lua_State *lua_state;

lua_State * (*lua_init) (const char *handler);

void (*lua_close) (lua_State *L);

void (*lua_request) (struct client *cl, struct http_request *req, lua_State *L);

#endif

#if defined(HAVE_CGI) || defined(HAVE_LUA)

int script_timeout;

#endif

#ifdef HAVE_TLS

char *cert;

char *key;

SSL_CTX *tls;

SSL_CTX * (*tls_init) (void);

int (*tls_cert) (SSL_CTX *c, const char *file);

int (*tls_key) (SSL_CTX *c, const char *file);

void (*tls_free) (struct listener *l);

int (*tls_accept) (struct client *c);

void (*tls_close) (struct client *c);

int (*tls_recv) (struct client *c, void *buf, int len);

int (*tls_send) (struct client *c, void *buf, int len);

#endif

};

端口绑定

服务器的端口绑定没有写在config里面，而是直接用uh_socket_bind进行了端口的绑定。

/* bind sockets */

bound += uh_socket_bind(

&serv_fds, &max_fd, bind[0] ? bind : NULL, port,

&hints,(opt == ‘s‘), &conf

);

uh_socket_bind：

static int uh_socket_bind(

fd_set *serv_fds, int *max_fd, const char *host, const char *port,

struct addrinfo *hints, int do_tls, struct config *conf

)

此函数进行端口绑定并且把listener加到了一个全局的链表中，于是我们可以绑定多个端口。

/* add listener to global list */

if( ! (l = uh_listener_add(sock, conf)) )

{

fprintf(stderr, "uh_listener_add(): Failed to allocate memory\n");

goto error;

}

比较有意思的是，uhttpd把一些信息存在了链表里，用add函数在表头插入。C语言没有现成的集合框架，但是自己写一个链表也是很轻松的。这些工具函数都在uhttpd-utils.c里。

static struct client *uh_clients = NULL;

struct client * uh_client_add(int sock, struct listener *serv);

struct client * uh_client_lookup(int sock);

void uh_client_remove(int sock);

配置文件

光用命令行的话肯定太麻烦，uhttpd也可以用配置文件来进行配置。

/* config file */

uh_config_parse(&conf);

但是配置文件的选项好像不是很多，最好的方式还是写一个启动脚本。

正式启动

在一系列的配置之后，uhttpd终于要正式启动了。它默认是后台启动，fork一个子进程，父进程退出，子进程带着配置文件和服务器的FD进入了mainloop。

/* server main loop */

uh_mainloop(&conf, serv_fds, max_fd);

等待请求

uh_mainloop函数也在uhttp.c里，最外层是一个大的循环。

while (run) {

if( select(max_fd + 1, &read_fds, NULL, NULL, NULL) == -1 )

{

...

}

...

}

select

select函数起到了阻塞请求的作用，并且和accept不用的是，它使用轮询机制，而不是fork，更加适合嵌入式设备。

if( select(max_fd + 1, &read_fds, NULL, NULL, NULL) == -1 )

{

perror("select()");

exit(1);

}

最后一个参数是设置超时时间，如果设置成NULL，则无限超时，直到FD有变动。

获得请求

之后会进入一个嵌套复杂的“if-else”语句，数了一下最深有六层if嵌套。主要的功能就是遍历所有的FD，分别找到服务端和客户端的FD，在服务端，accept并且把client加入链表。在客户端的FD中，处理请求。

用uh_http_header_recv获得请求之后，用uh_http_header_parse解析，得到一个http_request的结构体。

struct http_request {

intmethod;

float version;

int redirect_status;

char *url;

char *headers[UH_LIMIT_HEADERS];

struct auth_realm *realm;

};

请求分发

得到http_request之后，就可以根据URL来进行请求的分发了。带有lua前缀的给lua_request，否则交给uh_dispatch_request。

/* Lua request? */

if( conf->lua_state &&

uh_path_match(conf->lua_prefix, req->url) )

{

conf->lua_request(cl, req, conf->lua_state);

}

else

/* dispatch request */

if( (pin = uh_path_lookup(cl, req->url)) != NULL )

{

/* auth ok? */

if( !pin->redirected && uh_auth_check(cl, req, pin) )

uh_dispatch_request(cl, req, pin);

}

dispatch也只是做了一个简单的判断然后就交给下一级了。

if( uh_path_match(cl->server->conf->cgi_prefix, pin->name) ||

(ipr = uh_interpreter_lookup(pin->phys)) )

{

uh_cgi_request(cl, req, pin, ipr);

}

else

{

uh_file_request(cl, req, pin);

}

处理请求

lua请求暂时不说了，这里只说文件和CGI请求。

静态文件

file_request在uhttpd-file.c中。成员如下

uhttpd-file.c

macro

_XOPEN_SOURCE

_BSD_SOURCE

function

uh_file_mime_lookup

uh_file_mktag

uh_file_date2unix

uh_file_unix2date

uh_file_header_lookup

uh_file_response_ok_hdrs

uh_file_response_200

uh_file_response_304

uh_file_response_412

uh_file_if_match

uh_file_if_modified_since

uh_file_if_none_match

uh_file_if_range

uh_file_if_unmodified_since

uh_file_scandir_filter_dir

uh_file_dirlist

uh_file_request

既然是静态文件请求，自然是先看看本地有没有这个文件，有的话就读取内容发给客户端，没有就404。

这里有一个有趣的函数，

/* test preconditions */

if(ok) ensure_out(uh_file_if_modified_since(cl, req, &pi->stat, &ok));

if(ok) ensure_out(uh_file_if_match(cl, req, &pi->stat, &ok));

if(ok) ensure_out(uh_file_if_range(cl, req, &pi->stat, &ok));

if(ok) ensure_out(uh_file_if_unmodified_since(cl, req, &pi->stat, &ok));

if(ok) ensure_out(uh_file_if_none_match(cl, req, &pi->stat, &ok));

处理请求的过程中大量使用了ensure_out，它应该是保证关闭FD的。如果网络发生异常或者文件读写异常，需要保证FD被正确关闭。实现很简单，一个类函数宏就搞定了。

#define ensure_out(x) \

do { if((x) 0) goto out; } while(0)

out:

if( fd > -1 )

close(fd);

CGI请求

处理CGI请求稍微复杂一点。

uh_cgi_request函数位于uhttpd-cgi.c。成员如下。

uhttpd-cgi.c

function

uh_cgi_header_parse

uh_cgi_header_lookup

uh_cgi_error_500

uh_cgi_request

虽然成员很少，但是总体还是有600多行。

CGI的处理过程，基本上就是调用CGI程序，获得它的处理结果，然后返回给客户端。但CGI程序和主调函数，肯定是两个进程，它们之间如何通信，如何传递数据，这才是关键。

uhttpd采用了管道和CGI程序进行通信，有两个管道，实现双向通信。一个管道负责从父进程写数据到CGI程序，主要是客户端的POST数据。另一个就是读取CGI程序的处理结果。同时，按照CGI的标准，HTTP请求头都是通过环境变量的方式传给CGI程序的，CGI程序是fork和exec的，所以会继承环境变量，达到传递数据的目的。

在子进程中，则用dup2进行了一个重定向，把输入输出流都定向到了管道。

/* patch stdout and stdin to pipes */

dup2(rfd[1], 1);

dup2(wfd[0], 0);

之后就用了大段的代码设置环境变量。

setenv("SERVER_NAME", sa_straddr(&cl->servaddr), 1);

setenv("SERVER_ADDR", sa_straddr(&cl->servaddr), 1);

setenv("SERVER_PORT", sa_strport(&cl->servaddr), 1);

setenv("REMOTE_HOST", sa_straddr(&cl->peeraddr), 1);

setenv("REMOTE_ADDR", sa_straddr(&cl->peeraddr), 1);

setenv("REMOTE_PORT", sa_strport(&cl->peeraddr), 1);

之后才真正地调用CGI程序。

if( ip != NULL )

execl(ip->path, ip->path, pi->phys, NULL);

else

execl(pi->phys, pi->phys, NULL);

与此同时，父进程则焦急地等待着管道另一头的回音。它等来等去等的不耐烦了，于是它又机制地给自己设置了一个timeout，过了这个时间它就离开了。

ensure_out(rv = select_intr(fd_max, &reader,

(content_length > -1) ? &writer : NULL, NULL, &timeout));

......

/* read it from socket ... */

ensure_out(buflen = uh_tcp_recv(cl, buf,

min(content_length, sizeof(buf))));

.....

/* ... and write it to child‘s stdin */

if( write(wfd[1], buf, buflen) 0 )

perror("write()");

......

/* read data from child ... */

if( (buflen = read(rfd[0], buf, sizeof(buf))) > 0 )

从CGI程序读完了数据之后，它还是不放心，又解析了一下响应头，确认正确之后，才发给了客户端。

到这里，整个处理过程才算结束。

总结

第一次看服务器的源码，所以找了一个比较简单的服务器。大致能够理解它的原理，但是很多细节还是不明白，可能只有自己亲自去实现才能对它有一个深刻的理解。uhttd的代码并不多，其中很多的代码都用来处理错误，可见处理异常情况也是很重要的。有机会的话，希望自己能亲自实现一个服务器。