Опубликован выпуск основной ветки nginx 1.29.4, в которой продолжается развитие новых возможностей. В параллельно поддерживаемую стабильную ветку 1.28.x вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей. В дальнейшем на базе основной ветки 1.29.x будет сформирована стабильная ветка 1.30. Код проекта написан на языке Си и распространяется под лицензией BSD...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=64405
> позволяет использовать HTTP/2 при обращении к бэкендам.Ура! А то костыль с `grpc_pass` вместо `proxy_pass` выглядел убого.
видимо начитались параноиков (https://portswigger.net/research/http1-must-die)
> видимо начитались параноиков (https://portswigger.net/research/http1-must-die)Однако проблема имеет место быть. Request smuggling - через http 1.x прокси и разницу в обработке - это весьма модная тема. С дюжиной подвидов этой атаки основанной на разнице в парсинге у фронта и бэка. И вот уже админ ресурса якобы-выполнил якобы-запрос - которого он вообще никогда не отсылал. И так можно перехватить хоть все управление сайтом нахрен, чигача запросы от лица других юзерей.
Удивительно на сколько лет они отстают от того же haproxy !!!
Жду новость с обновлением OCH и HДC. У меня без них совсем не работает, начальник из-за этого грозится уволить и нанять помоложе.
> Жду новость с обновлением OCH и HДC. У меня без них совсем не работает,
> начальник из-за этого грозится уволить и нанять помоложе.НДС тебе налоговики сами обновят, в 2026 году, не парься. Это к твоей бухгалтерии вопросы.
Бухгалтерия не обновляет, а работает с уже имеющимися налогами. Налоги же обновляет государственный аппарат.
откройте для себя caddy. то же что nginx только на 2 порядка проще. сайт работает по http2,3 после указания 3-5 строк. а то и меньше.
https://www.netcraft.com/blog/november-2025-web-server-survey
Для меня вообще новость, что apache существует. Это что-то из времён php3 и shared хостингов.
Кроме того, он до сих пор есть в экзамене на сертификат RHCSA
Неудивительно, кому как не RH кормить всех дремучим легаси под соусом стабильности
Верно, но всё-же это бывает нужно, и что не мало важно - это работает!
Может и проще, но в плане производительности он заметно хуже. Для дома и мелкого проекта сгодится, но вот для крупных он совершенно непригоден
Не рассказывай сказки.
https://linuxconfig.org/ultimate-web-server-benchmark-apache...
Я пролистал ещё с десяток бенчей, и везде ± один и тот же порядок чисел. За исключением статьи на хабре. Но тут больше вопросов к автору, на что он рассчитывал, нагружая Caddy на 9000000 rps. :)
> Но тут больше вопросов к автору, на что он рассчитывал, нагружая Caddy на 9000000 rps. :)Обычный app-layer ddos. Нжинкс с полпинка отбивает такое, в отличие от шляпы с GC на игого.
Откройте для себя Angie. То же, что nginx, только Angie
> Откройте для себя Angie. То же, что nginx, только AngieИ сабжевые улучшения еще не скопипастили? :)
Так если это тот же нгникс, зачем его открывать? Можно просто продолжать жить с нгникс
Он умеет сам сертификаты получать. И другие изменения есть.
>> Так если это тот же нгникс, зачем его открывать? Можно просто продолжать жить с нгниксСофт нынче покупают вместе с людьми. Звучит странно, все-равно что землю или дом купить с людьми. Хоть мы и не в средневековье живем.
> откройте для себя caddy. то же что nginx только на 2 порядка
> проще. сайт работает по http2,3 после указания 3-5 строк. а то
> и меньше.Вот только тормозит и RAM жрет он в разы злее. Я тут видел как нжинкс держал на себе небольшой DDoS, не парясь особо. Воркеры несколько ядер прогрузили, да. Но - ничего не сдохло, и даже перфоманс не особо просел (рулесы нжинкса отбивали ботов перед тяжелыми реквестами). Боты упирались, упирались - но не судьба. А атака видимо стала дороговата длля атакующего и он отвалил в туман. А этот твой caddy наверное завалился бы под таим адовищем.
так сфера применения какая? надо вычислить для кого нужен nginx, а для кого caddy. окажется что количество домохозяек в разы больше чем хостеров. а домохозяйкам нужен caddy.
> так сфера применения какая? надо вычислить для кого нужен nginx, а для кого caddy.Я вообще не знаю зачем нужен caddy. Нечто на языке с GC - ни два ни полтора. Для хайлоада и статики оно такое нафиг не упало, ибо под нагрузкой начнет жрать проц и RAM своим GC. Как сервер приложений оно тоже вроде особо не. Зачем оно такое - я не знаю. И остальные кажется тоже. Судя по его % в вебе.
> окажется что количество домохозяек в разы больше чем хостеров.
Почему-то статистики типа netcraft не в курсе и никак не видят этот caddy на радарах.
> а домохозяйкамнужен caddy.
У домохозяек сайтов нет. Как максимум страничка в фэйсбуке.
Зачем ставят нжинкс я понимаю. Не, его ставят не хостинги. А просто те кто еще и пользуется вебом всерьез. Так что хочет шустро сервировать статику, прикрыть менее резвый бэкэнд от атак, так что скрипткидисы с DDoS пойдут нафиг и придется потратиться чуть сильнее чем просто тапать релоад паги на мобилке или (продвинутый вариант) ставить гирьку на F5. Вот именно шаред помойи - по жизни апач юзали. За .htaccess. Но это изините в RPS отливается. И .htaccess (лишнее io) и неповоротливость и оверинженерия апача в целом.
Мне не нравится HTTP/2.0 из-за бесконтрольности со стороны клиента:
- data compression of HTTP headers
- HTTP/2 Server Push
- prioritization of requests
- multiplexing multiple requests over a single TCP connection
> - data compression of HTTP headersЕго по моему опционально юзать. Да и простой он в общем то.
> - HTTP/2 Server Push
Уже объявлен deprecared как таковой. Нафиг нужная фича - криво юзалось и так и не получило особого распостранения.
> - prioritization of requests
Вы имеете что-то против шустрой загрузки сайтов?
> - multiplexing multiple requests over a single TCP connection
Вы походу ненавидите быструю загрузку сайтов, ибо зачем еще вам лишние RTT и оверхед надо? И какой-нибудь head of line blocking может здорово доставить на HTTP 1.x - когда сайт грузится с жалкой скоростью даже если все условия как бы и есть.
Кто сказал, что приоритетным и многопоточным будет трафик клиента-человека и то что ему нужно? Вы говорите об этом как само собой разумеющемся.
> Кто сказал, что приоритетным и многопоточным будет трафик клиента-человека
> и то что ему нужно? Вы говорите об этом как само собой разумеющемся.Мультиплексирование там в пределах 1 TCP конекции, в коей летает то что заппросил клиент.
В чем фишка? Не надо устанавливать новые TCP конекции (минус несколько RTT), нет head of line blocking как в HTTP/1.1 (загрузка не встает колом на ровном месте недогружая канал).
А так - в интересах сервака обеспечить хороший экспериенс пользака с сайтом. Иначе второй раз пользак на этот сайт не придет - особенно если конкурент запилил такой же, но без лагов. В этом смысле HTTP2 это шаг вперед. А HTTP3 и подавно, там еще и бестолковости congestion control их эпохи диалапа побустали. Потому что в эпоху беспроводных линков то что в TCP есть - работает довольно погано.
Всё так и всё не так.Мультиплексировать всё в одном TCP коннекте это значит сократить задержки на установление TCP соединения и TLS хэндшейк* но уменьшить окно передачи для каждого отдельного запроса.
Те несколько отдельных TCP соединений прокачают обычно гораздо больше за то же время и сильнее утилизируют канал.А сам HTTP/2 пушил гугль, как раз ради той фичи чтобы сервер сам мог зафигачить юзеру баннеры и рекламу без спроса, а гугол записал в лог что "реклама показана", а потом списал денег с рекламодателя. Приоритезация из той же оперы.
HTTP/2 сам по себе ни разу ни конкурент HTTP/1.1 пока они оба ходят в TCP - тут чем больше TCP коннектов - тем лучше.
QUIC - да, конкурент, но в целом это уже более зрелое решение где срезали всё лишнее что можно.
Если смотреть в целом то:
- мультиплексирование в одном TCP соединение - смысла не имеет, проще дать ОС мультиплексировать это на уровне сокетов/соединений
- отлаживать http/2+ и прочие бинарное месево сложнее на порядки, это тебе не tcpdump -A запустить
- quick - ну такое себе, весьма специфичное решение. С одной стороны лишнее выкинили, с другой вытащили в юзерспейс то что давно есть в ядре, а по итогу оно если и лучше - то не прям сильно, ВАУ эффекта и близко нет
- для "традиционной" реализации HTTP/1.1@TLS@TCP - давно придуманы и внедрены кучи разного:
-- TCP fast open чтобы подключатся с первого пакета
-- TLS *чего то там* чтобы тоже не с нуля ручкатся а сразу переходить к делу
-- мультплексирование - это прям база с самого старта TCP/IP стандартов :)
> Всё так и всё не так.Как обычно.
> TCP соединения и TLS хэндшейк* но уменьшить окно передачи для каждого
> отдельного запроса.И тем не менее. В http это зачастую так:
resource 1 -> depends resource 2 -> depends resource 3 -> ...Мы пытаемся вгружать 1, видим что для рендера надо 2 а потом и 3. И?!
При пайплайнинге (в 1.1 есть) в той же конекции - экономим на RTT, но курим бамбук до конца всей цепочки, просто потому что сервак чисто технически не может начать слать нам 2 и 3 ДО того как 1 вообще целом отдаст. И мы кукуем до упора. Последовательно. No win!
А если новые соединения фигачить, чтобы все же пытаться качать параллельно - мы замечаем что при попытке открыть новый конект и утащить 2 и 3 так - налетаем на несколько лишних RTT. No win, again.
HTTP/2 с мультиплексированием запросов - просто не имеет этих проблем. Нет ни налета на лишние RTT, и можно получить 2 и 3 не ожидая пока весь 1 нальется, параллельно, в чем прелесть мультиплексирования и состоит. Когда 1 докачается, 2 и 3 уже будут -> рендер ускоряется. Push был попыткой доразвить идею, но это много конфигурации требует и в целом неудобно вышло.
> Те несколько отдельных TCP соединений прокачают обычно гораздо больше за то же
> время и сильнее утилизируют канал.Вот только чтобы их открыть - надо RTT потратить. И окупится ли ради какой-то мелочевки от которой depends 1, который еще пока качается - вопрос. У HTTP/2 просто нет этой проблемы.
> А сам HTTP/2 пушил гугль, как раз ради той фичи чтобы сервер
> сам мог зафигачить юзеру баннеры и рекламу без спроса,Гугло по моему первое же и забило на сервер пуш. Пуш ресурса сам по себе не обязывает клиента ни к какому его рендеру или что там еще. Основная проблема пуша в том что это подвязывает контент на конфиг сервера и менять надо и то и другое. Синхронизированно. Это неудобно. А если это не делать, это АНТИфича. Т.е. может налить устаревший хлам, который уже не надо - но конфиг не обновили, так что нате вам. Синхронизировать конфиг сервака с контентом - неудобно.
> рекламодателя. Приоритезация из той же оперы.
Приоретизация - позволит в вышеупомянутом примере пропихнуть то что реально надо для рендера первым, а какие-нибудь пятиметровые фоты в галерею качавшиеся полчаса - пусть в фоне тянет, опосля остального, не якоря рендер. Идея так то норм.
> HTTP/2 сам по себе ни разу ни конкурент HTTP/1.1 пока они оба
> ходят в TCP - тут чем больше TCP коннектов - тем лучше.Это лишний оверхед, трафик и просто несколько нафигнужных новых RTT. А суммарно тормозная загузка сайта.
Потом - такие как вы начинают ныть что у гугло сайт грузится куда быстрее чем у вас, пользаки забивают на вас - и идут юзать гугло и его сервисы. Мозилла так на webp довыступалась, ей стали лить JPG на 40% жирнее, сайты гугла стали грузиться в хроме быстрее чем в лисе. Рыночной доле лисы сие воздалось. И тут вдруг мозилла почему-то перестала строить из себя целок и сделала webp. Некоторые понимают - только в таком формате. Вы, кажется, 1 из таких господ.
> QUIC - да, конкурент, но в целом это уже более зрелое решение
> где срезали всё лишнее что можно.QUIC это по сути почти HTTP/2 over UDP. Чтобы еще от congestion control в TCP отделаться нахрен. Ибо договориться со всеми на его тему - сложно, а user experience сие рушит конкретно, особенно на беспроводных линках.
> - мультиплексирование в одном TCP соединение - смысла не имеет,
Если сравнить как HTTP1 работает, там есть пайплайнинг но он напрочь последовательный, и в примере выше сперва придется грузить 1 целиком, чтбы потом ЗА ним догружать 2 и 3 нужные ему. Все последовательно. Или открывая новую конекцию - с налетом на несколько RTT.
В HTTP/2 - 2 и 3 можно слать параллельно и когда 1 докачается они уже могут быть тут. И нет налета на RTT. В целом соотношения получаются лучше и все кого user experience интересовал на h2 свалили давно, особенно крупные сайты с нормальными админами.
> проще дать ОС мультиплексировать это на уровне сокетов/соединений
Это стоит по N RTT на каждое соединение что видилте ли тормозит загрузку страниц.
> - отлаживать http/2+ и прочие бинарное месево сложнее на порядки, это тебе
> не tcpdump -A запуститьЭто ваши проблемы что вы не умеете что-то там отлаживать. Если вам техническая компетенция не позволяет, окей, значит вы заслужили чтобы конкуренты задвинули вас, чисто технологически.
> - quick - ну такое себе, весьма специфичное решение. С одной стороны
> лишнее выкинили, с другой вытащили в юзерспейс то что давно есть в ядре,Иди договорись с каким-нибудь майкрософтом на тему congestion control допустим. Чтоб какое там видео с ютуба не ловило якорь на полчаса от того что поезд проскочил тоннель в котором покрытия чисто технически не было, стек подумал что это потери пакетов. А оно ни разу не.
> - для "традиционной" реализации HTTP/1.1@TLS@TCP - давно придуманы и внедрены кучи разного:
Для начала оно тоже бинарное месиво в проводе, tcpdump ты тоже не много там поймаешь. А заодно позволяет прикольные десинк атаки на бэки. Ибо т.к. это текст, его можно парсить - весьма по разному как показала практика. Это хреновая спека, скажем прямо. Эксперимент показал что двуногие массово лажают и это позволяет нмало приколов, десинхронизируя парсинг.
> -- мультплексирование - это прям база с самого старта TCP/IP стандартов :)
Вот только там несколько RTT бонусом в комплекте. Что совсем не круто.
https://opennet.ru/63738-pingora
>Добавлена поддержка TLS-расширения ECHВот это хорошо.
РКН уже потирает свои грязные ручки.
Далее ты скажешь, что "ECH заблокирован в РФ"?
ТСПУ не умеет блокировать ECH , примитивно заблочили служебный домен клауда . Технология предназначена для безопасности , а не обхода - потому клауд недосмотрел . Но если начнут применять все , да без специфичных доменов - роскомпозор будет потирать НЕ ручки .
Все верно сказал, но если начнут применять все, то поступят просто как в Китае и Иране - заблокируют каналы получения DNS HTTPS RR а именно все "нехорошие" DoH/DOT серверы.
Ну ничего, DoQ в Китае всё равно работал. Они блокируют технологии позапрошлого поколения, устаревшие на 5 лет.
Как только ECH перейдёт в разряд mandatory - смогут хоть обблокироваться :)
Без интернетов - тоже нормально.
> Как только ECH перейдёт в разряд mandatory - смогут хоть обблокироваться :)
> Без интернетов - тоже нормально.Если ты не заметил вайтлисты появились, как минимум у сотовых операторов. И вот что ты с этим будешь делать? Да, господа на югах рутинно отдыхают... от интернета. Почему-то. Вот такой вот хреновый отдых.
Чего-чего. Возьму чемодан, поеду в аэропорт.
он поддерживает HTTP2 без TLS?
Http2 это как-то не особенно свежо звучит.Нужен-то http3.
>Нужен-то http3Зачем он нужен гуглу, амазону, етц я понимаю. А тебе зачем нужен http3? Поделись.
В Angie уже год как
Между nginx'ом и бекендом? Зачем?
в некоторых случаях http2 быстрее http3, а в некоторых наоборот. зависит от того что и как передаем.
Ждал чего то в этом роде. Что весь запад перейдет на ECH и РКН будет вынужден выбирать между капитуляцией и самоизоляцией. Ну, знаете, условно, если гугл вдруг скажет на давайте блочте нас. Только тогда обновлений на телефоны тоже не получите. И наверное все таки здравый смысл однажды возобладает. Т.к. наверное все таки дешевле пропустить одного "экстремиста", чем клепать свои телефоны и компьютеры.
Это при условии что клепать умеешь, а с этим ОЙ.
Так и я об этом. Променяют просто шило на мыло. Западные зонды на китайские, которые будут выдаваться за свои путем переклеивания шильдиков. Только вот суверенитета от этого не добавится.Я уже много раз говорил. Огораживание себя от всего мира - проявление слабости. Звучит это конечно как "Зачем нам их разврат? Нам и так хорошо". Если более конкретно, то зачем нам их Steam - мы же в 60х в казаков-разбойников играли и были счастливы. Но на деле это "Если людям не показывать, что где то живут лучше, то и свинарник будет дворцом". А смысл то какой? Мне кажется, что товарищи ошиблись века этак на 2. Неграмотные крестьяне, которых барин мог вертеть как угодно, были в последний раз в веке этак 19м. Демократические революции потому и произошли, что народ осознал, что он достаточно образован, что сам решать свою судьбу.
> Демократические революции потому и произошли, что народ осозналГлупость какая, как народ может осознать? или вы чувствуюте управляющую волю коллективного разума?
одни дяди заплатили деньги другим, чтобы те налили в уши третим, вот и вся история.
Если комуто выгодно, называть черное белым, и это быдет приносить прибыль, то обязательно найдутся те кто будет с этого кормиться, инквизиция отрицала главную заповедь своего бога, и не плохо себя чувствовала конфискуя имущество убиваемых еретиков, а попутно нарушала и все остальные заповеди, это бизнес.
Из-под палки ничего нормального не получится. Почитайте «Почему одни страны богатые, а другие бедные» 2012г.
Для этого в современном мире есть такая вещь, как статистика. Сколько людей играет в Steam? А сколько играет в VK Play или Mail игры? И вот тут и возникает главная проблема огораживания. Будут конечно предлагать альтернативу. И будет эта альтернатива заведомо хуже. Но дети как пустой сосуд, который можно наполнить чем угодно. Никто ведь не узнает, что альтернатива хуже, если не будет доступа к оригиналу, правда? Жили же 50 лет ВАЗ2101 и не знали, что люди уже лет 20 ездят со стеклоподъемниками и кондиционерами. Да, в этот раз все немного по другому. У нас еще остался запас западных технологий и есть китайские друзья, которые все будут делать за нас, а нам останется только переклеить шильдик.Но все же наверное не стоит быть социопатами и уметь преодолевать трудности, а не отгораживаться от них стенами.
Да не узнать-то можно, но это прямой путь в резервацию в разрезе столетия.
Ну или статистика попроще. Сколько людей добровольно пользовались VK Мессенжером до того, как альтернативы не начали блокировать? Это называется голосовать кошельком. И для этого даже не нужно идти на выборы, где "Главное не кто голосует, а кто считает".
Т.е. демократия это даже не про выборы и это вот все. Что толку сейчас от выборов, если они безальтернативные? Это как в старом анекдоте про супермакет и ларек. Смысл хотя бы возможности голосовать кошельком, а не хавать, что дают.
Вам гугл уже принёс подарочек, под ёлку навалил, после НГ вонять начнёт :)Если что я про то, что рустор вместе со всем хламом выкидывают с поляны андройда в след году.
Какие то производители может и придумают что то, но вой будет стоять знатный.
> Использование ECH включается через указание в директиве "ssl_ech_file" файла конфигурации ECHConfig в формате PEM.Ну т.е. по дефолту не работает, а специально этим заморачиваться мало кто будет.
А значит ECH не станет повсеместным.
К счастью, да.Ты самую мякотку пропустил:
> Поддержка доступна при использовании сборок OpenSSL с ECH.И ссылочка на мертвую ветку в гите.
тот специальнозаморочившийся васян просто переставит свой сервер, потому что вряд ли даже хватит мозга понять почему больше не может на него зайти, и больше так заморачиваться не будет.
Так вы тоже мыслите слишком коротко: сегодня всё так плохо, а через год гугл скажет что кто без ECH того понизим в выдаче, и стадо опять побежит внидрять!Тема того что всё надо закрыть криптой - она долгоиграющая, ECH тут просто заплатка, которая будет раскатана без вариантов. Через год или через 3 но будет.
https://support.mozilla.org/ru/kb/chto-nuzhno-znat-ob-ech