tipideed is the binary that actually does what you want from a web server package: it serves files over HTTP.
tipideed [ -v verbosity ] [ -f cdbfile ] [ -d basedir ] [ -R ] [ -U ]
tipideed is intended to be run under a TCP super-server such as s6-tcpserver, for plain text HTTP, or s6-tlsserver, for HTTPS. It delegates to the super-server the job of binding and listening to the socket, accepting connections, spawning a separate process to handle a given connection, and potentially establishing a TLS tunnel with the client for secure communication.
As such, a command line for tipideed, running as user www, listening on address ${ip}, would typically look like this, for HTTP:
s6-envuidgid www s6-tcpserver -U -- ${ip} 80 s6-tcpserver-access -- tipideed
or, for HTTPS:
s6-envuidgid www env KEYFILE=/path/to/private/key CERTFILE=/path/to/certificate s6-tlsserver -U -- ${ip} 443 tipideed
Most users will want to run these command lines as services, i.e. daemons run in the background when the machine starts. The examples/ subdirectory of the tipidee package provides service templates to help you run tipideed under OpenRC, s6 and s6-rc.
tipideed expects the following variables in its environment, and will exit with an error message if they are undefined. When tipideed is run under s6-tcpserver (with s6-tcpserver-access or s6-tlsserver, these variables are automatically set by the super-server. This is the way tipidee gets its network information without having to perform network operations itself.
tipideed can function without these variables, but if they're present, it uses them to get more information.
When spawning a CGI or NPH script, tipideed clears all the previous variables, so the passed environment is as close as possible to the environment of the super-server; and it adds all the variables that are required by the CGI 1.1 specification. It does not add PATH_TRANSLATED, which CGI scripts should not rely on.
On systems that implement posix_spawn(), the s6-tcpserver super-server (and the s6-tlsserver one as well, since both use the same underlying program) uses it instead of fork(), and that partly alleviates the performance penalty usually associated with servers that spawn one process per connection.
One of tipidee's stated goals is to explore what kind of performance is achievable for a fully compliant Web server within the limits of that model. To that effect, tipideed is meant to be fast. It should serve static files as fast as any server out there, especially on Linux (or other systems supporting splice()) where it uses zero-copy transfer. CGI performance should be limited by the performance of the CGI script itself, never by tipideed.
tipideed itself does not use fork() if the system supports posix_spawn() — with one exception, that you will not hit, and if you do, fork() will not be the bottleneck. (Can you guess which case it is, without looking at the code?) tipideed does not parse its configuration file itself, delegating the task to the offline tipidee-config program and directly mapping a binary file instead. To parse a client request, it uses a deterministic finite automaton, only reading the request once, and only backtracking in pathological cases. This should streamline request processing as much as possible.
If you have benchmarks, results of comparative testing of tipideed against other Web servers, please share them on the skaware mailing-list.