Small and efficient http server and client written in C++
httpp alternatives and similar libraries
Based on the "Web Application Framework" category.
Alternatively, view httpp alternatives based on common mentions on social networks and blogs.
8.6 9.0 httpp VS drogonDrogon: A C++14/17 based HTTP web application framework running on Linux/macOS/Unix/Windows [Moved to: https://github.com/drogonframework/drogon]
8.4 7.2 httpp VS Oat++🌱Light and powerful C++ web framework for highly scalable and resource-efficient web application. It's zero-dependency and easy-portable.
5.1 7.9 httpp VS CutelystA C++ Web Framework built on top of Qt, using the simple approach of Catalyst (Perl) framework.
3.1 0.0 httpp VS QSimpleScadaQt based simple SCADA framework, with dashboard, static and dynamic components
* Code Quality Rankings and insights are calculated and provided by Lumnify.
They vary from L1 to L5 with "L5" being the highest.
Do you think we are missing an alternative of httpp or a related project?
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).
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.
$> 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
$> 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).
The current stable is the v0.7.0. There are still some things missing:
- Optional commonpp dependencies;
- Probes in the server.
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).
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
(against 70 to 90K with the 0.6.2) and
-k -c 8
options on the same machine, this means that HTTPP overhead is about 5 to 6
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.