forum.opennet.ru - "Выпуск сервера приложений NGINX Unit 1.11.0" (85)

"Выпуск сервера приложений NGINX Unit 1.11.0"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Выпуск сервера приложений NGINX Unit 1.11.0"	+/–
Сообщение от opennews (ok), 20-Сен-19, 07:35
Увидел свет выпуск сервера приложений NGINX Unit 1.11, в рамках которого развивается решение для обеспечения запуска web-приложений на различных языках программирования (Python, PHP, Perl, Ruby, Go, JavaScript/Node.js и Java). Под управлением NGINX Unit может одновременно выполняться несколько приложений на разных языках программирования, параметры запуска которых можно изменять динамически без необходимости правки файлов конфигурации и перезапуска. Код написан на языке Си и распространяется под лицензией Apache 2.0. С особенностями NGINX Unit можно познакомиться в анонсе первого выпуска... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=51524
Ответить \| Правка \| Cообщить модератору

Оглавление

збс, давно ждал, спасибо, zo0M (ok), 07:35 , 20-Сен-19, (1) +4

Количество комментариев намекает на его нужность , Ан (??), 10:55 , 20-Сен-19, (21) +3

о, да, zo0M (ok), 08:22 , 22-Сен-19, (86)

А разве NGINX сам по себе не отдавал статику , Аноним (2), 08:51 , 20-Сен-19, (2) –4

NGINX и NGINX Unit это совершенно разные вещи , Аноним (3), 08:58 , 20-Сен-19, (3) +10
Nginx отдавал, Nginx Unit нет, zo0M (ok), 08:23 , 22-Сен-19, (87)

Молодец Игорь Сысоев, теперь спокойно работает, главное вовремя понять, когда на, Aytishnik.com (ok), 10:58 , 20-Сен-19, (22) –1

главное вовремя понять, куда А когда наступает примерно как можешь отдельно о, пох. (?), 11:38 , 20-Сен-19, (25) +3

Не, ну чуть попозже, всё же , Аноим (?), 11:53 , 20-Сен-19, (27) +2

До этого не спокойно работал Поделитесь о чем речь , test (??), 00:36 , 21-Сен-19, (58) +1

Надо полагать, примерно об этом 11 марта 2019 года объявлено, что компания F5 Ne, Lex (??), 08:29 , 25-Сен-19, (98)

Да что за бич опеннета с версткой маркеры маркированного списка плывут и на теле, Аноним (23), 11:01 , 20-Сен-19, (23) +9

уж лучше голый html, Аноним (28), 12:10 , 20-Сен-19, (28)
они оверинженеры, там и бэкенд на страшной жабе , Аноним (31), 13:08 , 20-Сен-19, (31) –3
Все хуже То едут, то не едутС десктопа едут под игровой виндой, не едут под ра, iPahcae6 (?), 14:24 , 20-Сен-19, (35)

Работают лучше Fronend специалисты индустрии , Аноним (31), 14:25 , 20-Сен-19, (36) –1

chtext li text-indent 0 , KonstantinB (ok), 21:26 , 20-Сен-19, (50)

Спасибо, поправил Расстановка отступов в CSS на сайте не менялась лет 15 и сдви, Maxim Chirkov (ok), 10:19 , 21-Сен-19, (62) +1

Да, в предпоследнем хроме вообще дров наломали На паре сайтов, которые я не тро, KonstantinB (ok), 16:55 , 21-Сен-19, (66) +1
Ты придумал Reset CSS, который используют все Frontend разработчики normalize c, Аноним (31), 09:51 , 22-Сен-19, (93)

https pastebin com r7CN7kve, Аноним (31), 09:54 , 22-Сен-19, (94)

интересно, на открытую версию nginx-не-юнит окончательно теперь будет положен , пох. (?), 11:37 , 20-Сен-19, (24) –4

Вообще есть повод для таких догадок Мое ИМХО - nginx просто в идеальном и стабил, kiwinix (?), 11:53 , 20-Сен-19, (26) +4

GZIP нельзя отключить для html контента при HTTPS BREACH Attack , Аноним (31), 14:27 , 20-Сен-19, (37)
не-опоздание родиться за повод считается Я прекрасно помню как он развивался до , пох. (?), 22:52 , 20-Сен-19, (56)

Без паники Над Unit и nginx работают две независимые команды Причем на данный , Valentin V. Bartenev (?), 13:45 , 20-Сен-19, (33) +10

Теперь понятно почему в NGINX больше не производиться работа над доработками tra, Аноним (31), 14:30 , 20-Сен-19, (38)

А о каких конкретно доработках идет речь Множество доработок происходит регуляр, Valentin V. Bartenev (?), 15:29 , 20-Сен-19, (40) +1

1 https trac nginx org nginx ticket 10832 https trac nginx org nginx ticke, Аноним (42), 15:50 , 20-Сен-19, (42) –1

1 По многим реализуемым фичам поступают десятки запросов в месяц, а тут 1 челов, Valentin V. Bartenev (?), 18:00 , 20-Сен-19, (45) +8

Валентин, что сейчас думаете про io_uring , Аноним другой (?), 23:58 , 25-Мрт-20, (107)

cache-aware learning server-push https h2o examp1e net configure http2_directi, Аноним (42), 15:54 , 20-Сен-19, (43)

Добрый день, Валентин У меня давно уже назрел вопрос На текущий момент у меня ве, Ilya Indigo (ok), 19:15 , 20-Сен-19, (48)

Я не Валентин, но - если вам нужен htaccess действительно нужен, а не банально, KonstantinB (ok), 21:31 , 20-Сен-19, (51) +2

вычтите те, что нужны для, собственно, отдачи файла на том же уровне - и удивите, пох. (?), 22:47 , 20-Сен-19, (54)

Я ничего про отдачу и не говорил Считаем сисколлы только на чтение конфигурации, KonstantinB (ok), 17:11 , 21-Сен-19, (68)

open read close, чего там считать-то Ну может stat еще, вдруг нам его читать не, пох. (?), 23:17 , 21-Сен-19, (79)

А сами сисколы там и есть самое затратное, особенно если речь идет о небольших ф, Valentin V. Bartenev (?), 00:53 , 22-Сен-19, (81) +1

учитывая поголовное сочетание zfs с https - его как-то уже особо и негде незачем, пох. (?), 16:22 , 25-Сен-19, (99)

Он мне нужен для безопасности и маршрутизации Сомневаюсь что подобное можно реал, Ilya Indigo (ok), 00:43 , 21-Сен-19, (59)

я вот одного не пойму, чем ссылка index php lang 1 view 2 token 1 PayerID 2 , Sw00p aka Jerom (?), 12:21 , 21-Сен-19, (63)

1 Тем что она длинная и не понятная пользователю Не ЧПУ 2 А также тем, что она, Ilya Indigo (ok), 14:03 , 21-Сен-19, (65)

Подобные реврайты прекрасно делается через location с регулярками и динамическое, KonstantinB (ok), 17:07 , 21-Сен-19, (67) +1

Благодарю Вас за ответ - Не знал что так вообще возможно Ну да это гораздо про, Ilya Indigo (ok), 18:16 , 21-Сен-19, (71)

При такой конфигурации - когда SCRIPT_FILENAME указывается в явном виде - достат, KonstantinB (ok), 22:08 , 21-Сен-19, (72) +1
Вообще то, что в nginx все fastcgi-параметры указываются в явном виде, позволяет, KonstantinB (ok), 22:09 , 21-Сен-19, (73) +1

Ёмаё, так это конфигурация nginx А я смотрю на это https httpd apache org mo, Ilya Indigo (ok), 22:19 , 21-Сен-19, (76)

В Apache никто не заставляет эту конфигурацию держать в htaccess Ее можно споко, KonstantinB (ok), 01:42 , 22-Сен-19, (83) +1

Благодарю, Вас Я и не знал что так можно было думал что mod_rewrite работает тол, Ilya Indigo (ok), 10:56 , 22-Сен-19, (95)

Еще очень полезно отключить включенный по умолчанию fix_pathinfo в php ini cgi f, KonstantinB (ok), 22:15 , 21-Сен-19, (74) +1

Благодарю за пояснение Согласен подобные костыли - зло https httpd apache org, Ilya Indigo (ok), 22:23 , 21-Сен-19, (77)

Добрый день А для чего у вас php c Apache через FastCGI работает вместо mod_php , Valentin V. Bartenev (?), 13:29 , 21-Сен-19, (64) +3

Благодарю Вас, Валентин, за подробный и развёрнутый ответ - Вы меня серьёзно о, Ilya Indigo (ok), 17:16 , 21-Сен-19, (69)

mod_php нормально работает только с prefork MPM С event вообще не работает С w, KonstantinB (ok), 22:19 , 21-Сен-19, (75)

Это я зная, просто не понимаю почему пишут что на высоких нагрузках mod_php с pr, Ilya Indigo (ok), 22:29 , 21-Сен-19, (78)

Я бы не сказал, что производительнее Примерно одинаково , KonstantinB (ok), 01:41 , 22-Сен-19, (82)

Я вообще не знаток Apache, но полагаю это всё же некое преувеличение Вряд ли та, Valentin V. Bartenev (?), 00:23 , 22-Сен-19, (80) +1

Ё-маё и снова Вы меня удивили - Я думал что mod_rewrite работает только чер, Ilya Indigo (ok), 11:16 , 22-Сен-19, (96)

Потому, что API и внутренние механизмы Unit-а достаточно существенно отличаются , Valentin V. Bartenev (?), 14:03 , 26-Сен-19, (100) +1

Благодарю Вас - , Ilya Indigo (ok), 14:20 , 26-Сен-19, (101)

Добрый день, Валентин и все кто сейчас читает эту ветку Я наконец-то сегодня пер, Ilya Indigo (ok), 13:18 , 16-Окт-19, (102)

А и не надо на нем регистрироваться Этот форум - всего лишь веб-интерфейс прич, Valentin V. Bartenev (?), 13:55 , 20-Окт-19, (103) +1

Вот не люблю я их, не удобные они, они не дают развёрнутого диалога как в багзил, Ilya Indigo (ok), 16:58 , 20-Окт-19, (104)

Почтовики STARTTLS Вы случайно с NNTP Usenet не попутали В списках рассылки м, Valentin V. Bartenev (?), 22:48 , 20-Окт-19, (105) +2

Нет не попутал Отправить баг в postfix и dovecot через их маиллисты мне не пред, Ilya Indigo (ok), 21:40 , 27-Окт-19, (106)

Всяко спасибо за труды , Michael Shigorin (ok), 20:24 , 23-Сен-19, (97)

о чем речь, разработка этих продуктов ведется параллельно разными командами , zo0M (ok), 08:25 , 22-Сен-19, (88)

Анонистные эксперты, ответьте всё, просто нгинкс можно выбрасывать , Аноним (29), 12:27 , 20-Сен-19, (29)

Зависит от задач Unit - это прежде всего web application server ну, не совсем,, KonstantinB (ok), 04:12 , 22-Сен-19, (84) +1
нет, нельзя, это по-прежнему основной продукт компании , zo0M (ok), 08:27 , 22-Сен-19, (89)

Я так и не понял, а зачем он для го и джавы нужен , Аноним (30), 13:05 , 20-Сен-19, (30) +1

А тебе и не надо значит 8482 , ansible (?), 13:24 , 20-Сен-19, (32) +3
эмм запуск приложений, оркестрация , zo0M (ok), 08:28 , 22-Сен-19, (90)

то что научили и статику отдавать, очень хорошо, , eRIC (ok), 14:04 , 20-Сен-19, (34) +3

таки да, кошерненько, zo0M (ok), 08:29 , 22-Сен-19, (91)

Всегда интересовался вопросом, что такое релиз а что такое выпуск Берем эту, Аноним (41), 15:42 , 20-Сен-19, (41) –1

Это синонимы А разные варианты в одной и той же новосте - это чтоб не повторять, Аноним (44), 17:25 , 20-Сен-19, (44) +1

Когда-то Сысоев говорил, что не будет писать второй апач По факту написали уж, Аноним (46), 18:38 , 20-Сен-19, (46) –2

таки да а вот этого не видать категорически, ибо нджинкс - не апач , Sw00p aka Jerom (?), 21:04 , 20-Сен-19, (49)
ты его неправильно понял - это он говорил про htaccess, человекопонимаемые влож, пох. (?), 21:40 , 20-Сен-19, (52)

идите к раку на горе ибо ждите когда сам спустится вот status page нджинкса эт, Sw00p aka Jerom (?), 22:39 , 20-Сен-19, (53)

я надеюсь, вы уже открыли для себя mod_vts это ни разу, конечно, не нормальный, пох. (?), 22:49 , 20-Сен-19, (55)

спасибо, лишний раз не хочется слышать от Дунина - отрубите все сторонние модул, Sw00p aka Jerom (?), 23:03 , 20-Сен-19, (57)

Ну мало ли какие модули кто понаписал Половина перечисленного - сторонние модул, KonstantinB (ok), 04:13 , 22-Сен-19, (85)

Ну норм, осталось туда весь обычный nginx встроить и будет таки апач , vitalif (ok), 17:49 , 21-Сен-19, (70) +2

Сообщения [Сортировка по времени | RSS]

1. "Выпуск сервера приложений NGINX Unit 1.11.0" +4 +/–

Сообщение от zo0M (ok), 20-Сен-19, 07:35

збс, давно ждал, спасибо

Ответить | Правка | Наверх | Cообщить модератору

21. "Выпуск сервера приложений NGINX Unit 1.11.0" +3 +/–

Сообщение от Ан (??), 20-Сен-19, 10:55

Количество комментариев намекает на его нужность ....

Ответить | Правка | Наверх | Cообщить модератору

86. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от zo0M (ok), 22-Сен-19, 08:22

о, да

Ответить | Правка | Наверх | Cообщить модератору

2. "Выпуск сервера приложений NGINX Unit 1.11.0" –4 +/–

Сообщение от Аноним (2), 20-Сен-19, 08:51

А разве NGINX сам по себе не отдавал статику?

Ответить | Правка | Наверх | Cообщить модератору

3. "Выпуск сервера приложений NGINX Unit 1.11.0" +10 +/–

Сообщение от Аноним (3), 20-Сен-19, 08:58

NGINX и NGINX Unit это совершенно разные вещи.

Ответить | Правка | Наверх | Cообщить модератору

87. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от zo0M (ok), 22-Сен-19, 08:23

Nginx отдавал, Nginx Unit нет

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

22. "Выпуск сервера приложений NGINX Unit 1.11.0" –1 +/–

Сообщение от Aytishnik.com (ok), 20-Сен-19, 10:58

Молодец Игорь Сысоев, теперь спокойно работает, главное вовремя понять, когда надо уезжать.

Ответить | Правка | Наверх | Cообщить модератору

25. "Выпуск сервера приложений NGINX Unit 1.11.0" +3 +/–

Сообщение от пох. (?), 20-Сен-19, 11:38

главное вовремя понять, куда.
А "когда" наступает примерно как можешь отдельно от мамкиной сиськи куда-то ездить.

Ответить | Правка | Наверх | Cообщить модератору

27. "Выпуск сервера приложений NGINX Unit 1.11.0" +2 +/–

Сообщение от Аноим (?), 20-Сен-19, 11:53

Не, ну чуть попозже, всё же)

Ответить | Правка | Наверх | Cообщить модератору

58. "Выпуск сервера приложений NGINX Unit 1.11.0" +1 +/–

Сообщение от test (??), 21-Сен-19, 00:36

До этого не спокойно работал? Поделитесь о чем речь.

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

98. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Lex (??), 25-Сен-19, 08:29

Надо полагать, примерно об этом:
11 марта 2019 года объявлено, что компания F5 Networks покупает NGINX. Сумма сделки оценивается приблизительно в 670 миллионов долларов

Ответить | Правка | Наверх | Cообщить модератору

23. "Выпуск сервера приложений NGINX Unit 1.11.0" +9 +/–

Сообщение от Аноним (23), 20-Сен-19, 11:01

Да что за бич опеннета с версткой?
маркеры маркированного списка плывут и на телефоне и на компе.
А еще недавно в новости забыли поставить закрывающий тег ссылке. 100% автор не осилил какой-нибудь markdown и пишут на голом html.
А чтоб не подумали что я ваще злой - скажу что это все же лучший ресурс из русскоязычных ;)

Ответить | Правка | Наверх | Cообщить модератору

28. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Аноним (28), 20-Сен-19, 12:10

> не осилил мрак даун
> где три с половиной возможности форматирования
> пишут на голом html
> полноценном языке разметки
уж лучше голый html

Ответить | Правка | Наверх | Cообщить модератору

31. "Выпуск сервера приложений NGINX Unit 1.11.0" –3 +/–

Сообщение от Аноним (31), 20-Сен-19, 13:08

они оверинженеры, там и бэкенд на страшной жабе!

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

35. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от iPahcae6 (?), 20-Сен-19, 14:24

Все хуже. То едут, то не едут
С десктопа едут под игровой виндой, не едут под рабочей линухой. С мобилы едут с Brave на Android и вроде не едут с Firefox(либо с чего-то еще более маргинального даже, не помню точно)

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

36. "Выпуск сервера приложений NGINX Unit 1.11.0" –1 +/–

Сообщение от Аноним (31), 20-Сен-19, 14:25

"Работают лучше Fronend специалисты индустрии"

Ответить | Правка | Наверх | Cообщить модератору

50. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от KonstantinB (ok), 20-Сен-19, 21:26

.chtext li {
    text-indent: 0;
}

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

62. "Выпуск сервера приложений NGINX Unit 1.11.0" +1 +/–

Сообщение от Maxim Chirkov (ok), 21-Сен-19, 10:19

Спасибо, поправил. Расстановка отступов в CSS на сайте не менялась лет 15 и сдвиг стал наблюдаться только в предпоследнем выпуске Chrome, после того как они добавили break-spaces и что-то поменяли в логике разрыва строк. Думал, что эту регрессию устранят в новом выпуске, но она так и остаётся. Интересно, что проявляется не для всех li, а только выборочно и, как правило, единично. Причины, по каким съезжает, а по каким нет, точно я не уловил, заметил лишь, что если следом идёт pre, как в этой новости, то текст смещается.

Ответить | Правка | Наверх | Cообщить модератору

66. "Выпуск сервера приложений NGINX Unit 1.11.0" +1 +/–

Сообщение от KonstantinB (ok), 21-Сен-19, 16:55

Да, в предпоследнем хроме вообще дров наломали. На паре сайтов, которые я не трогал уже пару лет, поломалось всякое, от подобных мелочей до полного схлопывания до нулевой ширины некоторых div-ов при динамической работе с DOM. Костыли везде придумал, но хром с его монополией явно начинает превращаться в очередной IE.

Ответить | Правка | Наверх | Cообщить модератору

93. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Аноним (31), 22-Сен-19, 09:51

Ты придумал Reset CSS, который используют все Frontend разработчики. normalize.css чуть иной.

Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

94. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Аноним (31), 22-Сен-19, 09:54

https://pastebin.com/r7CN7kve

Ответить | Правка | Наверх | Cообщить модератору

24. "Выпуск сервера приложений NGINX Unit 1.11.0" –4 +/–

Сообщение от пох. (?), 20-Сен-19, 11:37

интересно, на открытую версию nginx-не-юнит окончательно теперь будет положен $@й, или он на ней уже давным-давно лежит?

Ответить | Правка | Наверх | Cообщить модератору

26. "Выпуск сервера приложений NGINX Unit 1.11.0" +4 +/–

Сообщение от kiwinix (?), 20-Сен-19, 11:53

Вообще есть повод для таких догадок?
Мое ИМХО - nginx просто в идеальном и стабильном состоянии. Вообще никаких нареканий у меня нет

Ответить | Правка | Наверх | Cообщить модератору

37. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Аноним (31), 20-Сен-19, 14:27

GZIP нельзя отключить для html контента при HTTPS.
BREACH Attack!

Ответить | Правка | Наверх | Cообщить модератору

56. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от пох. (?), 20-Сен-19, 22:52

> Вообще есть повод для таких догадок?
не-опоздание родиться за повод считается?
Я прекрасно помню как он развивался до версии 1., и что с ним случилось после.
> Мое ИМХО - nginx просто в идеальном и стабильном состоянии.
"а на кладбище - все спокойненько!"

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

33. "Выпуск сервера приложений NGINX Unit 1.11.0" +10 +/–

Сообщение от Valentin V. Bartenev (?), 20-Сен-19, 13:45

Без паники. Над Unit и nginx работают две независимые команды. Причем на данный момент команда nginx даже больше. Фактически из бывших разработчиков nginx над Unit-ом трудятся только Игорь и я. Но Игорь и так не работал над nginx ещё с 2012, а я с 2017, что не мешает nginx-у продолжать активно развиваться последние годы.
Это две разные идеологии построения веб-сервера и мы не собираемся никого насильно пересаживать с одного на другое. Какая окажется доминирующей - время покажет. Я верю в Unit.

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

38. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Аноним (31), 20-Сен-19, 14:30

> Но Игорь и так не работал над nginx ещё с 2012, а я с 2017, что не мешает nginx-у продолжать активно развиваться последние годы.
Теперь понятно почему в NGINX больше не производиться работа над доработками.
trac.nginx служит как bash.org.

Ответить | Правка | Наверх | Cообщить модератору

40. "Выпуск сервера приложений NGINX Unit 1.11.0" +1 +/–

Сообщение от Valentin V. Bartenev (?), 20-Сен-19, 15:29

А о каких конкретно доработках идет речь? Множество доработок происходит регулярно. Количество реализуемых фич с момента создания компании возросло в разы, но в 10 раз увеличилось и количество пользователей.
По trac-у очень сложно судить о востребованности той или иной функциональности. Мы собираем информацию из множества разных источников.

Ответить | Правка | Наверх | Cообщить модератору

42. "Выпуск сервера приложений NGINX Unit 1.11.0" –1 +/–

Сообщение от Аноним (42), 20-Сен-19, 15:50

1. https://trac.nginx.org/nginx/ticket/1083
2. https://trac.nginx.org/nginx/ticket/1388
3. HPACK Dynamic Table Size in HTTP/2
   https://http2.github.io/http2-spec/compression.html#dynamic....
4. Accept-Encoding
   The "identity" content-coding is always acceptable, unless
   specifically refused because the Accept-Encoding field includes
   "identity;q=0", or because the field includes "*;q=0" and does
   not explicitly include the "identity" content-coding. If the
   Accept-Encoding field-value is empty, then only the "identity"
   encoding is acceptable.
5. HTTP/2 prioritization is intermittent and often ineffective
   https://trac.nginx.org/nginx/ticket/1763
6. AIO kernel feature io_uring pool Linux kernel 5.1+
Продолжать?

Ответить | Правка | Наверх | Cообщить модератору

45. "Выпуск сервера приложений NGINX Unit 1.11.0" +8 +/–

Сообщение от Valentin V. Bartenev (?), 20-Сен-19, 18:00

1. По многим реализуемым фичам поступают десятки запросов в месяц, а тут 1 человек тикет создал и 1 человек в нем отметился. Итого целых два человека за три года.
И не понятно, что мешает выключить gzip для проксируемых запросов. И это решение человек сам в том же тикете обнаружил. Вообще выключать компрессию для динамических HTML ответов - идея так себе. Тогда компрессия и не особо нужна, статика браузером будет кэшироваться и для нее есть gzip_static.
Если у вас злоумышленник может извне свободно контролировать содержимое ответа сервера конкретному пользователю, то у вас проблемы по умолчанию. С компрессией или без.
2. Для CF было толково в рассылке разобрано, почему это нормально не работает в реальных сетях, но они очень любят пиарить себя любимых.
3. Было бы конечно не лишним. Но не всегда и не для всех. При достаточно смешной экономии на заголовках, получаем существенное увеличение расхода памяти на каждое соединение. HTTP/2 сам по себе и так довольно затратный протокол, сплошной вектор для DoS-атак, а тут ещё дополнительные накладные расходы возникнут.
4. Ни одного запроса про это вспомнить не могу. Впрочем я уже не слежу так активно, так что не могу прокомменитровать никак.
5. Максим в тикете дал ответ. Проблемы HTTP/2 более-менее решаются с помощью HTTP/3, а остальное всё полумеры и различные хаки, ещё больше усложняющие и без того переусложненный протокол. Безусловно есть также и поле для улучшения в nginx в этом месте, но это не значит, что нужно все ресурсы тратить на игры в протокол от одной всем известной компании.
6. Для начала необходимо протестировать и измерить, есть ли какой-то выигрыш для паттерна использования nginx-а и стоит ли этот выигрыш тех возможных проблем и усложнений, с которыми предстоит иметь дело. Кроме того, на 5.1+ сейчас хорошо если хотя бы 1% установок nginx наберется, но скорее всего и того меньше.
Это исключительно мой взгляд со стороны, поскольку непосредственно над nginx уже больше двух лет не работаю и никаких решений не принимаю. Крайне наивно пологать, что вот мы там в nginx такие сидим вредные и не хотим реализовывать те или иные фичи на радость пользователям. Все заняты делом и работают над задачами, которые формируются на основании комплексного анализа множества факторов, огромных объемов информации. Мы варимся в этом котле по меньшей мере пять дней в неделю на протяжении многих лет. Каждый день занимаемся этими вопросами. Это наша ежедневная работа, труд множества людей. Просто изнутри крупнейшего вендора серверного ПО с миллионами пользователей, ситуация и картина мира выглядит несколько иначе, нежели со стороны отдельных энтузиастов.

Ответить | Правка | Наверх | Cообщить модератору

107. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Аноним другой (?), 25-Мрт-20, 23:58

Валентин, что сейчас думаете про io_uring?

Ответить | Правка | Наверх | Cообщить модератору

43. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Аноним (42), 20-Сен-19, 15:54

cache-aware learning server-push https://h2o.examp1e.net/configure/http2_directives.html#http...

Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

48. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Ilya Indigo (ok), 20-Сен-19, 19:15

Добрый день, Валентин!
У меня давно уже назрел вопрос.
На текущий момент у меня веб сервер на Apache + FastCGI + php-mod_fastcgi
Я уже давно хочу мигрировать или на nginx + php-fpm или на nginx unit (он наконец-то научился отдавать статику), но пока всё руки не доходят.
На Apache, в принципе, меня всё устраивает за исключением отсутствия 0-RTT и так и не начавшуюся работу над HTTP/3.
Из необходимых возможностей мне нужно чтение .htaccess и .user.ini файлов.
С точки зрения производительности и удобства на что лучше мигрировать и какие достоинства и недостатки у этих решений, а также какие трудности и особенности миграции с Apache для каждого из них.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

51. "Выпуск сервера приложений NGINX Unit 1.11.0" +2 +/–

Сообщение от KonstantinB (ok), 20-Сен-19, 21:31

Я не Валентин, но - если вам нужен .htaccess (действительно нужен, а не банально лень сконвертировать конфиги), то вам от Апача никуда не деться, просто по определению.
Посчитайте число системных вызовов, которое надо выполнить на каждый запрос для реализации аналога .htaccess, заплачьте и забудьте.

Ответить | Правка | Наверх | Cообщить модератору

54. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от пох. (?), 20-Сен-19, 22:47

> Посчитайте число системных вызовов, которое надо выполнить на каждый запрос для реализации
> аналога .htaccess
вычтите те, что нужны для, собственно, отдачи файла на том же уровне - и удивитесь.

Ответить | Правка | Наверх | Cообщить модератору

68. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от KonstantinB (ok), 21-Сен-19, 17:11

Я ничего про отдачу и не говорил. Считаем сисколлы только на чтение конфигурации.

Ответить | Правка | Наверх | Cообщить модератору

79. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от пох. (?), 21-Сен-19, 23:17

> Я ничего про отдачу и не говорил. Считаем сисколлы только на чтение конфигурации.
open/read/close, чего там считать-то? Ну может stat еще, вдруг нам его читать неположено.
И то при наличии этого самого файла, а если его там нет - а чаще всего его там нет - один stat(), который еще и кэшировать можно, в принципе.
От пробегания по всему дереву, проверки симлинков (которые не всегда надо читать) и т д - может десятая часть.
Оно на внутреннюю nginx'овую механику не ложится, с его прекомпиляцией и внутренним представлением, вычисляемым один раз, но вот ее-то как раз всю взорвать до основания, и залить слоем бетона в три с половиной метра, чтоб не фонило - никто бы и не плакал. Но нет, мы будем вечно таскать fastcgi_param и fastcgi.conf для совместимости с незнамочем.
(вот те кто понял последнюю фразу - согласятся и с предыдущей. Это ж надо было ТАКОЙ дремучий п-ц породить! Даже systemd, не к ночи, тьфу-тьфу-тьфу, умеет _отменять_ предыдущие multivalue.)

Ответить | Правка | Наверх | Cообщить модератору

81. "Выпуск сервера приложений NGINX Unit 1.11.0" +1 +/–

Сообщение от Valentin V. Bartenev (?), 22-Сен-19, 00:53

А сами сисколы там и есть самое затратное, особенно если речь идет о небольших файлах, лежащих в кэше страниц, что чаще всего. Даже если sendfile() не использовать, то копирование небольших объемов в памяти на современных системах не такая уж тяжелая операция.
Если это не файлопомойка и не медиа-контент, то чаще всего сервер отдает небольшие странички, скрипты и стили. open(), stat(), send(заголовки), sendfile(). При этом всё сразу помещается в сокетный буфер.
По дополнительному stat() на каждую директорию по пути - вполне себе добавят лишних задержек, что скажется на конечных цифрах RPS и прочего. Вряд ли сильно, но вполне измеримо.

Ответить | Правка | Наверх | Cообщить модератору

99. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от пох. (?), 25-Сен-19, 16:22

> sendfile() не использовать
учитывая поголовное сочетание zfs с https - его как-то уже особо и негде/незачем становится пользовать.
> Если это не файлопомойка и не медиа-контент,
то непонятно, что это вообще нынче такое.
И небольшие-небольшие: bootstrap.min.css - 150килобайт. (gzipped, полагаю ;-) shitfont.otf не отстает - 140
что это мы такое загрузили сейчас? А-а-а, форму из двух полей login/password и кнопкой submit. Не буду нажимать, хочу сохранить некоторые иллюзии.
> По дополнительному stat() на каждую директорию по пути - вполне себе добавят лишних задержек,
> что скажется на конечных цифрах RPS и прочего. Вряд ли сильно, но вполне измеримо.
ну вот и мне кажется - что измеримо, да, но никого особо не огорчит. А фанаты измеризмов и наносекундных замеров - всегда могут отключить, как, собственно, и в апаче это делают.
Но с существующей конфигурацией это просто вот никак не живет. Там что ни тронь - начинает шевелиться на другом конце тарелки.

Ответить | Правка | Наверх | Cообщить модератору

59. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Ilya Indigo (ok), 21-Сен-19, 00:43

Он мне нужен для безопасности и маршрутизации.
Сомневаюсь что подобное можно реализовать в настройках виртуального хоста.

RewriteEngine On
RewriteBase /
RewriteCond %{THE_REQUEST} \s/index\.php
RewriteRule ^index\.php/?$ /en/error
RedirectMatch 403 .*\/\..*
ErrorDocument 403 /en/error
ErrorDocument 404 /en/error
RewriteRule ^([a-z]{2})/?$ index.php?lang=$1 [END]
RewriteCond %{QUERY_STRING} ^token=([\w-]{20})&PayerID=([\w-]{13})$
RewriteRule ^([a-z]{2})/(payment)/?$ index.php?lang=$1&view=$2&token=%1&PayerID=%2 [END]
RewriteRule ^([a-z]{2})/([\w-']+)/?$ index.php?lang=$1&view=$2 [END]
RewriteRule ^([a-z]{2})/([\w-']+)/([\d-]+)\.html/?$ index.php?lang=$1&view=$2&id=$3 [END]
RewriteRule ^([a-z]{2})/([\w-']+)/([\w-']+)/([\d-]+)\.html/?$ index.php?lang=$1&view=$2&tab=$3&id=$4 [END]
Да и, как минимум, nginx точно .htaccess читает, синтаксис другой, но главное читает.
По поводу системных запросов я их не считал, но снижение производительности за счёт этого всё равно ничтожно мала на фоне всего остального.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

63. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Sw00p aka Jerom (?), 21-Сен-19, 12:21

я вот одного не пойму, чем ссылка index.php?lang=$1&view=$2&token=%1&PayerID=%2 такого вида не устраивает?
зачем обязательно нужно её представлять в виде ([a-z]{2})/(payment)/ (якобы ЧПУ), зачем? вам нужно эти ссылки индексировать в гуглях?
пс: западло уже в урле иметь ?lang=$1&view=$2&token=%1&PayerID=%2 и не дай Бог \.php, нет лучше пихнуть туда \.html - зачем ??????????

Ответить | Правка | Наверх | Cообщить модератору

65. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Ilya Indigo (ok), 21-Сен-19, 14:03

1 Тем что она длинная и не понятная пользователю. (Не ЧПУ)
2 А также тем, что она позволяет принять любые GET-параметры от пользователя, а не только те, которые я разрешил.
3 Эта ссылка сразу палит, что сайт написан на PHP.
Мне нужно чтобы боты и пользователи думали что работают с чистым html-сайтом (ЧПУ).
> пс: западло уже в урле иметь ?lang=$1&view=$2&token=%1&PayerID=%2 и не дай Бог \.php,
> нет лучше пихнуть туда \.html - зачем ??????????
Это строчка работы с PayPal через nvp. PayPal не позволяют сформировать ответ в нужном для меня виде и лепит GET-параметры, которые в моём ЧПУ идут лесом, поэтому эта строка делает исключение для PayPal если получена строка нужного вида.
> зачем ??????????
Эстетика + полный контроль над сайтом (обращаться и передавать можно только то, что я позволил, если что-то не дозволенное то отсылается на /en/error).

Ответить | Правка | Наверх | Cообщить модератору

67. "Выпуск сервера приложений NGINX Unit 1.11.0" +1 +/–

Сообщение от KonstantinB (ok), 21-Сен-19, 17:07

Подобные реврайты прекрасно делается через location с регулярками и динамическое построение QUERY_STRING.
Я обычно делаю пары conf.d/my_server.name.conf и conf.d/my_server_name.fcgi.
Скажем, для 3й с конца строки будет примерно так:
location ~ ^([a-z]{2})/([\w-']+)/?$ {
    set $_script_name "/index.php";
    set $_qs "lang=$1&view=$2";
    include /path/to/my_server_name.fcgi;
}
А в my_server_name.fcgi что-то такое:
fastcgi_pass что-там-у-вас;
fastcgi_param  SCRIPT_FILENAME  $document_root$_script_name;
fastcgi_param  QUERY_STRING       $_qs;
(...остальное стандартное из fastcgi_params)
Хотя я бы просто направил все "как есть" на index.php и написал это все на php - это было бы намного проще.
Что касается \s/index\.php и RedirectMatch 403 .*\/\..*, это можно просто убрать, с php-fpm такое не прокатит.

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

71. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Ilya Indigo (ok), 21-Сен-19, 18:16

Благодарю Вас за ответ! :-)
Не знал что так вообще возможно.
> Хотя я бы просто направил все "как есть" на index.php и написал
> это все на php - это было бы намного проще.
Ну да это гораздо проще будет сделать.
> Что касается \s/index\.php и RedirectMatch 403 .*\/\..*, это можно просто убрать, с
> php-fpm такое не прокатит.
Вы правильно поняли мой замысел?
\s/index\.php этим я запрещаю напрямую обращаться к index.php  сервер делает вид, как-будто файла нет. (403 у меня всё равно вызывает то же что и 404 и отдают 404 Not a found)
А RedirectMatch 403 .*\/\..* я делаю тоже самое для запросов к скрытым файлам и директориям.
Непроканает в смысле нельзя это будет запретить в php-fpm?

Ответить | Правка | Наверх | Cообщить модератору

72. "Выпуск сервера приложений NGINX Unit 1.11.0" +1 +/–

Сообщение от KonstantinB (ok), 21-Сен-19, 22:08

При такой конфигурации - когда SCRIPT_FILENAME указывается в явном виде - достаточно в явном виде перечислить все разрешенные location-ы, а в конце сделать в конце что-то вроде
location ~\.php$ {
    return 404;
}
А еще лучше вообще не класть php-скрипты в document root. Сделать root для статики поддиректорией, а все php-скрипты разместить выше.

Ответить | Правка | Наверх | Cообщить модератору

73. "Выпуск сервера приложений NGINX Unit 1.11.0" +1 +/–

Сообщение от KonstantinB (ok), 21-Сен-19, 22:09

Вообще то, что в nginx все fastcgi-параметры указываются в явном виде, позволяет куда бОльшую гибкость конфигурации, чем apache. Надо только 1 раз разобраться.

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

76. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Ilya Indigo (ok), 21-Сен-19, 22:19

> Вообще то, что в nginx все fastcgi-параметры указываются в явном виде, позволяет
> куда бОльшую гибкость конфигурации, чем apache. Надо только 1 раз разобраться.
Ёмаё, так это конфигурация nginx...
А я смотрю на это https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html и недуомеваю откуда Вы это взяли, думал это или в php-fpm настаивается или в nginx.
Понятно, значит в Apache всё равно для ЧПУ mod_rewrite нужен, а вот в nginx можно нативными средствами обойтись, которые Вы ранее показали.

Ответить | Правка | Наверх | Cообщить модератору

83. "Выпуск сервера приложений NGINX Unit 1.11.0" +1 +/–

Сообщение от KonstantinB (ok), 22-Сен-19, 01:42

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

Ответить | Правка | Наверх | Cообщить модератору

95. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Ilya Indigo (ok), 22-Сен-19, 10:56

Благодарю, Вас!
Я и не знал что так можно было думал что mod_rewrite работает только через .htaccess файлы. :-)
В общем сделал максимально просто и совместимо, в <virtualhost><Directory> заменил
AllowOverride All
на
AllowOverride None
IncludeOptional '/path/to/document_root/.htaccess'
.htaccess файлы я всё равно продолжаю использовать, но теперь их загружает 1 раз сам сервер, если я правильно всё понял и сделал. :-)
А также, видимо, по этой же самой причине стоит отключить чтение .user.ini файлов или загружать их также из виртуального хоста или вообще отказаться от них в пользу ручной установки ini_set() ?

Ответить | Правка | Наверх | Cообщить модератору

74. "Выпуск сервера приложений NGINX Unit 1.11.0" +1 +/–

Сообщение от KonstantinB (ok), 21-Сен-19, 22:15

Еще очень полезно отключить включенный по умолчанию fix_pathinfo в php.ini:
cgi.fix_pathinfo=0
fix_pathinfo - это такой костыль для кривых веб-серверов, который подразумевает "битые" PATH* и "угадывает" что имелось ввиду методом перебора вариантов. В случае cgi.fix_pathinfo=0 полным путем к php-скрипту считается содержимое (нестандартного) fastcgi-параметра SCRIPT_FILENAME и ничего кроме.
Оба поведения неидеальны, конечно. Но мой патч для fpm, который удаляет эту настройку и делает два варианта "разумного" поведения (совместимость с де-факто стандартным для PHP SCRIPT_FILENAME и полная совместимость со стандартом CGI) висит без движения уже лет 10. Ну и фиг с ним, SCRIPT_FILENAME ничем, кроме нестандартности, и не плох.

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

77. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Ilya Indigo (ok), 21-Сен-19, 22:23

> Еще очень полезно отключить включенный по умолчанию fix_pathinfo в php.ini:
> cgi.fix_pathinfo=0
Благодарю за пояснение. Согласен подобные костыли - зло!
https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidf...
В Apache mod_fcgid он отключен по умолчанию.

Ответить | Правка | Наверх | Cообщить модератору

64. "Выпуск сервера приложений NGINX Unit 1.11.0" +3 +/–

Сообщение от Valentin V. Bartenev (?), 21-Сен-19, 13:29

Добрый день.
А для чего у вас php c Apache через FastCGI работает вместо mod_php? Есть конечно кейсы в которых даже с Apache такой вариант необходим, но FastCGI имеет свои накладные расходы и тут не добавляет эффективности.
Если так сильно нужен .htaccess, то я бы рассмотрел связку nginx + Apache c mod_php. Но так ли необходим .htaccess? Даже просто отказ от него с сохранением Apache даст заметный прирост производительности. Дело в том, что для его работы приходится на каждый запрос сканировать все директории по пути на предмет наличия в них .htaccess файлов, даже если их нет. Это порождает огромное количество дополнительных системных вызовов на каждый запрос и, как следствие, сильно увеличивает накладные расходы. Последующий их парсинг и интерпретация - это пустяки на этом фоне. Да и вообще хранение конфигурации внутри директории, которая раздается в интернет - идея сомнительная.
Но, допустим, что по какой-то причине отказаться от .htaccess вы не можете. Тогда переход на mod_php уменьшил бы накладные расходы на обработку PHP в Apache, а nginx впереди освободил бы его от взаимодействия с медленной сетью и раздачи статики.
Идея тут такая. Поскольку nginx работает с соединениями асинхронно и не блокируясь, то вся обработка происходит в рамках небольшого количества процессов, каждый из которых способен обрабатывать сотни тысяч соединений с минимумом накладных расходов. Дело не сколько в скорости, сколько в масштабируемости при росте нагрузки. Процессы с интерпретатором php дорогие и каждый из них способен обрабатывать только один запрос в момент времени от начала и до конца. Иметь сотни тысяч таких процессов будет очень накладно, как по памяти, так и с точки зрения расходов на переключение контекстов. Поэтому их количество обычно небольшое и задача nginx сделать так, чтобы они работали максимально эффективно, тратя время только на интерпретацию кода, а не сетевые взаимодействия. Поэтому nginx ставят рядом на одну машину. Он работает с медленными соединениями клиентов (а они все медленные по сравнению с локальными процессами) не тратя много ресурсов на обработку. Как только он получил полностью запрос, то максимально быстро передает его в Apache или php-fpm, тот его обрабатывает, и nginx дальше максимально быстро забирает ответ, освобождая процесс c PHP для следующего запроса. Кроме того, все запросы к статике также обрабатываются внутри nginx и не занимая дорогостоящих процессов с php.
У Apache есть event MPM и некоторые заявляют, что это то же самое, что nginx. Но это лукавство, т.к. событийно там обрабатываются только keep-alive соединения в момент простоя. Такие соединения больше не занимают отдельных потоков, но как только начинается обработка запроса, то тут же Apache деградирует до модели с одним потоком на каждый запрос. Да, простаивающие соединения в Apache теперь примерно такие же дешевые, как в nginx, но не более того. Под нагрузкой всё это также схлопывается.
TLS 0-RTT nginx поддерживает, см. директиву конфигурации ssl_early_data (https://nginx.org/r/ssl_early_data/ru).
HTTP/3 запланирован в 1.17.x и точно появится в течение ближайшего года, может быть даже быстрее, полгода.
Если от .htaccess всё же можно отказаться, то замена Apache/mod-php на php-fpm в связке с nginx даст более простой и специализированный инструмент, проще конфигурацию PHP на мой взгляд. Но если в Apache повыключать всё лишнее, особенно .htaccess, то какой-то заметного превосходства по производительности у nginx+php-fpm перед nginx+apache/mod_php не будет. Тут скорее вопрос удобства и простоты.
Наиболее удобным и оптимальным со всех стороны решением мог бы стать Unit. Он делает то, что делает nginx, эффективно работает с соединениями и при этом имеет минимум накладных расходов на обмен данными с процессами интерпретатора. Но, к сожалению, 0-RTT в нем пока ещё нет, как и HTTP/3. И вообще конфигурация TLS в этом месте на данный момент убогая. В результате его пока что также придется использовать за nginx. И часть преимуществ из-за этого теряется. Тем не менее, даже в таком варианте можно начинать пробовать с целью познакомиться, поэкспериментировать и возможно в будущем отказаться от nginx, оставив один лишь Unit. Из плюшек nginx + Unit перед nginx + php-fpm, которые можно получить сразу - это динамическая конфигурация. В частности будет возможность изменять параметры php.ini и управлять процессами без перезагрузки всего Unit-а и потери запросов. Чтобы изменения в конфигурации php-fpm вступили в силу, его нужно полностью перезагрузить, даже если изменения касаются всего лишь одного пула. Это может быть  очень накладно, если пулов много, и создает момент времени, когда php-fpm будет не способен принимать соединения. Кроме того, если вы хотите одновременно использовать несколько версий интерпретатора php, то вам необходимо несколько отдельных php-fpm и раскидывать с помощью nginx между ними запросы. Unit может одновременно работать с несколькими разными версиями php, можно раскидать по ним разные проекты, либо протестировать то же приложение, но с другой версией, а затем без потерь переключить основной поток запросов на новую версию. Вариантов тут много, архитектура Unit-а позволяет любые комбинации и множество паттернов использования, кому как нравится. Кроме того, в новой версии у нас появилась изоляция за счет Linux namespaces и она дальше будет прогрессировать, обрастая новыми возможностями. Можно будет какой-нибудь вордпресс заизолировать, как в контейнере, но без необходимости связываться с Docker-ом. Ничего не имею против последнего, но многие очень приветствуют такую возможность в Unit-е.

Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

69. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Ilya Indigo (ok), 21-Сен-19, 17:16

Благодарю Вас, Валентин, за подробный и развёрнутый ответ! :-)
Вы меня серьёзно озадачили и заставили пересмотреть некоторые мои знания, впрочем этого я и хотел. :-)
> А для чего у вас php c Apache через FastCGI работает вместо mod_php? Есть конечно кейсы в которых даже с Apache такой вариант необходим, но FastCGI имеет свои накладные расходы и тут не добавляет эффективности.
Мне казалось что mod_php это удел конфигураций всяких денверов на локалхостах, которые не могут осилить нормальную конфигурацию сервера.
В mod_php:
- можно использовать только prefork, нельзя использовать event, что мне тогда казалось снижает производительность.
- интерпритатор задействован даже когда отдаётся статика.
- на каждый запрос создаётся свой процесс что приводит к повышенному расходу ОЗУ
- Ошибка в одном PHP-скрипте может положить Apache со всеми виртуальными хостами
- нельзя использовать разные версии PHP для разных виртуальных хостов.
- не читаются .user.ini файлы https://www.php.net/manual/ru/configuration.file.per-user.php
В FastCGI этого всего нет, мне тогда он казался однозначно лучше, хотя сейчас погуглив эту тему, пишут что при высокой нагрузке mod_php показывает большую производительность.
Почему большую, мне не понято. Читая Ваш ответ про MPM event, он должен быть. как минимум, не хуже.
> Но так ли необходим .htaccess?
> Даже просто отказ от него с сохранением Apache даст заметный прирост производительности.
Вот это для меня было новостью.
Я и не предполагал что mod_rewrite так сильно влияет на производительность Apache.
Я его использую для маршрутизации, тут https://www.opennet.ru/openforum/vsluhforumID3/118512.html#59 привёл пример его использования.
Пол дня думал над тем, могу ли я от него отказаться.
Если кратко, то в DOCUMENT_ROOT у меня есть только 2 объекта к которым можно обращаться
это директория static и файл index.php
Если я откажусь от .htaccess мне нужно чтобы на стороне сервера я мог прописать нечто такое.
- Если URI начинается на /static/ (/static/img/favicon.png) то сервер отдавал статику, даже не пытаясь задействовать php (короче чтобы он не вмешивался и делала что и обычно).
- Но если запрос НЕ содержит /static/ (/ru/user/1.html) то мне нужно чтобы сервер НЕ изменяя URL (пользователь должен всегда оставаться на том URL с которого он пришёл, если я сам в PHP/JS  не решу иначе) вместо попытки обращения к директориям ru и user и поиска там файла 1.html сразу перенаправил запрос на index.php?get=/ru/user/1.html а на стороне PHP я уже сам смогу определить что делать дальше с этим URI из $_GET['get']
Такое можно прописать на Apache или nginx или nginx unit?
Ну или какие-нибудь иные соображения как можно эффективно организовать ЧПУ маршрутизацию без mod_rewrite?

Ответить | Правка | Наверх | Cообщить модератору

75. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от KonstantinB (ok), 21-Сен-19, 22:19

mod_php нормально работает только с prefork MPM. С event вообще не работает. С worker очень рискованно: php в принципе можно собрать с thread safety, но эта safety касается только Zend VM: все php-расширения - это врапперы вокруг библиотек, в которых с thread safety все не очень хорошо.

Ответить | Правка | Наверх | Cообщить модератору

78. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Ilya Indigo (ok), 21-Сен-19, 22:29

> mod_php нормально работает только с prefork MPM. С event вообще не работает.
> С worker очень рискованно: php в принципе можно собрать с thread
> safety, но эта safety касается только Zend VM: все php-расширения -
> это врапперы вокруг библиотек, в которых с thread safety все не
> очень хорошо.
Это я зная, просто не понимаю почему пишут что на высоких нагрузках mod_php с prefork работает производительнее чем mod_fcgid + php-fastcgi с event?

Ответить | Правка | Наверх | Cообщить модератору

82. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от KonstantinB (ok), 22-Сен-19, 01:41

Я бы не сказал, что производительнее. Примерно одинаково.

Ответить | Правка | Наверх | Cообщить модератору

80. "Выпуск сервера приложений NGINX Unit 1.11.0" +1 +/–

Сообщение от Valentin V. Bartenev (?), 22-Сен-19, 00:23

> В mod_php:
> - можно использовать только prefork, нельзя использовать event, что мне тогда казалось снижает производительность.
> - интерпритатор задействован даже когда отдаётся статика.
Я вообще не знаток Apache, но полагаю это всё же некое преувеличение. Вряд ли там задействуется интерпретатор PHP (для чего?) в отдаче статики. Скорее речь идет о том, что он просто всегда загружен в память процесса, даже когда тот просто статику отдает, но при этом не задействуется.
> - на каждый запрос создаётся свой процесс что приводит к повышенному расходу ОЗУ
> - Ошибка в одном PHP-скрипте может положить Apache со всеми виртуальными хостами
Тут опять же логика подсказывает, что в режиме prefork должен падать только тот процесс, что обрабатывает конкретный запрос, приводящий к ошибке, а остальные при этом продолжат обрабатываться.
> В FastCGI этого всего нет, мне тогда он казался однозначно лучше, хотя сейчас погуглив эту тему, пишут что при высокой нагрузке mod_php показывает большую производительность.
> Почему большую, мне не понято. Читая Ваш ответ про MPM event, он должен быть. как минимум, не хуже.
Если говорить именно о динамическом контенте, то добавляя в обработку FastCGI - просто добавляются ещё накладные расходы на передачу данных по этому протоколу.
Что происходит в этом случае:
Один из рабочих потоков Apache вычитывает из сокета соединения запрос, затем парсит его, обрабатывает согласно конфигурации, затем преобразовывает в формат сообщений по протоколу FastCGI и далее записывает запрос в сокет, где на другом конце этого сокета уже запрос в формате FastCGI опять читается из сокета, парсится и передается интерпретатору PHP. Тот формирует ответ и далее всю по цепочке происходит в обратной последовательности с преобразованиями форматов, дополнительными записью и чтением из сокета.
Когда у вас mod_php в prefork работает, то рабочий процесс читает запрос из сокета, парсит его, обрабатывает согласно конфигурации и передает его интерпретатору PHP. Накладных расходов на FastCGI в виде системных вызовов, копирования данных и преобразования форматов тут нет.
Фактически ваша конструкция event MPM и PHP по FastCGI похожа на nginx + php-fpm, с той лишь разницей, что nginx будет эффективнее.

>> Но так ли необходим .htaccess?
>> Даже просто отказ от него с сохранением Apache даст заметный прирост производительности.
>
> Вот это для меня было новостью.
> Я и не предполагал что mod_rewrite так сильно влияет на производительность Apache.
> Я его использую для маршрутизации, тут https://www.opennet.ru/openforum/vsluhforumID3/118512.html#59 привёл пример его использования.
mod_rewrite и .htaccess - сущности ортогональные. Он тут ни при чем. На производительность влияет включение .htaccess файлов, даже если их не будет в каталогах или они будут пустыми. Правила mod_rewrite можно писать и в основной конфигурационный файл Apache, благополучно отключив при этом .htaccess. На производительность mod_rewrite не сильно должен влиять.

> Если кратко, то в DOCUMENT_ROOT у меня есть только 2 объекта к которым можно обращаться
> это директория static и файл index.php
> Если я откажусь от .htaccess мне нужно чтобы на стороне сервера я мог прописать нечто такое.
> - Если URI начинается на /static/ (/static/img/favicon.png) то сервер отдавал статику, даже не пытаясь задействовать php (короче чтобы он не вмешивался и делала что и обычно).
> - Но если запрос НЕ содержит /static/ (/ru/user/1.html) то мне нужно чтобы сервер НЕ изменяя URL (пользователь должен всегда оставаться на том URL с которого он пришёл, если я сам в PHP/JS  не решу иначе) вместо попытки обращения к директориям ru и user и поиска там файла 1.html сразу перенаправил запрос на index.php?get=/ru/user/1.html а на стороне PHP я уже сам смогу определить что делать дальше с этим URI из $_GET['get']
>
> Такое можно прописать на Apache или nginx или nginx unit?
> Ну или какие-нибудь иные соображения как можно эффективно организовать ЧПУ маршрутизацию без mod_rewrite?
Можно те же правила mod_rewrite прописать в основном конфиге Apache.
В целом, это достаточно тривиальная конфигурация. В nginx можно делать разными способами. Достаточно настроить пару location'ов (https://nginx.org/r/location/ru) - один для статики, а другой для FastCGI проксирования. А далее, или воспользоваться правилами его собственного модуля rewrite (https://nginx.org/r/rewrite/ru), или, что проще и "прямее", грамотно прописать соответствующие FastCGI переменные. В nginx они просто задаются с помощью директив fastcgi_param (https://nginx.org/r/fastcgi_param/ru), в которых можно указывать комбинации строк и переменных запроса (https://nginx.org/ru/docs/varindex.html). По умолчанию к nginx обычно прилагается файл конфигурации со стандартными значениями: https://hg.nginx.org/nginx/file/tip/conf/fastcgi.conf
В Unit сейчас можно гибко фильтровать запросы и раскидывать их по приложениям или директориям со статикой. Делается это правилами внутреннего роутинга, которые достаточно просты для восприятия: https://unit.nginx.org/configuration/#routes
Что касается rewrite-подобной функциональности, то её пока как таковой нет, но у модуля PHP есть два режима работы:
1. Задана опция "script", содержащая путь к .php скрипту. В этом случае все запросы в приложение будут обрабатываться с помощью данного скрипта. URI запроса будет содержаться в переменной $_SERVER['REQUEST_URI'], просто запущен будет указанный вами в конфигурации скрипт, а не то что пришло в запросе.

2. Опция не "script" не задана. Тогда запускается тот скрипт, на который указывает URI запроса. Также если URI содержит так называемый компонент PATH_INFO (например /index.php/some/path), то Unit отрежет путь после .php (в данном случае "/some/path") и поместит его в $_SERVER['PATH_INFO'].

Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

96. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Ilya Indigo (ok), 22-Сен-19, 11:16

> mod_rewrite и .htaccess - сущности ортогональные...
> Можно те же правила mod_rewrite прописать в основном конфиге Apache.
Ё-маё... и снова Вы меня удивили. :-)
Я думал что mod_rewrite работает только через .htaccess файлы. :-)
В общем сделал максимально просто и совместимо, в <virtualhost><Directory> заменил
AllowOverride All
на
AllowOverride None
IncludeOptional '/path/to/document_root/.htaccess'
.htaccess файлы я всё равно продолжаю использовать, но теперь их загружает 1 раз сам сервер, если я правильно всё понял и сделал. :-)
Благодарю Вас снова за подробный и детальный ответ! :-)
На данный момент, всё же решил в скором времени мигрировать на nginx + php-fpm, по крайней мере пока Unit не научиться полноценно обходится без nginx, и его статическая реализация будет не хуже.
И вот ещё озадачивает один момент, почему статическую реализацию в unit просто нельзя перенести, как есть, из nginx?
Это обусловлено какими-то конструктивными особенностями unit-а что её в принципе не возможно в нём также хорошо реализовать?
Иными словами можно будет ожидать в будущем от статической составляющей unit что она будет не хуже чем в nginx или nginx всегда будет лучше обрабатывать статику?

Ответить | Правка | Наверх | Cообщить модератору

100. "Выпуск сервера приложений NGINX Unit 1.11.0" +1 +/–

Сообщение от Valentin V. Bartenev (?), 26-Сен-19, 14:03

> И вот ещё озадачивает один момент, почему статическую реализацию в unit просто нельзя перенести, как есть, из nginx?
Потому, что API и внутренние механизмы Unit-а достаточно существенно отличаются от nginx.  Многое сделано иначе: другая работа с буферами, конфигурацией, по-другому выстроена обработка соединений, активно используются очереди, вместо накручивания стека.
Не забывайте, что архитектура nginx закладывалась Игорем Сысоевым 16 лет назад с теми знаниями, тем опытом и теми возможностями, которые у него были на тот момент. С тех пор поменялось всё: интернет, протоколы, ядра операционных систем, железо, требования к серверам, ожидания пользователей и т.д. Unit от nginx взял только отдельные очень удачные и проверенные временем концепции, но многое было переработано, весь код был написан практически с нуля. Особенно подверглись переработке те механизмы, которые по опыту в итоге принесли в nginx огромное количество боли и мешают более эффективной реализации тех или иных возможностей. И таких больных мест не мало, учитывая, как всё изменилось с тех пор. Плюс сам Игорь и команда за долгие годы работы над nginx стали гораздо опытнее и поменяли свое мнение относительно некоторых решений.
> Это обусловлено какими-то конструктивными особенностями unit-а что её в принципе не возможно в нём также хорошо реализовать?
Напротив, благодаря новой архитектуре, в нем возможно реализовать отдачу статики ещё более эффективно, чем это сделано в nginx.
> Иными словами можно будет ожидать в будущем от статической составляющей unit что она будет не хуже чем в nginx или nginx всегда будет лучше обрабатывать статику?
Можно ожидать что она будет лучше, чем что-либо существующее.

Ответить | Правка | Наверх | Cообщить модератору

101. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Ilya Indigo (ok), 26-Сен-19, 14:20

Благодарю Вас! :-)

Ответить | Правка | Наверх | Cообщить модератору

102. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Ilya Indigo (ok), 16-Окт-19, 13:18

Добрый день, Валентин и все кто сейчас читает эту ветку!
Я наконец-то сегодня перевёл с Apache на nginx свои сервера, но мне снова понадобится Ваша помощь, так как некоторые моменты мне не ясны, а некоторые и вовсе не получаются.
0 При попытке регистрации на форуме https://forum.nginx.org мне постоянно пишут
Your registration request has been blocked because its suspected to come from a forum spammer!
Хотя я ни разу его до этого вообще не посещал его, так что продолжу общение здесь, в этой тёплой и ламповой, для меня, обстановке. :-)
1 С Вашего наставления я отказался от .htaccess и перевёл ЧПУ на Location-ы, но я не уверен оптимально ли я это сделал.
В apache у меня было коротко и ясно.

RewriteEngine On
RewriteBase /
RewriteCond %{THE_REQUEST} \s/index\.php
RewriteRule ^index\.php/?$ /en/error
RedirectMatch 403 .*\/\..*
ErrorDocument 403 /en/error
ErrorDocument 404 /en/error
RewriteRule ^([a-z]{2})/?$ index.php?lang=$1 [END]
#https://gricargo.com/ru/payment?token=EC-9HP89464U39537617&P...
RewriteCond %{QUERY_STRING} ^token=([\w-]{20})&PayerID=([\w-]{13})$
RewriteRule ^([a-z]{2})/(payment)/?$ index.php?lang=$1&view=$2&token=%1&PayerID=%2 [END]
RewriteRule ^([a-z]{2})/([\w-]+)/?$ index.php?lang=$1&view=$2 [END]
RewriteRule ^([a-z]{2})/([\w-]+)/([\d-]+)\.html/?$ index.php?lang=$1&view=$2&id=$3 [END]
RewriteRule ^([a-z]{2})/([\w-]+)/([\w-]+)/([\d-]+)\.html/?$ index.php?lang=$1&view=$2&tab=$3&id=$4 [END]
RewriteRule ^([a-z]{2})/([\w-]+)/([\w-]+)/?$ index.php?lang=$1&view=$2&tab=$3 [END]
RewriteRule ^([a-z]{2})/(api)/([\w\s-]+)={1,3}([\w\s-]+)={1,3}\.html/?$ index.php?lang=$1&view=$2&data=$3&iv=$4 [END]
Но в nginx это развернулось вот в такую простыню.

error_page 404 /en/error;
error_page 500 502 503 504 /50x.html;
location = /50x.html
{
    root /srv/www/htdocs;
}
location = /favicon.ico
{
    log_not_found off;
    access_log off;
}
location = /
{
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
location = /index.php
{
    return 404;
}
location ~ /\.
{
    return 404;
}
location /
{
    try_files $uri return 404;
}
location ~ ^/([a-z][a-z])/?$
{
    set $_query_string "lang=$1";
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $_query_string;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
#/ru/payment?token=EC-9HP89464U39537617&PayerID=T94MQ4XMUXCWG
location ~ ^/([a-z][a-z])/(payment)$
{
    set $_query_string "lang=$1&view=$2";
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $_query_string&$query_string;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
location ~ ^/([a-z][a-z])/([\w-]+)/?$
{
    set $_query_string "lang=$1&view=$2";
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $_query_string;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
location ~ ^/([a-z][a-z])/([\w-]+)/([\d-]+)\.html/?$
{
    set $_query_string "lang=$1&view=$2&id=$3";
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $_query_string;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
location ~ ^/([a-z][a-z])/([\w-]+)/([\w-]+)/([\d-]+)\.html/?$
{
    set $_query_string "lang=$1&view=$2&tab=$3&id=$4";
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $_query_string;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
location ~ ^/([a-z][a-z])/([\w-]+)/([\w-]+)/?$
{
    set $_query_string "lang=$1&view=$2&tab=$3";
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $_query_string;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
location ~ ^/([a-z][a-z])/(api)/([\w\s-]+)=\{1,3\}([\w\s-]+)=\{1,3\}\.html/?$
{
    set $_query_string "lang=$1&view=$2&data=$3&iv=$4";
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $_query_string;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
Всё работает, как и ожидается, но каждое правило вместо 1-ой строчки, превратилось в блок, в котором почти в каждом повторяется 1 и тот же блок

fastcgi_pass unix:/run/php-fpm.sock;
include fastcgi_params;
fastcgi_param QUERY_STRING $_query_string
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
Можно ли это как-то оптимизировать?
Например, выноести этот блок, а потом вызывать это блок (читал про именованные location но не понял как их использовать и помогут ли они мне тут вообще.)
2 При написании правил, я использовал только Location-ы игнорировал if-ы и rewrite-ы, возможно что-то ещё, так как прочитал, что Location-ы работают лучше и быстрее.
Правильно ли я сделал и почему (почему Location производительнее чем rewrite если это так, и почему именно не стоит использовать if-ы если это так)?
2.1 Отдельно прошу обратить внимание на правило с payment, где в apache можно было задействовать для разбора не только URI, но и QUERY_STRING. В nginx, если я правильно понял, можно использовать только URI.
Конкретную задачу по маршрутизации я вроде решил конкатенацией нового и старого QUERY_STRING, но хотелось бы знать можно ли было это сделать иначе?
3 Стоит ли мне включить опцию в nginx pcre_jit on;?
Сделает ли она обработку моих Location-ов более производительной?
4 Socket vs Port на локалхосте.
Правильно ли я поступаю, что использую сокеты на локалхосте вместо портов с точки зрения производительности? Какие там нюансы?
5 Не получается указать ssl_ciphers и их порядок следования для TLS 1.3.
В апаче есть костыль, и можно указать так, и это работает:
SSLCipherSuite TLSv1.3 TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384
В nginx, как и везде.
ssl_ciphers TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384;
Это работает только для TLSv1.2 сиферов, а сиферы для TLSv1.3 выводятся те и только в таком порядке, в котором они зашиты в openssl ciphers.
Можно ли что-то с этим сделать?
6 Не получается включить 0-RTT (SSL Labs показывает 0-RTT enabled No)
https://nginx.org/ru/docs/http/ngx_http_ssl_module.html#ssl_...
Тут нет конкретного примера.
Я в http указал
ssl_early_data on;
и даже
proxy_set_header Early-Data $ssl_early_data;
Но оно не работает и, видимо, последняя строчка должна быть другой, ведь у меня nginx никого не проксирует, он сам единственный web-сервер.
7 Каким и можно ли вообще изменять параметр максимального времени жизни запроса для каждого виртуального хоста?
В apache это делалось так: FcgidIOTimeout 300
8 И вопрос по php-fpm, по каким правилам, критериям или стратегиям выбирается оптимальное число процессов в этих, возможно и других опциях для pm = dynamic.
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
P.S. Буду рад выслушаю конструктивные ответы от всех кто их может дать. :-)

Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

103. "Выпуск сервера приложений NGINX Unit 1.11.0" +1 +/–

Сообщение от Valentin V. Bartenev (?), 20-Окт-19, 13:55

> 0 При попытке регистрации на форуме https://forum.nginx.org мне постоянно пишут
> Your registration request has been blocked because its suspected to come from
> a forum spammer!
> Хотя я ни разу его до этого вообще не посещал его, так
> что продолжу общение здесь, в этой тёплой и ламповой, для меня,
> обстановке. :-)
А и не надо на нем регистрироваться. Этот форум - всего лишь веб-интерфейс (причем страшно кривой) к обычному списку рассылки, который когда-то давно приделал один из пользователей.  С тех пор он так и живет.  Мы на него убрали вроде ссылки, но каким-то образом пользователи всё равно его находят.
Есть списки рассылки, ими и нужно пользоваться: https://mailman.nginx.org/mailman/listinfo/nginx-ru

> try_files $uri return 404;
Тут что-то странное написано.
В таком виде директива try_files проверит сначала существование запрашиваемого файла, а затем, если его нет, проверит существование файла с названием "return" и если такого файла тоже нет, то сделает редирект на страницу с именем 404.
Вы наверное пытались написать:
try_files $uri =404;
Но в такой конструкции нет никакого смысла. Нужно просто оставить location пустым:
location / { }

> Всё работает, как и ожидается, но каждое правило вместо 1-ой строчки, превратилось
> в блок, в котором почти в каждом повторяется 1 и тот
> же блок
>
> fastcgi_pass unix:/run/php-fpm.sock;
> include fastcgi_params;
> fastcgi_param QUERY_STRING $_query_string
> fastcgi_param SCRIPT_FILENAME $document_root/index.php;
>
А и не надо так писать.  То же самое:
rewrite ^/([a-z][a-z])/?$ /?lang=$1? last;
rewrite ^/([a-z][a-z])/(payment)$ /?lang=$1&view=$2 last;
rewrite ^/([a-z][a-z])/([\w-]+)/?$ /?lang=$1&view=$2? last;
rewrite ^/([a-z][a-z])/([\w-]+)/([\d-]+)\.html/?$ /?lang=$1&view=$2&id=$3? last;
rewrite ^/([a-z][a-z])/([\w-]+)/([\w-]+)/([\d-]+)\.html/?$ /?lang=$1&view=$2&tab=$3&id=$4? last;
rewrite ^/([a-z][a-z])/([\w-]+)/([\w-]+)/?$ /?lang=$1&view=$2&tab=$3? last;
rewrite ^/([a-z][a-z])/(api)/([\w\s-]+)=\{1,3\}([\w\s-]+)=\{1,3\}\.html/?$ /?lang=$1&view=$2&data=$3&iv=$4? last;

> Можно ли это как-то оптимизировать?
> Например, выноести этот блок, а потом вызывать это блок (читал про именованные
> location но не понял как их использовать и помогут ли они
> мне тут вообще.)
Не помогут.  Именованные location нужны для перенаправлений без изменения URI. У вас URI требуется менять.

> 2 При написании правил, я использовал только Location-ы игнорировал if-ы и rewrite-ы,
> возможно что-то ещё, так как прочитал, что Location-ы работают лучше и
> быстрее.
> Правильно ли я сделал и почему (почему Location производительнее чем rewrite если
> это так, и почему именно не стоит использовать if-ы если это
> так)?
location-ы производительнее потому, что префиксное сопоставление позволяет построить дерево и по нему искать. Но это не касается location с регулярными выражениями. Никаких преимуществ перед аналогичными конструкциями с регулярными выражениями у location нет. Во всех случаях основной тормоз - это исполнение регулярного выражения.
Все проблемы, увы, PHP программисты создают себе сами. Хотите чтобы было просто и быстро - разбирайте URI в index.php. Будете вы разбирать URI в PHP с помощью той же регулярки или с помощью каких-то более эффективных функций - не так важно.
Сейчас же вы занимаетесь лишней работой. Сначала заставили веб-сервер с помощью регулярных выражений парсить URI и преобразовывать его в аргументы. А затем этот URI с аргументами отправляете PHP-интерпретатору, чтобы тот опять парсил ваш URI, но уже с аргументами, вычленял эти аргументы и запихивал в хэш.  Зачем такое усложнение? Зачем этот лишний этап преобразования URI из одной формы в другую? Почему нельзя его парсить сразу в index.php?

> 2.1 Отдельно прошу обратить внимание на правило с payment, где в apache
> можно было задействовать для разбора не только URI, но и QUERY_STRING.
> В nginx, если я правильно понял, можно использовать только URI.
> Конкретную задачу по маршрутизации я вроде решил конкатенацией нового и старого QUERY_STRING,
> но хотелось бы знать можно ли было это сделать иначе?
Можно проверять аргументы с помощью if.

> 3 Стоит ли мне включить опцию в nginx pcre_jit on;?
> Сделает ли она обработку моих Location-ов более производительной?
Возможно чуть ускорит.

> 4 Socket vs Port на локалхосте.
> Правильно ли я поступаю, что использую сокеты на локалхосте вместо портов с
> точки зрения производительности? Какие там нюансы?
Правильно. Особых нюансов нет.

> ssl_ciphers TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384;
>
> Это работает только для TLSv1.2 сиферов, а сиферы для TLSv1.3 выводятся те
> и только в таком порядке, в котором они зашиты в openssl
> ciphers.
> Можно ли что-то с этим сделать?
Сейчас алгоритмы для TLS 1.3 в nginx можно задать через openssl.conf, подробности в: https://trac.nginx.org/nginx/ticket/1529#comment:12

> 6 Не получается включить 0-RTT (SSL Labs показывает 0-RTT enabled No)
> https://nginx.org/ru/docs/http/ngx_http_ssl_module.html#ssl_...
> Тут нет конкретного примера.
> Я в http указал
> ssl_early_data on;
Ещё сам TLS 1.3 нужно включить с помощью ssl_protocols, а больше ничего и не нужно.  Но следует убедиться, что, во-первых, в системе стоит свежая версия OpenSSL 1.1.1+, а, во-вторых, сам nginx был именно с ней собран.

> 7 Каким и можно ли вообще изменять параметр максимального времени жизни запроса
> для каждого виртуального хоста?
> В apache это делалось так: FcgidIOTimeout 300
fastcgi_read_timeout

> 8 И вопрос по php-fpm, по каким правилам, критериям или стратегиям выбирается
> оптимальное число процессов в этих, возможно и других опциях для pm
> = dynamic.
> pm.max_children = 5
> pm.start_servers = 2
> pm.min_spare_servers = 1
> pm.max_spare_servers = 3
Параметры подбираются исходя из возможностей вашей системы, сколько в ней памяти и процессора доступно, и исходя из особенностей вашего приложения, сколько каждый процесс ест памяти, сколько ждет на I/O, а сколько работает. Пять процессов - это либо какой-нибудь Raspberry Pi, виртуалка, либо приложение на десяток активных пользователей. На нормальном сервере под средние нагрузки будет что-нибудь вроде:
pm.max_children = 300
pm.start_servers = 50
pm.min_spare_servers = 25
pm.max_spare_servers = 75

Ответить | Правка | Наверх | Cообщить модератору

104. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Ilya Indigo (ok), 20-Окт-19, 16:58

> Есть списки рассылки, ими и нужно пользоваться: https://mailman.nginx.org/mailman/listinfo/nginx-ru
Вот не люблю я их, не удобные они, они не дают развёрнутого диалога как в багзиле или форуме. Тем более многие почтовики на которых они построены даже STARTTLS осилить не могут, и я в принципе ими не могу пользоваться.
>> try_files $uri return 404;
> Тут что-то странное написано.
Согласен, уже самому страшно, я за наделю разобрался как это работает и переписал на

location /
{
    index index.html;
    try_files $uri $uri/ =404;
}

Обязательно в самом конце, и убрал его из всех других блоков!
> Но в такой конструкции нет никакого смысла. Нужно просто оставить location пустым:
>
location / { }
>
А вот до этого нужно было ещё догадаться...
Для меня не было очевидным что пустой location / и его отсутствие это не одно и тоже.
И с Вами я не соглашусь про пустой location.
При пустом location в лог ошибок заносятся все 404 Not a found, что для меня было нежданностью и удивлением, и чтобы этого не было то вся статика должна обрабатываться на сайте именно так, как я привёл ранее в location /.
Также этот location реализует стандартное поведение Apache к которому я привык. (В лог ошибок не попадпют 404 и обращение к директориям подставляется index.html)
Поправьте меня если я что-то понял не так и не допонял. (Собственно, сегодня ночью я занимался именно этим.)
>[оверквотинг удален]
>
rewrite ^/([a-z][a-z])/?$ /?lang=$1? last;
> rewrite ^/([a-z][a-z])/(payment)$ /?lang=$1&view=$2 last;
> rewrite ^/([a-z][a-z])/([\w-]+)/?$ /?lang=$1&view=$2? last;
> rewrite ^/([a-z][a-z])/([\w-]+)/([\d-]+)\.html/?$ /?lang=$1&view=$2&id=$3? last;
> rewrite ^/([a-z][a-z])/([\w-]+)/([\w-]+)/([\d-]+)\.html/?$ /?lang=$1&view=$2&tab=$3&id=$4?
> last;
> rewrite ^/([a-z][a-z])/([\w-]+)/([\w-]+)/?$ /?lang=$1&view=$2&tab=$3? last;
> rewrite ^/([a-z][a-z])/(api)/([\w\s-]+)=\{1,3\}([\w\s-]+)=\{1,3\}\.html/?$ /?lang=$1&view=$2&data=$3&iv=$4?
> last;
>

Иными словами, там где мне нужна регулярка (~), я могу заменить на rewrite, а там где нет регулярки (= или /) я могу оставить location и производительность будет такая же?
> Все проблемы, увы, PHP программисты создают себе сами. Хотите чтобы было просто
> и быстро - разбирайте URI в index.php. Будете вы разбирать URI
> в PHP с помощью той же регулярки или с помощью каких-то
> более эффективных функций - не так важно.
> Сейчас же вы занимаетесь лишней работой. Сначала заставили веб-сервер с помощью регулярных
> выражений парсить URI и преобразовывать его в аргументы. А затем этот
> URI с аргументами отправляете PHP-интерпретатору, чтобы тот опять парсил ваш URI,
> но уже с аргументами, вычленял эти аргументы и запихивал в хэш.
>  Зачем такое усложнение? Зачем этот лишний этап преобразования URI из
> одной формы в другую? Почему нельзя его парсить сразу в index.php?
Тут Я Вас не совсем понял. :-(
> разбирайте URI в index.php
От клиента приходит URI /ru/company/cargo/1.html Как мне его разбивать в /index.php если он полезет искать директории ru company cargo в ней файл 1.html, которых на сервере, естественно, нет и быть не может, а про наличие /index.php PHP и знаить не знает, если ему сервер не распарсит URI на GET-параметы и не вызовет /index.php с GET-параметрами? Как?
> Сейчас же вы занимаетесь лишней работой.
Или Вы под лишнюю работу считаете всё ЧПУ?
> А затем этот URI с аргументами отправляете PHP-интерпретатору, чтобы тот опять парсил ваш URI.
PHP URI не парсит. Он, разве что разбивает QUERY_STRING на GET-параметры, что очень лёгкая и быстрая задача, $_GET = explode('&',$_SERVER['QUERY_STRING']); причём деелает он это сам и всегда.
Я его ничем лишним не нагружаю, он даже не понимает что я использую ЧПУ. В этом весь и смысл.
>> 3 Стоит ли мне включить опцию в nginx pcre_jit on;?
>> Сделает ли она обработку моих Location-ов более производительной?
> Возможно чуть ускорит.
Ускорит только (пере)запуск nginx или также дальнейшую работу rewrite-ов.
>> 4 Socket vs Port на локалхосте.
>> Правильно ли я поступаю, что использую сокеты на локалхосте вместо портов с
>> точки зрения производительности? Какие там нюансы?
> Правильно. Особых нюансов нет.
Но почему-то почти у всех серверов в конфигурации по умолчанию, и в документации записаны именно порты, и мне приходится каждый раз тратить время чтобы найти как указывается socket в этом сервере... Думал, может я чего-то не понимаю.
>> ssl_ciphers TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384;
>>
>> Это работает только для TLSv1.2 сиферов, а сиферы для TLSv1.3 выводятся те
>> и только в таком порядке, в котором они зашиты в openssl
>> ciphers.
>> Можно ли что-то с этим сделать?
> Сейчас алгоритмы для TLS 1.3 в nginx можно задать через openssl.conf, подробности
> в: https://trac.nginx.org/nginx/ticket/1529#comment:12
Благодарю. Про это необходимо написать в документации к параметру ciphers.
>> 6 Не получается включить 0-RTT (SSL Labs показывает 0-RTT enabled No)
>> https://nginx.org/ru/docs/http/ngx_http_ssl_module.html#ssl_...
>> Тут нет конкретного примера.
>> Я в http указал
>> ssl_early_data on;
> Ещё сам TLS 1.3 нужно включить с помощью ssl_protocols, а больше ничего
> и не нужно.  Но следует убедиться, что, во-первых, в системе
> стоит свежая версия OpenSSL 1.1.1+, а, во-вторых, сам nginx был именно
> с ней собран.
https://build.opensuse.org/package/view_file/server:http/ngi...

nginx -V
nginx version: nginx/1.17.3
built by gcc 9.2.1 20190903 [gcc-9-branch revision 275330] (SUSE Linux)
built with OpenSSL 1.1.1c  28 May 2019
TLS SNI support enabled
/etc/nginx/nginx.conf

error_log /var/log/nginx/error.log warn;
pid /run/nginx.pid;
events
{
    multi_accept on;
    worker_connections 1024;
}
http
{
    include mime.types;
    default_type application/octet-stream;
    log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_x_forwarded_for"';
    access_log /var/log/nginx/access.log main;
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    add_header Strict-Transport-Security 'max-age=63072000; includeSubDomains; preload' always;
    ssl_protocols TLSv1.3 TLSv1.2;
    ssl_ciphers TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers on;
    ssl_ecdh_curve prime256v1;
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s ipv6=off;
    ssl_early_data on;
    proxy_set_header Early-Data $ssl_early_data;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    keepalive_timeout 70;
    gzip on;
    include conf.d/*.conf;
    server
    {
        listen 443 default_server http2 ssl;
        ssl_certificate /etc/apache2/ssl.crt/gricargo.com.crt;
        ssl_certificate_key /etc/apache2/ssl.key/gricargo.com.key;
        return 301 https://gricargo.com;
    }
    include vhosts.d/*.conf;
}

https://www.ssllabs.com/ssltest/analyze.html?d=gricargo.com
0-RTT enabled     No :-(
>[оверквотинг удален]
> Параметры подбираются исходя из возможностей вашей системы, сколько в ней памяти и
> процессора доступно, и исходя из особенностей вашего приложения, сколько каждый процесс
> ест памяти, сколько ждет на I/O, а сколько работает. Пять процессов
> - это либо какой-нибудь Raspberry Pi, виртуалка, либо приложение на десяток
> активных пользователей. На нормальном сервере под средние нагрузки будет что-нибудь вроде:
>
pm.max_children = 300
> pm.start_servers = 50
> pm.min_spare_servers = 25
> pm.max_spare_servers = 75
>

Хотелось бы если не формул, то инструкций по тому как узнать что процессов не хватает или их в избытке. Понимаю что эта тема не Ваша, буду разбираться с этим дальше.
Благодарю Вас, за ответ, мне он, как всегда очень помог. :-)

Ответить | Правка | Наверх | Cообщить модератору

105. "Выпуск сервера приложений NGINX Unit 1.11.0" +2 +/–

Сообщение от Valentin V. Bartenev (?), 20-Окт-19, 22:48

>> Есть списки рассылки, ими и нужно пользоваться: https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> Вот не люблю я их, не удобные они, они не дают развёрнутого
> диалога как в багзиле или форуме. Тем более многие почтовики на
> которых они построены даже STARTTLS осилить не могут, и я в
> принципе ими не могу пользоваться.
Почтовики? STARTTLS? Вы случайно с NNTP/Usenet не попутали? В списках рассылки можно хоть из веб-интерефейса Gmail с двухфакторной авторизацией общаться.

> И с Вами я не соглашусь про пустой location.
> При пустом location в лог ошибок заносятся все 404 Not a found,
> что для меня было нежданностью и удивлением, и чтобы этого не
> было то вся статика должна обрабатываться на сайте именно так, как
> я привёл ранее в location /.
> Также этот location реализует стандартное поведение Apache к которому я привык. (В
> лог ошибок не попадпют 404 и обращение к директориям подставляется index.html)
index.html и так подставляется при запросе директории.  А вот эмулировать поведение log_not_found off; с помощью try_files - это странно.

> Иными словами, там где мне нужна регулярка (~), я могу заменить на
> rewrite, а там где нет регулярки (= или /) я могу
> оставить location и производительность будет такая же?
Да.

> От клиента приходит URI /ru/company/cargo/1.html Как мне его разбивать в /index.php если
> он полезет искать директории ru company cargo в ней файл 1.html,
> которых на сервере, естественно, нет и быть не может, а про
> наличие /index.php PHP и знаить не знает, если ему сервер не
> распарсит URI на GET-параметы и не вызовет /index.php с GET-параметрами? Как?
Обычно вся конфигурация сводится к следующим двум location-ам:

location / {
    try_files $uri @php;
}
location @php {
    fastcgi_pass unix:/run/php-fpm.sock;
    fastcgi_param SCRIPT_FILENAME path/to/app.php;
    include fastcgi_params;
}
Всё предельно просто: если файл есть на диске - мы его отдаем, а всё остальное отправляем в приложение. Приложение уже возьмет $_SERVER['REQUEST_URI'] и распарсит как угодно.
Программисты на других ЯП всю дорогу так и делали и только PHP-шники извращаются.
А ещё правильнее - это всю статику положить в отдельную директорию. Посмотрите, к примеру, насколько просто выглядит конфигурация nginx для типичного сайта на Django:
https://uwsgi.readthedocs.io/en/latest/tutorials/Django_and_...

>> А затем этот URI с аргументами отправляете PHP-интерпретатору, чтобы тот опять парсил ваш URI.
> PHP URI не парсит. Он, разве что разбивает QUERY_STRING на GET-параметры, что
> очень лёгкая и быстрая задача, $_GET = explode('&',$_SERVER['QUERY_STRING']); причём
> деелает он это сам и всегда.
Вот вы сначала полностью перезаписываете URI, формируя новый QUERY_STRING из уже существующего URI, а затем этот QUERY_STRING будет парсится в недрах интерпретатора для заполнения хэш-массива $_GET. Хотя можно было бы просто взять $_SERVER['REQUEST_URI'] и выполнить над ним ту же самую регулярку, но сделать это в PHP-скрипте и получить сразу все ваши переменные. Но для этого не надо перезаписывать URI, а просто позвать нужный SCRIPT_FILENAME, ничего больше не меняя.
REQUEST_URI не обязан как-либо пересекаться с SCRIPT_FILENAME. Это в Apache с mod_php и .htaccess иначе сложно, там выполняемый файл эквивалентен запрашиваемому URI. С FastCGI не так и нет смысла тащить костыли от mod_php на FastCGI конфигурацию.

> Я его ничем лишним не нагружаю, он даже не понимает что я
> использую ЧПУ. В этом весь и смысл.
ЧПУ - это изобретение исключительно php-шников для решения собственноручно созданной проблемы. Сначала php-шники придумали, что файлы с кодом приложения надо класть в document root веб-сервера и запрашивать их как .html странички, а затем, обнаружив, что URI с .php на конце выглядят некрасиво - теперь героически придумывают способы преодоления.
Хотя просто не нужно мешать статику с данными в одной директории. Да и то, даже для такой смеси есть выход, см. выше.

>>> 3 Стоит ли мне включить опцию в nginx pcre_jit on;?
>>> Сделает ли она обработку моих Location-ов более производительной?
>> Возможно чуть ускорит.
> Ускорит только (пере)запуск nginx или также дальнейшую работу rewrite-ов.
Только работу. А перезапуск наоборот затормозит и памяти съест чуть больше. Ведь регулярки с включенной опцией pcre_jit будут компилироваться перед использованием. Т.е. есть плюсы и минусы. Поэтому опция по умолчанию и выключена.
Вообще в nginx все значения директив по умолчанию не с потолка взяты и лучше их не трогать без явной нужды.

> https://www.ssllabs.com/ssltest/analyze.html?d=gricargo.com
> 0-RTT enabled  No :-(
Я что-то не нашел  в сети сервера, на котором бы данный сайт показал Yes. Даже на специально созданных для демонстрации 0-RTT тестовых серверах (типа 0rtt.tls13.com) оно показывает No.
При этом в выводе:
% openssl s_client -connect gricargo.com:44
Можно наблюдать Max Early Data: 16384

> Хотелось бы если не формул, то инструкций по тому как узнать что
> процессов не хватает или их в избытке. Понимаю что эта тема
> не Ваша, буду разбираться с этим дальше.
Посмотрите для начала сколько у вас один процесс занимает памяти. Настраивать их количество больше, чем имеющейся свободной памяти на сервере - точно не стоит.

Ответить | Правка | Наверх | Cообщить модератору

106. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Ilya Indigo (ok), 27-Окт-19, 21:40

> Почтовики? STARTTLS? Вы случайно с NNTP/Usenet не попутали? В списках рассылки можно
> хоть из веб-интерефейса Gmail с двухфакторной авторизацией общаться.
Нет не попутал. Отправить баг в postfix и dovecot через их маиллисты мне не представляется возможным. В Гугле, Яндексе и прочих зондах читающих Вашу почту и разрешающие общение с почтовиками без STARTTLS, можно, но я же PHP-ник, я ими не пользуюсь и никому не доверяю свою почту кроме своих почтовых серверов.
> index.html и так подставляется при запросе директории.  А вот эмулировать поведение
> log_not_found off; с помощью try_files - это странно.
А зачем вообще тогда по умолчанию заносить каждую 404 в лог ошибок?
Я думал логика в том, что каждый отдаваемый nginx-ом должен проходить через try_files, и если он отдаёт каким-то иным способом то именно это должно отображаться в файлах ошибок, но Ваш ответ меня удивил.
> Обычно вся конфигурация сводится к следующим двум location-ам:
> Всё предельно просто: если файл есть на диске - мы его отдаем,
> а всё остальное отправляем в приложение. Приложение уже возьмет $_SERVER['REQUEST_URI']
> и распарсит как угодно.
Огромная Вам благодарность за этот пример!
Во-первых я хоть где-то увидел как используется именованный location, когда в документации упоминается только что он есть и он указывается через @.
Во-вторых мне и в голову раньше не приходило, что так вообще возможно. Не знаю, можно ли так в апаче было сделать?
Мой код теперь.

error_page 404 /en/error;
location = /index.php
{
    return 404;
}
location ^~ /.
{
    return 404;
}
location /
{
    try_files $uri @php;
}
location @php
{
    fastcgi_pass unix:/run/php-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
    include fastcgi_params;
}

А на стороне PHP

<?php if(strpos($_SERVER['REQUEST_URI'],'?') > 0)
{
    if(isset($_SERVER['REQUEST_URI'][59],$_GET['token'][19],$_GET['PayerID'][12]) && !isset($_SERVER['REQUEST_URI'][60]) && strpos($_SERVER['REQUEST_URI'],'/payment?') == 3)
        $_SERVER['REQUEST_URI'] = substr($_SERVER['REQUEST_URI'],0,strpos($_SERVER['REQUEST_URI'],'?'));
    else
    {
        unset($_GET,$_REQUEST);
        $_SERVER['REQUEST_URI'] = substr($_SERVER['REQUEST_URI'],0,4).'error';
    }
}
if(strpos($_SERVER['REQUEST_URI'],'/.') === false && strpos($_SERVER['REQUEST_URI'],'.php') === false)
{
    $arr = explode('/',substr($_SERVER['REQUEST_URI'],1));
    if(isset($arr[0][1]) && !isset($arr[0][2]))
    {
        $_GET['lang'] = $arr[0];
        if(isset($arr[1]))
        {
            $_GET['view'] = $arr[1];
            if(isset($arr[2]))
            {
                if($_GET['view'] == 'api')
                {
                    if(substr($arr[2],-6) == '=.html')
                    {
                        $_GET['data'] = substr($arr[2],0,$p=strpos($arr[2],'='));
                        $_GET['iv'] = substr($arr[2],++$p,-6);
                        unset($p);
                    }
                    else $_GET['view'] = 'error';
                }
                elseif(substr($arr[2],-5) == '.html')
                    $_GET['id'] = substr($arr[2],0,-5);
                else
                {
                    $_GET['tab'] = $arr[2];
                    if(isset($arr[3]) && substr($arr[3],-5) == '.html')
                        $_GET['id'] = substr($arr[3],0,-5);
                }
            }
        }
    }
    else $_GET['view'] = 'error';
    unset($arr);
}
else $_GET['view'] = 'error';

Я полностью избавился от регулярок и от дублирования, не считая повторяющийся return 404;
При этом на стороне PHP это делать проще и удобнее, причём для этого мне не нужны регулярки вообще!
Этим кодом я почти доволен.
Осталось только логи отформатировать, статус прикрутить и кеширование со сжатием добавить.
Вот только одна особенность nginx-а и try_files доставила мне проблем.
У Apache 403 всегда сопровождается заголовком Access Denied и означает только это.
У nginx 403 сопровождается заголовком Forbidden и может означать что угодно. :-(

location /
{
    index index.html;
    try_files $uri $uri/ @php;
}

По моей логике при $uri / или /static/js/lib_name/doc/ (в doc есть index.html) алгоритм должен быть такой (эмулирую то, что в Apache по умолчанию)
1 Проверяет если файл $uri Да - отдаёт Нет - идёт дальше.
2 Проверяет есть ли файл $uri/index.html Да - отдаёт Нет - идёт дальше
3 Если дошло до этого шга, то запрос отправляется в PHP.
Но каково было моё удивление и недоумение получить 403 Forbidden в этой конфигурации и далеко не сразу понять почему и где...
оказывается, если $uri/index.html не существует - то никакой передачи дальше в PHP не происходит а nginx тупо выдаёт 403 Forbidden
В итоге приходится не использовать индексирование и указывать полный путь к /static/js/lib_name/doc/index.html и подобным докам не приятно, но жить с этим можно.
Почему в nginx так и зачем так было сделано?
Можно ли как-то просто и универсально исправить проблему и привести к желаемому поведению?
И ещё интересный вопрос, можно ли как-нибудь ещё вызывать именованые location кроме как из try_files? Если да, приведите, пожалуйста, примеры
> Программисты на других ЯП всю дорогу так и делали и только PHP-шники
> извращаются.
> А ещё правильнее - это всю статику положить в отдельную директорию. Посмотрите,
> к примеру, насколько просто выглядит конфигурация nginx для типичного сайта на
> Django:
> https://uwsgi.readthedocs.io/en/latest/tutorials/Django_and_...
Видимо потому-что программисты на других языках, занимаются не web-сайтами, в их классическом понимании, а всякими CRM-ками, встроенными интерфейсами, например для управления IP-камерами и прочими вещами не предназначенными для всеобщего обозрения.
По этому им не нужна ни безопасность, ни ЧПУ, ни индексирование в поисковиках, ни вообще чтобы кто-то про них знал и их находил.
В конфигурации на Django всё, казалось бы красиво, но вот незадача, она совершенно не знает про /robots.txt и /sitemap.xml Эти файлы пойдут лесом. А ещё файлы авторизации различных СЕО-ников для разных систем аналитики, которые в корень кладутся...
Мне, как админу серверов, нужно для каждого из них правило в nginx прописывать и каждый раз сервер передёргивать?
Знаю про то что для последнего можно DNS использовать, но давать СЕО-никам доступ к DNS ещё хуже.
А более, на мой взгляд, главное, эта конфигурация не защищает от отдачи скрытых файлов!
Например .git, или даже .directory,
Слышал, в Яндексе как раз и было такое, что у них их /.git/ спокойно nginx раздавал.
Так что не вижу ничего плохого в том, чтобы класть index.php в DOCUMENT_ROOT и запрещать к нему доступ, как и доступ ко всем скрытым файлам и директориям хотя бы в DOCUMENT_ROOT.
Это и удобнее и безопаснее, тем более у меня ущё со времён апача в нём всего одна строчка <?php require dirname(__DIR__).'/init.php';
Ещё для меня одним неприятным открытием было, когда я убрал index.php из DOCUMENT_ROOT и вызывал сразу init.php, у меня перестал читаться .user.ini файл, даже после того, как я продублировал его за DOCUMENT_ROOT, видимо для его чтения он должен находится только в DOCUMENT_ROOT вместе с вызываемым скриптом (точкой входа).
Так что пользы от выноса index.php из DOCUMENT_ROOT я не вижу, а проблемы появляются достаточно.
> REQUEST_URI не обязан как-либо пересекаться с SCRIPT_FILENAME. Это в Apache с mod_php
> и .htaccess иначе сложно, там выполняемый файл эквивалентен запрашиваемому URI. С
> FastCGI не так и нет смысла тащить костыли от mod_php на
> FastCGI конфигурацию.
Я это уже понял. Для этого я и веду с Вами этот публичный диалог, чтобы работать с nginx правильно, а не так, как я привык работать с Apache.
А также чтобы это потом пригодилось не только мне, но у другим... PHP-никам.
> Можно наблюдать Max Early Data: 16384
Благодарю, значит работает! :-)
>> Хотелось бы если не формул, то инструкций по тому как узнать что
>> процессов не хватает или их в избытке. Понимаю что эта тема
>> не Ваша, буду разбираться с этим дальше.
> Посмотрите для начала сколько у вас один процесс занимает памяти. Настраивать их
> количество больше, чем имеющейся свободной памяти на сервере - точно не
> стоит.
На сервере же не один PHP работает. Там и MariaDB ей тоже ОЗУ нужна под всякие индексы.
Redis обитает, кеширующий ответы от MariaDB, и тоже будет рад лишней ОЗУ.
Но с redis я понимаю и знаю как определять и контролировать его расход ОЗУ и выдаю ему столько, сколько нужно, но чтобы без переизбытка.
И у php-fpm, наверно есть какой-то разумный предел кол-ва процессов, больше которого ресурсы потребляет, но выигрыш в производительности не приносит.
Или ему нужно отдавать все свободные ресурсы сервера?

Ответить | Правка | Наверх | Cообщить модератору

97. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Michael Shigorin (ok), 23-Сен-19, 20:24

> Но Игорь и так не работал над nginx ещё с 2012, а я с 2017,
> что не мешает nginx-у продолжать активно развиваться последние годы.
Всяко спасибо за труды!

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

88. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от zo0M (ok), 22-Сен-19, 08:25

о чем речь, разработка этих продуктов ведется параллельно разными командами.

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

29. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Аноним (29), 20-Сен-19, 12:27

Анонистные эксперты, ответьте: всё, просто нгинкс можно выбрасывать?

Ответить | Правка | Наверх | Cообщить модератору

84. "Выпуск сервера приложений NGINX Unit 1.11.0" +1 +/–

Сообщение от KonstantinB (ok), 22-Сен-19, 04:12

Зависит от задач. Unit - это прежде всего web application server (ну, не совсем, но очень важный кусочек его). Но судя по тому, в какую сторону он развивается, Unit это и есть давно обещанный Nginx 2 :-)

Ответить | Правка | Наверх | Cообщить модератору

89. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от zo0M (ok), 22-Сен-19, 08:27

нет, нельзя, это по-прежнему основной продукт компании.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

30. "Выпуск сервера приложений NGINX Unit 1.11.0" +1 +/–

Сообщение от Аноним (30), 20-Сен-19, 13:05

Я так и не понял, а зачем он для го и джавы нужен?

Ответить | Правка | Наверх | Cообщить модератору

32. "Выпуск сервера приложений NGINX Unit 1.11.0" +3 +/–

Сообщение от ansible (?), 20-Сен-19, 13:24

А тебе и не надо значит™

Ответить | Правка | Наверх | Cообщить модератору

90. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от zo0M (ok), 22-Сен-19, 08:28

эмм... запуск приложений, оркестрация?

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

34. "Выпуск сервера приложений NGINX Unit 1.11.0" +3 +/–

Сообщение от eRIC (ok), 20-Сен-19, 14:04

то что научили и статику отдавать, очень хорошо, +++

Ответить | Правка | Наверх | Cообщить модератору

91. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от zo0M (ok), 22-Сен-19, 08:29

таки да, кошерненько

Ответить | Правка | Наверх | Cообщить модератору

41. "Выпуск сервера приложений NGINX Unit 1.11.0" –1 +/–

Сообщение от Аноним (41), 20-Сен-19, 15:42

Всегда интересовался вопросом, что такое "релиз" а что такое "выпуск". Берем эту тему, тут "релиз". Берем соседнюю тему "https://www.opennet.ru/opennews/art.shtml?num=51522" в которой пишут что Выпуск Samba 4.11.0, но потом "Представлен релиз" Может кто внятно объяснить чем релиз лучше выпуска?

Ответить | Правка | Наверх | Cообщить модератору

44. "Выпуск сервера приложений NGINX Unit 1.11.0" +1 +/–

Сообщение от Аноним (44), 20-Сен-19, 17:25

Это синонимы. А разные варианты в одной и той же новосте - это чтоб не повторяться.

Ответить | Правка | Наверх | Cообщить модератору

46. "Выпуск сервера приложений NGINX Unit 1.11.0" –2 +/–

Сообщение от Аноним (46), 20-Сен-19, 18:38

Когда-то Сысоев говорил, что не будет писать "второй апач". По факту написали уже ДВА апача, всё с тем же вкомпиленными mod_perl, mod_lua, mod_чёрт-в-ступе.
<...>
libnginx-mod-http-geoip
libnginx-mod-http-image-filter
libnginx-mod-http-lua
libnginx-mod-http-ndk
libnginx-mod-http-perl
libnginx-mod-http-subs-filter
libnginx-mod-http-uploadprogress
libnginx-mod-http-upstream-fair
libnginx-mod-http-xslt-filter
<...>
Ждём добавления поддержки .htaccess.

Ответить | Правка | Наверх | Cообщить модератору

49. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Sw00p aka Jerom (?), 20-Сен-19, 21:04

>что не будет писать "второй апач".
таки да :)
>Ждём добавления поддержки .htaccess.
а вот этого не видать категорически, ибо нджинкс - не апач

Ответить | Правка | Наверх | Cообщить модератору

52. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от пох. (?), 20-Сен-19, 21:40

> Когда-то Сысоев говорил, что не будет писать "второй апач". По факту написали
ты его неправильно понял - это он говорил про .htaccess, человекопонимаемые вложенные уровни синтаксиса и прочее ненужное устаревшее ненужно.
> уже ДВА апача, всё с тем же вкомпиленными mod_perl, mod_lua, mod_чёрт-в-ступе.
это соверенно не противоречит генеральной линии (хотя unit ни разу и не апач...скорее уж - tomcat?)
> Ждём добавления поддержки .htaccess.
вот этого можете ждать пока рак на горе не свистнет.
А я уже не надеюсь дождаться хотя бы чего-нибудь похожего на апачевский status в бешплатной версии. Причем я бы купил платную - если бы ее цена была хоть как-то экономически обоснована.

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

53. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Sw00p aka Jerom (?), 20-Сен-19, 22:39

>похожего на апачевский status
идите к раку на горе ) ибо ждите когда сам спустится.
вот status page нджинкса это хороший пример "ху*к-ху*ка", легче было бы если тупо циферки через пробел в одну строку и в документации описание полей, чем то гамно которое лет 15 как не изменилось, регексом в одну строку не пропарсишь.

Ответить | Правка | Наверх | Cообщить модератору

55. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от пох. (?), 20-Сен-19, 22:49

я надеюсь, вы уже открыли для себя mod_vts? (это ни разу, конечно, не нормальный статус, но, во всяком случае, он умеет модный json)
> регексом в одну строку не пропарсишь
мне бы ваши проблемы... было бы там, что парсить.

Ответить | Правка | Наверх | Cообщить модератору

57. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от Sw00p aka Jerom (?), 20-Сен-19, 23:03

>вы уже открыли для себя mod_vts?
спасибо, лишний раз не хочется слышать от Дунина - "отрубите все сторонние модули"
> мне бы ваши проблемы... было бы там, что парсить.
про мултилайн регекс увы не читал, ну как всегда бывает. Вы лучше бы скинули бы свой регекс :)

Ответить | Правка | Наверх | Cообщить модератору

85. "Выпуск сервера приложений NGINX Unit 1.11.0" +/–

Сообщение от KonstantinB (ok), 22-Сен-19, 04:13

Ну мало ли какие модули кто понаписал.
Половина перечисленного - сторонние модули.

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

70. "Выпуск сервера приложений NGINX Unit 1.11.0" +2 +/–

Сообщение от vitalif (ok), 21-Сен-19, 17:49

> Встроена возможность самостоятельной отдачи статического контента без обращения к внешнему http-серверу
Ну норм, осталось туда весь обычный nginx встроить и будет таки апач!))

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Выпуск сервера приложений NGINX Unit 1.11.0"	+4 +/–
Сообщение от zo0M (ok), 20-Сен-19, 07:35
збс, давно ждал, спасибо
Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Выпуск сервера приложений NGINX Unit 1.11.0"	+3 +/–
	Сообщение от Ан (??), 20-Сен-19, 10:55
	Количество комментариев намекает на его нужность ....
	Ответить \| Правка \| Наверх \| Cообщить модератору


	86. "Выпуск сервера приложений NGINX Unit 1.11.0"	+/–
	Сообщение от zo0M (ok), 22-Сен-19, 08:22
	о, да
	Ответить \| Правка \| Наверх \| Cообщить модератору

2. "Выпуск сервера приложений NGINX Unit 1.11.0"	–4 +/–
Сообщение от Аноним (2), 20-Сен-19, 08:51
А разве NGINX сам по себе не отдавал статику?
Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Выпуск сервера приложений NGINX Unit 1.11.0"	+10 +/–
	Сообщение от Аноним (3), 20-Сен-19, 08:58
	NGINX и NGINX Unit это совершенно разные вещи.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	87. "Выпуск сервера приложений NGINX Unit 1.11.0"	+/–
	Сообщение от zo0M (ok), 22-Сен-19, 08:23
	Nginx отдавал, Nginx Unit нет
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору

22. "Выпуск сервера приложений NGINX Unit 1.11.0"	–1 +/–
Сообщение от Aytishnik.com (ok), 20-Сен-19, 10:58
Молодец Игорь Сысоев, теперь спокойно работает, главное вовремя понять, когда надо уезжать.
Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Выпуск сервера приложений NGINX Unit 1.11.0"	+3 +/–
	Сообщение от пох. (?), 20-Сен-19, 11:38
	главное вовремя понять, куда. А "когда" наступает примерно как можешь отдельно от мамкиной сиськи куда-то ездить.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	27. "Выпуск сервера приложений NGINX Unit 1.11.0"	+2 +/–
	Сообщение от Аноим (?), 20-Сен-19, 11:53
	Не, ну чуть попозже, всё же)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	58. "Выпуск сервера приложений NGINX Unit 1.11.0"	+1 +/–
	Сообщение от test (??), 21-Сен-19, 00:36
	До этого не спокойно работал? Поделитесь о чем речь.
	Ответить \| Правка \| К родителю #22 \| Наверх \| Cообщить модератору


	98. "Выпуск сервера приложений NGINX Unit 1.11.0"	+/–
	Сообщение от Lex (??), 25-Сен-19, 08:29
	Надо полагать, примерно об этом: 11 марта 2019 года объявлено, что компания F5 Networks покупает NGINX. Сумма сделки оценивается приблизительно в 670 миллионов долларов
	Ответить \| Правка \| Наверх \| Cообщить модератору

23. "Выпуск сервера приложений NGINX Unit 1.11.0"	+9 +/–
Сообщение от Аноним (23), 20-Сен-19, 11:01
Да что за бич опеннета с версткой? маркеры маркированного списка плывут и на телефоне и на компе. А еще недавно в новости забыли поставить закрывающий тег ссылке. 100% автор не осилил какой-нибудь markdown и пишут на голом html. А чтоб не подумали что я ваще злой - скажу что это все же лучший ресурс из русскоязычных ;)
Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "Выпуск сервера приложений NGINX Unit 1.11.0"	+/–
	Сообщение от Аноним (28), 20-Сен-19, 12:10
	> не осилил мрак даун > где три с половиной возможности форматирования > пишут на голом html > полноценном языке разметки уж лучше голый html
	Ответить \| Правка \| Наверх \| Cообщить модератору


	31. "Выпуск сервера приложений NGINX Unit 1.11.0"	–3 +/–
	Сообщение от Аноним (31), 20-Сен-19, 13:08
	они оверинженеры, там и бэкенд на страшной жабе!
	Ответить \| Правка \| К родителю #23 \| Наверх \| Cообщить модератору


	35. "Выпуск сервера приложений NGINX Unit 1.11.0"	+/–
	Сообщение от iPahcae6 (?), 20-Сен-19, 14:24
	Все хуже. То едут, то не едут С десктопа едут под игровой виндой, не едут под рабочей линухой. С мобилы едут с Brave на Android и вроде не едут с Firefox(либо с чего-то еще более маргинального даже, не помню точно)
	Ответить \| Правка \| К родителю #23 \| Наверх \| Cообщить модератору


	36. "Выпуск сервера приложений NGINX Unit 1.11.0"	–1 +/–
	Сообщение от Аноним (31), 20-Сен-19, 14:25
	"Работают лучше Fronend специалисты индустрии"
	Ответить \| Правка \| Наверх \| Cообщить модератору


	50. "Выпуск сервера приложений NGINX Unit 1.11.0"	+/–
	Сообщение от KonstantinB (ok), 20-Сен-19, 21:26
	.chtext li { text-indent: 0; }
	Ответить \| Правка \| К родителю #23 \| Наверх \| Cообщить модератору


	62. "Выпуск сервера приложений NGINX Unit 1.11.0"	+1 +/–
	Сообщение от Maxim Chirkov (ok), 21-Сен-19, 10:19
	Спасибо, поправил. Расстановка отступов в CSS на сайте не менялась лет 15 и сдвиг стал наблюдаться только в предпоследнем выпуске Chrome, после того как они добавили break-spaces и что-то поменяли в логике разрыва строк. Думал, что эту регрессию устранят в новом выпуске, но она так и остаётся. Интересно, что проявляется не для всех li, а только выборочно и, как правило, единично. Причины, по каким съезжает, а по каким нет, точно я не уловил, заметил лишь, что если следом идёт pre, как в этой новости, то текст смещается.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	66. "Выпуск сервера приложений NGINX Unit 1.11.0"	+1 +/–
	Сообщение от KonstantinB (ok), 21-Сен-19, 16:55
	Да, в предпоследнем хроме вообще дров наломали. На паре сайтов, которые я не трогал уже пару лет, поломалось всякое, от подобных мелочей до полного схлопывания до нулевой ширины некоторых div-ов при динамической работе с DOM. Костыли везде придумал, но хром с его монополией явно начинает превращаться в очередной IE.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	93. "Выпуск сервера приложений NGINX Unit 1.11.0"	+/–
	Сообщение от Аноним (31), 22-Сен-19, 09:51
	Ты придумал Reset CSS, который используют все Frontend разработчики. normalize.css чуть иной.
	Ответить \| Правка \| К родителю #62 \| Наверх \| Cообщить модератору


	94. "Выпуск сервера приложений NGINX Unit 1.11.0"	+/–
	Сообщение от Аноним (31), 22-Сен-19, 09:54
	https://pastebin.com/r7CN7kve
	Ответить \| Правка \| Наверх \| Cообщить модератору

24. "Выпуск сервера приложений NGINX Unit 1.11.0"	–4 +/–
Сообщение от пох. (?), 20-Сен-19, 11:37
интересно, на открытую версию nginx-не-юнит окончательно теперь будет положен $@й, или он на ней уже давным-давно лежит?
Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Выпуск сервера приложений NGINX Unit 1.11.0"	+4 +/–
	Сообщение от kiwinix (?), 20-Сен-19, 11:53
	Вообще есть повод для таких догадок? Мое ИМХО - nginx просто в идеальном и стабильном состоянии. Вообще никаких нареканий у меня нет
	Ответить \| Правка \| Наверх \| Cообщить модератору


	37. "Выпуск сервера приложений NGINX Unit 1.11.0"	+/–
	Сообщение от Аноним (31), 20-Сен-19, 14:27
	GZIP нельзя отключить для html контента при HTTPS. BREACH Attack!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	56. "Выпуск сервера приложений NGINX Unit 1.11.0"	+/–
	Сообщение от пох. (?), 20-Сен-19, 22:52
	> Вообще есть повод для таких догадок? не-опоздание родиться за повод считается? Я прекрасно помню как он развивался до версии 1., и что с ним случилось после. > Мое ИМХО - nginx просто в идеальном и стабильном состоянии. "а на кладбище - все спокойненько!"
	Ответить \| Правка \| К родителю #26 \| Наверх \| Cообщить модератору


	33. "Выпуск сервера приложений NGINX Unit 1.11.0"	+10 +/–
	Сообщение от Valentin V. Bartenev (?), 20-Сен-19, 13:45
	Без паники. Над Unit и nginx работают две независимые команды. Причем на данный момент команда nginx даже больше. Фактически из бывших разработчиков nginx над Unit-ом трудятся только Игорь и я. Но Игорь и так не работал над nginx ещё с 2012, а я с 2017, что не мешает nginx-у продолжать активно развиваться последние годы. Это две разные идеологии построения веб-сервера и мы не собираемся никого насильно пересаживать с одного на другое. Какая окажется доминирующей - время покажет. Я верю в Unit.
	Ответить \| Правка \| К родителю #24 \| Наверх \| Cообщить модератору


	38. "Выпуск сервера приложений NGINX Unit 1.11.0"	+/–
	Сообщение от Аноним (31), 20-Сен-19, 14:30
	> Но Игорь и так не работал над nginx ещё с 2012, а я с 2017, что не мешает nginx-у продолжать активно развиваться последние годы. Теперь понятно почему в NGINX больше не производиться работа над доработками. trac.nginx служит как bash.org.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	40. "Выпуск сервера приложений NGINX Unit 1.11.0"	+1 +/–
	Сообщение от Valentin V. Bartenev (?), 20-Сен-19, 15:29
	А о каких конкретно доработках идет речь? Множество доработок происходит регулярно. Количество реализуемых фич с момента создания компании возросло в разы, но в 10 раз увеличилось и количество пользователей. По trac-у очень сложно судить о востребованности той или иной функциональности. Мы собираем информацию из множества разных источников.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	42. "Выпуск сервера приложений NGINX Unit 1.11.0"	–1 +/–
	Сообщение от Аноним (42), 20-Сен-19, 15:50
	1. https://trac.nginx.org/nginx/ticket/1083 2. https://trac.nginx.org/nginx/ticket/1388 3. HPACK Dynamic Table Size in HTTP/2 https://http2.github.io/http2-spec/compression.html#dynamic.... 4. Accept-Encoding The "identity" content-coding is always acceptable, unless specifically refused because the Accept-Encoding field includes "identity;q=0", or because the field includes "*;q=0" and does not explicitly include the "identity" content-coding. If the Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable. 5. HTTP/2 prioritization is intermittent and often ineffective https://trac.nginx.org/nginx/ticket/1763 6. AIO kernel feature io_uring pool Linux kernel 5.1+ Продолжать?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	45. "Выпуск сервера приложений NGINX Unit 1.11.0"	+8 +/–
	Сообщение от Valentin V. Bartenev (?), 20-Сен-19, 18:00
	1. По многим реализуемым фичам поступают десятки запросов в месяц, а тут 1 человек тикет создал и 1 человек в нем отметился. Итого целых два человека за три года. И не понятно, что мешает выключить gzip для проксируемых запросов. И это решение человек сам в том же тикете обнаружил. Вообще выключать компрессию для динамических HTML ответов - идея так себе. Тогда компрессия и не особо нужна, статика браузером будет кэшироваться и для нее есть gzip_static. Если у вас злоумышленник может извне свободно контролировать содержимое ответа сервера конкретному пользователю, то у вас проблемы по умолчанию. С компрессией или без. 2. Для CF было толково в рассылке разобрано, почему это нормально не работает в реальных сетях, но они очень любят пиарить себя любимых. 3. Было бы конечно не лишним. Но не всегда и не для всех. При достаточно смешной экономии на заголовках, получаем существенное увеличение расхода памяти на каждое соединение. HTTP/2 сам по себе и так довольно затратный протокол, сплошной вектор для DoS-атак, а тут ещё дополнительные накладные расходы возникнут. 4. Ни одного запроса про это вспомнить не могу. Впрочем я уже не слежу так активно, так что не могу прокомменитровать никак. 5. Максим в тикете дал ответ. Проблемы HTTP/2 более-менее решаются с помощью HTTP/3, а остальное всё полумеры и различные хаки, ещё больше усложняющие и без того переусложненный протокол. Безусловно есть также и поле для улучшения в nginx в этом месте, но это не значит, что нужно все ресурсы тратить на игры в протокол от одной всем известной компании. 6. Для начала необходимо протестировать и измерить, есть ли какой-то выигрыш для паттерна использования nginx-а и стоит ли этот выигрыш тех возможных проблем и усложнений, с которыми предстоит иметь дело. Кроме того, на 5.1+ сейчас хорошо если хотя бы 1% установок nginx наберется, но скорее всего и того меньше. Это исключительно мой взгляд со стороны, поскольку непосредственно над nginx уже больше двух лет не работаю и никаких решений не принимаю. Крайне наивно пологать, что вот мы там в nginx такие сидим вредные и не хотим реализовывать те или иные фичи на радость пользователям. Все заняты делом и работают над задачами, которые формируются на основании комплексного анализа множества факторов, огромных объемов информации. Мы варимся в этом котле по меньшей мере пять дней в неделю на протяжении многих лет. Каждый день занимаемся этими вопросами. Это наша ежедневная работа, труд множества людей. Просто изнутри крупнейшего вендора серверного ПО с миллионами пользователей, ситуация и картина мира выглядит несколько иначе, нежели со стороны отдельных энтузиастов.
	Ответить \| Правка \| Наверх \| Cообщить модератору