Далее, судя по всему, кто-то подсказал или у нас подсмотрели, что наверное это очень плохая идея и так делать не нужно.
Вы хотите, чтобы лично для вас сделал отдельное ревью кода, который ещё к тому же даже не в релизе и уже после написания статьи поменялся несколько раз? Или вы хотите, прибегая к развешиванию ярлыков в стиле "это лозунги", "это агрессия", запретить кому-то иметь и выражать своё мнение на основе опыта? Спасибо, мне есть чем заняться более полезным. Оставайтесь при своем мнении, задачи кому-то что-то доказать - нет.
У энтерпрайзных компаний (любых) может быть 100500 причин (и 100499 из них глупые) не брать чужой код и наработки.
Прекрасно. А у меня есть право объяснять это глупостью, учитывая, что контрибьют следует всем публичным гайдлайнам и не нарушает ни чьих прав, а никакой другой причины публично озвучено не было.
И да, с какого перепугу ты разговариваешь со мной как-будто бы первый раз меня видишь и рассказываешь мне истории времён, когда у меня уже волосы седыми были? Знаю я прекрасно как кто куда и почему развивался
С кем-то вы меня видимо путаете. Не припоминаю, чтобы мы лично были знакомы.
И что за зацикленность русские не русские?
Вам мерещится. Я в своем сообщении вообще ни одной национальности не упоминал.
В 2023 году в Angie была реализована поддержка проксирования по протоколу HTTP/3. Реализацией занимался один из самых опытных разработчиков, который проработал в nginx c 2012 года вплоть до закрытия московского офиса в 2022. Он же до этого работал с коллегами над HTTP/3 в серверной части nginx, поэтому прекрасно знаком с протоколом и всеми нюансами. Ещё тогда в конце 2023 мы решили закотрибьютить эту функциональность в nginx: https://mailman.nginx.org/pipermail/nginx-devel/2023-December/THMZAQ36SN5BICJSCLX6FLEUI45FHR4H.html
Кроме краткого общего обмена мнениями с Максимом никакой реакции на патчи не последовало (на всякий случай поясню, что на момент 2023 года список рассылки разработчиков был основным способом контрибьюта в nginx, а Максим уже не работал в F5). Но на конец 2025 года они уже полгода упорно практически с нуля переизобретают велосипед.
Проксирование HTTP/3 в Angie разрабатывалось по заказу одного очень крупного зарубежного облачного провайдера и на текущий момент тщательно оттестировано в боевых условиях. В nginx сейчас, игнорируя наш опыт, будут идти по граблям ещё после коммита и доводить до ума.
Мне понятно почему так происходит. Разработчики в этом не виноваты, а виноват в этом определенный корпоративный маразм. Есть ли от этого кому-то польза? Нет, в итоге страдают все.
делая вид, что действительно не понятна суть претензий к людям, которые вообще подаются на сертификацию ФСТЭК и работают с российскими государственными конторами сейчас от мирового сообщества
С чего вы решили, что я делаю вид? Да я реально не понимаю. Объясните мне, чем российские государственные конторы отличаются от государственных контор в других странах? Поскольку мы оппонируем к продукту американской конторы, то давайте их сравнивать с американскими государственными конторами. Чем российские хуже американских? В чем тут справедливость недоверия?
У меня вообще очень обостренное чувство справедливости. Я не терплю никакой дискриминации. А для меня это натуральная дискриминация. Человек работал в Сбере - о боже, сразу недоверие, точка. А вот если в ЦРУ, то тут другое, тут доверие. И я не понимаю почему одну и ту же фичу нужно делать два раза или исправлять несколько раз один тот же баг. Мы что-то исправили, а nginx потом у себя исправляет спустя время, вместо того, чтобы подтянуть наше исправление. Кому от этого легче?
К счастью, мировое сообщество всё же разумнее, чем некоторым кажется, а потому у нас растет число пользователей Angie и в США, и по всему миру. А мы всем рады и держим зеркало на гитхабе, со всеми общаемся, переводим документацию на разные языки мира.
А я вам отвечу по существу, потому что вы реально видимо не понимаете насколько смешные вещи пишите. Ругать за наличие сертификации ФСТЭК - это все равно, что ругать строителя, который прошел аттестацию на знание техники безопасности, надевает каску на стройке и регулярно меняет страховочный трос.
Об остальном у вас такие же "глубокие" представления. Советую почитать статью - возможно просветитесь. Впрочем, если вы живете в парадигме, что всё государственное - зло по умолчанию, то едва ли поможет. Но в таком случае, я не очень понимаю как вы живете, ведь без взаимодействия с государством вы ни ИНН не получите, ничего не сделаете. Поэтому сильно подозреваю, что все же вы с государством тоже регулярно взаимодействуете и налоги платите, а потому просто тут лицемерите, либо уже поставили на себе такую же черную метку.
Спасибо за запрос. Я передам его инженерам, отвечающим за сборочную инфраструктуру, но не могу обещать, что они сразу возьмутся переделывать. Неудобство понятно. Текущая версия в первую очередь заточена на наши собственные сборочные процессы.
Отличный пример лицемерия и инфантилизма. Видимо коммиты Максим Дунина во freenginx какие-то более чистые, что ли... без черных меток, правда ведь?! Но только почему-то вот беда, их также игнорируют. Может вы знаете почему?
Но если тот же код послать отдельно, без копирайта, то всё сразу хорошо! Примерно как углеводороды, когда перекачиваются на танкер под другим флагом или пересекают границу третьих стран, то сразу становятся вдруг правильными, с духом свободы, как говорится.
А то, что F5 поставщик военных ведомств США, а за безопасность там отвечал вербовщик из ЦРУ, который ранее занимался внедрением в информационные системы других стран, о чем сам не стесняясь рассказывал в интервью - это, как мы знаем, другое.
И конечно же, ФСТЭК - плохо, а FIPS 140-2 и NIST 800-53 - это хорошо, т.к. стандарты правильной страны. И судя по всему, вы даже не знаете о чем там речь, но заранее имеете мнение.
Лично от себя, давнего пользователя nginx,
Прекращайте срочно использовать, там много кода написано теми самыми нами. Это теперь нерукопожатный код с черной меткой.
И это не лично я на эту мерзость убил неделю своего рабочего времени, чтобы выяснить, что она каким-то хитрым образом делает, емнип, stat на путь $dockroot/location всегда, если root в конфиге определён.
`root` в конфиге всегда определен. У него есть значение по умолчанию, но stat() при этом не делается (и зачем?). Игорь всегда очень трепетно относился к сисколам и минимизировал их количество.
Я понимаю, что наверное вы что-то наблюдали. Такое запросто может делать какой-нибудь сторонний модуль, этого исключать нельзя. Ванильный nginx так не делает. В любом случае - правильным действием было бы не тратить время на поиски, а пойти и задать вопрос разработчикам, благо я, Максим и многие другие коллеги регулярно в списках рассылки отвечали пользователям.
Может быть нормальная динамическая конфигурация, а не reload&pray с "сейчас я буду рвать все вебсокеты"?
Веб-сокеты не рвуться, а дорабатывают дальше, если только специально не настроено разрывать долгие соединения через таймаут.
Может быть нормальные политики управления трафиком на L7, с ретраями, circuit breaker'ами, и прочей прелестью, которые можно просто сконфигурить и оно будет работать?
В свое время пришлось повозиться с Envoy и у меня создалось впечатление, что его конфигурация вообще не для человека сделана, а для машин и кишки торчат наружу. Что само по себе конечно имеет свои плюсы, но и имеет и минусы. Для кого-то они существенны, для кого-то нет. Чтобы удостовериться, что это не одному мне так показалась - спрашивал ещё независимых мнений и получил подтверждение своему впечатлению.
И не даром же, даже при наличии Envoy, ингресс-контроллер на базе nginx набрал большую популярность. И коммерческая версия такого ингресс-контроллера пользуется спросом.
Или это отсутствие странных сюрпризов, вроде того, что при любом матче локации nginx ходит в файловую систему, даже если в локации нет ничего кроме proxy_pass?
Это не так. И никогда такого не было ни в одной версии. `proxy_pass` однозначно устанавливает обработчик на location, который вызывается в content-фазе. А матчинг - это просто префиксное дерево и списки с регулярками. Там вообще нет сисколов. То, что вы описали, больше похоже на некоторые моменты в Apache.
Ну, а если указали try_files - назначение которого буквально кричит из названия директивы, то тут странно удивляться.
Может быть автодискавери сервисов? Система плагинов и фильтров без "а давайте мы просто всунем код на луа вот прямо сюда"?
Экосистема модулей для nginx одна из самых больших. Луа - тут лишь один из сторонних модулей и не надо вставлять код на луа, это скорее про OpenResty, что суть отдельный проект со своей идеологией ближе к серверам приложений.
Наверное это я тупой и старый и хочу странного. Но почему-то конфиги nginx которые делали нужные вещи, очень сильно напоминали ёжа из костылей. А конфиги envoy - напоминали ну, просто конфиги. И их можно было просто менеджить без наличия штатного шамана, гуляющего в код nginx и знающего, почему вот эту хрень рядом с вот этой использовать ну никак нельзя.
Абсолютно нормально если вы лучше познакомились с одним проектом и плохо знаете другой. Плюс у всех разные подходы и взгляды на то, а как должна выглядеть конфигурация. Выше я писал про свое впечатление от того же Envoy. А кто-то вообще хочет, чтобы всё мышкой тыкалось и таких очень много. Прекрасно, что на любой запрос есть свое решение.
P.S. У меня есть понимание как сделать конфигурацию более гибкой, простой и интуитивно понятной. Но для этого нужно время и по опыту NGINX Unit, где подход к конфигурированию был принципиально другим - понятно, что какие-то радикальные идеи и изменения тоже не находят отклика в массах, т.к. есть большая инерция мышления и есть в этом также существенный момент субъективизма.
Например потому, что nginx-подобные продукты во многом лучше. И уж точно производительнее и устойчивее к пиковым нагрузкам, чем тот же Traefik. Не стоит так оголтело записывать админов большей части интернета и крупнейших компаний мира в "отставшие от жизни".
Разумеется у Traefik и Envoy есть свои плюсы. Все разработчики друг на друга смотрят и многие полезные фичи перенимают. Тут нет никакого однозначного лидера, но есть разные подходы и предпочтения в цвете фломастера.
Так всё модульное. Если какие-то модули не требуются, то можно их не собирать, но смысла в этом большого нет, т.к. влияние на производительность от наличия модуля в сборке - чаще всего неизмеримо мало. Мы динамически собираем в основном те модули, которые устанавливают дополнительные зависимости.
Но вообще на разработку "мало кому нужных фич" нет времени. Количество запросов от сообщества сильно больше, чем ресурсов. Плюс технологии развиваются и конкуренты тоже. Если ничего не делать, то какое-то время можно за счет запаса инерции оставаться в тренде, но рано или поздно уйдешь на задворки истории. Естественно никто не будет делать ту или иную фичу по одному-двум запросам - разработка вообще дорогая, поэтому это возможно только на коммерческой основе.
Тут в оценках главное не впадать в субъективизм. Когда работаешь в одной/нескольких компаниях, то имеешь определенное представление о том, что нужно и что не нужно в рамках кейсов, с которыми сам сталкивался. А когда работаешь в вендоре ПО, будь то NGINX, Inc. ранее и теперь Angie Software - то имеешь дело с тысячами компаний и их кейсами, которые зачастую богаче всех твоих фантазий.
В конце-концов, посмотрите какое большое количество сторонних модулей для nginx написало сообщество. Многие из них очень популярны. Не стоит недооценивать модульность и расширяемость - это тоже всегда был значимый критерий успеха и мы трепетно поддерживаем совместимость со сторонними модулями.
P.S. Но вообще, если хочется ставший в какой-то степени каноничным nginx, который существовал с 2011 по 2022 год, то порекомендую freenginx, который разрабатывается Максимом Дуниным. Долгие годы без его одобрения в nginx не попадало ничего, а когда в F5 на его мнение решили наплевать, то ему пришлось сделать свой форк. У нас с ним разные взгляды на развитие, но желаю Максиму успехов. Какие-то полезные изменения мы в том числе портируем из freenginx и за это ему большое спасибо, что неустанно продолжает своё дело.
Серьезно. У нас в телеграме уже больше тысячи подписчиков на новости и мы там выкладываем ссылки на статьи. Пользователи написали, что часть из них побанили после лайка нашей статьи.
P.S. Как по мне, то просто даже сама формулировка про "ошибочное представление, что продукты кому-то интересны" и "кружок с предвзятыми оценками" - это откровенное хамство.
Он не лучше по производительности. При этом возможности кэширования у него весьма ограничены, а кэширование играет важную роль в защите бекендов от DoS-атак.
Всем занимаются рабочие процессы. У мастера только одна функция: обеспечивать отказоустойчивость, т.е. перезагружать конфигурацию без потери соединений и восстанавливать рабочие процессы, если с ними что-то не так. Мастер процесс максимально упрощен и не умеет обслуживать соединения, у него даже полноценного цикла событий нет.
Доступ к сокету соответственно должен быть у пользователя от которого запускаются рабочие процессы.
MTU минус IP/TCP/TLS/HTTP заголовки, т.к. там в сумме набегает ~500B.
Открыл `google.com` - он мне выдал заголовков на 1,4 КБ, не даром же сжатие для них начали делать в HTTP/2. У некоторых на сайтах только одних кук на несколько килобайт набирается, какие уж там 500 байт...
каждый ресурс сжимается независимо от другого, а агрегация происходит на уровне стрима, так что если ваш ресурс меньше 1KB вы просто потратите процессорное время, а данные будут пересылаться так же как и без сжатия.
Не очень понял мысль этого заявления. Предположим, что у нас в пакет помещается с учетом всех оберток около 1200 байт ответов. Если каждый ответ по 1Кб в несжатом виде и около 600 Байт в сжатом, то при запросе двух ресурсов - оба они могут поместиться в 1 пакет в сжатом виде или в 2 пакета в несжатом. Поэтому всё же нет, не так же.
Изначально версия nginx была отвратительна хотя бы тем, что там просто дублировалось 6 десятков директив из существующего proxy-модуля: https://github.com/arut/nginx/blob/5d015359ec2452e508949f24a823fa3b20cb101e/src/http/v3/ngx_http_v3_proxy_module.c#L277 и тысячи строк копипасты.
Далее, судя по всему, кто-то подсказал или у нас подсмотрели, что наверное это очень плохая идея и так делать не нужно.
Вы хотите, чтобы лично для вас сделал отдельное ревью кода, который ещё к тому же даже не в релизе и уже после написания статьи поменялся несколько раз? Или вы хотите, прибегая к развешиванию ярлыков в стиле "это лозунги", "это агрессия", запретить кому-то иметь и выражать своё мнение на основе опыта? Спасибо, мне есть чем заняться более полезным. Оставайтесь при своем мнении, задачи кому-то что-то доказать - нет.
Прекрасно. А у меня есть право объяснять это глупостью, учитывая, что контрибьют следует всем публичным гайдлайнам и не нарушает ни чьих прав, а никакой другой причины публично озвучено не было.
С кем-то вы меня видимо путаете. Не припоминаю, чтобы мы лично были знакомы.
Вам мерещится. Я в своем сообщении вообще ни одной национальности не упоминал.
В 2023 году в Angie была реализована поддержка проксирования по протоколу HTTP/3. Реализацией занимался один из самых опытных разработчиков, который проработал в nginx c 2012 года вплоть до закрытия московского офиса в 2022. Он же до этого работал с коллегами над HTTP/3 в серверной части nginx, поэтому прекрасно знаком с протоколом и всеми нюансами. Ещё тогда в конце 2023 мы решили закотрибьютить эту функциональность в nginx: https://mailman.nginx.org/pipermail/nginx-devel/2023-December/THMZAQ36SN5BICJSCLX6FLEUI45FHR4H.html
Кроме краткого общего обмена мнениями с Максимом никакой реакции на патчи не последовало (на всякий случай поясню, что на момент 2023 года список рассылки разработчиков был основным способом контрибьюта в nginx, а Максим уже не работал в F5). Но на конец 2025 года они уже полгода упорно практически с нуля переизобретают велосипед.
Проксирование HTTP/3 в Angie разрабатывалось по заказу одного очень крупного зарубежного облачного провайдера и на текущий момент тщательно оттестировано в боевых условиях. В nginx сейчас, игнорируя наш опыт, будут идти по граблям ещё после коммита и доводить до ума.
Мне понятно почему так происходит. Разработчики в этом не виноваты, а виноват в этом определенный корпоративный маразм. Есть ли от этого кому-то польза? Нет, в итоге страдают все.
Так объясните. В чем проблема то?
С чего вы решили, что я делаю вид? Да я реально не понимаю. Объясните мне, чем российские государственные конторы отличаются от государственных контор в других странах? Поскольку мы оппонируем к продукту американской конторы, то давайте их сравнивать с американскими государственными конторами. Чем российские хуже американских? В чем тут справедливость недоверия?
У меня вообще очень обостренное чувство справедливости. Я не терплю никакой дискриминации. А для меня это натуральная дискриминация. Человек работал в Сбере - о боже, сразу недоверие, точка. А вот если в ЦРУ, то тут другое, тут доверие. И я не понимаю почему одну и ту же фичу нужно делать два раза или исправлять несколько раз один тот же баг. Мы что-то исправили, а nginx потом у себя исправляет спустя время, вместо того, чтобы подтянуть наше исправление. Кому от этого легче?
К счастью, мировое сообщество всё же разумнее, чем некоторым кажется, а потому у нас растет число пользователей Angie и в США, и по всему миру. А мы всем рады и держим зеркало на гитхабе, со всеми общаемся, переводим документацию на разные языки мира.
А я вам отвечу по существу, потому что вы реально видимо не понимаете насколько смешные вещи пишите. Ругать за наличие сертификации ФСТЭК - это все равно, что ругать строителя, который прошел аттестацию на знание техники безопасности, надевает каску на стройке и регулярно меняет страховочный трос.
Об остальном у вас такие же "глубокие" представления. Советую почитать статью - возможно просветитесь. Впрочем, если вы живете в парадигме, что всё государственное - зло по умолчанию, то едва ли поможет. Но в таком случае, я не очень понимаю как вы живете, ведь без взаимодействия с государством вы ни ИНН не получите, ничего не сделаете. Поэтому сильно подозреваю, что все же вы с государством тоже регулярно взаимодействуете и налоги платите, а потому просто тут лицемерите, либо уже поставили на себе такую же черную метку.
Спасибо за запрос. Я передам его инженерам, отвечающим за сборочную инфраструктуру, но не могу обещать, что они сразу возьмутся переделывать. Неудобство понятно. Текущая версия в первую очередь заточена на наши собственные сборочные процессы.
Отличный пример лицемерия и инфантилизма. Видимо коммиты Максим Дунина во freenginx какие-то более чистые, что ли... без черных меток, правда ведь?! Но только почему-то вот беда, их также игнорируют. Может вы знаете почему?
Но если тот же код послать отдельно, без копирайта, то всё сразу хорошо! Примерно как углеводороды, когда перекачиваются на танкер под другим флагом или пересекают границу третьих стран, то сразу становятся вдруг правильными, с духом свободы, как говорится.
А то, что F5 поставщик военных ведомств США, а за безопасность там отвечал вербовщик из ЦРУ, который ранее занимался внедрением в информационные системы других стран, о чем сам не стесняясь рассказывал в интервью - это, как мы знаем, другое.
И конечно же, ФСТЭК - плохо, а FIPS 140-2 и NIST 800-53 - это хорошо, т.к. стандарты правильной страны. И судя по всему, вы даже не знаете о чем там речь, но заранее имеете мнение.
Прекращайте срочно использовать, там много кода написано теми самыми нами. Это теперь нерукопожатный код с черной меткой.
`root` в конфиге всегда определен. У него есть значение по умолчанию, но stat() при этом не делается (и зачем?). Игорь всегда очень трепетно относился к сисколам и минимизировал их количество.
Я понимаю, что наверное вы что-то наблюдали. Такое запросто может делать какой-нибудь сторонний модуль, этого исключать нельзя. Ванильный nginx так не делает. В любом случае - правильным действием было бы не тратить время на поиски, а пойти и задать вопрос разработчикам, благо я, Максим и многие другие коллеги регулярно в списках рассылки отвечали пользователям.
Веб-сокеты не рвуться, а дорабатывают дальше, если только специально не настроено разрывать долгие соединения через таймаут.
В свое время пришлось повозиться с Envoy и у меня создалось впечатление, что его конфигурация вообще не для человека сделана, а для машин и кишки торчат наружу. Что само по себе конечно имеет свои плюсы, но и имеет и минусы. Для кого-то они существенны, для кого-то нет. Чтобы удостовериться, что это не одному мне так показалась - спрашивал ещё независимых мнений и получил подтверждение своему впечатлению.
И не даром же, даже при наличии Envoy, ингресс-контроллер на базе nginx набрал большую популярность. И коммерческая версия такого ингресс-контроллера пользуется спросом.
Это не так. И никогда такого не было ни в одной версии. `proxy_pass` однозначно устанавливает обработчик на location, который вызывается в content-фазе. А матчинг - это просто префиксное дерево и списки с регулярками. Там вообще нет сисколов. То, что вы описали, больше похоже на некоторые моменты в Apache.
Ну, а если указали try_files - назначение которого буквально кричит из названия директивы, то тут странно удивляться.
Экосистема модулей для nginx одна из самых больших. Луа - тут лишь один из сторонних модулей и не надо вставлять код на луа, это скорее про OpenResty, что суть отдельный проект со своей идеологией ближе к серверам приложений.
Абсолютно нормально если вы лучше познакомились с одним проектом и плохо знаете другой. Плюс у всех разные подходы и взгляды на то, а как должна выглядеть конфигурация. Выше я писал про свое впечатление от того же Envoy. А кто-то вообще хочет, чтобы всё мышкой тыкалось и таких очень много. Прекрасно, что на любой запрос есть свое решение.
P.S. У меня есть понимание как сделать конфигурацию более гибкой, простой и интуитивно понятной. Но для этого нужно время и по опыту NGINX Unit, где подход к конфигурированию был принципиально другим - понятно, что какие-то радикальные идеи и изменения тоже не находят отклика в массах, т.к. есть большая инерция мышления и есть в этом также существенный момент субъективизма.
Например потому, что nginx-подобные продукты во многом лучше. И уж точно производительнее и устойчивее к пиковым нагрузкам, чем тот же Traefik. Не стоит так оголтело записывать админов большей части интернета и крупнейших компаний мира в "отставшие от жизни".
Разумеется у Traefik и Envoy есть свои плюсы. Все разработчики друг на друга смотрят и многие полезные фичи перенимают. Тут нет никакого однозначного лидера, но есть разные подходы и предпочтения в цвете фломастера.
Так всё модульное. Если какие-то модули не требуются, то можно их не собирать, но смысла в этом большого нет, т.к. влияние на производительность от наличия модуля в сборке - чаще всего неизмеримо мало. Мы динамически собираем в основном те модули, которые устанавливают дополнительные зависимости.
Но вообще на разработку "мало кому нужных фич" нет времени. Количество запросов от сообщества сильно больше, чем ресурсов. Плюс технологии развиваются и конкуренты тоже. Если ничего не делать, то какое-то время можно за счет запаса инерции оставаться в тренде, но рано или поздно уйдешь на задворки истории. Естественно никто не будет делать ту или иную фичу по одному-двум запросам - разработка вообще дорогая, поэтому это возможно только на коммерческой основе.
Тут в оценках главное не впадать в субъективизм. Когда работаешь в одной/нескольких компаниях, то имеешь определенное представление о том, что нужно и что не нужно в рамках кейсов, с которыми сам сталкивался. А когда работаешь в вендоре ПО, будь то NGINX, Inc. ранее и теперь Angie Software - то имеешь дело с тысячами компаний и их кейсами, которые зачастую богаче всех твоих фантазий.
В конце-концов, посмотрите какое большое количество сторонних модулей для nginx написало сообщество. Многие из них очень популярны. Не стоит недооценивать модульность и расширяемость - это тоже всегда был значимый критерий успеха и мы трепетно поддерживаем совместимость со сторонними модулями.
P.S. Но вообще, если хочется ставший в какой-то степени каноничным nginx, который существовал с 2011 по 2022 год, то порекомендую freenginx, который разрабатывается Максимом Дуниным. Долгие годы без его одобрения в nginx не попадало ничего, а когда в F5 на его мнение решили наплевать, то ему пришлось сделать свой форк. У нас с ним разные взгляды на развитие, но желаю Максиму успехов. Какие-то полезные изменения мы в том числе портируем из freenginx и за это ему большое спасибо, что неустанно продолжает своё дело.
Серьезно. У нас в телеграме уже больше тысячи подписчиков на новости и мы там выкладываем ссылки на статьи. Пользователи написали, что часть из них побанили после лайка нашей статьи.
P.S. Как по мне, то просто даже сама формулировка про "ошибочное представление, что продукты кому-то интересны" и "кружок с предвзятыми оценками" - это откровенное хамство.
Он не лучше по производительности. При этом возможности кэширования у него весьма ограничены, а кэширование играет важную роль в защите бекендов от DoS-атак.
В первой версии скорее всего только php появится. В последующих поддержку других ЯП будем добавлять.
Если уволить по политическим соображениям всех ключевых разработчиков, включая лидера и идеолога проекта, то результат очевиден. =)
nginx сильно поплохело, а Unit загнулся совсем.
Протокол QUIC реализован не в ядре.
Через labels домен прикрутить сейчас нельзя.
Всем занимаются рабочие процессы. У мастера только одна функция: обеспечивать отказоустойчивость, т.е. перезагружать конфигурацию без потери соединений и восстанавливать рабочие процессы, если с ними что-то не так. Мастер процесс максимально упрощен и не умеет обслуживать соединения, у него даже полноценного цикла событий нет.
Доступ к сокету соответственно должен быть у пользователя от которого запускаются рабочие процессы.
Добавлю ещё, что мониторинга состояния кэша в open source версии nginx тоже никакого нет.
Открыл `google.com` - он мне выдал заголовков на 1,4 КБ, не даром же сжатие для них начали делать в HTTP/2. У некоторых на сайтах только одних кук на несколько килобайт набирается, какие уж там 500 байт...
Не очень понял мысль этого заявления. Предположим, что у нас в пакет помещается с учетом всех оберток около 1200 байт ответов. Если каждый ответ по 1Кб в несжатом виде и около 600 Байт в сжатом, то при запросе двух ресурсов - оба они могут поместиться в 1 пакет в сжатом виде или в 2 пакета в несжатом. Поэтому всё же нет, не так же.