После года разработки представлена (http://nginx.org/#2014-04-24) новая стабильная ветка высокопроизводительного HTTP-сервера nginx 1.6.0 (http://nginx.org/), которая вобрала в себя изменения, накопленные в рамках основной ветки 1.5.x. В дальнейшем все изменения в стабильной ветке 1.6 будут связаны с устранением ошибок и внесением незначительных улучшений, не нарушающих API. Одновременно сформирована (http://mailman.nginx.org/pipermail/nginx-announce/2014/00013...) основная ветка nginx 1.7, в рамках которой будет продолжено развитие новых возможностей.
Из улучшений (http://nginx.org/ru/CHANGES.ru-1.6), добавленных в процессе формирования основной ветки 1.5.x, можно отметить:- Новый модуль ngx_http_auth_request_module (http://nginx.org/ru/docs/http/ngx_http_auth_request_module.html), для организации авторизации клиента на основании результата запроса по определённому URI (например, при успешной авторизации в другой директории);- В модуле ngx_http_spdy_module (http://nginx.org/ru/docs/http/ngx_http_spdy_module.html) добавлена поддержка протокола SPDY 3.1 (http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-dra...). Для ограничения скорости передачи ответов клиенту в SPDY-соединениях теперь допускается использовать директиву limit_rate;
- В модуль ngx_http_proxy_module (http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#pro...) добавлена возможность подтверждения корректности содержимого просроченных элементов кэша при помощи условных запросов с полем заголовка If-Modified-Since;- Новые переменные: $ssl_session_reused и $proxy_protocol_addr;- Новые директивы:- ssi_last_modified, sub_filter_last_modified и
xslt_last_modified;- fastcgi_buffering;- proxy_cache_revalidate, fastcgi_cache_revalidate, scgi_cache_revalidate и uwsgi_cache_revalidate;- ssl_buffer_size, ssl_session_ticket_key, ssl_session_tickets;- proxy_ssl_protocols и proxy_ssl_ciphers;- spdy_chunk_size;- Возможность использования нескольких директив error_log;- В директивы allow и deny добавлена поддержка unix domain сокетов;- В директиву listen добавлена поддержка параметра fastopen;- В директивы proxy_next_upstream,
fastcgi_next_upstream, scgi_next_upstream и uwsgi_next_upstream добавлена поддержка параметра http_403;
- Директива disable_symlinks теперь использует O_PATH в Linux;- При использовании длинных цепочек сертификатов задействована
оптимизация SSL handshake;- В почтовый прокси-сервер добавлена поддержка SMTP pipelining;- В resolver добавлена поддержка IPv6;- В секцию contrib добавлены скрипты для подсветки синтаксиса в vim- В модуль ngx_http_uwsgi_module добавлена поддержка SSL;- В модуле ngx_http_mp4_module обеспечен пропуск дорожек,
имеющих меньшую длину, чем запрошенная перемотка. Обеспечена поддержка byte ranges и аргумента end;
- В директивы listen и real_ip_header добавлен параметр proxy_protocol;- Поддержка byte ranges при сохранении ответов в кэш.
Новшества (http://nginx.org/en/CHANGES), представленные в выпуске nginx 1.7.0:
- Поддержка верификации сертификатов SSL-бэкендов;
- Поддержка SNI (Server Name Indication, позволяет обеспечить доступ через шифрованное соединение к виртуальным хостам на одном IP) при работе с SSL-бэкендами;
- Новая переменная $ssl_server_name.
- Возможность использования параметра "if" в директиве access_log.
URL: http://mailman.nginx.org/pipermail/nginx-announce/2014/00013...
Новость: http://www.opennet.me/opennews/art.shtml?num=39638
Ну и комбайн, скоро апач догонит.
Уже перегнал. Апач не может в SMTP, IMAP и POP3.
А ему это надо?
Ему уже ничего не надо.
Я бы с большим интересом выслушал рассказ о месте апача в мире образца 2014 года.
Кроме очевидных случаев legacy, конечно.
С учетом наличия ngx_lua и сопутствующих модулей.
(Про фронтенд не будем, разумеется, дабы не избивать младенцев^W старцев совсем больно).А так-то в своё время 1.3.x был очень хорош. А вместе с mod_perl так и просто ultimate.
Только с тех пор много воды утекло.
(из любопытства - нет, я реально не слежу за ситуацией) - nginx уже научился htaccess?
Т.е. не общему конфигу, перечитываемому через restart/reload, а "изменил кто-нибудь настройки данного каталога - и на лету то, что под ним стало отдаваться иначе".По-моему, раньше утверждалось, что nginx "ради скорости" by design такого никогда не сможет. Поменяли что-нибудь - скажите админу пере
грузить конфиг, иначе ничего не подхватится.
> Поменяли что-нибудь - скажите админу перегрузить конфиг, иначе ничего не подхватится.ай беда... как же теперь быть шаредпомойкам...
> ай беда... как же теперь быть шаредпомойкам...Учитывая, что шаредпомойки - это не меньше половины рынка вебни, правильно сказать "как же быть Сысоеву?"
Да, вполне кейс. Хотя, конечно, considered "нинужна" (http://wiki.nginx.org/LikeApache-htaccess), но мы не станем им уподобляться.
Я бы, наверное, написал для таких кейсов пятнадцатистрочник, ловящий через inotify изменения и шлющий nginx-у сигнал перечитать конфиг - и странно если никто его, в общем виде с конфигурируемостью и прочим не написал, но может я чего не вижу, сонный.
На то есть важная причина. В случае некорректного .htaccess'а проблеме будет подвержена только директория, в которой он лежит. В случае некорректного инклюда в nginx.conf весь релоад зафейлится, а после экстренного ребута сервера nginx вообще не взлетит, пока этот инклюд не поправят.
> На то есть важная причина. В случае некорректного .htaccess'а проблеме будет подвержена
> только директория, в которой он лежит. В случае некорректного инклюда в
> nginx.conf весь релоад зафейлится, а после экстренного ребута сервера nginx вообще
> не взлетит, пока этот инклюд не поправят.Странно сначала релоад непроверенный и сразу же reboot экстренный, ну так никто не мешает и httpd.conf поломать...
Ну так никто не пускает жопоруких кодеров в httpd.conf. .htaccess же они править могут. Это дает возможность позволить им переопределять конфигурацию сервера для себя, не мешая жить другим даже в случае синтаксических ошибок.
> Ну так никто не пускает жопоруких кодеров в httpd.conf. .htaccess же они
> править могут. Это дает возможность позволить им переопределять конфигурацию сервера для
> себя, не мешая жить другим даже в случае синтаксических ошибок.Да это понятно, но в nginx-е не нужно (ИМХО), другая модель работы (он же идейно скорее замена lighttpd ).
Кстати видел рекламу шаред-хостингов с front-end на nginx, вероятно как то решают такие вопросы.
Ну придется добавить проверку (вызов nginx с ключом -t, и посылать сигнал только если ОК), большое дело.
Вы не поняли. В случае наличия одного некорректного инклюда не удастся добавлять/менять никакие другие инклюды, пока тот не пофиксят. поэтому для сценария использования .htaccess такой метод неприемлем - все-таки один сломанный .htaccess не мешает остальным.
Я ниже дописал об этом
> после экстренного ребута сервера nginx вообще
> не взлетит, пока этот инклюд не поправят.Это неприятно, да.
Модуль мог бы инклудить только то что корректно, но так с разбегу не уверен что это можно корректно реализовать используя только "законные" API nginx-а.
Впрочем, те, кому это действительно нужно, могли бы и патч поддерживать, он простенький же должен получаться.
> Впрочем, те, кому это действительно нужно, могли бы и патч поддерживать, он
> простенький же должен получаться.Это много кому нужно, но в мейнстрим не пустят принципиально, так что гемор получится приличный.
А в мейнстрим, скорее всего, не пускают, чтобы сделать это в качестве эксклюзивной фичи nginx gold enterprise edition.
> а после экстренного ребута сервера nginx вообще не взлетит,В нормальных ДЦ не бывает "экстренных ребутов", ибо вменяемые админы и бесперебойники.
> В нормальных ДЦ не бывает "экстренных ребутов", ибо вменяемые админы и бесперебойники.И бэкапов там не делают, по той же причине.
Смысл nginx именно в том что бы сократить время/ресурсы на обработку запроса, парсить конфиг на ходу дурацкая с точки зрения производительности идея. Почему не сделано автоматическое обновление, тоже понятно, reload позволяет не применять настройки если они кривые, что очень удобно в использовании.
У этого решения есть плюсы и минусы, основной плюс - скорость работы.
Я не про дурацкая/не дурацкая (можно сделать опцией, в конце концов.. хоть на стадии компиляции), а про кейз. Он реально существует и востребован, и это один из примеров, где nginx до httpd не дотягивает.
> Я не про дурацкая/не дурацкая (можно сделать опцией, в конце концов.. хоть
> на стадии компиляции), а про кейз. Он реально существует и востребован,
> и это один из примеров, где nginx до httpd не дотягивает.Для этого есть apache, зачем оно в nginx, если для shared-хостинга хочется организовать именно nginx в фронт-end и с поддержкой какой-то части .htaccess, то это можно сделать скриптами с проверкой, но ведь функциональность того же .htaccess зависит от набора модулей apache, сначала добавим access/deny туда, потом функции mod_rewrite, потом настройки mod_php ( а с nginx-ом как его запустить то ;) ) и так далее, в итоге получим тот же монструозный apache, который уже есть и в котором исправлены многие детские промахи, памяти он тоже будет жрать не как сейчас.
NikolayV81,Если за nginx стоит апач, то mod_rewrite отлично работает для php-скриптов, например.
В подавляющем большинстве случаев он только для этого и нужен (по опыту в хостинге).
> уже научился htaccess?Он не научится ему никогда. Если вам на эффективность и скорость пофиг и надо вашу cpaную общественную помойку в виде шаредхостинга где 100500 ничего не делающих "сайтов" свалено - вам на опач, гoвнo в гoвнe не тонет как раз. А нжинкс пытается обрабатывать запросы эффективно. Лишние чтения файловых систем почем зря - явно не в тему.
> (из любопытства - нет, я реально не слежу за ситуацией) - nginx
> уже научился htaccess?Наверное никогда.
Но это нужно, по большому счету, только на шаред хостингах.
Ну и на хостингах разрабов (которые пишут сайты для размещения на шаред хостингах).
Т.е. это одна ниша, причем не самая большая.
А для своего сайта логику из htaccess можно впихнуть в конфиг nginx.
Апача хрен догонишь по пожирону ресурсов и неэффективной отгрузке статики.
> Ну и комбайн, скоро апач догонит.Nginx крут тем что уже достаточно фичаст для того чтобы им можно было пользоваться, а не чертыхаться на все и вся, но при этом намного быстрее и легче чем апач. А замена апача на нжинкс на сайте отгружающем пнг и жыпег оказалась заметна на глаз. Так что авторы нжинкса могут собой гордиться - редкое явление когда продукт такого плана можно заметить невооруженным глазом.
> Nginx крут тем что уже достаточно фичаст для того чтобы им можно было пользоваться, а не чертыхаться на все и всяЧтобы не чертыхаться на отсутствие поддержки htaccess, нужна исключительная сила воли и любовь к Сысоеву.
>> Nginx крут тем что уже достаточно фичаст для того чтобы им можно было пользоваться, а не чертыхаться на все и вся
> Чтобы не чертыхаться на отсутствие поддержки htaccess, нужна исключительная сила воли и
> любовь к Сысоеву.htaccess не нужен всем поголовно.
Да, шаред хостингам он нужен, т.к. ещё полно cms'ок, которые написаны так, чтобы его использовать.
Поэтому на шаред хостингах стоит апач бекендом (а фронтенд - давно nginx).
Но и то - просто потому, что клиенты не умеют/не хотят отказаться от htaccess.
А клиент платит - клиент получает.
Это единственная объективная причина, когда можно оставить apache.
Ах да, ещё есть свой хостинг разработчиков, которые пишут сайты на заказ.
Но это подвид шаред хостинга - все делается для клиента.В остальных случаях (т.е. когда сайт свой) можно сказать, что все упирается в скилл/лень админов и разработчиков.
Т.е. причины уже субьективные.
Разработчики также сделали опрос для сообщества, чтобы лучше спланировать будущие релизы:
http://mailman.nginx.org/pipermail/nginx/2014-April/043282.html
Там какие-то глупые вопросы.
> Там какие-то глупые вопросы.Вопросы как вопросы. Вполне можно и фи высказать и похвалить и указать что не так.
>Разработчики также сделали опрос для сообщества, чтобы лучше спланировать будущие релизы:https://www.surveymonkey.com/s.aspx?sm=nQUaqZCCgCT1gpjs%...
aspx?
> aspx?Это вообще совершенно посторонний ресурс занимающийся проведением опросов. Хотя, конечно, aspx в опросе про nginx - это да, фэйловато :). Могли бы нанять пару веб-обезьянок, они бы формы для опроса за пару дней накодили без таких фиаско.
>> aspx?
> Это вообще совершенно посторонний ресурс занимающийся проведением опросов. Хотя, конечно,
> aspx в опросе про nginx - это да, фэйловато :). Могли
> бы нанять пару веб-обезьянок, они бы формы для опроса за пару
> дней накодили без таких фиаско.спасибо, капитан.
Оно еще и символично. На CDN nginx, а сзади IIS.
> Оно еще и символично. На CDN nginx, а сзади IIS.Ну да, IIS гомно. Вы не знали? Сюрприз. Остается правда вопрос - зачем платить за серверную винду и IIS? Кроме "тyпость админов/манагеров упомянутого ресурса" разумных ответов в голову не приходит. А нжинкс приделали уже потом, когда заметили что IIS под нагрузкой жидко сдpиcтывает.
>/s.aspx?sm=nQUaqZCCgCT1gpjs+uGOvw==
> aspx?Ты бы хотел, чтоб в следующий раз опрос был на mod_lua? /s.lua?sm=nQUaqZCCgCT1gpjs+uGOvw==, да?
>>/s.aspx?sm=nQUaqZCCgCT1gpjs+uGOvw==
>> aspx?
> Ты бы хотел, чтоб в следующий раз опрос был на mod_lua?
> /s.lua?sm=nQUaqZCCgCT1gpjs+uGOvw==, да?ngx_lua_module, двоешниг, mod_штота это опач.
а опач нужен в 2014 году только для того чтобы организовать http[s] перед svn и на этом, пожалуй, все.
> а опач нужен в 2014 году только для того чтобы организовать http[s]
> перед svn и на этом, пожалуй, все.Ещё redmine (и ещё что-нибудь на ruby пускать) через mod_passenger, а потом лениться переделывать :)
Рекомендуется использовать основную ветку: http://nginx.com/blog/nginx-1-6-1-7-released/
> Рекомендуется использовать основную ветку: http://nginx.com/blog/nginx-1-6-1-7-released/Рекомендуют, так как им тестировщики нужны. Поэтому в своё время они unstable в mainline и переименовали, но суть мало изменилась.
> Рекомендуют, так как им тестировщики нужны.А они не думали что тестировщик - это профессия такая? Раз уж они корпорация с коммерческими блобиками - наверное можно и команду тестировщиков тогда нанять.
> А они не думали что тестировщик - это профессия такая? Раз уж
> они корпорация с коммерческими блобиками - наверное можно и команду тестировщиков
> тогда нанять.Использовать халявных - более выгодно, так как снижает расходы компании. BSD-way же!
УРА! sni!!!!
> УРА! sni!!!!Вы так бурно радуетесь тому, что SNI в сторону клиента поддерживается, начиная с 0.5.23, вышедшей 7 лет назад? :)
Или вы прямо жить не могли без SNI в сторону бэкенда?
Зачем запятая перед "что"?
> УРА! sni!!!!Интересно, напуркуа брать SNI от бекенда.
вопрос чайника - а оно с вебсокетами еще не дружит ?
последний раз глядел на это чудо, когда - не было :/
http://nginx.org/en/docs/http/websocket.html
http://nginx.org/ru/docs/http/websocket.html
nginx шаред хостингу не нужен даже перед апачем. Где он будет хранить n TB статики? А еще в шаред хостинге нет необходимости в эффективности. А если речь идет о быстродействии php на толстых серверах, то одним nginx там тоже не обойтись. Опять же, .htaccess это не только простота и гибкость, но и безопасность. Так что каждому свое и каждый для своего.
Нужен, чтобы у апача воркеры подолгу не висели во время отдачи ответов сервера. Апач гораздо лучше работает по принципу: быстро получил запрос от nginx - обработал - быстро отдал ответ nginx'у, чем по принципу: принял запрос от (потенциально медленного, напр. мобильного) клиента - обработал запрос - медленно отдал ответ клиенту.
Может все-таки префорки, а не воркеры?