Высокопроизводительная клиентская http библиотека

А что, какой-нибудь curl не подходит?

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

Вот что курловика говорит:

Starting in 7.43.0, libcurl fully supports HTTP/2 multiplexing, which is the term for doing multiple independent transfers over the same physical TCP connection.

я имею ввиду какой-нибудь epoll, а не ХТТП 2

я имею ввиду какой-нибудь epoll

Ну у народа, вроде, получается прикрутить

https://gist.github.com/clemensg/5248927

curl не зависит от используемого event loop - бери какой нравится

курл как минимум не подходит потому что там нет ограничения на объем использованной памяти. если не закрывать хендлер - память будет расти до бесконечности. если каждый раз открывать/закрывать - медленно

Что за чушь? Если вычитывать входящие данные в CURLOPT_WRITEFUNCTION, а не накапливать их в памяти, то никакой проблемы нет

Wrong! Curl будет работать так, как ему скажешь. И где скажешь.

Еще кстати нетлиб есть. Или как его там.

curl_easy_setopt для ограничения памяти дайте пожалуйста

libserf

но я так понял кроме самое либы, еще кучу зависимостей нужно ставить

Это, вроде, два пакета: apr и apr-util. От них тот же Firefox, кажется, зависит. Я бы просто попробовал подключить serf, прежде чем что-то другое искать.

на каждый запрос - свой поток нужно создавать.

Поток на соединение, сказать keep-alive, чтобы сервер не отключался после запроса. После получения ответа на запрос можно в это-же соединение кидать следующий запрос. Где-то (сайт или исходники курла) был пример.

поток с разных хостов скачивает. и запросов очень много, на всех потоков не хватит

По потоку на хост. Если сервера быстро отдают, то несколько потоков(или десятков) займут весь канал. По мере выкачки и закрытия соединений конектиться к следующим хостам. Если толстый канал, то узкое место - диски, а не кол-во потоков.

curl_easy

Автор, извини, но ты сношаешь окружающим мозг. Ты бы еще из шелла курл вызывал и жаловался на производительность. Если надо стучаться по хттп неизвестно куда - то curl_multi в помощь. Он много всего умеет. Если для локального использоания - то наваять руками на асио псевдо-хттп парсер будет производительнее.

Как тут правильно упомянули, можно использовать curl через его curl_multi_socket интерфейс

pocoproject.org не подойдёт? Не знаю насчёт производительности.

curl_multi или libserf - есть мнения что быстрее?

Попробуй http://www.seastar-project.org/

Написан на идиоматическом C++11 с асинхронностью через future-promise-continuation, статической привязкой фиксированного числа тредов к ядрам и статическим пулом памяти, выделяемым при старте.

В конфигурации с кастомным сетевым стеком на DPDK на нем, теоретически, можно выжать практически предел производительности.

Пример реализации http клиента можно подсмотреть в apps/seawreck.

P.S. Правда чтобы его использовать нужно достаточно хорошо знать C++.

Ну и зачем нам в этом треде kernel-bypass networking, если мы здесь параметры curl_easy изучаем? И вообще у этого чуда израильской high-frequency trading мысли есть http клиент? А то поверхностное гугление только сервер выдает.

М, дочитал пост до конца и посмотрел seawreck - а где мои X.509 сертификаты и прозрачная обработка редиректов? Насколько это вообще http-библиотека (со всеми http(s) плюшками для людей), а не ASIO - только в профиль? Ну и распарсить chunked ответ - оно скорее всего распарсит, а посылать его умеет?

а где мои X.509 сертификаты

net/tls.hh

прозрачная обработка редиректов
Насколько это вообще http-библиотека (со всеми http(s) плюшками для людей), а не ASIO - только в профиль?

Второе, но «with batteries included». Поэтому часть все же придется писать руками.

Ну и зачем нам в этом треде kernel-bypass networking, если мы здесь параметры curl_easy изучаем?

Ну топикстартер не объяснил, что он имеет в виду под «Высокопроизводительная».