Popularity
2.9
Growing
Activity
0.9
-
130
12
23

Description

Small and efficient http server and client written in C++

Code Quality Rank: L1
Programming language: C++
Tags: Web Application Framework     HTTP     Asio     Curl    

httpp alternatives and similar libraries

Based on the "Web Application Framework" category

  • Crow

    8.9 0.0 L1 httpp VS Crow
    Crow is C++ micro web framework (inspired by Python Flask). [BSD]
  • lwan

    Experimental, scalable, high performance HTTP server. [GPL2]
  • Kore

    8.0 8.7 L3 httpp VS Kore
    ultra fast and flexible web server / framework for web applications developed in C. [ISC]
  • Civetweb

    Provides easy to use, powerful, C/C++ embeddable web server with optional CGI, SSL and Lua support. [MIT]
  • Pistache

    Pistache is a C++ REST framework written in pure C++11 with no external dependency. [Apache2]
  • libOnion

    lightweight library to help you create webservers in C programming language. [LGPLv3]
  • Wt

    6.4 8.7 L3 httpp VS Wt
    A C++ library for developing web applications.
  • facil.io

    Write network services in C using dynamic protocols such as HTTP and Websockets
  • TreeFrog Framework

    High-speed and full-stack web application framework based on C++ and Qt, which supports HTTP and WebSocket protocol (with O/R mapping). [BSD] website
  • Cutelyst

    A C++ Web Framework built on top of Qt, using the simple approach of Catalyst (Perl) framework.
  • QDjango

    A web framework written in C++ and built on top of the Qt library. Where possible it tries to follow django's API, hence its name. [LGPL]
  • CppCMS

    CppCMS is a Free High Performance Web Development Framework (not a CMS) aimed at Rapid Web Application Development.

Do you think we are missing an alternative of httpp or a related project?

Add another 'Web Application Framework' Library

README

Build Status Coverity Status

httpp

Micro http server and client written in C++

The motivation behind this little piece of code is to provide a really simple, yet efficient HTTP server to implement in-app webservice easily.

The HttpServer will take care of the connections, request parsing and response generation. The handler on another hand is reponsible for implementing the "logic" behind the service. For example, the server has a very limited knowledge of the HTTP protocol…

The HttpClient has been implemented using curl and its multi interface.

See an exampe [here](examples/echo/simple_echo_server.cpp) or [here](examples/ping/ping.cpp).

REQUIREMENTS

Boost is required, version >= 1.54 and libcurl. HTTPP has a dependency on CommonPP since the version 0.7. CommonPP has a dependency on Boost and TBB. The TBB dependency will become optional.

A C++14 compliant compiler is also required.

BUILD

$> mkdir -p $HTTPP_PATH && cd $HTTPP_PATH
$> git clone https://github.com/daedric/httpp.git .
$> git submodule update --init
$> mkdir -p $HTTPP_BUILD_PATH && cd $HTTPP_BUILD_PATH
$> cmake $HTTPP_PATH
$> make

A debian package can be generated running:

$> make package

To build tests:

$> cmake $HTTPP_PATH -DBUILD_TESTS=ON

Examples:

$> cmake $HTTPP_PATH -DBUILD_EXAMPLES=ON

To build the shared library version:

$> cmake $HTTPP_PATH -DBUILD_SHARED_LIBS=ON

By default the build is in release mode, to change that you can:

$> cmake $HTTPP_PATH -DBUILD_TESTS=ON -DCMAKE_BUILD_TYPE=DEBUG

The compilation and tests have been run on Mac OS X (curl and openssl from homebrew seems to be required to have all tests passing, I don't know why yet), and GNU/Linux distro (Ubuntu, ArchLinux).

Current stable

The current stable is the v0.7.0. There are still some things missing:

  • Optional commonpp dependencies;
  • Probes in the server.

Design choices

This section is only about the server.

Since the 0.7 version, HTTPP is trying to allocate as few memory as possible. Each connection is associated with some buffers that are never released to the system. This this might create a memory overhead, this allows to achieve a better performance.

The HTTP parser has been ported to Ragel to generate a faster parser than the one based on stream. I found out after having finished that Mongel did the same way before me, so I might try to import it if it makes sense.

At the same time, the parser avoids as much as possible copies by using boost::string_ref.

One of the reason is that HTTPP is designed to be used in a REST server exposing an API and developed for RTB platform, each request is relatively similar to the previous one in size. Second reason, it makes everything simpler (no buffer management, no release, no cache needed, etc).

Performances

This section is only about the server.

On a Dell 3800 with an Intel(R) Core(TM) i7-4702HQ CPU @ 2.20GHz, I was able to achieve between 160K and 180K request per second with the ping program (against 70 to 90K with the 0.6.2) and ab with -k -c 8 options on the same machine, this means that HTTPP overhead is about 5 to 6 micro seconds.

With a slightly more complex server that decoded the request, performed some string manipulation and returned a predefined json payload, we have seen approximately 220K requests per second on identical hardware, using wrk to drive the load testing. 5 threads were allocated to the httpp server, and 3 to wrk (with 500 concurrent connections).

This is scaling as threads are added but I don't have enough proper machine to do a real benchmark.