высокопроизводительный веб-сервер приложений на C / C ++

Question

Существует ли какой-либо высокопроизводительный веб-сервер (с идеальным выравниванием и открытым исходным кодом) на C или C ++?

Я бы хотел использовать его, так как он вызывает метод / функцию в моем приложении сзаполненный класс / структура HTTP-запроса, а затем я могу вернуть ему заполненный класс / структуру HTTP-ответа.

Если это не открытый исходный код, мне нужна встроенная поддержка для длительного опросасоединения, поддержание работоспособности и т. д., в противном случае, я думаю, что я могу добавить эти вещи самостоятельно.

Если вы не знаете ни о каких доступных серверах, вы бы порекомендовали написать свой собственный веб-сервер для выполнения задачи?Это не может быть основанным на файлах и должно быть написано на высокопроизводительном C / C ++.

---

Редактировать: я думаю что-то вроде Ruby Mongrel для C, если этопомогает.

Answer 1

У меня были те же требования к моей работе, поэтому я оценил несколько решений: mongoose, libmicrohttpd, libevent.И я также думал о написании модулей nginx.Вот краткое изложение моих выводов:

nginx

страница проекта nginx

Я люблю этот сервер и очень его использую.Его производительность и использование ресурсов намного лучше, чем у Apache, который я до сих пор использую, но планирую перейти на nginx.

• Очень хорошая настраиваемая производительность.Богатый функционал.Переносимость.
• Модуль API не документирован и кажется очень многословным.См., Например, nginx hello world module .
• Nginx не использует потоки, но использует несколько процессов.Это усложняет написание модулей, требует изучения API nginx для разделяемой памяти и т. Д.

mongoose

страница проекта mongoose

• Весь код сервера находится в одном файле mongoose.c (около 130 КБ), никаких зависимостей.Это хорошо.
• Один поток на соединение, поэтому, если вам нужен параллелизм, вам нужно настроить множество потоков, т.е.высокое использование оперативной памяти.Не слишком хорошо.
• Производительность хорошая, хотя и не исключительная.
• API прост, но вы должны сами составлять все HTTP-заголовки ответа, т.е.подробное изучение протокола HTTP.

libmicrohttpd

Страница проекта libmicrohttpd

• Официальный проект GNU.
• Подробный API кажется мне неловким, хотя гораздо проще, чем писать модули nginx.
• Хорошая производительность в режиме keep-alive (ссылка на мои тесты ниже), не очень хорошая без keep-alive.

libevent

страница проекта libevent

Библиотека Libevent имеет встроенный веб-сервер evhttp.

• Это событиена основе, использует libevent для этого.
• Easy API.Создает заголовки HTTP автоматически.
• Официально однопоточный.Это главный недостаток.Я нашел хак , который заставляет несколько экземпляров evhttp работать одновременно, принимая соединения из одного сокета.Не уверен, что все это безопасно и надежно.
• Производительность однопоточного evhttp на удивление плохая.Многопоточный хак работает лучше, но все же не хорошо.

G-WAN

Проект G-WAN не является открытым исходным кодом, но я бы хотелЧтобы сказать несколько слов об этом.

• Очень хорошая производительность, низкое использование памяти, исполняемый файл 150 КБ.
• Очень удобное развертывание "сервлета": просто скопируйте файл .c в каталог cspи запущенный сервер автоматически его компилирует.Модификации кода также скомпилированы на лету.
• Простой API.Хотя ограничен в некоторых отношениях.Богатая функциональность (json, хранилище значений ключей и т. Д.).
• Нестабильный.У меня были segfaults на статических файлах.Зависает на некоторых образцах скриптов.(Опытный при чистой установке. Никогда не смешивайте файлы разных версий).
• Только 32-разрядный двоичный файл (больше нет).

Итак, как вы можете видетьНи одна из существующих альтернатив не удовлетворила меня полностью.Итак, я разработал свой собственный сервер, который ...

NXWEB

Страница проекта NXWEB

Основные характеристики:

• Очень хорошая производительность;см. тесты на странице проекта
• Может обслуживать десятки тысяч одновременных запросов
• Небольшой объем памяти
• Многопоточная модель, рассчитанная на масштабирование
• Исключительно легкая база кода
• Простой API
• Достойная обработка протокола HTTP
• Поддержание активности соединений
• Поддержка SSL (через GNUTLS)
• HTTP-прокси (сkeep-alive пул соединений)
• Неблокирующая поддержка sendfile (с настраиваемым кешем малой файловой памяти; подача предварительно закодированных файлов gzip)
• Модульная конструкция для разработчиков
• Может бытьбеги как демон;перезапускается при ошибке
• с открытым исходным кодом

ограничения:

• Зависит от библиотеки libev (больше нет)
• Проверено только на Linux

Answer 2

Я бы предложил написать исполняемый файл FastCGI, который можно использовать со многими высокопроизводительными веб-серверами (даже с закрытым исходным кодом).

Answer 3

мангуст: один файл.Легко и просто использовать.не asycn io, но идеально подходит для встраиваемых и специальных целей.

gwan.отлично.без сбоев.ультра хорошо спланированная конфигурация.очень умный и простой для разработки на c / c ++, другими словами, очень чистый разумный API по сравнению с nginx.обеспечивает поток на ядро.или что вы укажете.отличный выбор.самый большой недостаток (может быть, мне не хватает в этой области): не может пройти через код.

libevent: однопоточность не является недостатком на одноядерном компьютере.В конце концов, его точка - асинхронный ввод / вывод.действительно имеет многопоточность для других ядер.

nginx: нет личного опыта.получить серьезные основания на пятнистом сервере.(ужасно сбивает с толку API)

boost asio: библиотека c ++ для asynchio (asio).классно.нужен дружелюбный API высокого уровня для таких простаков, как я.и другие, которые пришли из php, java, javascript, node.js и других веб-языков.

бутылка python: потрясающая библиотека из 1 файла (framework / system), которая облегчает создание веб-приложений на python.имеет / является встроенным httpd-сервером, например, libevent и node.js

node.js: javascript asyncio server.отличный выбор.к сожалению, приходится программировать на javascript, что становится утомительным.пока есть что сказать, чтобы выполнить работу;Есть также что-то, что можно сказать, чтобы повеселиться во время процесса.надеюсь никто не придумает node.php

Answer 4

Я собираюсь предложить то же самое, что и Аксель Гнейтинг, - но предоставил ответ с моими причинами для такого подхода:

1) HTTP не является тривиальным в качестве протокола - написание собственного сервера иливнесение изменений в готовое решение является очень сложной задачей - намного более сложной, чем использование доступных API для реализации отдельного механизма обработки

2) Использование (неизмененного) основного веб-сервера должно предоставить вам больше функциональностичем вам требуется (чтобы у вас было все больше места).

3) Использование (неизмененного) основного веб-сервера обычно означает, что он был гораздо более тщательно протестирован и задокументирован, чем система домашнего приготовления.

4) .. и, скорее всего, он будет безопасным и стабильным.

5) Используя fastCGI, вы можете использовать все виды языков для разработки вашей внутренней обработки, включая C ++ и C. Есть стандартные наборы инструментов доступны для облегчения этого.

6) в качестве альтернативы многие веб-серверы предоставляют поддержку для runnвнутри движков интерпретатора (например, mod_php, mod_perl).Я бы посоветовал не запускать собственный нативный код как модуль.

Он не может быть основан на файлах.

А?Что это значит?

Answer 5

Я заядлый nginx пользователь; nginx написан на C; Кажется, что nginx может работать на вас. Если вам нужна самая лучшая скорость из nginx, я бы сделал модуль nginx. Вот сторонние модули , с которыми вы можете ознакомиться, чтобы понять, что для этого требуется.

Что касается требования длительного опроса, возможно, вы захотите взглянуть на push-модули http.