Сформирован выпуск основной ветки nginx 1.19.5, в рамках которой продолжается развитие новых возможностей (в параллельно поддерживаемой стабильной ветке 1.18 вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей)...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54148

• Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,Vlad Violentiy, 10:22 , 26-Ноя-20
  • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,Программист, 10:30 , 26-Ноя-20
    • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,anonymous, 12:05 , 26-Ноя-20
      • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,Аноним, 12:08 , 26-Ноя-20
      • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,Программист, 13:50 , 26-Ноя-20
      • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,master, 17:35 , 26-Ноя-20
    • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,Аноним, 18:04 , 26-Ноя-20
    • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,Аноним, 16:57 , 28-Ноя-20
  • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,Ilya Indigo, 10:59 , 26-Ноя-20
    • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,leibniz, 11:02 , 26-Ноя-20
      • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,n00by, 15:23 , 26-Ноя-20
        • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,leibniz, 17:20 , 26-Ноя-20
          • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,n00by, 18:38 , 26-Ноя-20
        • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,master, 17:37 , 26-Ноя-20
          • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,n00by, 18:48 , 26-Ноя-20
          • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,Аноним, 02:22 , 27-Ноя-20
          • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,leibniz, 05:50 , 27-Ноя-20
            • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,n00by, 11:05 , 27-Ноя-20
        • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,Ordu, 20:26 , 28-Ноя-20
          • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,n00by, 09:03 , 05-Дек-20
    • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,Аноним, 12:26 , 26-Ноя-20
      • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,flkghdfgklh, 21:54 , 26-Ноя-20
      • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,burik666, 17:13 , 27-Ноя-20
  • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,Разработчики nginx, 11:01 , 26-Ноя-20
  • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,master, 17:34 , 26-Ноя-20
  • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,jura12, 09:16 , 28-Ноя-20
• Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,ano, 11:18 , 26-Ноя-20
• Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,Аноним, 11:57 , 26-Ноя-20
  • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,odd.mean, 12:02 , 26-Ноя-20
• Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,Аноним, 12:46 , 26-Ноя-20
  • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,пох., 13:01 , 26-Ноя-20
    • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,master, 17:41 , 26-Ноя-20
      • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,пох., 22:32 , 26-Ноя-20
  • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,Аноним, 14:27 , 26-Ноя-20
  • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,Ordu, 14:33 , 26-Ноя-20
    • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,пох., 15:44 , 26-Ноя-20
• Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,GentooBoy, 14:55 , 26-Ноя-20
  • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,пох., 15:46 , 26-Ноя-20
  • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,Valentin V. Bartenev, 16:57 , 26-Ноя-20
    • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,GentooBoy, 12:49 , 27-Ноя-20
    • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,мяя, 13:20 , 28-Ноя-20
      • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,Valentin V. Bartenev, 21:19 , 28-Ноя-20
        • Выпуск nginx 1.19.5 сервера приложений Unit 1.21.0 ,мяя, 11:51 , 29-Ноя-20
• Выпуск nginx 1.19.5 и сервера приложений Unit 1.21.0 ,Аноним, 14:16 , 28-Ноя-20

когда уже quic в апстирме будет?

Что он конкретно ВАМ даст? Вы делали тесты и у вас есть реальный прирост в скорости в реальных цифрах?

Ну вот я делал. И у меня реально есть прирост для коротких сообщений. Что дальше? :)

ждать

Хотелось бы цифры увидеть и понять как часто будет такой прирост и на сколько он большой. Просто ради интереса. Потому что моё мнение это сферический конь. Для гугла с его высоконагруженными сервисами может и есть смысл, а вот для всех остальных - есть ли он?

Ничего, твои тесты вообще ниочём.

В недавних новостях же писали - 3% дает прироста.
HTTP/3 == 3%

Его очень не хватает браузерным играм. Хотя, так как все еще не разработано вебсокет-сервера для QUIC придется продолжать костылять на WebRTC.

Quic никогда не будет!
HTTP/3, не раньше чем появится окончательный стандарт.

а пруф можно, пожалуйста?..

> а пруф можно, пожалуйста?..

Интересно, кто и зачем минусует вот такие комментарии? Даже если (предположим), спрашивающий в чём-то не прав, тем не менее, по здешним меркам, сообщение тянет на образец вежливости. Неужели именно это вызывает негативную реакцию?

Боюсь, ответа Вы не получите (:

Иногда возможно понять по косвенными признакам.

Я минусую, потому что это синдром iPony

Спасибо. Страшно представить, что это.

Почему "iPony"? Это пони робот от компании Apple?

я болен им? что же мне делать?!

Как правило, кому бы ни были адресованы подобные "диагнозы", они пишутся про себя. Но в данном случае похоже, что отвечающий юродствовал под минусаторов.

> Интересно, кто и зачем минусует вот такие комментарии?

Я могу предположить. Минусующий очень не любит QUIC, и ему очень хочется верить в то, что родительский коммент глаголет истину. Запрос пруфов, в понимании минусующего, ставит истину под сомнение, то есть воспринимается как попытка разрушить иллюзию. И хорошо, что это просто минус, люди, бывает, убивают тех, кто покушается на их иллюзии. Ну или они думают, что покушается -- тут уже без разницы, как "покушающийся" оценивает свои действия, важно то, что его действия привели к тому, что иллюзии в голове у минусующего пошатнулись или даже рассыпались.

Спасибо, смелое предположение. Могу подтвердить, в частных случаях так и есть, мне угрожали нанесением тяжких телесных, поскольку публикации определённо фигурантам не нравятся. Но там запущенный случай (пугало настолько серьёзно уходит в запои, что даже его коллеги не стесняются говорить об этом на публике), а тут исходное сообщение совершенно безобидно, не представляю, кому оно может не понравиться.

> HTTP/3, не раньше чем появится окончательный стандарт.

А стандарт не появится, потому что гугловцы выпускают новый QUIC в среднем раз в два месяца. Это их собственный протокол, имеют право.

Ты, как всегда, обосратушки
Это уже не протокол гугла, а передан в IETF HTTP, где разрабатывается как http/3

Ну это как с HTTP/2 и SPDY от Google.

Vlad Violentiy, скоро.

Надеюсь никогда.

я видел тесты. он еше тормозней http2. может это проявляется в некоторых условиях?

При сборке разных модулей-дополнений теперь можно использовать общие исходные файлы.

А после дождя будет ясная погода™

А запятую поставить в новости? Или и

Уже предложил исправление, дело за модераторами.

> Вместо имени файла можно указать специальное значение stderr.

Зачем нужно специально обрабатывать это значение, когда уже есть /dev/stderr? Работает даже там, где автор проги и не предполагал такое использование.

Потому что авторы очень, очень старые, и еще помнят что помимо "нового стандарта" может быть, внезапно, другой юникс, где нет никакого /dev/stderr

Но это, конечно, скоро пройдет.

> Потому что авторы очень, очень старые

Нет, потому что голова на месте.

Так у любителей нового стандарта - тоже на месте. Или во что, по-твоему, они едят?!

Открыл спецификацию posix, ищу /dev/stderr и не могу найти. А, ну да, это потому что там ничего такого нет и не было.

Угу, а ещё есть /proc/self/fd/2

Зачем только нужен этот /dev/stderr?

Это симлинк, примерно туда же. Просто чтоб не запоминать бессмысленные цифирьки.

"примерно", потому что на самом деле это симлик в /dev/fd/2 - потому что даже в новых стандартах /proc, внезапно, может просто не быть.

слабо понямаю зачем nginx unit треды. Вообще получяеться что в нем нет канкаренси и он не может на одном потоке обрабатывать больше одного соединения, тогда вопрос нафига это надо если тоже самое может apache ?

> слабо понямаю зачем nginx unit треды

это не ему треды, это "приложению" треды.

> тогда вопрос нафига это надо если тоже самое может apache

apache не может в сервер приложений, если только это не mod_php (и то с ним какие-то вечные проблемы - вот, в частности, в треды он тоже не может, ему подавай только обычный mpm)

Unit гораздо сложнее устроен. Если кратко, то Unit это nginx + php-fpm (или любой другой запускатор приложений на любимом ЯП по вкусу) - только современные и без накладных расходов на протокол и сокеты между.

Вся обработка соединений, маршрутизация между приложениями, а также раздача статики, проксирование  - происходят в отдельном процессе, который называется "router". Этот процесс использует несколько асинхронных потоков, по одному на ядро процессора. Каждый поток имеет свой собственный epoll/kqueue и работает с соединениями.

По сути этот процесс воплощает собой современный nginx, как бы он выглядел, если бы проектировался сейчас, а не 18 лет назад.

Далее, если запрос нужно передать на обработку приложению, которое работает в отдельных процессах и изолировано от всего остального, то этот запрос с помощью быстрого IPC, построенного на блоках разделяемой памяти и безлоковых очередях - переправляется в свободный процесс с этим приложением.

Сами процессы приложения могут быть синхронные или асинхронные в зависимости от ЯП и реализуемых интерфейсов. В новой версии сделали ещё, что бы в каждом процессе приложения могло быть ещё и несколько потоков, где это возможно.

Тут разумеется есть нюансы, как, например, GIL в Python/Ruby, а вот PHP похоже до сих пор не особо thread-safe, поэтому в нем большого смысла реализовывать это пока нет. Но мы посмотрим.

>Далее, если запрос нужно передать на обработку приложению, которое работает в отдельных процессах и изолировано от всего остального, то этот запрос с помощью быстрого IPC, построенного на блоках разделяемой памяти и безлоковых очередях - переправляется в свободный процесс с этим приложением.

Вот теперь стало понятно где треды.
Я так и не добрался до покрутить unit, но njs очень порадовал. Быстренько поработать и умереть прямо то что нужно.
Спасибо за продукт

> По сути этот процесс воплощает собой современный nginx, как бы он выглядел, если бы проектировался сейчас, а не 18 лет назад.

Но Unit не заменяет nginx. Будут ли nginx переписывать или доводить unit до функционала nginx?

> доводить unit до функционала nginx?

Этим и занимаемся постепенно.

Понял направление. Спасибо за ответ.

В NGINX Unit конфиги добавили? Вот это новость, может скоро станет надо.