Такие сообщения регулярно в телеграм чате поддержки и комментариях в разных местах. Там просто не о чем писать: "поставили Angie, добавили пару директив, все работает автоматически, спасибо большое" - в таком духе. Пример: https://t.me/angie_support/7987 Если вдруг не работает, то обращаются за помощью и помогаем разобраться почему не работает.
Как поддержку добавили, я сам у себя на сервере удалил Certbot, добавил пару директив и работает с тех пор. Какой плюс? Избавился от лишнего компонента, которым забываешь как пользоваться через несколько месяцев и приходится вспоминать, когда нужно очередной домен завести. В конфиге веб-сервера его так или иначе нужно прописывать и теперь для этого достаточно просто добавить домен в server_name, сделать релоад конфига и всё. Не знаю как из этого выжать целую статью.
А тут коллега детально описал самый комплексный случай настройки, который только можно придумать, разобрался с OctoDNS и другими инструментами, которыми может кто-то захотеть воспользоваться, всё протестировал, написал скрипт и AFAIK никаких промптов. Людям теперь везде ИИ мерещатся. =)
зашёл узнать, насколько удобнее angie, чем связка nginx+dehydrated именно для получения сертификатов с http-авторизацией (т.е., условно говоря, я добавляю новый server {}, а сертификаты для него получаю автоматически).
А чем в таком случае не устроила официальная документация?
Традиционный путь - это держать где-то список доменов, и иногда перестраивать конфиги вебсервера из списк и запрашивать сертификаты. Но мне кажеся, это каким-то сложным, кривым путем. Вроде бы Caddy умеет так делать. Про Angie не знаю, я вот о нем только услышал.
Вам в любом случае придется хранить список доменов и проверять по нему, прежде чем выпустить сертификат. Попробую объяснить почему.
Представим, что такого списка нигде нет. В SNI, как и в заголовке Host, клиент может указать вообще всё, что угодно, абсолютно любой домен. Таким образом злоумышленник сможет вывести ваш сервер из строя, начав запрашивать произвольные домены. Попытка выпустить сертификат на такой произвольный домен не увенчается успехом, однако вы попадете в черный список у ACME-сервера и не сможете получить сертификат для реального нужного домена.
Ок, вы скажите, что ACME клиент должен перед тем, как идти получать сертификат на новый домен - сам попытаться его отрезолвить. А я отвечу, что ничего не мешает злоумышленнику зарегистрировать какой-то домен и прописать для него IP-адрес вашего сервера. И ваш сервер даже получит на него сертификат, но при определенном количестве таких запросов у того же Let's Encrypt сработает лимит и получение новых сертификатов на какое-то время будет далее невозможно, что опять приведет к DoS.
Т.е. так или иначе, перед тем, как идти получать сертификат на какой-то домен с которым пришел клиент - неплохо бы проверить его по списку.
Те, кто использует Caddy таким образом в проде, сильно рискуют, если они не поставили перед ним ещё какой-то прокси, который умеет фильтровать TLS-подключения по SNI и таким образом фильтруют их по списку, либо используют механизм проверки домена внешним запросом к хранилищу, который предоставляет Caddy. Т.е. так или иначе, список доменов где-то есть и по нему происходит сверка.
Потенциально такой режим можно добавить и в Angie с соответствующими предупреждениями и инструкциями, как это безопасно настроить. Но какая-то проверка по списку доменов все равно будет, просто этот список будет храниться вне конфигурации сервера.
Еще, почему-то веб-сервера не умеют сами подбирать сертификаты. Мне кажется немного тупостью, что нужно для каждого виртхоста прописывать, где ему искать файлы с сертификатом и ключам - лишние хлопоты, громоздкий конфиг, лишние ошибки.
Абсолютно с вами согласен. Поэтому в свое время в NGINX Unit я реализовал это иначе. Там сертификат и ключ автоматически выбирается по SNI исходя из тех доменов, что прописаны в сертификате.
nginx и многие сервера появились задолго до того, как появился SNI, отсюда и такая настройка. Можно подумать над тем, как это переделать в Angie, чтобы было проще и удобнее чем механизм, унаследованный от nginx, но это уже отдельная задача.
рановато заявлять о плюсе который ещё не в проде..
Тут я скорее о том, что в принципе технически нормально не реализовать в случае отдельной утилиты, т.к. требует вмешательства в сам процесс TLS-хендшейка.
ну nginx/angie это всё же не для пользователей а для тех кто делает этим пользователям сервисы.
Мы пользователями привыкли называть тех, кто пользуется нашим ПО, т.е. устанавливает и занимается его настройкой. =)
пользователям свойственно ошибаться, если вы утверждаете что так лучше для пользователя то снова вопрос: "чем?"
Они по этой причине уходят на кадди, и не ощущают, что ошиблись. Опять же, кому не нужно и кто считает это ошибкой - может просто не пользоваться данным модулем и вообще его не собирать. Тем не менее, отставание от конкурентов в этом плане приводит только к потере пользователей. Кажется, это весомый аргумент, чтобы не отставать, если хочешь разрабатывать действительно популярное решение, а не что-то сугубо нишевое.
не вижу почему бы из коробки у меня бы не заработал lego/certbot/acme.sh/etc. меньше сил это когда ты добавляешь в свой ansible/puppet/etc проект ещё один хост с его варсами и запускаешь сто раз проверенный плейбук
Значит у вас уже есть какой-то плейбук, вы в этом однажды разобрались и его написали. Это не из коробки. Это не поставил apt install angie, а дальше добавил две директивы и всё работает, причем добавил в парадигме конфигурационного файла, который и так нужно изучать, чтобы пользоваться nginx/Angie.
потому что она провереная временем, эта догма строится на базе того что человек не всесилен и ему свойственно допускать ошибки, и на том как уменьшить возможное кол-во ошибок не более.
Да, и ошибки он допускает при настройке двух разных инструментов. Тратит время на изучение дополнительного инструмента, написание плейбука и пр. пр. Зачем этим заниматься, если можно воспользоваться встроенным решением, которое уже раз разработали те, кто разобрались в вопросе глубже, чем просто настройка Certbot и реализовали это автоматически.
Тут нужно понимать, что в статье рассмотрен довольно комплексный и сложный случай настройки. В простейшем виде вся настройка заключается в добавлении пары директив в конфиг из документации:
acme_client example https://acme-v02.api.letsencrypt.org/directory;
server {
acme example;
...
При этом обновление сертификатов происходит без перезагрузки процессов веб-сервера. Для тех, у кого доменов и сертификатов очень много, необходимость чаще перезапускать процессы - становится отдельной проблемой.
Вот вы спорите, а мы регулярно получаем благодарность от пользователей, которые пишут, что поддержка ACME в Angie - это стало для них одним из ключевых факторов, чтобы перейти с nginx и они очень довольны, благодарят за эту функциональность чаще, чем за многую другую.
Это же не вот вдруг нам заняться было нечем. Это был нескончаемый поток просьб встроить поддержку ACME в веб-сервер, т.к. по той или иной причине пользователи не хотят возиться с отдельным Certbot/Acme.sh и др., предпочитая вместо этого даже сменить веб-сервер на такой, где поддержка ACME уже встроена. Можно конечно сидеть и заявлять, что такие пользователи ошибаются, не должен этим заниматься веб-сервер, но это странный способ кому-то что-то доказать, весьма не конструктивный в плане развития и популяризации проекта.
В конце статьи есть ответ на вопрос чем лучше. Самое банальное - не нужно поддерживать список доменов в двух разных местах. Из небанального, что никогда в принципе не сможет скрипт на bash делать, так это выполнять ALPN-челендж, поддержку которого уже в ближайших версиях добавим.
люди забыли принцип "утилита должна выполнять только одну задачу, но делать это хорошо"
Сколько я работаю в индустрии, то постоянно сталкиваюсь, что реальные пользователи чаще всего хотят обратного, а именно, чтобы всё работало из коробки и желательно тратить на это как можно меньше сил. И в целом, в этом нет ничего плохого... есть в индустрии другие задачи, чем как сопряжение отдельных разрозненных компонентов между собой каждый раз.
Так для чего повторять когда-то десятилетия назад выдвинутую догму, когда задачи и масштабы были совсем другие, снова и снова? Тем более, что тут возникает коллизия в том, а что есть утилита в части веб-сервера... должен ли он хорошо обрабатывать HTTPS трафик? Современному веб-серверу без этого никуда, а если да, то входит ли в эту задачу работа с сертификатами? Ведь если он не сможет обновлять сертификаты, то хорошо обрабатывать HTTPS трафик тоже не получится. Какая-то неполноценная утилита тогда выходит, не справляющаяся со свой задачей.
Форк создан большинством бывших разработчиков nginx. Среди них Хомутов, Ермилов, Бартенев.
Сысоев не занимается разработкой nginx примерно с 2012 года. Не знаю, с кем вы там знакомы, но мы вместе с ним работали над NGINX Unit вплоть до его увольнения из F5. =)
Мы отслеживаем найденные уязвимости в nginx и других форках, оперативно выпускаем исправления, иногда даже раньше, чем это делают сам nginx. Прецедентов нахождения уязвимостей в функциональности самого Angie ещё не было.
Кроме того, у нас есть ряд улучшений, направленных на дополнительное повышение безопасности и защиты от DoS-атак, в том числе портированных из freenginx.
Ещё было бы круто где-то найти полный список отличий в конфигах nginx/angie, чтобы можно было выполнять проверки конфигураций на предмет небезопасных настроек.
Вы можете взять конфиг от nginx и запустить с ним Angie - будет работать также. Rutube, например, так и делает, им так удобнее. У нас же есть руководство по миграции.
Если вы не используете новую функциональность, которая была добавлена только в Angie, то отличий в директивах конфигурации нет за одним незначительным исключением.
Список фич есть на странице документации: https://angie.software/angie/docs/#index-features-oss - если преобразовать это в табличку, то будет просто более громоздко. Или требуется какой-то более расширенный список?
Аналогичная история. Разумеется никакую симку не менял и в Т-Мобайл отрицают то, что какую-либо информацию об этом направляли.
В итоге в Альфе по телефону стояли на своем и сказали приходить с паспортом в отделение. Но обновил страницу в интернет-банке и там появилась вверху плашка "В банк поступила информация о смене сим карты... бла-бла необходимо подтвердить" и кнопка "Подтвердить". Нажал кнопку - появилась табличка "Подтверждения не требуется" и все заработало.
Мое понимание заключается в том, что nginx из коробки не должен проигрывать haproxy в разы. Указанное число RPS для сервера с 32 CPU - это вообще крайне мало... и выглядит очень подозрительно.
Жаль, если вы не хотите разобраться в причинах наблюдаемого явления. Даже если я попрошу воспроизвести коллег, то с большой вероятностью у нас не получатся такие же цифры, т.к. не получится точно повторить указанный стенд.
Вопрос, у вас HTTPS соединения keepalive или на каждый запрос новое? А если на каждый запрос новое соединение, то используется ли возобновление TLS-сессий и каким механизмом? Полный хендшейк - это весьма CPU-нагруженная операция, и лишь разница в настройках TLS-сессий может полностью перевернуть картину между серверами. Опять же, каждая настройка хороша под конкретный стенд, поэтому выравнивать сервера по настройкам, тем более таким критичным, как TLS - необходимо, иначе будет просто необъективный результат, который применим только к конкретному стенду, а на другом стенде будет совсем другим. Так вы протестировали сервера на то, как их настройки по умолчанию подходят для вашего стенда и это будет иметь мало общего с производительностью в реальности, даже на тех же настройках - просто в силу того, что клиенты обычно не ведут себя как отдельно взятый тестовый стенд.
У haproxy, кстати, по умолчанию включен кэш SSL-сессий, а у nginx он выключен. И если клиент, например, не умеет в сессионные тикеты, то вот и разница - тогда в одном случае вы считаете полные хендшейки, а в другом возобновления сессий.
Какие ошибки в логах? Во всех тестах, что мы проводили на моей памяти, haproxy оказывался чуть хуже nginx, да в общем-то неоткуда там разнице особой взяться, тем более в разы - архитектура очень похожа. Поэтому есть все основания полагать, что что-то фундаментально не так с конкретной установкой nginx. Что все же в логах ошибок? И сам nginx, кстати, откуда? Из официального репозитория на `nginx.org`?
И кстати, ни один из серверов сам не обрабатывает TLS - эту задачу решают TLS-библиотеки. Учитывая, как изменились результаты с настройкой ssl_ciphers, возможно вы на самом деле протестировали производительность сборок конкретных библиотек. Для равноценного теста с участием TLS - сервера должны быть собраны с одной и той же библиотекой.
Если интересно все же разобрать в причинах, я бы предложил попробовать повторить тест без TLS в принципе. Если результаты nginx и haproxy окажутся в этом случае близки, то дальше нужно будет разбираться, а что не так с TLS.
И обращаю также внимание на то, что у nginx по умолчанию включен `access_log`, а у того же haproxy, насколько я помню, его нужно включать принудительно.
> Затем и включили, что без него только хуже)
По вашим данным с выключенным multi_accept число успешных запросов больше:
checks_succeeded...................: 30.91% 312910 out of 1012194 checks_failed......................: 69.08% 699284 out of 1012194
против с включенным:
checks_succeeded...................: 25.90% 244664 out of 944528 checks_failed......................: 74.09% 699864 out of 944528
или я неправильно интерпертирую данные?
Но должно быть вообще 100%. То, что nginx теряет запросы - это что-то ненормальное, в error_log должны быть причины этому.
Если проект перестанет делать заявления, от которых откажется буквально через пару месяцев, то я с радостью попытаюсь придумать где взять деньги.(видите, это в обе стороны может работать)
Перестанет и заявления во множественном числе предполагает, что мы их продолжаем делать. Можете указать пожалуйста, какие ещё заявления мы делали? Это важно, т.к. я не в курсе этого и меня это беспокоит.
Иван Полуянов давно уже больше не является представителем компании и у нас не работает. Могу лишь принести за него извинения от себя лично за его прошлую ошибку и введение в заблуждение. Это его собственное высказывание - откровенный бред, ибо PRO версия уже была и, в том числе, на момент конференции уже более 4 месяцев в репозитории PRO велась разработка довольно значительной фичи - конфигурационного Rest API для изменения списка проксируемых серверов, которая появилась в августе того же года в рамках 1.2.0.
У меня нет разумных объяснений почему он это сказал. Этого не было в его докладе, это не было согласовано с нами, он отвечал на вопрос из зала от себя. К сожалению, люди допускают ошибки.
Первая версия PRO вышла в феврале 2023: https://angie.software/angie/docs/pro_changes/#angie-pro-1-1-0 - а питерский хайлоад обычно летом проводят. Так что на тот момент PRO версия уже была, а на самом хайлоаде выступал Полуянов, которому, по его словам, на солнце и под светом софитов напекло голову, что он неправильно выразился - хотел сказать, что никакие фичи, которые есть уже в open source версии, не будут закрыты. И оно действительно так, мы не закрываем фичи. Про существование коммерческой версии уже как полгода на тот момент - он, очевидно, не мог не знать.
Если вы расскажите где взять деньги, чтобы платить людям зарплату, кормить семью и продолжать разрабатывать исключительно open source версию, то мы с радостью перенесем все фичи из PRO в open source.
Так называемого "удержания" фич нет - просто если бы никто не покупал PRO версию, то вообще никаких бы фич не было, ни новых релизов PRO, ни новых релизов open source версии. Чтобы в open source версии появились какие-то фичи, для начала, их кто-то должен там разработать. Почему-то бесплатно люди работать не хотят, это очень удивительно! Хотите чтобы было больше open source фич - приобретайте PRO лицензию, особенно если у вас коммерческая компания - это лучший способ поддержать разработчиков. Поддержку компании не особо горят покупать, а чтобы поддержка окупала бы разработку, то стоимость этой поддержки должна быть такой, что вообще никто бы не купил. Более того, нам прямым текстом говорили, что "зачем нам у вас что-то покупать, если мы можем вашу бесплатную версию взять, а с поддержкой и сами справимся". Добро пожаловать в реальный мир. Если вы считаете, что можно было зарабатывать только на поддержке, то вперед и с песней, делайте свой форк, успехов, все будут только рады, но эта модель не сработала с nginx, поэтому повяился nginx plus (где-то спустя три года после основания компании, после долгих неуспешных попыток заработать на поддержке и заказной разработке) и с тех пор ничего не изменилось.
Зачем включили multi_accept? Он выключен по умолчанию не просто так. Это лучший способ вызвать дисбаланс в бенчмарке. Скорее всего у вас большинство соединений в итоге приняли и обрабатывали всего несколько первых рабочих процессов. От того и такие результаты...
Что в логе ошибок было? nginx пишет обычно что пошло не так... возможно у вас закончились дескрипторы или уперлись в лимит как раз из-за multi_accept.
Перед тем, как тестировать, выровняли ли настройки TLS-шифрования? У nginx по умолчанию `ssl_ciphers HIGH:!aNULL:!MD5;`. У других серверов скорее всего шифрование использовалось более слабое и менее ресурсоемкое, так что CPU не стал для них бутылочным горлышком.
Одинаковы ли у серверов настройки логирования?
Крайне предвзятый тест, без попытки разобраться в причинах и изначально неравными настройками.
Моя гипотеза: из-за "multi_accept" соединения между рабочими процессами распределялись крайне неравномерно, а из-за тяжелой криптографии рабочие процессы, набрав соединения, заблокировались на CPU.
Такой вопрос: как организовали синхронизацию потоков при работе с WASM и с файловой системой в частности?
В примере с SQLite всё просто и без изысков: взяли лок на базу, поработали, отпустили. Разные рабочие процессы будут ждать на локе. Это всё-таки демонстрационный пример WASM-модуля, а не настоящая база данных.
P.S. В недостатках WASIp1 сказано "нет сокетов", но в WASIp1 есть файловые сокеты.
Оно не сильно помогает с точки зрения установления соединений с кем-то в сети.
Так чем простейший пример в документации плох: https://angie.software/angie/docs/configuration/acme/#http - зачем ждать, пока где-то в каком-то блоге появится какая-то заметка, цитирующая документацию? =)
Такие сообщения регулярно в телеграм чате поддержки и комментариях в разных местах. Там просто не о чем писать: "поставили Angie, добавили пару директив, все работает автоматически, спасибо большое" - в таком духе. Пример: https://t.me/angie_support/7987 Если вдруг не работает, то обращаются за помощью и помогаем разобраться почему не работает.
Как поддержку добавили, я сам у себя на сервере удалил Certbot, добавил пару директив и работает с тех пор. Какой плюс? Избавился от лишнего компонента, которым забываешь как пользоваться через несколько месяцев и приходится вспоминать, когда нужно очередной домен завести. В конфиге веб-сервера его так или иначе нужно прописывать и теперь для этого достаточно просто добавить домен в server_name, сделать релоад конфига и всё. Не знаю как из этого выжать целую статью.
А тут коллега детально описал самый комплексный случай настройки, который только можно придумать, разобрался с OctoDNS и другими инструментами, которыми может кто-то захотеть воспользоваться, всё протестировал, написал скрипт и AFAIK никаких промптов. Людям теперь везде ИИ мерещатся. =)
А чем в таком случае не устроила официальная документация?
Вам в любом случае придется хранить список доменов и проверять по нему, прежде чем выпустить сертификат. Попробую объяснить почему.
Представим, что такого списка нигде нет. В SNI, как и в заголовке Host, клиент может указать вообще всё, что угодно, абсолютно любой домен. Таким образом злоумышленник сможет вывести ваш сервер из строя, начав запрашивать произвольные домены. Попытка выпустить сертификат на такой произвольный домен не увенчается успехом, однако вы попадете в черный список у ACME-сервера и не сможете получить сертификат для реального нужного домена.
Ок, вы скажите, что ACME клиент должен перед тем, как идти получать сертификат на новый домен - сам попытаться его отрезолвить. А я отвечу, что ничего не мешает злоумышленнику зарегистрировать какой-то домен и прописать для него IP-адрес вашего сервера. И ваш сервер даже получит на него сертификат, но при определенном количестве таких запросов у того же Let's Encrypt сработает лимит и получение новых сертификатов на какое-то время будет далее невозможно, что опять приведет к DoS.
Т.е. так или иначе, перед тем, как идти получать сертификат на какой-то домен с которым пришел клиент - неплохо бы проверить его по списку.
Те, кто использует Caddy таким образом в проде, сильно рискуют, если они не поставили перед ним ещё какой-то прокси, который умеет фильтровать TLS-подключения по SNI и таким образом фильтруют их по списку, либо используют механизм проверки домена внешним запросом к хранилищу, который предоставляет Caddy. Т.е. так или иначе, список доменов где-то есть и по нему происходит сверка.
Потенциально такой режим можно добавить и в Angie с соответствующими предупреждениями и инструкциями, как это безопасно настроить. Но какая-то проверка по списку доменов все равно будет, просто этот список будет храниться вне конфигурации сервера.
Абсолютно с вами согласен. Поэтому в свое время в NGINX Unit я реализовал это иначе. Там сертификат и ключ автоматически выбирается по SNI исходя из тех доменов, что прописаны в сертификате.
nginx и многие сервера появились задолго до того, как появился SNI, отсюда и такая настройка. Можно подумать над тем, как это переделать в Angie, чтобы было проще и удобнее чем механизм, унаследованный от nginx, но это уже отдельная задача.
Кстати, сам Игорь с вами не знаком. Что и не удивительно, оказалось такое же вранье, как и всё, что вы тут понавыдумывали.
Тут я скорее о том, что в принципе технически нормально не реализовать в случае отдельной утилиты, т.к. требует вмешательства в сам процесс TLS-хендшейка.
Мы пользователями привыкли называть тех, кто пользуется нашим ПО, т.е. устанавливает и занимается его настройкой. =)
Они по этой причине уходят на кадди, и не ощущают, что ошиблись. Опять же, кому не нужно и кто считает это ошибкой - может просто не пользоваться данным модулем и вообще его не собирать. Тем не менее, отставание от конкурентов в этом плане приводит только к потере пользователей. Кажется, это весомый аргумент, чтобы не отставать, если хочешь разрабатывать действительно популярное решение, а не что-то сугубо нишевое.
Значит у вас уже есть какой-то плейбук, вы в этом однажды разобрались и его написали. Это не из коробки. Это не поставил apt install angie, а дальше добавил две директивы и всё работает, причем добавил в парадигме конфигурационного файла, который и так нужно изучать, чтобы пользоваться nginx/Angie.
Да, и ошибки он допускает при настройке двух разных инструментов. Тратит время на изучение дополнительного инструмента, написание плейбука и пр. пр. Зачем этим заниматься, если можно воспользоваться встроенным решением, которое уже раз разработали те, кто разобрались в вопросе глубже, чем просто настройка Certbot и реализовали это автоматически.
Тут нужно понимать, что в статье рассмотрен довольно комплексный и сложный случай настройки. В простейшем виде вся настройка заключается в добавлении пары директив в конфиг из документации:
При этом обновление сертификатов происходит без перезагрузки процессов веб-сервера. Для тех, у кого доменов и сертификатов очень много, необходимость чаще перезапускать процессы - становится отдельной проблемой.
Вот вы спорите, а мы регулярно получаем благодарность от пользователей, которые пишут, что поддержка ACME в Angie - это стало для них одним из ключевых факторов, чтобы перейти с nginx и они очень довольны, благодарят за эту функциональность чаще, чем за многую другую.
Это же не вот вдруг нам заняться было нечем. Это был нескончаемый поток просьб встроить поддержку ACME в веб-сервер, т.к. по той или иной причине пользователи не хотят возиться с отдельным Certbot/Acme.sh и др., предпочитая вместо этого даже сменить веб-сервер на такой, где поддержка ACME уже встроена. Можно конечно сидеть и заявлять, что такие пользователи ошибаются, не должен этим заниматься веб-сервер, но это странный способ кому-то что-то доказать, весьма не конструктивный в плане развития и популяризации проекта.
В конце статьи есть ответ на вопрос чем лучше. Самое банальное - не нужно поддерживать список доменов в двух разных местах. Из небанального, что никогда в принципе не сможет скрипт на bash делать, так это выполнять ALPN-челендж, поддержку которого уже в ближайших версиях добавим.
Сколько я работаю в индустрии, то постоянно сталкиваюсь, что реальные пользователи чаще всего хотят обратного, а именно, чтобы всё работало из коробки и желательно тратить на это как можно меньше сил. И в целом, в этом нет ничего плохого... есть в индустрии другие задачи, чем как сопряжение отдельных разрозненных компонентов между собой каждый раз.
Так для чего повторять когда-то десятилетия назад выдвинутую догму, когда задачи и масштабы были совсем другие, снова и снова? Тем более, что тут возникает коллизия в том, а что есть утилита в части веб-сервера... должен ли он хорошо обрабатывать HTTPS трафик? Современному веб-серверу без этого никуда, а если да, то входит ли в эту задачу работа с сертификатами? Ведь если он не сможет обновлять сертификаты, то хорошо обрабатывать HTTPS трафик тоже не получится. Какая-то неполноценная утилита тогда выходит, не справляющаяся со свой задачей.
Форк создан большинством бывших разработчиков nginx. Среди них Хомутов, Ермилов, Бартенев.
Сысоев не занимается разработкой nginx примерно с 2012 года. Не знаю, с кем вы там знакомы, но мы вместе с ним работали над NGINX Unit вплоть до его увольнения из F5. =)
Мы отслеживаем найденные уязвимости в nginx и других форках, оперативно выпускаем исправления, иногда даже раньше, чем это делают сам nginx. Прецедентов нахождения уязвимостей в функциональности самого Angie ещё не было.
Кроме того, у нас есть ряд улучшений, направленных на дополнительное повышение безопасности и защиты от DoS-атак, в том числе портированных из freenginx.
Вы можете взять конфиг от nginx и запустить с ним Angie - будет работать также. Rutube, например, так и делает, им так удобнее. У нас же есть руководство по миграции.
Если вы не используете новую функциональность, которая была добавлена только в Angie, то отличий в директивах конфигурации нет за одним незначительным исключением.
Список фич есть на странице документации: https://angie.software/angie/docs/#index-features-oss - если преобразовать это в табличку, то будет просто более громоздко. Или требуется какой-то более расширенный список?
"Встроенный DNS‑резолвер NGINX не поддерживает fallback на TCP" - это неправда, как и множество других ошибок и неточностей в статье
Аналогичная история. Разумеется никакую симку не менял и в Т-Мобайл отрицают то, что какую-либо информацию об этом направляли.
В итоге в Альфе по телефону стояли на своем и сказали приходить с паспортом в отделение. Но обновил страницу в интернет-банке и там появилась вверху плашка "В банк поступила информация о смене сим карты... бла-бла необходимо подтвердить" и кнопка "Подтвердить". Нажал кнопку - появилась табличка "Подтверждения не требуется" и все заработало.
Какой-то у них сбой.
Мое понимание заключается в том, что nginx из коробки не должен проигрывать haproxy в разы. Указанное число RPS для сервера с 32 CPU - это вообще крайне мало... и выглядит очень подозрительно.
Жаль, если вы не хотите разобраться в причинах наблюдаемого явления. Даже если я попрошу воспроизвести коллег, то с большой вероятностью у нас не получатся такие же цифры, т.к. не получится точно повторить указанный стенд.
Вопрос, у вас HTTPS соединения keepalive или на каждый запрос новое? А если на каждый запрос новое соединение, то используется ли возобновление TLS-сессий и каким механизмом? Полный хендшейк - это весьма CPU-нагруженная операция, и лишь разница в настройках TLS-сессий может полностью перевернуть картину между серверами. Опять же, каждая настройка хороша под конкретный стенд, поэтому выравнивать сервера по настройкам, тем более таким критичным, как TLS - необходимо, иначе будет просто необъективный результат, который применим только к конкретному стенду, а на другом стенде будет совсем другим. Так вы протестировали сервера на то, как их настройки по умолчанию подходят для вашего стенда и это будет иметь мало общего с производительностью в реальности, даже на тех же настройках - просто в силу того, что клиенты обычно не ведут себя как отдельно взятый тестовый стенд.
У haproxy, кстати, по умолчанию включен кэш SSL-сессий, а у nginx он выключен. И если клиент, например, не умеет в сессионные тикеты, то вот и разница - тогда в одном случае вы считаете полные хендшейки, а в другом возобновления сессий.
50k RPS для nginx - это вообще пустяки, но вот криптография, которой занимается TLS-библиотека - она может стать лимитирующим фактором. К примеру, вот такой sizing guide для nginx plus: https://www.f5.com/pdf/deployment-guide/Sizing-Guide-for-Deploying-NGINX-Plus-on-Bare-Metal-Servers-2019-11-09.pdf - он уже старенький, ещё от 2019 года, но можно заметить, что на 32 CPU легко может быть 1 000 000 RPS, но всего около 50к полных хендшейков.
Какие ошибки в логах? Во всех тестах, что мы проводили на моей памяти, haproxy оказывался чуть хуже nginx, да в общем-то неоткуда там разнице особой взяться, тем более в разы - архитектура очень похожа. Поэтому есть все основания полагать, что что-то фундаментально не так с конкретной установкой nginx. Что все же в логах ошибок? И сам nginx, кстати, откуда? Из официального репозитория на `nginx.org`?
И кстати, ни один из серверов сам не обрабатывает TLS - эту задачу решают TLS-библиотеки. Учитывая, как изменились результаты с настройкой
ssl_ciphers, возможно вы на самом деле протестировали производительность сборок конкретных библиотек. Для равноценного теста с участием TLS - сервера должны быть собраны с одной и той же библиотекой.Если интересно все же разобрать в причинах, я бы предложил попробовать повторить тест без TLS в принципе. Если результаты nginx и haproxy окажутся в этом случае близки, то дальше нужно будет разбираться, а что не так с TLS.
И обращаю также внимание на то, что у nginx по умолчанию включен `access_log`, а у того же haproxy, насколько я помню, его нужно включать принудительно.
> Затем и включили, что без него только хуже)
По вашим данным с выключенным multi_accept число успешных запросов больше:
checks_succeeded...................: 30.91% 312910 out of 1012194 checks_failed......................: 69.08% 699284 out of 1012194против с включенным:
checks_succeeded...................: 25.90% 244664 out of 944528 checks_failed......................: 74.09% 699864 out of 944528или я неправильно интерпертирую данные?
Но должно быть вообще 100%. То, что nginx теряет запросы - это что-то ненормальное, в error_log должны быть причины этому.
Перестанет и заявления во множественном числе предполагает, что мы их продолжаем делать. Можете указать пожалуйста, какие ещё заявления мы делали? Это важно, т.к. я не в курсе этого и меня это беспокоит.
Иван Полуянов давно уже больше не является представителем компании и у нас не работает. Могу лишь принести за него извинения от себя лично за его прошлую ошибку и введение в заблуждение. Это его собственное высказывание - откровенный бред, ибо PRO версия уже была и, в том числе, на момент конференции уже более 4 месяцев в репозитории PRO велась разработка довольно значительной фичи - конфигурационного Rest API для изменения списка проксируемых серверов, которая появилась в августе того же года в рамках 1.2.0.
У меня нет разумных объяснений почему он это сказал. Этого не было в его докладе, это не было согласовано с нами, он отвечал на вопрос из зала от себя. К сожалению, люди допускают ошибки.
Меня не было на Saint Highload 2023.
Первая версия PRO вышла в феврале 2023: https://angie.software/angie/docs/pro_changes/#angie-pro-1-1-0 - а питерский хайлоад обычно летом проводят. Так что на тот момент PRO версия уже была, а на самом хайлоаде выступал Полуянов, которому, по его словам, на солнце и под светом софитов напекло голову, что он неправильно выразился - хотел сказать, что никакие фичи, которые есть уже в open source версии, не будут закрыты. И оно действительно так, мы не закрываем фичи. Про существование коммерческой версии уже как полгода на тот момент - он, очевидно, не мог не знать.
Если вы расскажите где взять деньги, чтобы платить людям зарплату, кормить семью и продолжать разрабатывать исключительно open source версию, то мы с радостью перенесем все фичи из PRO в open source.
Так называемого "удержания" фич нет - просто если бы никто не покупал PRO версию, то вообще никаких бы фич не было, ни новых релизов PRO, ни новых релизов open source версии. Чтобы в open source версии появились какие-то фичи, для начала, их кто-то должен там разработать. Почему-то бесплатно люди работать не хотят, это очень удивительно! Хотите чтобы было больше open source фич - приобретайте PRO лицензию, особенно если у вас коммерческая компания - это лучший способ поддержать разработчиков. Поддержку компании не особо горят покупать, а чтобы поддержка окупала бы разработку, то стоимость этой поддержки должна быть такой, что вообще никто бы не купил. Более того, нам прямым текстом говорили, что "зачем нам у вас что-то покупать, если мы можем вашу бесплатную версию взять, а с поддержкой и сами справимся". Добро пожаловать в реальный мир. Если вы считаете, что можно было зарабатывать только на поддержке, то вперед и с песней, делайте свой форк, успехов, все будут только рады, но эта модель не сработала с nginx, поэтому повяился nginx plus (где-то спустя три года после основания компании, после долгих неуспешных попыток заработать на поддержке и заказной разработке) и с тех пор ничего не изменилось.
Все модули есть в репозиториях: https://angie.software/angie/docs/installation/external-modules/
Существующий сторонний модуль не подходит?
Зачем включили multi_accept? Он выключен по умолчанию не просто так. Это лучший способ вызвать дисбаланс в бенчмарке. Скорее всего у вас большинство соединений в итоге приняли и обрабатывали всего несколько первых рабочих процессов. От того и такие результаты...
Что в логе ошибок было? nginx пишет обычно что пошло не так... возможно у вас закончились дескрипторы или уперлись в лимит как раз из-за multi_accept.
Перед тем, как тестировать, выровняли ли настройки TLS-шифрования? У nginx по умолчанию `ssl_ciphers HIGH:!aNULL:!MD5;`. У других серверов скорее всего шифрование использовалось более слабое и менее ресурсоемкое, так что CPU не стал для них бутылочным горлышком.
Одинаковы ли у серверов настройки логирования?
Крайне предвзятый тест, без попытки разобраться в причинах и изначально неравными настройками.
Моя гипотеза: из-за "multi_accept" соединения между рабочими процессами распределялись крайне неравномерно, а из-за тяжелой криптографии рабочие процессы, набрав соединения, заблокировались на CPU.
В примере с SQLite всё просто и без изысков: взяли лок на базу, поработали, отпустили. Разные рабочие процессы будут ждать на локе. Это всё-таки демонстрационный пример WASM-модуля, а не настоящая база данных.
Оно не сильно помогает с точки зрения установления соединений с кем-то в сети.