13 ms·

H2O – an optimized HTTP server and library implementation

102 points by dochtman 12y ago

sbarre 12y ago
Does this server/library allow the same kind of hooks and configuration that a traditional web server allows? Or is that the point? If you don't need all the configuration and features of an off-the-shelf web server, you can more easily custom-build an H20 HTTP server for your specific needs that is blazing fast?
marktangotango 12y ago
Very nice, I've often wondered at the lack of embeddable http servers in the c/c++ world. Are there any other libraries that do the same thing? What is the status of this project? Is it being used in production anywhere?
- fredliu 12y ago
  Another example is Mongoose. It's small, easy to config and embeddable(I've used Mongoose on android with NDK with no problem). Unlike H2O, Mongoose is using an old school one-thread-per-request approach, so I would expect the throughput won't be as high as H2O, which seems to be using an event based approach similar to ngnix. Be aware of the license of Mongoose though, it used to be MIT (or apapche?), but now it's GPLv2.
  - nodivbyzero 12y ago
    https://code.google.com/p/mongoose/ https://code.google.com/p/mongoose/
  - reverius42 12y ago
    See also https://github.com/pfalcon/mongoose-mit https://github.com/pfalcon/mongoose-mit or https://github.com/sunsetbrew/civetweb https://github.com/sunsetbrew/civetweb
- to3m 12y ago
  I wrote one: https://github.com/tom-seddon/yhs https://github.com/tom-seddon/yhs (README includes a bunch of links to others at the bottom) I wrote it for an iOS game, the idea being that configuration of the game would be done in real time by connecting to your iThing via a web browser and tweaking it using a bunch of HTML widgets or whatever. But its intended users ended up preferring to do their tweaking using some on-screen Cocoa Touch stuff that I'd also put in, so the HTML idea never ended up being taken further. My library has a few good points, I think: no dependencies, no threading, easy integration, simple API, builds as C89/C99/C++, doesn't hate Windows. (I've often wished other libraries did all of those.) But I don't currently have any plans to work on it further, and you can probably find other options that have been more thoroughly battle-tested, were more carefully planned, and are actively maintained. (These days I'm more comfortable with Javascript, and I've come to the conclusion that a better approach would be to implement a bare bones WebSocket server that does little more than let the iWhatever send data to the browser and vice versa. No need for the iDevice to serve any HTML or cooked data or anything like that; just send raw data and interpret it in your JS code, which of course would be stored locally on your PC, along with associated HTML/CSS/etc. Quicker turnaround during development, and easier to push updates to its users, who would probably just need to get latest and hit refresh in the browser as they'd be running it straight from their working copy.)
- lultimouomo 12y ago
  cpp-netlib provides an embeddable HTTP server based on boost::asio, which adopts a proactor pattern. As with all things boost, it is well made and elegant, and takes a bit getting used to. The Poco Net libraries include a more traditional thread-per-request server which is very easy to use, with a clean OO approach. I think ACE includes an HTTP server as well, but I have no experience with it.
- sircomatose 12y ago
  There is kore. See https://kore.io https://kore.io and https://github.com/jorisvink/kore https://github.com/jorisvink/kore Has quite alot of neat features for C web development imho, then again I wrote it so of course I like it.
- nly 12y ago
  For C, libmicrohttpd https://www.gnu.org/software/libmicrohttpd/ https://www.gnu.org/software/libmicrohttpd/ Big list of alternative libraries at the bottom also.
- dmoreno 12y ago
  There is also libonion (https://github.com/davidmoreno/onion https://github.com/davidmoreno/onion), another high performance HTTP library. It also has C and C++ support, with very clean API, django-like templates, initial Python and PHP bindings, Websocket, Webdav, has several threading modes (poll, pool, one thread...) And many other goodies. Disclaimer: Im the author.
billyhoffman 12y ago
As happy as I am so see open source libraries that can support SPDY/HTTP2, these "2x faster than nginx" stats are a joke. This dubious claim is based on how fast H20 and nginx can serve a 6 byte, and a 4KB response
paraboul 12y ago
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, ... FWIW, Tsung is an awesome benchmarking tool written in erlang : http://tsung.erlang-projects.org/ http://tsung.erlang-projects.org/
- justincormack 12y ago
  ab is also very slow, it can be the limiting factor in the benchmarking. But the nginx http parser is one of the things that is fast, so a faster one is interesting. I think having a library implementation is very useful as well.
  - paraboul 12y ago
    Sure! And it supports HTTP/2.0 !
  - kazuho 12y ago
    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 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.
    - deleted 12y ago
      [deleted]
deleted 12y ago
[deleted]
zokier 12y ago
I hope to see it in TechEmpowers benchmarks: http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/
jedisct1 12y ago
I don't trust any benchmark using ab. Use Tsung or Siege. That said, this library is very clean and easy to use. I just wish it had high-level functions to create sockets, but that's a minor detail. Good job by Kazuho, as usual.
- escaped_hn 12y ago
  It uses libuv which you can use to create sockets. http://nikhilm.github.io/uvbook/networking.html#tcp http://nikhilm.github.io/uvbook/networking.html#tcp
kazuho 12y ago
As the author of H2O, I would like to leave a comment here. First of all, the development is still in early stages, please forgive me for the lack of documentation. That said, below are some high-level design issues that are not addressed by the README. - it is designed to be pluggable (though not as flexible as Apache), by providing virtual-host-based configuration of generators, output filters and loggers - lib/file.c and lib/chunked.c would be a good place to understand their interface if you are interested - I am (at the moment) not interested in providing support for input filters - performance of HTTP parser is likely going to become importance since the ratio of small files being served is expected to increase in HTTP/2; H2O is designed with that in mind
- tinco 12y ago
  Why is H2O faster than nginx? I've read the source of nginx and it does attempt to be very clean and tightly optimized, which makes me suspicious of H2O. Is there some big architectural advantage or is it less robust in some way?
  - kazuho 12y ago
    Please read my other comment here https://news.ycombinator.com/item?id=8342684 https://news.ycombinator.com/item?id=8342684
SwellJoe 12y ago
I think it's interesting that performance is mentioned as a primary feature of this. I haven't deployed a web service in nearly 15 years that had the HTTP server as the limiting factor for the performance of a website. Serving small files from RAM really fast just isn't that interesting. For this kind of workload Apache is fast enough for the vast majority of deployments (such a large majority that I've never worked on a deployment that it wasn't, and I've worked on some very large deployments), nginx is fast enough, and H2O is fast enough. Going from "fast enough" to "2x fast enough" isn't going to matter to end users who are waiting on other parts of the system. The database is still gonna be a bottleneck. The application is still gonna be a bottleneck. The disks are still gonna be a bottleneck. The network is still gonna be a bottleneck (Apache can saturate a Gbit NIC, so can nginx, so can H2O). I'm not saying this is useless. It looks like a cool project, built by someone really clever (unco is hilariously clever), with lots of good uses (an easily embedded HTTP server library is nothing to sneeze at). I'm saying I think it's weird and unfortunate that so many people focus on performance of the web server, as though it will make a difference for end users. In the vast majority of web server deployments any of the major web servers will do the job and will perform well enough to not be the bottleneck in the system.
- kikoreis 12y ago
  Is there a latency angle to webserver performance that /is/ valid? I have heard anecdotal information that single-thread performance does affect webserver response latency and I can see how an optimized server could make a difference there.
  - SwellJoe 12y ago
    Request latency is certainly a factor, especially with more requests happening per page, and more demanding desktop-experience applications on the web. But, none of the servers I mentioned are a significant contributor to latency when configured appropriately for the workload. Apache has competent concurrency options on modern systems (including libevent), as does nginx. Certainly performance is nice. I'm not saying it isn't. But, the webserver is going to spend most of its time waiting on your application and your database. I'd like to see folks more focused on standards-compliant behavior, secure behavior, etc. That's not as easy as slapping up an ab benchmark, but it's more useful in helping me decide if a new server is appropriate for my needs, and it's helpful in moving the state of the art forward on fronts that are far more important than squeezing another bajillion requests out of hardware that can already serve a bajillion requests. Another interesting angle is memory usage. Apache does require more memory than nginx or, presumably, H2O. It's not a huge difference, if Apache is configured as minimally as nginx is, by default, but it's notable on a very high concurrency system. In the "Internet of things", small embeddable web servers will be important. If H2O uses less memory than nginx, that'd be interesting (I think more interesting than performance). But, memory usage isn't really mentioned anywhere that I see...if a memory graph were beside the ab benchmarks, I probably wouldn't have even complained about the benchmarks being so prominent. It would have added a useful and maybe even predictive piece of data to the page.
p1mrx 12y ago
Looks like it doesn't support IPv6. src/main.c: conf->fd = socket(AF_INET, SOCK_STREAM, 0)
- justincormack 12y ago
  Although that is the example server, maybe the library does?

102 points by dochtman 12y ago

Does this server/library allow the same kind of hooks and configuration that a traditional web server allows? Or is that the point? If you don't need all the configuration and features of an off-the-shelf web server, you can more easily custom-build an H20 HTTP server for your specific needs that is blazing fast?

marktangotango 12y ago

Very nice, I've often wondered at the lack of embeddable http servers in the c/c++ world. Are there any other libraries that do the same thing? What is the status of this project? Is it being used in production anywhere?

fredliu 12y ago
Another example is Mongoose. It's small, easy to config and embeddable(I've used Mongoose on android with NDK with no problem). Unlike H2O, Mongoose is using an old school one-thread-per-request approach, so I would expect the throughput won't be as high as H2O, which seems to be using an event based approach similar to ngnix. Be aware of the license of Mongoose though, it used to be MIT (or apapche?), but now it's GPLv2.
- nodivbyzero 12y ago
  https://code.google.com/p/mongoose/ https://code.google.com/p/mongoose/
- reverius42 12y ago
  See also https://github.com/pfalcon/mongoose-mit https://github.com/pfalcon/mongoose-mit or https://github.com/sunsetbrew/civetweb https://github.com/sunsetbrew/civetweb
to3m 12y ago
I wrote one: https://github.com/tom-seddon/yhs https://github.com/tom-seddon/yhs (README includes a bunch of links to others at the bottom) I wrote it for an iOS game, the idea being that configuration of the game would be done in real time by connecting to your iThing via a web browser and tweaking it using a bunch of HTML widgets or whatever. But its intended users ended up preferring to do their tweaking using some on-screen Cocoa Touch stuff that I'd also put in, so the HTML idea never ended up being taken further. My library has a few good points, I think: no dependencies, no threading, easy integration, simple API, builds as C89/C99/C++, doesn't hate Windows. (I've often wished other libraries did all of those.) But I don't currently have any plans to work on it further, and you can probably find other options that have been more thoroughly battle-tested, were more carefully planned, and are actively maintained. (These days I'm more comfortable with Javascript, and I've come to the conclusion that a better approach would be to implement a bare bones WebSocket server that does little more than let the iWhatever send data to the browser and vice versa. No need for the iDevice to serve any HTML or cooked data or anything like that; just send raw data and interpret it in your JS code, which of course would be stored locally on your PC, along with associated HTML/CSS/etc. Quicker turnaround during development, and easier to push updates to its users, who would probably just need to get latest and hit refresh in the browser as they'd be running it straight from their working copy.)
lultimouomo 12y ago
cpp-netlib provides an embeddable HTTP server based on boost::asio, which adopts a proactor pattern. As with all things boost, it is well made and elegant, and takes a bit getting used to. The Poco Net libraries include a more traditional thread-per-request server which is very easy to use, with a clean OO approach. I think ACE includes an HTTP server as well, but I have no experience with it.
sircomatose 12y ago
There is kore. See https://kore.io https://kore.io and https://github.com/jorisvink/kore https://github.com/jorisvink/kore Has quite alot of neat features for C web development imho, then again I wrote it so of course I like it.
nly 12y ago
For C, libmicrohttpd https://www.gnu.org/software/libmicrohttpd/ https://www.gnu.org/software/libmicrohttpd/ Big list of alternative libraries at the bottom also.
dmoreno 12y ago
There is also libonion (https://github.com/davidmoreno/onion https://github.com/davidmoreno/onion), another high performance HTTP library. It also has C and C++ support, with very clean API, django-like templates, initial Python and PHP bindings, Websocket, Webdav, has several threading modes (poll, pool, one thread...) And many other goodies. Disclaimer: Im the author.

billyhoffman 12y ago

As happy as I am so see open source libraries that can support SPDY/HTTP2, these "2x faster than nginx" stats are a joke. This dubious claim is based on how fast H20 and nginx can serve a 6 byte, and a 4KB response

paraboul 12y ago

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, ... FWIW, Tsung is an awesome benchmarking tool written in erlang : http://tsung.erlang-projects.org/ http://tsung.erlang-projects.org/

justincormack 12y ago
ab is also very slow, it can be the limiting factor in the benchmarking. But the nginx http parser is one of the things that is fast, so a faster one is interesting. I think having a library implementation is very useful as well.
- paraboul 12y ago
  Sure! And it supports HTTP/2.0 !
- kazuho 12y ago
  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 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.
  - deleted 12y ago
    [deleted]

deleted 12y ago

[deleted]

zokier 12y ago

I hope to see it in TechEmpowers benchmarks: http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/

jedisct1 12y ago

I don't trust any benchmark using ab. Use Tsung or Siege. That said, this library is very clean and easy to use. I just wish it had high-level functions to create sockets, but that's a minor detail. Good job by Kazuho, as usual.

escaped_hn 12y ago
It uses libuv which you can use to create sockets. http://nikhilm.github.io/uvbook/networking.html#tcp http://nikhilm.github.io/uvbook/networking.html#tcp

kazuho 12y ago

As the author of H2O, I would like to leave a comment here. First of all, the development is still in early stages, please forgive me for the lack of documentation. That said, below are some high-level design issues that are not addressed by the README. - it is designed to be pluggable (though not as flexible as Apache), by providing virtual-host-based configuration of generators, output filters and loggers - lib/file.c and lib/chunked.c would be a good place to understand their interface if you are interested - I am (at the moment) not interested in providing support for input filters - performance of HTTP parser is likely going to become importance since the ratio of small files being served is expected to increase in HTTP/2; H2O is designed with that in mind

tinco 12y ago
Why is H2O faster than nginx? I've read the source of nginx and it does attempt to be very clean and tightly optimized, which makes me suspicious of H2O. Is there some big architectural advantage or is it less robust in some way?
- kazuho 12y ago
  Please read my other comment here https://news.ycombinator.com/item?id=8342684 https://news.ycombinator.com/item?id=8342684

SwellJoe 12y ago

I think it's interesting that performance is mentioned as a primary feature of this. I haven't deployed a web service in nearly 15 years that had the HTTP server as the limiting factor for the performance of a website. Serving small files from RAM really fast just isn't that interesting. For this kind of workload Apache is fast enough for the vast majority of deployments (such a large majority that I've never worked on a deployment that it wasn't, and I've worked on some very large deployments), nginx is fast enough, and H2O is fast enough. Going from "fast enough" to "2x fast enough" isn't going to matter to end users who are waiting on other parts of the system. The database is still gonna be a bottleneck. The application is still gonna be a bottleneck. The disks are still gonna be a bottleneck. The network is still gonna be a bottleneck (Apache can saturate a Gbit NIC, so can nginx, so can H2O). I'm not saying this is useless. It looks like a cool project, built by someone really clever (unco is hilariously clever), with lots of good uses (an easily embedded HTTP server library is nothing to sneeze at). I'm saying I think it's weird and unfortunate that so many people focus on performance of the web server, as though it will make a difference for end users. In the vast majority of web server deployments any of the major web servers will do the job and will perform well enough to not be the bottleneck in the system.

kikoreis 12y ago
Is there a latency angle to webserver performance that /is/ valid? I have heard anecdotal information that single-thread performance does affect webserver response latency and I can see how an optimized server could make a difference there.
- SwellJoe 12y ago
  Request latency is certainly a factor, especially with more requests happening per page, and more demanding desktop-experience applications on the web. But, none of the servers I mentioned are a significant contributor to latency when configured appropriately for the workload. Apache has competent concurrency options on modern systems (including libevent), as does nginx. Certainly performance is nice. I'm not saying it isn't. But, the webserver is going to spend most of its time waiting on your application and your database. I'd like to see folks more focused on standards-compliant behavior, secure behavior, etc. That's not as easy as slapping up an ab benchmark, but it's more useful in helping me decide if a new server is appropriate for my needs, and it's helpful in moving the state of the art forward on fronts that are far more important than squeezing another bajillion requests out of hardware that can already serve a bajillion requests. Another interesting angle is memory usage. Apache does require more memory than nginx or, presumably, H2O. It's not a huge difference, if Apache is configured as minimally as nginx is, by default, but it's notable on a very high concurrency system. In the "Internet of things", small embeddable web servers will be important. If H2O uses less memory than nginx, that'd be interesting (I think more interesting than performance). But, memory usage isn't really mentioned anywhere that I see...if a memory graph were beside the ab benchmarks, I probably wouldn't have even complained about the benchmarks being so prominent. It would have added a useful and maybe even predictive piece of data to the page.

p1mrx 12y ago

Looks like it doesn't support IPv6. src/main.c: conf->fd = socket(AF_INET, SOCK_STREAM, 0)

justincormack 12y ago
Although that is the example server, maybe the library does?