UNIX-like systems in general, and Linux in particular, make a clear distinction between two types of processes: kernel space processes and user space processes. The kernel handles kernel space processes. If some event that the kernel handles triggers such a process, the process can be initiated very quickly. User space processes, by contrast, impose an overhead to start, and to communicate important data back to the kernel. This fact is not a problem for many processes, because user space processes often do substantial processing within user space. The overhead of calling user space programs is also tolerated in the name of security and stabilitykernel space processes have privileged access to hardware, filesystems, and so on, so they can wreak havoc if they contain bugs or if unauthorized individuals gain control of them.
Researchers who have looked for ways to optimize the performance of Web servers have discovered that, although Web servers like Apache are user space programs, much of the work they do is performed in kernel space or in calls between the kernel and the server. Figure 20.1 illustrates the flow of requests between the kernel and a traditional user space Web server. In fact, Figure 20.1 simplifies matters considerably. For instance, the file read request by Apache results in the kernel performing fairly complex file read operations. Ultimately, in a simple transfer (the most common type on many sites), Apache does little more than receive the file from the kernel and then deliver it straight back to the kernel. This is a huge waste of CPU time, memory, and other resources.
Figure 20.1. User space Web servers generate a lot of communication between the kernel and the user space server.
In order to better optimize a Web server computer's performance, developers have created simple Web servers that run within the kernel. This eliminates the communications between the Web server and the kernel, thus streamlining the process of serving Web pages and (it is hoped) improving performance. In fact, the 2.4. x and later kernels include one such kernel-based Web server: kHTTPd, headquartered at http://www.fenrus.demon.nl. This server is configured by writing data to files in the /proc/sys/net/khttpd directory. To use it, follow these steps:
You may want to create a custom SysV or local startup script to handle Steps 4 through 8 automatically when the system boots. Whether you start kHTTPd manually or through a script, the result is that it handles simple requeststhose for ordinary files that exist in the specified directory, aren't CGI scripts, and so on. If a request doesn't meet kHTTPd's requirements, kHTTPd passes the request on to the user-space Web server via the port number indicated in Steps 2 and 5. This adds some overhead when dealing with these file types, so kHTTPd isn't worth using if your site handles mostly CGI scripts or other nonstatic files. Indeed, kHTTPd may not be worth using even on a site with moderate amounts of traffic; it's most worth considering if Apache is having trouble keeping up with requests to your Web site. Also, kHTTPd is officially experimental, so it might not be as reliable as Apache or some other fully debugged user-space Web server. Finally, because it runs in kernel space, the risks if a bug exists in kHTTPd are much greater than are the risks involved if a bug is present in Apache. For a truly secure Web site, you're best sticking to a well- tested user-space program such as Apache.
Although kHTTPd is the kernel-based Web server that's most readily accessible, it's not the only one available. Red Hat's TUX product is one other that's received good reviews, and researchers are working on several more. In the future, we may see a wide selection of kernel-based Web servers for Linux.