Hochleistungs-Anwendungs-Webserver in C/C++

Gibt es einen Hochleistungs-Webserver (idealerweise Evented und Open Source) in C oder C++?

Ich möchte es verwenden können, indem es eine Methode/Funktion in meiner Anwendung mit einer ausgefüllten HTTP-Anforderungsklasse/-struktur aufruft, und dann kann ich eine ausgefüllte HTTP-Antwortklasse/-struktur zurückgeben.

Wenn es sich nicht um Open Source handelt, brauche ich eine integrierte Unterstützung für Long-Polling-Verbindungen, Keep-Alive usw. Andernfalls denke ich, dass ich diese Dinge selbst hinzufügen kann.

Wenn Sie keinen solchen verfügbaren Server kennen, würden Sie empfehlen, einen eigenen Webserver zu schreiben, um die Aufgabe zu erfüllen? Es kann nicht dateibasiert und in leistungsfähigem C/C++ geschrieben sein.

Bearbeiten: Ich denke so etwas wie den Ruby Mongrel für C, wenn das hilft.

Ich hatte die gleichen Anforderungen für meinen Job, also habe ich eine Reihe von Lösungen evaluiert: Mongoose, libmicrohttpd, libevent. Und ich habe auch darüber nachgedacht, Nginx-Module zu schreiben. Hier die Zusammenfassung meiner Erkenntnisse:

nginx

nginx-Projektseite

Ich liebe diesen Server und benutze ihn viel. Seine Leistung und Ressourcennutzung ist viel besser als die von Apache, den ich auch immer noch verwende, aber eine Migration zu nginx plane.

• Sehr gute abstimmbare Leistung. Reichhaltige Funktionalität. Portabilität.
• Die Modul-API ist nicht dokumentiert und scheint sehr ausführlich zu sein. Sieh dir das an nginx Hallo-Welt-Modul zum Beispiel.
• Nginx verwendet keine Threads, sondern mehrere Prozesse. Dies erschwert das Schreiben von Modulen, das Erlernen der nginx-API für gemeinsam genutzten Speicher usw.

Mungo

Mongoose-Projektseite

• Der gesamte Code des Servers befindet sich in einer einzigen mongoose.c-Datei (ca. 130 KB), keine Abhängigkeiten. Das ist gut.
• Ein Thread pro Verbindung. Wenn Sie also Parallelität benötigen, müssen Sie viele Threads konfigurieren, dh. hohe RAM-Auslastung. Nicht so gut.
• Die Leistung ist gut, wenn auch nicht außergewöhnlich.
• Die API ist einfach, aber Sie müssen alle Antwort-HTTP-Header selbst zusammenstellen, dh. Lernen Sie das HTTP-Protokoll im Detail.

libmicrohttpd

libmicrohttpd-Projektseite

• Offizielles GNU-Projekt.
• Die ausführliche API erscheint mir umständlich, obwohl sie viel einfacher ist, als Nginx-Module zu schreiben.
• Gute Leistung im Keep-Alive-Modus (Link zu meinen Benchmarks unten), nicht so gut ohne Keep-Alive.

libevent

libevent-Projektseite

Die Libevent-Bibliothek verfügt über einen integrierten Webserver namens evhttp.

• Es ist ereignisbasiert, verwendet dafür libevent.
• Einfache API. Erstellt HTTP-Header automatisch.
• Offiziell Singlethread. Dies ist ein großer Nachteil. Ich habe gefunden ein hack, wodurch mehrere Instanzen von evhttp gleichzeitig ausgeführt werden und Verbindungen vom selben Socket akzeptieren. Ich bin mir nicht sicher, ob alles sicher und robust ist.
• Die Leistung von Single-Threaded evhttp ist überraschend schlecht. Multi-Threaded-Hack funktioniert besser, aber immer noch nicht gut.

G-WAN

G-WAN-Projekt ist nicht Open Source, aber ich möchte ein paar Worte dazu sagen.

• Sehr gute Performance, geringer Speicherverbrauch, 150 KB ausführbar.
• Sehr bequeme ‘Servlet’-Bereitstellung: Kopieren Sie einfach die .c-Datei in das csp-Verzeichnis, und der laufende Server kompiliert sie automatisch. Code-Änderungen auch on the fly kompiliert.
• Einfache API. Obwohl in gewisser Weise eingeschränkt. Umfangreiche Funktionalität (json, Key-Value Store usw.).
• Instabil. Ich hatte Segfaults bei statischen Dateien. Hängt an einigen Beispielskripten. (Erfahren bei einer sauberen Installation. Nie gemischte Dateien verschiedener Versionen).
• Nur 32-Bit-Binär (nicht mehr).

Wie Sie also sehen können, hat mich keine der bestehenden Alternativen vollständig zufrieden gestellt. Also habe ich einen eigenen Server entwickelt, der …

NXWEB

NXWEB-Projektseite

Feature-Highlights:

• Sehr gute Leistung; siehe Benchmarks auf der Projektseite
• Kann Zehntausende gleichzeitige Anfragen bedienen
• Geringer Speicherbedarf
• Skalierbares Multithread-Modell
• Außergewöhnlich leichte Codebasis
• Einfache API
• Ordentliche Handhabung des HTTP-Protokolls
• Keep-Alive-Verbindungen
• SSL-Unterstützung (über GNUTLS)
• HTTP-Proxy (mit Keep-Alive-Verbindungspooling)
• Nicht blockierende Sendfile-Unterstützung (mit konfigurierbarem Speichercache für kleine Dateien; gzip-vorcodierte Dateibereitstellung)
• Modulares Design für Entwickler
• Kann als Daemon ausgeführt werden; startet sich bei einem Fehler neu
• Open Source

Einschränkungen:

• Hängt von der libev-Bibliothek ab (nicht mehr)
• Nur unter Linux getestet

Ich würde vorschlagen, eine ausführbare FastCGI-Datei zu schreiben, die mit vielen Hochleistungs-Webservern (sogar Closed-Source-Servern) verwendet werden kann.

Mungo: eine Datei. einfach und leicht zu bedienen. kein asycn io, aber perfekt für eingebettete und spezielle zwecke.

gwan. Ausgezeichnet. keine Abstürze. ultra gut geplante Konfiguration. sehr intelligent und einfach für die c/c++-Entwicklung, mit anderen Worten, sehr saubere, vernünftige api im Vergleich zu nginx. bietet einen Thread pro Kern. oder was auch immer Sie angeben. eine tolle Wahl. Größter Nachteil (vielleicht fehlt mir in diesem Bereich): Code kann nicht durchlaufen werden.

libevent: Single-Thread ist auf einem Single-Core-Rechner kein Nachteil. schließlich ist sein Punkt ein asynchroner I/O. hat Multithreads für andere Kerne.

nginx: keine persönliche Erfahrung. auf einem lückenhaften Server ernsthaft an Boden gewinnen. (schrecklich verwirrende API)

boost asio: eine C++-Bibliothek für Asynchio (Asio). fantastisch. braucht eine freundliche API auf höherer Ebene für Einfaltspinsel wie mich. und andere, die von PHP, Java, Javascript, node.js und anderen Websprachen kommen.

Python-Flasche: Tolle 1-Datei-Lib (Framework/System), die es einfach macht, Python-Web-Apps zu erstellen. hat/ist ein eingebauter httpd-Server, wie libevent und node.js

node.js: Javascript-Asyncio-Server. eine hervorragende Auswahl. Leider müssen Sie in Javascript programmieren, das wird mühsam. während es etwas zu sagen gibt, um die Arbeit zu erledigen; es gibt auch etwas zu sagen, um sich während des Prozesses zu amüsieren. hoffentlich kommt niemand mit node.php

Ich werde dasselbe vorschlagen wie Axel Gneiting – habe aber eine Antwort mit meinen Gründen für diesen Ansatz geliefert:

1) HTTP ist als Protokoll nicht trivial – das Schreiben eines eigenen Servers oder das Ändern einer Standardlösung ist eine sehr komplexe Aufgabe – viel komplexer als die Verwendung der verfügbaren APIs zur Implementierung einer separaten Verarbeitungs-Engine

2) Die Verwendung eines (unmodifizierten) Mainstream-Webservers sollte Ihnen mehr Funktionalität bieten, als Sie benötigen (so dass Sie Platz zum Wachsen haben).

3) Die Verwendung eines (unmodifizierten) Mainstream-Webservers bedeutet normalerweise, dass er weitaus umfassender getestet und dokumentiert wurde als ein Homebrew-System.

4) .. und es ist wahrscheinlicher, dass es sicher und stabil ist.

5) Mit fastCGI können Sie alle Arten von Sprachen verwenden, um Ihre Back-End-Verarbeitung in zu entwickeln – einschließlich C++ und C. Es gibt Standard-Toolkits zur Verfügung, um dies zu erleichtern.

6) Alternativ bieten viele Webserver Unterstützung für das Ausführen von Interpreter-Engines im Prozess (z. B. mod_php, mod_perl). Ich würde jedoch davon abraten, Ihren eigenen nativen Code als Modul auszuführen.

Es kann nicht dateibasiert sein.

Eh? Was bedeutet das?

Ich bin ein begeisterter nginx Benutzer; nginx ist in C geschrieben; nginx scheint, als könnte es für Sie funktionieren. Wenn Sie die allerbeste Geschwindigkeit aus Nginx herausholen möchten, würde ich ein Nginx-Modul erstellen. Hier sind Module von Drittanbietern die Sie untersuchen können, um eine Vorstellung davon zu bekommen, was es erfordert.

Was die langen Abfrageanforderungen betrifft, sollten Sie sich die HTTP-Push-Module ansehen.