https://www.opennet.ru/openforum/vsluhforumID3/120398.html После года разработки представлена новая стабильная ветка высокопроизводительного HTTP-сервера и многопротокольного прокси-сервера nginx 1.18.0, которая вобрала в себя изменения, накопленные в рамках основной ветки 1.17.x. В дальнейшем все изменения в стабильной ветке 1.18 будут связаны с устранением серьёзных ошибок и уязвимостей. В скором времени будет сформирована основная ветка nginx 1.19, в рамках которой будет продолжено развитие новых возможностей. Для обычных пользователей, у которых нет задачи обеспечить совместимость со сторонними модулями, рекомендуется использовать основную ветку, на базе которой раз в три месяца формируются выпуски коммерческого продукта Nginx Plus...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52780<br> https://www.opennet.ru/openforum/vsluhforumID3/120398.html#64 Fri, 24 Apr 2020 22:27:07 GMT Для сложной конфигурации придуман njs. Ну или ngx-lua, если больше нравится.<br> https://www.opennet.ru/openforum/vsluhforumID3/120398.html#63 Thu, 23 Apr 2020 14:25:15 GMT Радуйтесь, вы имеете свою нишу :)<br> https://www.opennet.ru/openforum/vsluhforumID3/120398.html#62 Thu, 23 Apr 2020 14:07:24 GMT &gt; До-до, &#8230; лучше &#8230; поставить десяток сервисов,<br><br>Я не о сервисах. Я предлагал нашим разработчикам всю логику перенести с конфига в<br>самописный nginx_модуль.so. Сейчас вся логика отдачи защищённого контента реализована<br>на запутанном конфиге nginx + PHP.<br> https://www.opennet.ru/openforum/vsluhforumID3/120398.html#61 Thu, 23 Apr 2020 06:12:06 GMT &gt; что это что-то из академическое из OSI<br><br>сами эти названия - именно академическая бессмыслица из OSI. Им место там же, где "l3 switch".<br><br>Интересно, к какому дурацкому "уровню" у нас теперь относится http и как это протолкуют высокоучоные рэбе от computer science? Учитывая http/3, где "сессии" надо самому реализовывать, но можно ведь и не, и что это в одном сервисе с http/1.0<br><br>&gt;&gt; гиперусложненное многоуровневое ненужно проиграло наколенной поделке<br>&gt; это же стратегия nginx<br><br>да нет, вся беда nginx как раз в той простоте, что хуже воровства - отсюда и не-иерархический конфиг, потому что лень было продумывать, проще настроить 1:1 отображение внутренних никому неинтересных кишок в текстовую форму, и трахайся как хочешь - хоть свой парсер теперь пиши.<br>Там и метрики "коммерческие" только потому, что неоткуда нормальные метрики снимать - либо опять ненужные совсем внутренние потроха, гадать по которым желающих мало, либо надо городить специальную систему автогадания, а это уже перебор для админа а не разработ https://www.opennet.ru/openforum/vsluhforumID3/120398.html#60 Thu, 23 Apr 2020 01:51:45 GMT &gt; Причем большинство из них даже не в курсе, что это не "условности", а описание вполне реального, только мертвенького, сетевого стека - потому и мертвенького, что гиперусложненное многоуровневое ненужно проиграло наколенной поделке, разработчики которой ничего не слышали ни о каких "уровнях", и вовсе этой модели не придерживались.<br><br>Чудик, которому ты отвечал настолько неграмотный, что даже не знает что такое "Layer 4 Load balancer" и "Layer 7 Load balancer" предполагает что это что-то из академическое из OSI, а это просто такие же гуманитарные названия как и то что ты пишешь ниже... но ты заставил меня задуматься вот над этим:<br>&gt; гиперусложненное многоуровневое ненужно проиграло наколенной поделке<br><br>это же стратегия nginx<br> https://www.opennet.ru/openforum/vsluhforumID3/120398.html#59 Thu, 23 Apr 2020 01:41:40 GMT &gt; Запомни, малыш - сессии и OSI уровни - это условности которые вдалбливают книжки из прошлого века и преподы ничего кроме них не видившие. Нет ни сессий, ни OSI уровней, а есть пакеты и их содержимое.<br><br>А содержится в содержимом видимо смузи и фалафель, да?<br><br>L4 balancer и L7 balancer - это просто устойчивые названия типов балансировки. L4 занимается роутингом и портфорвардингом, а L7 проксированием. Они мало какое отношение имеют к академической модели OSI. <br><br>&gt; Как пример, балансировать FTP на основе только TCP сессий не получится, нужно лезть внутрь протокола<br><br>И не нужно тут мудрствовать лукаво про FTP. Во-первых его можно балансировать на L7 обычными сессиями. Да для этого потребуется двухплечная сетевая топология (с двумя подсетями) даже для L7<br>Вот пример сходу: https://gist.githubusercontent.com/erkie/922996a2ec4125d79c7f8772cda328ce/raw/1c3d61b44f8c394abdcc21f89d41aab73cfe6bf6/Load%2520Balancing%2520FTP.txt<br>Я бы сходу сделал через 2 подсети и DNAT, маркируя фаерволом привязку 21 к группе фиксиров https://www.opennet.ru/openforum/vsluhforumID3/120398.html#58 Thu, 23 Apr 2020 00:32:18 GMT До-до, наверное лучше вместо одного nginx который, собственно, делает одну задачу, эффективно раскидывая соединения и пакеты на бэкенды, с "большим конфигом" поставить десяток сервисов, каждый с чуть меньшим конфигом, зато в сумме в разы больше и разных форматов, и всем этим управлять.<br> https://www.opennet.ru/openforum/vsluhforumID3/120398.html#57 Thu, 23 Apr 2020 00:29:19 GMT &gt; до первого tcp fallback. Не надо его ТАК балансировать, он встроенным round-robin вполне нормально балансируется<br><br>Встроенным round-robin он очень плохо балансируется, об этом на каждом углу написано.<br><br>&gt; (а вот фейловерить - надо, времена когда можно было просто подождать второго сервера - давнооо прошли)<br><br>А балансировка и фейловер рука об руку идут.<br> https://www.opennet.ru/openforum/vsluhforumID3/120398.html#56 Wed, 22 Apr 2020 17:29:18 GMT Ваше мнение очень важно для нас.<br>