Looks impressive though benchmarking with "ab" should be taken with a grain of salt.
nginx does a lot of optimization at many level that ab can't figure out.
In short, it only profiles the speed of the HTTP parser and certainly not the network stack.
There are a lot of things that a HTTP server does in order to keep the connections stack "steady" : Disabling the Nagle algorithm at the right moment, gracefully handling failure, managing slow clients the right way, ...
ab has not been the bottleneck in the benchmarks since both servers were pinned to a single core. It is true that ab is too slow for benchmarking a HTTP server running on multiple CPU cores, but it is at least faster than a server only using one core.
Regarding the performance of the HTTP parser, I have heard that picohttpparser (the HTTP/1 parser used by H2O) is much faster than the HTTP parser used by nginx.
https://github.com/kazuho/picohttpparser
If that is true, it is likely due to the difference between the approaches the parsers take. Unlike most parsers, picohttpparser does not have a callback-based API. Instead it uses a loop for parsing the HTTP request and header lines.
note: This comment might be biased since I am the author of H2O and picohttpparser.
I believe you when you say that picohttpparser is faster. But is it also correct and secure? Is it fully RFC7230 compliant? Are there no parsing bugs that would allow a security exploit?
It is hard to argue the secureness of a software, but I would say that if there are problems in the library it would be taken seriously.
picohttpparser is the core of HTTP::Parser::XS which is used by many HTTP application servers for Perl (see http://plackperl.org). There are many deployments using it.
nginx does a lot of optimization at many level that ab can't figure out.
In short, it only profiles the speed of the HTTP parser and certainly not the network stack.
There are a lot of things that a HTTP server does in order to keep the connections stack "steady" : Disabling the Nagle algorithm at the right moment, gracefully handling failure, managing slow clients the right way, ...
FWIW, Tsung is an awesome benchmarking tool written in erlang : http://tsung.erlang-projects.org/