Когда то ковырялся в системе плагинов envoy, так же thread local storage хоста кладете экземпляры wasm-движка и из-за этого имеете повышенное потребление памяти?
У нас рабочие процессы однопоточные, так что thread local storage в принципе не используется. Движок один, а виртуальные машины могут быть на каждый запрос или по одной на все запросы внутри каждого рабочего процесса - как настроите.
Не появились пропозалы, позволяющие не копировать память?
Нет. Это архитектурная проблема nginx, которую невозможно исправить не сломав обратную совместимость тотально. Там нет как такового публичного обособленного интерфейса для разработчиков модулей, а просто выставлены внутренние кишки наружу, как есть, и способ сборки с ними.
В итоге понятие API для модулей размыто: практически всё является публичным API и даже то, во что авторы не предполагали, что модулям следует лезть. Поэтому любая доработка или исправление бага потенциально может что-то сломать в чужом коде.
Это с одной стороны дает мощь и гибкость: в модулях можно реализовать практически что угодно, а с другой создает множество проблем в плане поддержки всего этого хозяйства.
nginx пытался решать это с помощью njs, агитируя писать расширения в рамках встроенного движка JavaScript.
Любой сторонний модуль на Си в nginx и любом его форке - это потенциальная головная боль, мина замедленного действия. Никаких гарантий совместимости API даже между минорными версиями у nginx нет. В любой момент, после очередного обновления, модуль может начать подтекать, либо вызывать ещё какие-то проблемы, совершенно неожиданные. И обычно первое же, что мы просим при жалобе на любой баг - это попробовать воспроизвести без сторонних модулей, ибо статистика по ним печальная.
Поэтому если можно лишний раз не использовать какой-то сторонний модуль, то лучше и не использовать.
К тому же в официальных репозиториях nginx, например, никакого fancyindex модуля нет. Т.е. если вы его используете, то видимо собирали самостоятельно, либо nginx у вас установлен не из официального репозитория. Качество пакета nginx в сторонних репозиториях, в том числе репозиториях дистрибутивов, оставляет желать лучшего. Там обычно пакетами занимаются плохо разбирающиеся в нюансах nginx мейнтейнеры. Как результат, сборщики в Debian умудрялись долгое время собирать пакет с серьезной уязвимостью - очень наглядный прецедент. Да и версии пакетов зачастую в других репозиториях отстают, из-за чего серьезные и важные исправления порой сильно запаздывают.
я акцентировал внимание на том, что "у нас" почему-то принято сразу получать прибыль, а не инвестировать, иногда реально долго, прежде чем получать доход
Это же не зависит от нашего желания или нежелания. Это вопрос доступности долгих денег. И в текущих экономических реалиях (ставку ЦБ РФ знаете же, а как часто у нас постоянно какие-то потрясения...) вполне понятно почему мало кто готов вкладывать немалые деньги на десятки лет вперед. Таковы реалии, к сожалению.
Некоторые и не меняют, а просто делают симлинк angie -> nginx, вот живой пример: https://habr.com/ru/articles/869204/ - в чем обман то? И так тоже можно. =)
У нас в пакетах пути отличаются специально, чтобы не конфликтовать с пакетами nginx и дать возможность поставить в систему одновременно оба сервера, протестировать, плавно переехать. Тут уж кому как удобнее.
Я не считаю пользователей бесплатной версии какими-то не такими. Просто есть такая пословица "дареному коню в зубы не смотрят". Вы рассуждаете, что вот сделали бы мы активные проверки в бесплатной версии - тогда бы больше было пользователей и нам было бы лучше. Но весь практический опыт говорит ровно об обратном. Есть пользователи, которые купили PRO благодаря активным проверкам и это позволило расширить команду, сделать больше фич в том числе в бесплатной версии и, например, не закрыться.
Я вот в nginx пришел практически с момента основания компании, в 2011. Тогда никто о платной версии nginx plus даже не помышлял. Имея долю на рынке веб-серверов более 5% во всем мире, сколько nginx собирал пожертвований, знаете? Ровно столько, что хватало исключительно только на оплату хостинга для `nginx.org`. Разработчики просто проедали деньги западных инвесторов, которые разумеется хотели их приумножить рано или поздно (что потом и случилось в момент продажи в F5).
И это были реалии, когда западные инвесторы с интересом смотрели на стартапы с офисами в Москве и можно было рассчитывать на венчур, долгие деньги. Если кто-то считает, что мы жадные и что-то не так делаем, то пожалуйста: лицензия BSD позволяет, делайте ещё форк, делайте лучше - тут никто ж не мешает. Наш коллега, Максим Дунин так и поступил, взял сделал freenginx - никакой коммерческой версии у него нет, никакого конфликта интересов. Много там нового за год то появилось? То-то и оно.
На счет личности не согласен, лишь ответил на то, что звучало как обвинение в том числе в мой адрес: "а вы все также продолжаете урезать функционал".
А по поводу наличия желания конкурировать все очень просто. Одного желания недостаточно. Ещё ресурсы нужны.
одного включения в реестр "отечественного" ПО недостаточно. Нужны реальные преимущества относительно ванильного nginx.
Как лихо обнулили многие сотни часов разработчиков, потраченные на более десятка различных функциональных возможностей относительно ванильного nginx, часть из которых, например, перечислена тут: https://angie.software/angie/docs/#index-features-oss
Есть же функции, нужные реально только Энтерпрайзу, а базовые вещи вроде балансирования должны быть во всех версиях.
Извините, но кому должны? Завтра вызывает начальник и говорит, а вот эту работу вы должны делать бесплатно, а почему спросите? А потому, что вот Иван Иваныч из соседнего отдела - это бесплатно сделал.
Если вы готовы работать бесплатно - то напишите на `hr@wbsrv.ru`. Честно скажу, пока ни одного такого сотрудника не встречал.
Правда же в том, что бесплатного ничего не бывает, а то, что вы бесплатно получаете на самом деле просто оплатил кто-то другой прямо или косвенно (в том числе это относится и к haproxy и вообще любому написанному коду - кто-то потратил свое время, поработал над кодом). Не секрет, что nginx всю дорогу был убыточной компанией - итог всем известен. Про наши приключения есть отдельная статья.
Лучшее, что вы можете сделать - это убедить начальство закупить Angie PRO, чтобы поддержать разработку в том числе опенсорс версии (предполагаю, что у вас компания не бесплатно работает и выручка есть?). А без этого не будет никакой версии и никаких новых фич, только если не найдутся люди, готовые работать бесплатно столько же, сколько они используют бесплатного ПО.
Когда разработчиков и их семьи начнут бесплатно кормить и бесплатно предоставлять жилье - тогда начнем программировать все в бесплатной версии. А пока суровый оскал капитализма заставляет искать возможности для существования.
Вообще это довольно востребованная функциональность. Как простой пример, php-fpm не может вместить в себя бесконечное количество параллельно обрабатываемых запросов - просто память закончится. Поэтому число рабочих процессов ограничено сверху. И вместо того, чтобы пытаться наливать запросы сверх этого числа - более разумной стратегией будет выставить ограничение на балансировщике, чтобы тот не пытался наливать больше, чем позволяет ёмкость бекенда, тогда лишние запросы можно либо отсекать, либо складывать во временную очередь и далее направлять на первый освободившийся сервер (что и делает "queue").
Всё это верно в той или иной степени относительно любого балансируемого бекенда. Ресурсы бекендов не безграничны, в том числе поэтому их разворачивают несколько и горизонтально пытаются масштабировать.
> Думается, что если бы это было нужной многим фичей, то оно было бы в разных проксях доступно.
Оно доступно во многих серьезных балансировщиков крупных вендоров и появилось не на пустом месте.
А в тексте вроде это указано в конце соответствующих абзацев про эти модули: "Модуль "queue" создаёт .. Модуль существует для HTTP подсистемы и доступен в составе коммерческих продуктов Angie." и "Модуль активных проверок называется "upstream_probe" и доступен в составе коммерческих продуктов Angie.".
С точки зрения возможностей запуска процессов приложений - да. Производительность предполагается даже выше чем Unit отдельно и заметно выше, чем связка nginx+unit или любая другая комбинация с ним.
Или не работает, если есть какие-то конфликты или загружаются какие-то модули (модули от nginx не могут быть загружены в Angie, а пути к ним указываются в конфигах).
Как раз идея была в том, что не нужно сносить и останавливать nginx, а переход осуществляется плавно, предварительно протестировав и убедившись, что всё работает - уже далее переключать обработку запросов с nginx на Angie, сохраняя возможность в любой момент откатить обратно, если что-то пойдет не так.
Текущий подход позволяет мигрировать сохраняя конфигурацию nginx в первозданном виде и не удаляя его модулей из системы.
У нас SemVer по сути, т.е. 1.X.Y, где X обозначает основные обратно совместимые релизы новой функциональности, а Y - багфиксы. Стабильной и актуальной является единственная самая последняя версия на момент времени (на момент написания этого комментария - это 1.7.0).
Не стоит обманываться названием "стабильной" ветки nginx. Это просто неудачное название для legacy-ветки, из-за которого в своем блоге компания постоянно пыталась объяснять что "We generally recommend using the mainline branch". Стабильность стабильной ветки заключалась лишь в том, что это была замороженная на год произвольная версия, что давало время сторонним разработчикам адаптировать свой код, а тем, кто вынужден эти модули использовать - получать портированные из основной ветки исправления критических ошибок (где эти исправления появлялись одновременно или даже раньше).
Какой-то особой стабильности с точки зрения пользователя - там не было и не могло быть, поскольку она рождалась в результате ежегодного ритуала, когда просто текущий "mainline" релиз становился "stable", но в нем точно также содержались, как довольно старые фичи, добавленные год назад, так и самые свежие, добавленные только в последних версиях. В действительности, нечетные релизы зачастую были более стабильны просто за счет того, что там было больше актуальных исправлений и появлялись они раньше.
Поэтому всем рекомендовалось использовать именно нечетную ветку, если только у вас нет зависимости от какого-то стороннего модуля, который может сломаться. Более того, коммерческая версия NGINX Plus выпускалась на базе именно mainline ветки.
В сухом остатке - все релизы nginx - это стабильные релизы. А четные - это просто замороженные версии с возрастом от 0 до года.
У нас такой нужды в legacy-ветке нет, т.к. большинство популярных сторонних модулей мы собираем сами в своем репозитории под практически все мало-мальски популярные дистрибутивы и, при необходимости, сами их патчим.
Ошибки - это всегда неприятно и требуют исправления. К сожалению, не все ошибки в nginx можно легко исправить, некоторые из них имеют архитектурную природу. Но благо, как правило, такого рода ошибки не являются критичными.
Согласно Википедии, у Netflix 277 млн пользователей, т.е. получается на весь Netflix должно быть 20 стримящих серверов.
У Netflix-а около 18 000 серверов. У вас все расчеты имеют очень мало отношения к практике. Поэтому тут даже обсуждать нечего - всё это какие-то теоретические рассуждения исходя из того, что вам выдал чатгпт.
Я когда читал о протоколах мне показалось странным, что QUIC был уже два года на момент выхода HTTP/2
Вы что-то путаете. Финальная версия спецификации HTTP/2 появилась в мае 2015 году, а первый черновик в 2012.
QUIC стали придумывать ровно после того, как стала понятна неэффективность HTTP/2. Первый черновик спецификации на QUIC появился в в конце 2016, а финальная версия в 2021.
Стоимость шифрования упала, а объем HTTP-трафика также вырос в разы.
10 ГБ/с и 10 тыс. хендшейков это довольно мало для крупных сервисов. Вы очень странно пересчитали это в пользователей - оно разумеется не так и столько пользователей вы с такой низкой производительностью не обслужите.
Для сравнения, Netflix на своих серверах вынужден добиваться пиковой производительности до 800 Гб/c и таких серверов у них более десяти тысяч по всему миру.
Всего мировой трафик измеряется десятками эксабайт в день и немалую его часть составляет HTTP. Речь идет о протоколе, который будет использоваться отнюдь не на одном сервере, а во всей глобальной сети интернет. И тут стоит задуматься о том, какой вклад протокол вносит уже в энергопотребление всего человечества. По некоторым подсчетам: "20% of the world’s total electricity consumption may be used by the Internet by 2025" - в этот процент конечно входят затраты не только на передачу данных, но все равно она впечатляет и думать об энергоэффективности протокола имеет смысл.
Это один момент. А второй момент, заметная часть HTTP-клиентов - это мобильные устройства, где вопрос энергоэффективности также один из краеугольных сам по себе.
P.S. И спустя 10 лет можно с уверенностью сказать, что мистер Камп оказался во многом прав. Протокол HTTP/2 показал себя с не лучшей стороны, уязвимости в нем и вектора для DoS атак продолжают находить пачками по сей день. Пресловутый инновационный "server push" все браузеры повыкидывали, наигравшись и признав, что от этой технологии больше вреда нежели пользы, а работоспособность самого протокола в реальном мире оказалась местами хуже HTTP/1.1, что спешно начали изобретать замену в виде HTTP/3. Т.е. HTTP/2 не просуществовал и нескольких лет до того момента, как потребовалось создавать ему преемника.
man-pages - это не утилита. Это просто проект по документированию интерфейсов Linux-ядра и glibc (набор документации в формате понятном для утилиты man).
Отдельно есть утилита man и странички man по другим разделам, проектам, командам и т.д. - их разработкой и сопровождением занимаются другие люди.
Если man пропадет, для меня это будет катастрофой.
Так воспользуйтесь man, чтобы узнать кто же автор man/man-db. Не путать их с man-pages. Или хотя бы зайдите в репозиторий, чтобы посмотреть, кто же контрибьютер: https://gitlab.com/man-db/man-db/-/graphs/main?ref_type=heads - не сложно понять, что упомянутый Алехандро не имеет к самой утилите man никакого отношения.
The current man-pages maintainer is (since 2004) Michael Kerrisk (mtk.manpages@gmail.com; blog); starting in 2020, Alejandro Colomar (alx.manpages@gmail.com) has joined as comaintainer.
И похоже автор новости путает man-pages с man-db и утилитой man. Разрабочтик утилиты man с 2001 года и по сей день - Колин Ватсон.
У нас рабочие процессы однопоточные, так что thread local storage в принципе не используется. Движок один, а виртуальные машины могут быть на каждый запрос или по одной на все запросы внутри каждого рабочего процесса - как настроите.
Не встречались.
Нет. Это архитектурная проблема nginx, которую невозможно исправить не сломав обратную совместимость тотально. Там нет как такового публичного обособленного интерфейса для разработчиков модулей, а просто выставлены внутренние кишки наружу, как есть, и способ сборки с ними.
В итоге понятие API для модулей размыто: практически всё является публичным API и даже то, во что авторы не предполагали, что модулям следует лезть. Поэтому любая доработка или исправление бага потенциально может что-то сломать в чужом коде.
Это с одной стороны дает мощь и гибкость: в модулях можно реализовать практически что угодно, а с другой создает множество проблем в плане поддержки всего этого хозяйства.
nginx пытался решать это с помощью njs, агитируя писать расширения в рамках встроенного движка JavaScript.
Мы в Angie ещё добавили возможность делать это на WASM: https://angie.software/angie/docs/configuration/modules/wasm/
В общем-то основные минусы в статье упомянуты.
Любой сторонний модуль на Си в nginx и любом его форке - это потенциальная головная боль, мина замедленного действия. Никаких гарантий совместимости API даже между минорными версиями у nginx нет. В любой момент, после очередного обновления, модуль может начать подтекать, либо вызывать ещё какие-то проблемы, совершенно неожиданные. И обычно первое же, что мы просим при жалобе на любой баг - это попробовать воспроизвести без сторонних модулей, ибо статистика по ним печальная.
Поэтому если можно лишний раз не использовать какой-то сторонний модуль, то лучше и не использовать.
К тому же в официальных репозиториях nginx, например, никакого fancyindex модуля нет. Т.е. если вы его используете, то видимо собирали самостоятельно, либо nginx у вас установлен не из официального репозитория. Качество пакета nginx в сторонних репозиториях, в том числе репозиториях дистрибутивов, оставляет желать лучшего. Там обычно пакетами занимаются плохо разбирающиеся в нюансах nginx мейнтейнеры. Как результат, сборщики в Debian умудрялись долгое время собирать пакет с серьезной уязвимостью - очень наглядный прецедент. Да и версии пакетов зачастую в других репозиториях отстают, из-за чего серьезные и важные исправления порой сильно запаздывают.
Это же не зависит от нашего желания или нежелания. Это вопрос доступности долгих денег. И в текущих экономических реалиях (ставку ЦБ РФ знаете же, а как часто у нас постоянно какие-то потрясения...) вполне понятно почему мало кто готов вкладывать немалые деньги на десятки лет вперед. Таковы реалии, к сожалению.
Некоторые и не меняют, а просто делают симлинк angie -> nginx, вот живой пример: https://habr.com/ru/articles/869204/ - в чем обман то? И так тоже можно. =)
У нас в пакетах пути отличаются специально, чтобы не конфликтовать с пакетами nginx и дать возможность поставить в систему одновременно оба сервера, протестировать, плавно переехать. Тут уж кому как удобнее.
Я не считаю пользователей бесплатной версии какими-то не такими. Просто есть такая пословица "дареному коню в зубы не смотрят". Вы рассуждаете, что вот сделали бы мы активные проверки в бесплатной версии - тогда бы больше было пользователей и нам было бы лучше. Но весь практический опыт говорит ровно об обратном. Есть пользователи, которые купили PRO благодаря активным проверкам и это позволило расширить команду, сделать больше фич в том числе в бесплатной версии и, например, не закрыться.
Я вот в nginx пришел практически с момента основания компании, в 2011. Тогда никто о платной версии nginx plus даже не помышлял. Имея долю на рынке веб-серверов более 5% во всем мире, сколько nginx собирал пожертвований, знаете? Ровно столько, что хватало исключительно только на оплату хостинга для `nginx.org`. Разработчики просто проедали деньги западных инвесторов, которые разумеется хотели их приумножить рано или поздно (что потом и случилось в момент продажи в F5).
И это были реалии, когда западные инвесторы с интересом смотрели на стартапы с офисами в Москве и можно было рассчитывать на венчур, долгие деньги. Если кто-то считает, что мы жадные и что-то не так делаем, то пожалуйста: лицензия BSD позволяет, делайте ещё форк, делайте лучше - тут никто ж не мешает. Наш коллега, Максим Дунин так и поступил, взял сделал freenginx - никакой коммерческой версии у него нет, никакого конфликта интересов. Много там нового за год то появилось? То-то и оно.
На счет личности не согласен, лишь ответил на то, что звучало как обвинение в том числе в мой адрес: "а вы все также продолжаете урезать функционал".
А по поводу наличия желания конкурировать все очень просто. Одного желания недостаточно. Ещё ресурсы нужны.
Как лихо обнулили многие сотни часов разработчиков, потраченные на более десятка различных функциональных возможностей относительно ванильного nginx, часть из которых, например, перечислена тут: https://angie.software/angie/docs/#index-features-oss
Извините, но кому должны? Завтра вызывает начальник и говорит, а вот эту работу вы должны делать бесплатно, а почему спросите? А потому, что вот Иван Иваныч из соседнего отдела - это бесплатно сделал.
Если вы готовы работать бесплатно - то напишите на `hr@wbsrv.ru`. Честно скажу, пока ни одного такого сотрудника не встречал.
Правда же в том, что бесплатного ничего не бывает, а то, что вы бесплатно получаете на самом деле просто оплатил кто-то другой прямо или косвенно (в том числе это относится и к haproxy и вообще любому написанному коду - кто-то потратил свое время, поработал над кодом). Не секрет, что nginx всю дорогу был убыточной компанией - итог всем известен. Про наши приключения есть отдельная статья.
Лучшее, что вы можете сделать - это убедить начальство закупить Angie PRO, чтобы поддержать разработку в том числе опенсорс версии (предполагаю, что у вас компания не бесплатно работает и выручка есть?). А без этого не будет никакой версии и никаких новых фич, только если не найдутся люди, готовые работать бесплатно столько же, сколько они используют бесплатного ПО.
Когда разработчиков и их семьи начнут бесплатно кормить и бесплатно предоставлять жилье - тогда начнем программировать все в бесплатной версии. А пока суровый оскал капитализма заставляет искать возможности для существования.
Вообще это довольно востребованная функциональность. Как простой пример, php-fpm не может вместить в себя бесконечное количество параллельно обрабатываемых запросов - просто память закончится. Поэтому число рабочих процессов ограничено сверху. И вместо того, чтобы пытаться наливать запросы сверх этого числа - более разумной стратегией будет выставить ограничение на балансировщике, чтобы тот не пытался наливать больше, чем позволяет ёмкость бекенда, тогда лишние запросы можно либо отсекать, либо складывать во временную очередь и далее направлять на первый освободившийся сервер (что и делает "queue").
Всё это верно в той или иной степени относительно любого балансируемого бекенда. Ресурсы бекендов не безграничны, в том числе поэтому их разворачивают несколько и горизонтально пытаются масштабировать.
> Думается, что если бы это было нужной многим фичей, то оно было бы в разных проксях доступно.
Оно доступно во многих серьезных балансировщиков крупных вендоров и появилось не на пустом месте.
А в тексте вроде это указано в конце соответствующих абзацев про эти модули: "Модуль "queue" создаёт .. Модуль существует для HTTP подсистемы и доступен в составе коммерческих продуктов Angie." и "Модуль активных проверок называется "upstream_probe" и доступен в составе коммерческих продуктов Angie.".
error_logв режимеdebugбыл всегда. Или что вы имеете в виду?С точки зрения возможностей запуска процессов приложений - да. Производительность предполагается даже выше чем Unit отдельно и заметно выше, чем связка nginx+unit или любая другая комбинация с ним.
Или не работает, если есть какие-то конфликты или загружаются какие-то модули (модули от nginx не могут быть загружены в Angie, а пути к ним указываются в конфигах).
Как раз идея была в том, что не нужно сносить и останавливать nginx, а переход осуществляется плавно, предварительно протестировав и убедившись, что всё работает - уже далее переключать обработку запросов с nginx на Angie, сохраняя возможность в любой момент откатить обратно, если что-то пойдет не так.
Текущий подход позволяет мигрировать сохраняя конфигурацию nginx в первозданном виде и не удаляя его модулей из системы.
При запуске всегда можно передать опцию
-cи изменить путь к конфигурационному файлу.У нас SemVer по сути, т.е. 1.X.Y, где X обозначает основные обратно совместимые релизы новой функциональности, а Y - багфиксы. Стабильной и актуальной является единственная самая последняя версия на момент времени (на момент написания этого комментария - это 1.7.0).
Не стоит обманываться названием "стабильной" ветки nginx. Это просто неудачное название для legacy-ветки, из-за которого в своем блоге компания постоянно пыталась объяснять что "We generally recommend using the mainline branch". Стабильность стабильной ветки заключалась лишь в том, что это была замороженная на год произвольная версия, что давало время сторонним разработчикам адаптировать свой код, а тем, кто вынужден эти модули использовать - получать портированные из основной ветки исправления критических ошибок (где эти исправления появлялись одновременно или даже раньше).
Какой-то особой стабильности с точки зрения пользователя - там не было и не могло быть, поскольку она рождалась в результате ежегодного ритуала, когда просто текущий "mainline" релиз становился "stable", но в нем точно также содержались, как довольно старые фичи, добавленные год назад, так и самые свежие, добавленные только в последних версиях. В действительности, нечетные релизы зачастую были более стабильны просто за счет того, что там было больше актуальных исправлений и появлялись они раньше.
Поэтому всем рекомендовалось использовать именно нечетную ветку, если только у вас нет зависимости от какого-то стороннего модуля, который может сломаться. Более того, коммерческая версия NGINX Plus выпускалась на базе именно mainline ветки.
В сухом остатке - все релизы nginx - это стабильные релизы. А четные - это просто замороженные версии с возрастом от 0 до года.
У нас такой нужды в legacy-ветке нет, т.к. большинство популярных сторонних модулей мы собираем сами в своем репозитории под практически все мало-мальски популярные дистрибутивы и, при необходимости, сами их патчим.
Придерживаемся.
Ошибки - это всегда неприятно и требуют исправления. К сожалению, не все ошибки в nginx можно легко исправить, некоторые из них имеют архитектурную природу. Но благо, как правило, такого рода ошибки не являются критичными.
У Netflix-а около 18 000 серверов. У вас все расчеты имеют очень мало отношения к практике. Поэтому тут даже обсуждать нечего - всё это какие-то теоретические рассуждения исходя из того, что вам выдал чатгпт.
Вы что-то путаете. Финальная версия спецификации HTTP/2 появилась в мае 2015 году, а первый черновик в 2012.
QUIC стали придумывать ровно после того, как стала понятна неэффективность HTTP/2. Первый черновик спецификации на QUIC появился в в конце 2016, а финальная версия в 2021.
Стоимость шифрования упала, а объем HTTP-трафика также вырос в разы.
10 ГБ/с и 10 тыс. хендшейков это довольно мало для крупных сервисов. Вы очень странно пересчитали это в пользователей - оно разумеется не так и столько пользователей вы с такой низкой производительностью не обслужите.
Для сравнения, Netflix на своих серверах вынужден добиваться пиковой производительности до 800 Гб/c и таких серверов у них более десяти тысяч по всему миру.
Всего мировой трафик измеряется десятками эксабайт в день и немалую его часть составляет HTTP. Речь идет о протоколе, который будет использоваться отнюдь не на одном сервере, а во всей глобальной сети интернет. И тут стоит задуматься о том, какой вклад протокол вносит уже в энергопотребление всего человечества. По некоторым подсчетам: "20% of the world’s total electricity consumption may be used by the Internet by 2025" - в этот процент конечно входят затраты не только на передачу данных, но все равно она впечатляет и думать об энергоэффективности протокола имеет смысл.
Это один момент. А второй момент, заметная часть HTTP-клиентов - это мобильные устройства, где вопрос энергоэффективности также один из краеугольных сам по себе.
P.S. И спустя 10 лет можно с уверенностью сказать, что мистер Камп оказался во многом прав. Протокол HTTP/2 показал себя с не лучшей стороны, уязвимости в нем и вектора для DoS атак продолжают находить пачками по сей день. Пресловутый инновационный "server push" все браузеры повыкидывали, наигравшись и признав, что от этой технологии больше вреда нежели пользы, а работоспособность самого протокола в реальном мире оказалась местами хуже HTTP/1.1, что спешно начали изобретать замену в виде HTTP/3. Т.е. HTTP/2 не просуществовал и нескольких лет до того момента, как потребовалось создавать ему преемника.
man-pages - это не утилита. Это просто проект по документированию интерфейсов Linux-ядра и glibc (набор документации в формате понятном для утилиты man).
Отдельно есть утилита man и странички man по другим разделам, проектам, командам и т.д. - их разработкой и сопровождением занимаются другие люди.
Так воспользуйтесь man, чтобы узнать кто же автор man/man-db. Не путать их с man-pages. Или хотя бы зайдите в репозиторий, чтобы посмотреть, кто же контрибьютер: https://gitlab.com/man-db/man-db/-/graphs/main?ref_type=heads - не сложно понять, что упомянутый Алехандро не имеет к самой утилите man никакого отношения.
Непонятно, почему Керриск назван предыдущим сопровождающим.
Он никуда и не уходил.
https://www.kernel.org/doc/man-pages/maintaining.html
The current man-pages maintainer is (since 2004) Michael Kerrisk (mtk.manpages@gmail.com; blog); starting in 2020, Alejandro Colomar (alx.manpages@gmail.com) has joined as comaintainer.
И похоже автор новости путает man-pages с man-db и утилитой man. Разрабочтик утилиты man с 2001 года и по сей день - Колин Ватсон.