Comments 57
Да, с удалением spdy весело, если mainline репозиторий был подключен и использовалось автоматическое обновление. Т. е. обновишься с 1.9.4 на 1.9.5 и не заметишь, что после reload всё ещё 1.9.4 работает, т. к. конфиги стали невалидными.
Жалко, что server push пока не поддерживается в http2, хотя и не понятно, как он должен работать, если nginx используется в качестве reverse proxy и upstream не использует http2.
Жалко, что server push пока не поддерживается в http2, хотя и не понятно, как он должен работать, если nginx используется в качестве reverse proxy и upstream не использует http2.
UFO just landed and posted this here
Это не так. В http2 устанавливается TLS соединение и в client hello обычно используется NPN/ALPN. Далее:
— если сервер поддерживает NPN/ALPN, то он отдаёт доступные протоколы в server hello и клиент, выбрав один, передаёт его в encrypted extensions во второй фазе handshake'а, далее клиент уже работает по http2;
— если сервер не поддерживает NPN/ALPN, то используется http/1.1 over TLS и делается http upgrade (что требует ещё не менее 2x RTT).
— если сервер поддерживает NPN/ALPN, то он отдаёт доступные протоколы в server hello и клиент, выбрав один, передаёт его в encrypted extensions во второй фазе handshake'а, далее клиент уже работает по http2;
— если сервер не поддерживает NPN/ALPN, то используется http/1.1 over TLS и делается http upgrade (что требует ещё не менее 2x RTT).
Никакого http upgrade не делается, просто работает и дальше по https.
Не прав ни я, ни вы. В http/2 upgrade поддерживается только для h2c (cleartext) и запрещено использование upgrade поверх h2.
Т. е., если клиент не поддерживает ALPN — он сразу идёт лесом, на обычный http/1.1 over TLS.
Видимо, мне в мозг запало обсуждение этого драфта.
A client that makes a request for an «http» URI without prior knowledge about support for HTTP/2 on the next hop uses the HTTP Upgrade mechanism (Section 6.7 of [RFC7230]). The client does so by making an HTTP/1.1 request that includes an Upgrade header field with the «h2c» token.http2.github.io/http2-spec/#rfc.section.3.2
…
A server MUST ignore an «h2» token in an Upgrade header field. Presence of a token with «h2» implies HTTP/2 over TLS, which is instead negotiated as described in Section 3.3.
A server that supports HTTP/2 accepts the upgrade with a 101 (Switching Protocols) response. After the empty line that terminates the 101 response, the server can begin sending HTTP/2 frames. These frames MUST include a response to the request that initiated the upgrade.
Т. е., если клиент не поддерживает ALPN — он сразу идёт лесом, на обычный http/1.1 over TLS.
Видимо, мне в мозг запало обсуждение этого драфта.
Сам скрипт запускается посредством директивы js_run и позволяет прямо на стороне сервера (что я несу?)… Нет, прямо в самом сервере выполнять многие низкоуровневые операции с запросом, без необходимости написания отдельного модуля на языке Си/Lua или на чем там еще пишут и решают такие задачи.Относительно простые вещи раньше можно было делать на lua и perl. Чтобы написать модуль для nginx'а на C надо очень заморочиться. Документации по nginx internals не сильно много, комментарием в коде и того меньше…
Больше ада в конфигах с новым nginScript!
Так скоро и приложения на nginx писать начнут :)
уже :-) пример выше показывает, что на фибоначчи не останавливаются…
Приложения уже писали/пишут, но на Lua и фреймворке habrahabr.ru/post/240217
Но сообщество Lua web-разработчиков сильно меньше, чем сообщество JS разработчиков.
Игорь Сысоев решил это исправить =)
Но сообщество Lua web-разработчиков сильно меньше, чем сообщество JS разработчиков.
Игорь Сысоев решил это исправить =)
Nginx.js :-)
На мой взгляд было бы удобнее все выносить в отдельный файл в виде директивы js_load.
Статья об этом на OpenNet/Лоре была неделю назад. В действительно очень интересно посмотреть на сравнение производительности, а не на плагиат.
Обколются своей марихуаной и кодят javascript в конфигах.
«Не нужно программировать на конфигах nginx». Видимо, кто-то уже устал говорить эту фразу, превратив её в «А, чёрт с вами, программируйте!». Мне уже становится страшно, как представлю, что наши товарищи разработчики попытаются запихнуть туда из логики приложения.
Да, программировать конечно же не нужно. Но вдруг надо сделать какой-то подвыперт…
…
прошло еще 30 лет… В ВУЗЕ преподают низкоуровненвое программирование. Преподаватель:
… JavaScript — это ассемблер, язык на котором написано всё…
- Когда-то говорили что на JS не напишешь ничего хорошего… Не пытайтесь даже...
- Потом говорили — Js на сервере? Ха, смешно, но играйтесь, если так нравится. Но оно не взлетит...
- Операционная система на JS? Ой, как забавненько, но оно не взлетит...
- Плагины для браузера на JS — интересная идея, но на С++ будет лучше...
- Браузер на JS — не смешите меня...
- Десктопное приложение на JS — ну хватит уже...
- IDE на JS — да ты упоротый...
- Программировать микроконтроллеры на JS??? — 0_о ...
- Конфиги для Nginx на JS — блин, ну не смешно же...
…
прошло еще 30 лет… В ВУЗЕ преподают низкоуровненвое программирование. Преподаватель:
… JavaScript — это ассемблер, язык на котором написано всё…
Я надеюсь WebAssembly и спрос на производительный веб избавит нас от подобного будущего. Распространеность этого языка обусловлена ростом веба и соответствующим спросом на разработчиков, умеющих программировать под единственый язык, заимплеменченный во всех браузерах.
Осталось объяснить популярность всего остального в списке, начиная с Node.js
Вот уж микроконтроллеры явно не фронтендеры программируют.
Вот уж микроконтроллеры явно не фронтендеры программируют.
Цепная реакция, начавшаяся именно с Node.js во многом благодаря чистым фронтендерам с одной стороны, и фулл-стэкерам, не дождавшимся возможности писать нормально для браузеров на любимом языке :)
Ну давай пройдусь по пунктам:
1. Приложения в браузере. Ну… Эта, давайте я не буду напоминать лишний раз о том, что приложения в браузере не дотягивают до уровня десктопных?
2. Node.js — изоморфные приложения, избавление от необходимости дублировать логику, серверный рендринг страниц и прочие плюшки. Популярность понятна.
3. Операционная система на js? NodeOs что-ли? Это там где взяли linux, выкинули bash и поставили node.js? Мне чё, сделать brainfuck os, чтобы показать абсурдность ситуации? Или может имеются в виду всякого рода веб-оси, которые прикольны только как концепт, но ничего сделать не позволяют?
4. Плагины для браузера на js? Логично их писать на js, раз веб пишется на js. А давать возможность писать их на C++ — упадет, поломает, уязвимости всякие.
5. Браузер на JS? Ну давайте, покажите мне браузер на js. Я например пользуюсь Вивальди, у которого UI сделан на react. Да, UI написан на javascript. Глюки пока списываю на то, что браузер не вышел в релиз, однако некоторые артефакты весьма специфичны для глюкавых html/css. Если подключиться к самому вивальди через developer tools, то можно увидеть засранную консоль от ошибок типичных для языка с динамической типизацией. Однако это UI, сам браузер написан на другом языке.
6. Десктопное приложение на JS? Ну, в эпоху когда люди хотят все онлайн, то написать веб-приложение, а потом упаковать его node-webkit выглядит логичным решением. Или нет?
7. IDE на JS? О да, я даже знаю одну такую — LightTable. Правда она написана на clojurescript. Просто у людей, которые её писали был выбор между clojure (компилится в java) и clojurescript (компилится в javascript). Так уж получилось, что писать UI оптимальнее с использованием html/css/js. Будет WebAssembly — будет транскомпиляция туда. Работает кстати хорошо, быстренько вроде. Правда консоль опять же засрана типичными ошибками для языков с динамической типизацией.
8. Микроконтроллеры на JS? А почему вы уверены, что их не фронтендеры программируют? И вообще, как насчет python, rust? Это просто удешевление рынка игрушек для гиков. Гугление показало, что в тех микроконтроллерах характеристики лучше, чем у моего первого компьютера (если что, я молод душой и телом). Рост характеристик позволил писать программы на языках с динамической типизацией. А я таки уверен, что среди фронтенд разработчиков много людей, которым интересны такого рода игрушки. Спрос есть, возможность есть — банальные законы рынка. Но если рассматривать не игрушечный бизнес, то сколько компаний пишут софт для микроконтроллеров на javascript?
9. Конфиги на JS? Внимательное чтение статьи намекает, что это не javascript, а всего-лишь диалект. Кроме того, ну а чем javascript не хороший язык для скриптов? Ведь он для них и задумывался. Вот приложения на нем писать больно, да, а скрипты норм.
Вообще, еще можно вспомнить mongodb и couchbase, как базы данных, в которых юзается javascript для юзерских скриптов. Но все это не важно. Веб порождает спрос на javascript разработчиков, javascript разработчики порождают спрос на плюшки, с которыми они могут работать. Вопрос заключается в том, как быстро сойдет спрос на javascript разработчиков, когда появятся реальные альтернативы, а не транскомпиляторы недоделанные?
Давайте представим гипотетическую ситуацию. Какая-нибудь компания стартует большой проект. У компании есть выбор между двумя языками программирования: каким-нибудь из хороших и javascriptом. При сравнении эти языки оказываются одинаковыми по дешевизне разработки, количеству разработчиков, количеству библиотек и прочее-прочее в рамках этого проекта. Как много компаний вы знаете, которые выбрали или пожелали бы выбрать javascript потому что ну это же javascript — клёвый язык программирования; и разработчики под него хорошие и толковые; и завершим мы проект пораньше, потому что язык такой хороший?
1. Приложения в браузере. Ну… Эта, давайте я не буду напоминать лишний раз о том, что приложения в браузере не дотягивают до уровня десктопных?
2. Node.js — изоморфные приложения, избавление от необходимости дублировать логику, серверный рендринг страниц и прочие плюшки. Популярность понятна.
3. Операционная система на js? NodeOs что-ли? Это там где взяли linux, выкинули bash и поставили node.js? Мне чё, сделать brainfuck os, чтобы показать абсурдность ситуации? Или может имеются в виду всякого рода веб-оси, которые прикольны только как концепт, но ничего сделать не позволяют?
4. Плагины для браузера на js? Логично их писать на js, раз веб пишется на js. А давать возможность писать их на C++ — упадет, поломает, уязвимости всякие.
5. Браузер на JS? Ну давайте, покажите мне браузер на js. Я например пользуюсь Вивальди, у которого UI сделан на react. Да, UI написан на javascript. Глюки пока списываю на то, что браузер не вышел в релиз, однако некоторые артефакты весьма специфичны для глюкавых html/css. Если подключиться к самому вивальди через developer tools, то можно увидеть засранную консоль от ошибок типичных для языка с динамической типизацией. Однако это UI, сам браузер написан на другом языке.
6. Десктопное приложение на JS? Ну, в эпоху когда люди хотят все онлайн, то написать веб-приложение, а потом упаковать его node-webkit выглядит логичным решением. Или нет?
7. IDE на JS? О да, я даже знаю одну такую — LightTable. Правда она написана на clojurescript. Просто у людей, которые её писали был выбор между clojure (компилится в java) и clojurescript (компилится в javascript). Так уж получилось, что писать UI оптимальнее с использованием html/css/js. Будет WebAssembly — будет транскомпиляция туда. Работает кстати хорошо, быстренько вроде. Правда консоль опять же засрана типичными ошибками для языков с динамической типизацией.
8. Микроконтроллеры на JS? А почему вы уверены, что их не фронтендеры программируют? И вообще, как насчет python, rust? Это просто удешевление рынка игрушек для гиков. Гугление показало, что в тех микроконтроллерах характеристики лучше, чем у моего первого компьютера (если что, я молод душой и телом). Рост характеристик позволил писать программы на языках с динамической типизацией. А я таки уверен, что среди фронтенд разработчиков много людей, которым интересны такого рода игрушки. Спрос есть, возможность есть — банальные законы рынка. Но если рассматривать не игрушечный бизнес, то сколько компаний пишут софт для микроконтроллеров на javascript?
9. Конфиги на JS? Внимательное чтение статьи намекает, что это не javascript, а всего-лишь диалект. Кроме того, ну а чем javascript не хороший язык для скриптов? Ведь он для них и задумывался. Вот приложения на нем писать больно, да, а скрипты норм.
Вообще, еще можно вспомнить mongodb и couchbase, как базы данных, в которых юзается javascript для юзерских скриптов. Но все это не важно. Веб порождает спрос на javascript разработчиков, javascript разработчики порождают спрос на плюшки, с которыми они могут работать. Вопрос заключается в том, как быстро сойдет спрос на javascript разработчиков, когда появятся реальные альтернативы, а не транскомпиляторы недоделанные?
Давайте представим гипотетическую ситуацию. Какая-нибудь компания стартует большой проект. У компании есть выбор между двумя языками программирования: каким-нибудь из хороших и javascriptом. При сравнении эти языки оказываются одинаковыми по дешевизне разработки, количеству разработчиков, количеству библиотек и прочее-прочее в рамках этого проекта. Как много компаний вы знаете, которые выбрали или пожелали бы выбрать javascript потому что ну это же javascript — клёвый язык программирования; и разработчики под него хорошие и толковые; и завершим мы проект пораньше, потому что язык такой хороший?
Но если рассматривать не игрушечный бизнес, то сколько компаний пишут софт для микроконтроллеров на javascript?
Может не прямо для микроконтроллеров, но для ембедед девайсов пишут (или аутсорясят разработку) на джс мировые (не ИТ) бренды.
Пруфы?
NDA
Но если посмотрите вокруг себя на девайсы с экранами, может даже тач, но не являющиеся пк, смартфонами, планшетами и т. п., то в многих из них как минимум веб-морда к функциональности, будет выглядить достойной для рассмотрения альтернативой нативным гуи-приложениям.
Но если посмотрите вокруг себя на девайсы с экранами, может даже тач, но не являющиеся пк, смартфонами, планшетами и т. п., то в многих из них как минимум веб-морда к функциональности, будет выглядить достойной для рассмотрения альтернативой нативным гуи-приложениям.
Т.е. только отрисовка UI? А альтернативой им будет C++ под кастомную платформу, более дорогие и редкие разработчики и сложности при разработке связанные с тем, что нету эмулятора устройства? Ну в данном случае это действительно хороший выбор по дешевизне разработки.
Разные варианты встречаются. Только работа веб-UI с локальным сервером на Сях или Питоне, взаимодействующим с миром и железом — минимальный. Максимум, пожалуй — всё нестандартное на джсе, если периферия типа купюропреемника или датчика скорости на стандартных интерфейсах типа юсб или ком (не редкость). Средний вариант — обвязка (высокоуровневые драйверы поверх низкоуровневых от вендора) для железа на Сях, локальный сервер и ЮИ на джсе.
Но вдруг надо сделать какой-то подвыперт…
Вроде везде черным по белому пишут, что на nginx не надо программировать. Не сталкивался с ситуацией, когда можно было бы реализовать какую либо фичу только программированием в конфигах… Поправьте, если это не так.
Все что описано в статье предлагают сами разработчики Nginx. Как пример, они говорят про сложные роутинги динамические, персональные ссылки, авторизацию и так далее…
Да, я понимаю, что это разработчики nginx. Но ведь согласитесь, что с точки зрения архитектуры, эти задачи находятся на логическом (бизнес) уровне приложения. Мне как то странно думать, что веб сервер, в задачи которого входит отдача статического контента и проксирование, будет вместо приложения рулить роутингом или авторизацией…
Единственное что приходит на ум в качестве примера использования таких модулей, это legacy код, который не можешь физически поправить, но при этом позарез нужен именно nginx. Но такие случаи достаточно редки в общей массе применений, поэтому поддержать это на уровне ядра… Ну не знаю, тот же Lua в модуле и никому не мешает. У кого есть надобность, тот и поставил и использует вполне осознанно.
Единственное что приходит на ум в качестве примера использования таких модулей, это legacy код, который не можешь физически поправить, но при этом позарез нужен именно nginx. Но такие случаи достаточно редки в общей массе применений, поэтому поддержать это на уровне ядра… Ну не знаю, тот же Lua в модуле и никому не мешает. У кого есть надобность, тот и поставил и использует вполне осознанно.
С Lua есть засада — его еще учить надо. Так что это те же возможности, но на другой лад. Я не сомневаюсь что это даже просто дань тренду. Вряд ли Луа медленнее получившегося JS. И в Lua больше возможностей из коробки, там интепретатор полноценный, а не урезанный.
На самом деле когда люди сами попробуют пописать конфиги — быстро пыл спадет. Отладка сложная, почему упал сервер — не сразу понятно. Так что это то еще развлечение.
На самом деле когда люди сами попробуют пописать конфиги — быстро пыл спадет. Отладка сложная, почему упал сервер — не сразу понятно. Так что это то еще развлечение.
А что с производительстью?
Сильно тормозить будет?
Сильно тормозить будет?
Статья написана в приятной манере хорошим языком. Побольше бы таких статей! Спасибо.
Интересно, на js можно будет в нгиксе сделать привязку агентов к апстримным серверам? Хоть через ту же куку.
Интересно, на js можно будет в нгиксе сделать привязку агентов к апстримным серверам? Хоть через ту же куку.
Вы про это?
Custom Request Routing.
With the location block in NGINX you can route traffic based on URI. With nginScript you can route traffic based on any data in the request, including cookies, headers, arguments, or any keywords in the request body. The following example routes traffic based on the presence of an argument named upstream:
upstream my_upstream0 {
server server1.example.com;
server server2.example.com;
}
upstream my_upstream1 {
server server3.example.com;
server server4.example.com;
}
js_set $my_upstream "
var s, upstream, upstream_num;
upstream = $r.args.upstream;
// convert upstream number to integer
upstream_num = +upstream | 0;
if (upstream_num < 0 || upstream_num > 1) {
upstream_num = 0;
}
s = 'my_upstream' + upstream_num;
s;
";
server {
listen 80;
location / {
proxy_set_header Host $host;
proxy_pass http://$my_upstream;
}
}
«У сервера Nginx резко увеличилась поверхность атаки»
Вирусы в конфигах — фрустрацирую, однако.
Когда люди качают докер, не вникая что внутри, когда выполняют рекомендации типа sudo wget ...../install.sh | bash. вирусы в конфиге уже не являются злом. Зато вот обфусцированный код в конфиге — это да. Написал конфиг, но не хочешь секрет раскрывать. Мол проприетарный он. Вот это поле для размышления =)
Прикольная штука. Интересно, будет ли этот модуль в поставке по умолчанию? Lua-то вроде не было, надо было компилить отдельно, а лень.
А вообще — давно пора, роутинг давно требует неких несложных вычислений в конфиге. Очень обидно ставить костылик на отдельный сервер, даже и через сокет, когда вопрос-то — всего лишь хэш от запроса, например.
А вообще — давно пора, роутинг давно требует неких несложных вычислений в конфиге. Очень обидно ставить костылик на отдельный сервер, даже и через сокет, когда вопрос-то — всего лишь хэш от запроса, например.
Читал https://t.co/F9K8oSjgQO и радостно, довольно, заливисто смеялся: сервер NGINX станет напоминать сервер Express.js в скором времени!…
— Mithgol (@FidonetRunes) 24 сентября 2015
Если кому-то интересно то дополню: есть похожая тема openresty.org Это похожая штука со встроенной Lua и кучей либ в придачу.
UFO just landed and posted this here
В блоге у них есть про причины создания собственной реализации: nginScript – Why Are We Creating Our Own JavaScript Implementation?. Если кратко — это не совсем JS как он есть. Это упрощенная модель для каких-то простых инструкций на высоконагруженном сервере. Для всего остального есть NodeJS =)
В 1.9.5 при включенном http2 SERVER_PROTOCOL пустой, а то мало ли.
Lua был хорошим претендентом, но он не так широко распространен в кругах web-разработчиков
Кто же допускает веб-разработчиков к серверным конфигам. Если идти дальше, то JavaScript тоже не очень распространён среди, скажем, маркетологов, даёшь nginVBA.
nginVBA — это JScript
ru.wikipedia.org/wiki/JScript
JScript – это версия JavaScript от Microsoft. JScript основан на реализации стандарта ECMAScript. Синтаксис JScript во многом похож на язык JavaScript. Так же используется при создании вэб-страниц ASP.
ru.wikipedia.org/wiki/JScript
Odin Ass забыли.
Sign up to leave a comment.
JavaScript и Nginx = nginScript, а HTTP2 в придачу