首页 > 代码库 > uhttpd源码分析

uhttpd源码分析

2024-08-05 22:29:41   237人阅读

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

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

概述

uhttpd.pnguhttpd.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，它接受命令行参数，进行服务器配置，并且启动服务器。让我们先来看看它有哪些配置。

helphelp

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

1
./uhttpd -p 8080

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
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进行了端口的绑定。

1
2
3
4
5
/* bind sockets */
bound += uh_socket_bind(
&serv_fds, &max_fd, bind[0] ? bind : NULL, port,
&hints, (opt == ‘s‘), &conf
);

uh_socket_bind：

1
2
3
4
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加到了一个全局的链表中，于是我们可以绑定多个端口。

1
2
3
4
5
6
/* 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里。

1
2
3
4
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也可以用配置文件来进行配置。

1
2
/* config file */
uh_config_parse(&conf);

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

正式启动

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

1
2
/* server main loop */
uh_mainloop(&conf, serv_fds, max_fd);

等待请求

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

1
2
3
4
5
6
7
while (run) {
if( select(max_fd + 1, &read_fds, NULL, NULL, NULL) == -1 )
{
...
}
...
}

select

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

1
2
3
4
5
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的结构体。

1
2
3
4
5
6
7
8
struct http_request {
int method;
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。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
/* 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也只是做了一个简单的判断然后就交给下一级了。

1
2
3
4
5
6
7
8
9
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中。成员如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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。

这里有一个有趣的函数，

1
2
3
4
5
6
/* 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被正确关闭。实现很简单，一个类函数宏就搞定了。

1
2
3
4
5
6
#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。成员如下。

1
2
3
4
5
6
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进行了一个重定向，把输入输出流都定向到了管道。

1
2
3
/* patch stdout and stdin to pipes */
dup2(rfd[1], 1);
dup2(wfd[0], 0);

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

1
2
3
4
5
6
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程序。

1
2
3
4
if( ip != NULL )
execl(ip->path, ip->path, pi->phys, NULL);
else
execl(pi->phys, pi->phys, NULL);

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

1
2
3
4
5
6
7
8
9
10
11
12
13
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的代码并不多，其中很多的代码都用来处理错误，可见处理异常情况也是很重要的。有机会的话，希望自己能亲自实现一个服务器。

uhttpd源码分析


联系
我们