Требуется встраиваемая библиотека HTTP-сервера в реальном времени

Question

Изучив несколько доступных библиотек http-сервера, я еще не нашел того, что искал, и уверен, что не могу быть первым, кто предъявляет этот набор требований.

Мне нужна библиотека, которая представляет API, который является «конвейерным». Конвейерная передача используется для описания функции HTTP, при которой несколько запросов HTTP могут отправляться по каналу TCP одновременно, не ожидая ответа. Мне нужна похожая функция в библиотечном API, где мое приложение может получать все эти запросы без необходимости отправки ответа (я отвечу, но хочу иметь возможность обрабатывать несколько запросов одновременно, чтобы уменьшить влияние внутренней задержки).

Таким образом, библиотека веб-сервера должна будет поддерживать следующий поток

1) HTTP-клиент передает http-запрос 1

2) HTTP-клиент передает http-запрос 2 ...

3) Библиотека веб-сервера получает запрос 1 и передает его в приложение «Мой веб-сервер»

4) Приложение My Web Server получает запрос 1 и отправляет его в «Моя система»

5) Веб-сервер получает запрос 2 и передает его в приложение «Мой веб-сервер»

6) Приложение My Web Server получает запрос 2 и отправляет его в «Моя система»

7) Приложение My Web Server получает ответ на запрос 1 от My System и передает его на веб-сервер

8) Веб-сервер передает HTTP-ответ 1 клиенту HTTP

9) Приложение My Web Server получает ответ на запрос 2 от My System и передает его на веб-сервер

10) Веб-сервер передает HTTP-ответ 2 клиенту HTTP

Надеюсь, это иллюстрирует мое требование. Есть две ключевые точки для распознавания. Ответы на библиотеку веб-сервера: асинхронный и может быть несколько HTTP-запросов, переданных в My Web Серверное приложение с выдающимися ответами.

Дополнительные требования

1. Встраиваемый в существующее приложение 'C'
2. Маленький след; Мне не нужны все функции, доступные в Apache и т. Д.
3. Эффективное; нужно будет поддерживать тысячи запросов в секунду
4. Разрешает асинхронные ответы на запросы; это небольшая задержка ответов, и, учитывая требуемую пропускную способность запросов, синхронная архитектура не будет работать для меня.
5. Поддержка постоянных TCP-соединений
6. Поддержка использования с соединениями Server-Push Comet
7. Open Source / GPL
8. поддержка HTTPS
9. Портативный через Linux, Windows; желательно больше.

Буду очень признателен за любую рекомендацию

С наилучшими пожеланиями

Answer 1

Для справки в будущем, которая соответствует вашим требованиям, взгляните на libasyncd Я один из авторов.

Встраиваемый в существующее приложение 'C'

Это написано на C.

Маленький след; Мне не нужны все функции, доступные в Apache и т. Д.

Очень компактный.

Эффективное; нужно будет поддерживать тысячи запросов в секунду

Это основанная на Libvent среда. Может справиться больше, чем это.

Разрешает асинхронные ответы на запросы;

Это асинхронно. Также поддерживаю конвейерную обработку.

Поддержка постоянных TCP-соединений

Конечно, продолжай в том же духе.

Поддержка использования с соединениями Server-Push Comet

Это зависит от того, как вы кодируете свою логику.

Open Source / GPL

по лицензии BSD

поддержка HTTPS

Да. он поддерживает https с openssl.

Портативный через Linux, Windows; желательно больше.

Переносной, но не windows на данный момент, но переносимый на windows.

Answer 2

Вы можете попробовать libmicrohttp .

Answer 3

Используйте Лук , Люк. Это легкая и простая в использовании библиотека HTTP-сервера на C.

Answer 4

То, что вы хотите - это то, что поддерживает HTTP-конвейеризацию . Вам следует ознакомиться с этой страницей, если вы еще этого не сделали.

Да, перейдите на libmicrohttp . Он поддерживает SSL и т. Д. И работает как в Unix, так и в Windows.

Тем не менее, Кристофер прямо на месте в своем комментарии. Если у вас есть время запуска для каждого ответа, вы не получите большого выигрыша от конвейерной обработки. Однако, если у вас есть только значительное время ответа на первый запрос, вы можете что-то выиграть.

С другой стороны, если у каждого ответа есть время запуска, вы можете получить большую выгоду , а не , используя конвейеризацию, но создав новый запрос для каждого объекта. Тогда у каждого запроса может быть свой собственный поток, который параллельно поглощает затраты на запуск. Все ответы будут отправлены «сразу» в оптимальном случае. libmicrohttp поддерживает этот режим работы в своей потоковой модели MHD_USE_THREAD_PER_CONNECTION.

Answer 5

UIP или LWIP может работать для вас. Я лично использую UIP. Это хорошо для небольшого числа клиентов и одновременных соединений (или, как вы это называете, «конвейерная обработка»). Тем не менее, это не так масштабируемо и не так быстро, как подача контента, как я понял из прочитанного. Я использовал простоту и небольшой размер uIP вместо мощности lwip, поскольку в моем приложении обычно всего 1 пользователь.

Я обнаружил, что uIP довольно ограничен по мере увеличения числа одновременных соединений. Однако я уверен, что это ограничение моих доступных буферов приема MAC, а не самого uIP. Я думаю, что lwip использует значительно больше памяти, чтобы обойти это. У меня просто недостаточно оперативной памяти Ethernet для поддержки тонны входящих пакетов запросов. Тем не менее, я могу выполнять фоновый опрос ajax с задержкой около 15 мс на процессоре 56 МГц.

http://www.sics.se/~adam/software.html

На самом деле я изменил uIP несколькими способами. Добавление DHCP-сервера и поддержка многоэтапного POST для загрузки файлов - вот что важно. Дайте мне знать, если у вас есть какие-либо вопросы.

Answer 6

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

Answer 7

Говард,

Вы смотрели на lighthttpd ? Он отвечает всем вашим требованиям, за исключением того, что он явно не является встроенным веб-сервером. Но это открытый исходный код, и его компиляция в ваше приложение не должна быть слишком сложной. Затем вы можете написать собственный плагин для обработки ваших запросов.

Answer 8

Отслеживание предыдущих комментариев и обновлений ...

Вы не говорите, сколько одновременных подключений у вас будет, а просто «TCP-связь».
Если это одно соединение, то вы будете использовать HTTP конвейерную обработку, как упоминалось ранее; так что вам понадобится всего несколько потоков & mdash; а не тысячи & mdash; обрабатывать запросы в начале конвейера.

Так что вам не нужно иметь поток для каждого запроса; просто небольшой пул рабочих для каждого соединения.

Провели ли вы какое-либо тестирование или внедрение, чтобы показать, действительно ли у вас есть проблемы с задержкой ответа для конвейерных соединений?
Если ваше встроенное устройство достаточно мощное, чтобы справляться с тысячами запросов в секунду, включая настройку TLS, шифрование и дешифрование, я бы опасался преждевременной оптимизации на этом уровне.