Или у вас какие-то другие требования к протоколам для хайлоада, акромя пресловутой бинарности?

HTTP достаточно навороченный из коробки, чтобы позволять совершать очень разнообразные запросы -- с параметрами и со всякой сопутствующей метаинформацией. Он позволяет всякие разные режимы ответа, с фиксированной длиной или chunked, сжатие если чё можно подключить. Опять же криптографически можно прикрыть канал, если надо. Можно упаковать несколько запросов в одно соединение, или открыть несколько соединений. Можно использовать кукисы, чтобы идентифицировать агента, который разные запросы отсылает по разным соединениям, то есть прерывающаяся сессия -- это не проблема. С http знакомо всё сетевое оборудование, и, скорее всего, пропускает его без проблем.

И хрен бы с ним, всё это (за исключением номера порта <1000 -- с этим могут быть проблемы) несложно написать в спецификацию своего на коленке созданного протокола, но к http прилагается куча уже готовых библиотек, как клиентских, так и серверных. _Любых_ библиотек, на любой вкус, под любой язык программирования. Можно даже с целым фреймворком, причём тут тоже есть выбор, вне зависимости от того, какой язык программирования ты выберешь. Можно балансировать нагрузку готовыми инструментами. Тебе не надо писать аж целый nginx, если тебе вдруг понадобится прокси или ревёрс-прокси.

Я не представляю себе, насколько острым должен быть рецидив NIH-синдрома, чтобы начать пилить аж целый новый протокол со всеми сопутствующими библиотеками, фреймворками и инструментами. Не, ну если требования какие-нибудь сильно неподходящие для http, типа двустороннего обмена сообщениями по три байта каждый... Но даже здесь у http есть web-socket'ы.

> рекламируют как решения для хай лоада, используют мать его http
> базы данных

Это базы данных, у них узкое место -- вовсе не парсинг http. Ты можешь словить приступ NIH синдрома, проделать всё, что написано выше, запилить специально заточенный на скорость разбора бинарный протокол, и получить прирост производительности, который будет невозможно выделить из статистического шума.

А вот если на твоей нагрузке вдруг парсинг http станет узким местом, то вот тогда ты разработаешь альтернативный протокол, и добавишь в свой сервер опцией для тех, кому действительно надо. И даже нельзя сказать, что в результате ты будешь проделывать лишнюю работу (типа сначала на http реализовал, а потом на своём протоколе). На http реализовывать -- это настолько просто, что дополнительные затраты на разработку будет невозможно выделить из статистического шума (в том случае, если ты повторишь всё это действо достаточное количество раз, чтобы можно было бы считать статистику).

Не помогает. Так что получается ненужный.

Вы не туда видимо его пихаете.

Нужно делать бота имитирующего работу программиста(или иного ИТ специалиста) для всевозможных метрик. То есть чтобы он юлозил мышкой, митинги принимал, вносил правки в жиру.
Ну, для сисадмина(девопса) будет немного по другом но идея ясна, главное понимать корпоративные метрики.
И тогда можно работать сразу от 3х до 10ти работах.
Заодно бота который ищет работу в случае когда работодатель на одной из работ замечает бота.

>AWS lambda

Забавная штука, правда уже с главной страницы возникает один вопрос - что это такое, на который Амазон упорно не хочет давать ответа. Обилие маркетингового буллщита на квадратный миллиметр текста зашкаливает.
!Безсерверные! вычисления на !серверах! амазона онли 9.99 лол.

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