С точки зрения возможностей запуска процессов приложений - да. Производительность предполагается даже выше чем 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 года и по сей день - Колин Ватсон.
График "Available burst tokens" на картинке "rate=2, burst=2" - неверен. На самом деле он должен быть таким же, как на последней картинке с nodelay.
Само наличие или отсутствие параметра nodelay никак не влияет на burst. При обработке запросов, которые попали в burst и отмечены желтым на картинке - доступные burst-токены должны прибавляться.
Для начала у всех комментаторов пишущих про "срубить бабла с государства" хочется спросить, хотя бы просто для расширения своего кругозора, а как это сделать? Расскажите, если у вас такой опыт имеется и видите сразу сходу такую перспективу. Отдельно интересно, как это сделать на OSS версии и зачем в таком случае вообще выпускать какую-то OSS версию? Есть у меня подозрения, что среди пишущих подобные комментарии нет никого, кто сам бы пытался вот так прийти и продать что-то в госкомпанию, либо получить какой-то грант от государства. Если коротко, это не секрет полишинеля, что хуже и труднее заказчика, чем госзаказчик для частного бизнеса - придумать сложно. Для компаний с участием государства возможно всё иначе, но я в таких не работал, не знаю.
А второй момент в том, что независимо от того, заинтересуются ли какие-нибудь госы нашим продуктом или нет - хочется продолжать разрабатывать достаточно хороший и проверенный временем веб-сервер, продолжать успешно применять свой опыт и знания в той сфере и в том продукте, где есть наибольшие компетенции. Если бы можно было продолжать разрабатывать nginx, мы бы сидели и спокойно продолжали его разрабатывать, никто бы и пальцем не пошевелил, никакого Angie не возникло. Но это вообще не наше решение. Это решение компании, которая владеет сейчас nginx, и довольно очевидно, что это её решение было принято не ради импортозамещения в России.
> Angie (и ещё тысячи “российских” продуктов из известного реестра т.н. “отечественного ПО”) вряд ли бы появился, кабы не принятый закон об импортозамещении (сослагательное наклонение призвано вполне недвусмысленно показать, что я этого не утверждаю, а лишь предполагаю/допускаю).
А Angie в реестре и не присутствует. В нем только Angie PRO.
Ссылаясь на этот закон, компании прекрасно используют nginx. Для OSS присутствие в реестре не дает примерно ничего, поэтому Angie OSS в реестре и не присутствует. Для не OSS пока тоже особо не дает, при наличии OSS аналога. Зато если не присутствуешь, то на твою коммерческую версию даже смотреть не будут.
Исходя из этого, по факту реестр отечественного ПО не особо работает, тем более в нашем случае.
Но мне интересно, почему вы написали определенные слова и в кавычках? Присутствие в данном реестре - это не какая-то формальность, из него и исключить могут. Это не означает, что все строчки кода ПО, которое там находится - были написаны в России, хотя для nginx это даже на 99% именно так. Но это означает прежде всего, что есть некая компания, некое юр.лицо в российской юрисдикции, которое может понести вполне себе не "ответственность", а ОТВЕТСТВЕННОСТЬ по всей строгости, если вдруг что. Как на мой взгляд, это вполне себе в духе отечества, чтобы не писать это слово в кавычках применительно к реестру. Готовы на себя такую ответственность за какой-нибудь продукт взять просто так?
Поднятие бабла с госов и военки в США с некоторых пор стало совсем невозможно совместить с наличием офиса в России. Поэтому проще всех уволить и закрыть офис, что и предопределило появление Angie.
Потому, что это ближе по концепции к LTS. Т.е. каждый mainline релиз является стабильным, просто некоторые из них получают продленный на год срок поддержки и исправления критических ошибок.
И если у кого-то ещё остаются какие-то сомнения по поводу стабильности и позиционирования mainline ветки, то отдельно обращу внимание на то, как появляется очередная stable ветка: раз в год, обычно весной, текущая mainline ветка превращается в очередную stable ветку, при этом не имеет никакого значения, что какие-то функции и модули там уже почти год, а какие-то были добавлены за месяц до того. И ничего другого не происходит, никакой стабилизации кода, никаких дополнительных тестов - это просто ежегодное чисто формальное мероприятие от которого код не становится каким-то магическим образом более стабилен, чем был до того.
И "экспериментальность" отдельных модулей и функций - тут тоже совершенно ортогональная история. От переименования mainline ветки в очередную stable - "экспериментальные" модули и функции не перестают быть экспериментальными. Так, например, perl-модуль является экспериментальным с момента своего появления (в версии 0.3.21, выпущенной ещё в 2006 году) и по сей день. Т.е. этот "экспериментальный" модуль входит во все stable ветки за последние 18 лет.
Давайте заменим экспериментальный на нестабильный, что изменится? Вероятно ничего.
Как вы справедливо заметили ниже: нестабильный код не добавляют в стабильные релизы.
Тут у меня пожалуй вопрос лишь - зачем нестабильный модуль добавлять в стабильный релиз?
Это было бы очень странным и недальновидным решением с нашей стороны. Поэтому мы этого не делали. Может авторы nginx это сделали? Ниже попробуем разобраться.
Нестабильный - это тот код который не покрыт тестами, не поддерживает полностью rfc и имеет прочие недочеты.
Код HTTP/3 модуля достаточно неплохо покрыт тестами, а также неплохо соответствует RFC, благодаря чему даже согласно независимым тестам имеет хорошие характеристики по кросс-совместимости с другими реализациями (которые, кстати, не маркируются экспериментальными): https://interop.seemann.io/
Просто процитирую старшего продуктового директора nginx: We generally recommend using the mainline branch. This is where we commit all new features, performance improvements, and enhancements. We actively test and QA the mainline branch, so it’s arguably more stable than the “stable” branch. The mainline branch is also the source of NGINX Plus builds for our commercial customers.
Да, название второй ветки не совсем точное, что может сбить с толку. Правильнее было бы назвать вторую ветку - legacy, т.к. stable в её названии прежде всего означает заморозку API, что более актуально, если у вас есть какие-то устаревшие модули, на поддержку совместимости и актуальности которых вы хотите тратить меньше сил.
Я также замечу, что разработчик, не только включил модуль HTTP/3 в ветку, которая позиционируется достаточно стабильной, но и собирает с ним пакеты, в чем не трудно убедиться, установив пакет из официального репозитория nginx. И само собой этот модуль входит в официальные стабильные сборки релизов коммерческой версии NGINX Plus.
Делаем ли мы в Angie что-то иначе? Нет. В сухом остатке, Angie от nginx отличается расширенным набором стабильной и востребованной функциональности, которую давно уже спрашивают и ждут от самого nginx.
Любопытно чем сейчас отличается freenginx от nginx. А отличается он только отсутствием релиза с исправлениями критических багов в HTTP/3. В чем не трудно убедиться сравнив репозитории на текущий момент:
Где, кто и кому тут свинью подложил? Просто мы, как и F5, не считаем, что пользователи HTTP/3 должны дожидаться очередного релиза, чтобы закрыть критические ошибки. И с учетом всего изложенного выше - есть веские основания так считать.
Отдельно отмечу, что оба бага, которые были расценены как критические, поскольку позволяют сделать DoS атаку на сервер - обнаружены благодаря тем самым пользователям HTTP/3, которые с ними столкнулись в продакшене и завели тикеты:
Цитирую: its on production machine and happened several times
Ага, спасибо им, что сообщили, но наплевать на них, пусть ждут следующего очередного релиза, ведь сами виноваты, что включили в конфигурационном файле экспериментальный модуль, который поставляется в официальной стабильной сборке сервера - так что ли?
Мы не просто взяли у nginx, а мы его в том числе разрабатывали. Один из активных разработчиков HTTP/3 в nginx - работает у нас. Поэтому мы также добавили поддержку HTTP/3 клиента в сторону бэкенда и попробовали даже предложить эти патчи в nginx: https://mailman.nginx.org/pipermail/nginx-devel/2023-December/THMZAQ36SN5BICJSCLX6FLEUI45FHR4H.html - и в том числе отчасти из-за этого у нас оказалось на одну уязвимость меньше, наш код отличается.
"Экспериментальный" - это не более, чем способ снять с себя ответственность. Надо заметить, довольно плохой способ. Пользователи же хотят видеть нормальную, полноценную поддержку современных протоколов, а не вот эти отмазки. Что им с этим делать? Эксперименты ставить? Переходить на конкурентов, где поддержка HTTP/3 ни чуть не лучше, но просто не содержит слова "экспериментальный"? Наша позиция заключается в том, что современный веб-сервер заслуживает иметь полноценную поддержку современных протоколов.
Проработав в nginx одиннадцать лет и будучи, среди прочего, разработчиком аж 3-х "экспериментальных" модулей/механизмов: SPDY, HTTP/2, thread pools - я догадываюсь, что во многом "экспериментальность" HTTP/3 обусловлена негативным отношением одного человека к самому протоколу и тем, что он лично не принимал активного участия в разработке и ревью данного кода. И этот человек вовсе даже не Игорь Сысоев, написавший большую часть кода и заложивший основную архитектуру сервера.
С точки зрения возможностей запуска процессов приложений - да. Производительность предполагается даже выше чем 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 года и по сей день - Колин Ватсон.
График "Available burst tokens" на картинке "rate=2, burst=2" - неверен. На самом деле он должен быть таким же, как на последней картинке с nodelay.
Само наличие или отсутствие параметра nodelay никак не влияет на burst. При обработке запросов, которые попали в burst и отмечены желтым на картинке - доступные burst-токены должны прибавляться.
Для начала у всех комментаторов пишущих про "срубить бабла с государства" хочется спросить, хотя бы просто для расширения своего кругозора, а как это сделать? Расскажите, если у вас такой опыт имеется и видите сразу сходу такую перспективу. Отдельно интересно, как это сделать на OSS версии и зачем в таком случае вообще выпускать какую-то OSS версию? Есть у меня подозрения, что среди пишущих подобные комментарии нет никого, кто сам бы пытался вот так прийти и продать что-то в госкомпанию, либо получить какой-то грант от государства. Если коротко, это не секрет полишинеля, что хуже и труднее заказчика, чем госзаказчик для частного бизнеса - придумать сложно. Для компаний с участием государства возможно всё иначе, но я в таких не работал, не знаю.
А второй момент в том, что независимо от того, заинтересуются ли какие-нибудь госы нашим продуктом или нет - хочется продолжать разрабатывать достаточно хороший и проверенный временем веб-сервер, продолжать успешно применять свой опыт и знания в той сфере и в том продукте, где есть наибольшие компетенции. Если бы можно было продолжать разрабатывать nginx, мы бы сидели и спокойно продолжали его разрабатывать, никто бы и пальцем не пошевелил, никакого Angie не возникло. Но это вообще не наше решение. Это решение компании, которая владеет сейчас nginx, и довольно очевидно, что это её решение было принято не ради импортозамещения в России.
> Angie (и ещё тысячи “российских” продуктов из известного реестра т.н.
“отечественного ПО”) вряд ли бы появился, кабы не принятый закон об
импортозамещении (сослагательное наклонение призвано вполне недвусмысленно показать, что я этого не утверждаю, а лишь предполагаю/допускаю).
А Angie в реестре и не присутствует. В нем только Angie PRO.
Ссылаясь на этот закон, компании прекрасно используют nginx. Для OSS присутствие в реестре не дает примерно ничего, поэтому Angie OSS в реестре и не присутствует. Для не OSS пока тоже особо не дает, при наличии OSS аналога. Зато если не присутствуешь, то на твою коммерческую версию даже смотреть не будут.
Исходя из этого, по факту реестр отечественного ПО не особо работает, тем более в нашем случае.
Но мне интересно, почему вы написали определенные слова и в кавычках? Присутствие в данном реестре - это не какая-то формальность, из него и исключить могут. Это не означает, что все строчки кода ПО, которое там находится - были написаны в России, хотя для nginx это даже на 99% именно так. Но это означает прежде всего, что есть некая компания, некое юр.лицо в российской юрисдикции, которое может понести вполне себе не "ответственность", а ОТВЕТСТВЕННОСТЬ по всей строгости, если вдруг что. Как на мой взгляд, это вполне себе в духе отечества, чтобы не писать это слово в кавычках применительно к реестру. Готовы на себя такую ответственность за какой-нибудь продукт взять просто так?
Поднятие бабла с госов и военки в США с некоторых пор стало совсем невозможно совместить с наличием офиса в России. Поэтому проще всех уволить и закрыть офис, что и предопределило появление Angie.
Готово: https://angie.software/configuration/modules/http_acme/
Потому, что это ближе по концепции к LTS. Т.е. каждый mainline релиз является стабильным, просто некоторые из них получают продленный на год срок поддержки и исправления критических ошибок.
А зачем для этого open-source делать?
И если у кого-то ещё остаются какие-то сомнения по поводу стабильности и позиционирования mainline ветки, то отдельно обращу внимание на то, как появляется очередная stable ветка: раз в год, обычно весной, текущая mainline ветка превращается в очередную stable ветку, при этом не имеет никакого значения, что какие-то функции и модули там уже почти год, а какие-то были добавлены за месяц до того. И ничего другого не происходит, никакой стабилизации кода, никаких дополнительных тестов - это просто ежегодное чисто формальное мероприятие от которого код не становится каким-то магическим образом более стабилен, чем был до того.
И "экспериментальность" отдельных модулей и функций - тут тоже совершенно ортогональная история. От переименования mainline ветки в очередную stable - "экспериментальные" модули и функции не перестают быть экспериментальными. Так, например, perl-модуль является экспериментальным с момента своего появления (в версии 0.3.21, выпущенной ещё в 2006 году) и по сей день. Т.е. этот "экспериментальный" модуль входит во все stable ветки за последние 18 лет.
Как вы справедливо заметили ниже: нестабильный код не добавляют в стабильные релизы.
Это было бы очень странным и недальновидным решением с нашей стороны. Поэтому мы этого не делали. Может авторы nginx это сделали? Ниже попробуем разобраться.
Код HTTP/3 модуля достаточно неплохо покрыт тестами, а также неплохо соответствует RFC, благодаря чему даже согласно независимым тестам имеет хорошие характеристики по кросс-совместимости с другими реализациями (которые, кстати, не маркируются экспериментальными): https://interop.seemann.io/
Ветка mainline - это основная стабильная ветка, которую разработчик рекомендует использовать, а также на базе этой ветки выпускает коммерческую версию NGINX Plus.
Просто процитирую старшего продуктового директора nginx:
We generally recommend using the mainline branch. This is where we commit all new features, performance improvements, and enhancements. We actively test and QA the mainline branch, so it’s arguably more stable than the “stable” branch. The mainline branch is also the source of NGINX Plus builds for our commercial customers.
https://www.nginx.com/blog/nginx-1-12-1-13-released/
Да, название второй ветки не совсем точное, что может сбить с толку. Правильнее было бы назвать вторую ветку - legacy, т.к. stable в её названии прежде всего означает заморозку API, что более актуально, если у вас есть какие-то устаревшие модули, на поддержку совместимости и актуальности которых вы хотите тратить меньше сил.
Я также замечу, что разработчик, не только включил модуль HTTP/3 в ветку, которая позиционируется достаточно стабильной, но и собирает с ним пакеты, в чем не трудно убедиться, установив пакет из официального репозитория nginx. И само собой этот модуль входит в официальные стабильные сборки релизов коммерческой версии NGINX Plus.
Делаем ли мы в Angie что-то иначе? Нет. В сухом остатке, Angie от nginx отличается расширенным набором стабильной и востребованной функциональности, которую давно уже спрашивают и ждут от самого nginx.
Любопытно чем сейчас отличается freenginx от nginx. А отличается он только отсутствием релиза с исправлениями критических багов в HTTP/3. В чем не трудно убедиться сравнив репозитории на текущий момент:
Где, кто и кому тут свинью подложил? Просто мы, как и F5, не считаем, что пользователи HTTP/3 должны дожидаться очередного релиза, чтобы закрыть критические ошибки. И с учетом всего изложенного выше - есть веские основания так считать.
Отдельно отмечу, что оба бага, которые были расценены как критические, поскольку позволяют сделать DoS атаку на сервер - обнаружены благодаря тем самым пользователям HTTP/3, которые с ними столкнулись в продакшене и завели тикеты:
https://trac.nginx.org/nginx/ticket/2585
https://trac.nginx.org/nginx/ticket/2586
Цитирую: its on production machine and happened several times
Ага, спасибо им, что сообщили, но наплевать на них, пусть ждут следующего очередного релиза, ведь сами виноваты, что включили в конфигурационном файле экспериментальный модуль, который поставляется в официальной стабильной сборке сервера - так что ли?
Мы не просто взяли у nginx, а мы его в том числе разрабатывали. Один из активных разработчиков HTTP/3 в nginx - работает у нас. Поэтому мы также добавили поддержку HTTP/3 клиента в сторону бэкенда и попробовали даже предложить эти патчи в nginx: https://mailman.nginx.org/pipermail/nginx-devel/2023-December/THMZAQ36SN5BICJSCLX6FLEUI45FHR4H.html - и в том числе отчасти из-за этого у нас оказалось на одну уязвимость меньше, наш код отличается.
"Экспериментальный" - это не более, чем способ снять с себя ответственность. Надо заметить, довольно плохой способ. Пользователи же хотят видеть нормальную, полноценную поддержку современных протоколов, а не вот эти отмазки. Что им с этим делать? Эксперименты ставить? Переходить на конкурентов, где поддержка HTTP/3 ни чуть не лучше, но просто не содержит слова "экспериментальный"? Наша позиция заключается в том, что современный веб-сервер заслуживает иметь полноценную поддержку современных протоколов.
Проработав в nginx одиннадцать лет и будучи, среди прочего, разработчиком аж 3-х "экспериментальных" модулей/механизмов: SPDY, HTTP/2, thread pools - я догадываюсь, что во многом "экспериментальность" HTTP/3 обусловлена негативным отношением одного человека к самому протоколу и тем, что он лично не принимал активного участия в разработке и ревью данного кода. И этот человек вовсе даже не Игорь Сысоев, написавший большую часть кода и заложивший основную архитектуру сервера.
Факт от этого не меняется, что заметная часть коллектива ушла делать Angie.