По маске пробегать относительно дешево, а написано другое, я же процитировал: нам приходится обрабатывать все наши коннекты и проверять их на получение данных, делая с них read
У select есть большой недостаток — мы не можем знать, какое именно событие произошло и с каким именно сокетом. Каждый раз, когда мы получаем процессорное время, нам приходится обрабатывать все наши коннекты и проверять их на получение данных, делая с них read. Если у нас будет 1000 соединений, а данные придут только по одному из них, то мы обработаем все 1000 соединений, чтобы найти нужный.
Тут написана неправда. Процитирую man: On exit, the sets are modified in place to indicate which file descriptors actually changed status.
Все родные модули написаны с учетом асинхронной архитектуры. С XSLT должно быть всё нормально, за исключением каких-то экстремальных случаев, когда у вас такой шаблон, что требует несколько секунд процессорного времени на обработку.
Просто многие авторы сторонних модулей не понимают как устроен nginx и в своих модулях могут блокировать обработку событий на долгое время (что недопустимо), например, подключаясь и запрашивая базу данных в блокирующем режиме.
На самом деле время обновляется каждую итерацию цикла обработки событий. В нормальной ситуации события обрабатываются мгновенно. Если у вас итерация обработки событий затянулась на секунды, то скорее всего это следствие кривого стороннего модуля, который заблокировал nginx или сервер уже не справляется с нагрузкой (рабочий процесс nginx оказался выгружен в своп, ему не дают процессорного времени или заблокирован на диске).
Стандарты пишутся точно такими же людьми. И помимо того, что людям в принципе свойственно ошибаться, авторы стандартов не всегда умнее разработчиков, которые по этим стандартам что-то реализовывают. Иногда, ради безопасности или эффективности, где-то приходится отступать от стандарта и думать своей головой.
Совсем недавно — это почти два года назад, начиная с nginx 1.9.0. =)
Исключить можно, для этого есть опция down у директивы server в блоке upstream. Не считая ряд сторонних модулей, есть статистика для бесплатной версии nginx в виде сервиса.
SSL или не SSL, а также детали соединения — не являются частью URI.
Типичный HTTP/1.1-запрос выглядит так:
GET /blog HTTP/1.1
Host: example.com
User-Agent: Mozilla...
Accept: text/html
и он так выглядит вне зависимости от того, по SSL/TLS он сделан или поверх голого TCP.
URI в данном случае /blog. POST-запросы с этой точки зрения выглядят точно также, только еще содержат тело. Так что ваша фраза:
На стороне nginx не реально воссоздать GET запрос и реальный IP-адрес клиента (какие данные точно не передаются сейчас не скажу). С телом POST и т. п. запросов проблем как раз не заметил
вообще лишена смысла.
Если вам обязательно знать, используется ли SSL/TLS или нет на соединении с клиентом с haproxy, так разнесите также эти соединения по разным портам. Пусть haproxy проксирует либо на один порт, либо на другой. В чем проблема?
Либо можно выкинуть haproxy, поставить nginx на его место — и тогда будет счастье. Всю информацию можно будет передавать в заголовках.
Для предотвращения DNS-спуфинга рекомендуется использовать DNS-серверы в защищённой доверенной локальной сети.
Встроенный резолвер заточен на производительность, для чего пришлось несколько пожертвовать безопасностью. Он не рассчитан на применение в незащищенных сетях. Не говоря уж о том, что задержка при обращении к гугловому серверу может сказаться на скорости обработки запроса, а его недоступность или неправильная работа и вовсе привести к недоступности вашего сервиса.
А, пардон, код в примере маску всё же проверяет. Но комментарий опять же вводит в заблуждение:
//Читаем данные из каждого сокета, так как не знаем какие события заставил ОС дать нам CPUПо маске пробегать относительно дешево, а написано другое, я же процитировал: нам приходится обрабатывать все наши коннекты и проверять их на получение данных, делая с них read
И код в примере именно так и делает зачем-то.
Тут написана неправда. Процитирую man:
On exit, the sets are modified in place to indicate which file descriptors actually changed status.Все родные модули написаны с учетом асинхронной архитектуры. С XSLT должно быть всё нормально, за исключением каких-то экстремальных случаев, когда у вас такой шаблон, что требует несколько секунд процессорного времени на обработку.
Просто многие авторы сторонних модулей не понимают как устроен nginx и в своих модулях могут блокировать обработку событий на долгое время (что недопустимо), например, подключаясь и запрашивая базу данных в блокирующем режиме.
На самом деле время обновляется каждую итерацию цикла обработки событий. В нормальной ситуации события обрабатываются мгновенно. Если у вас итерация обработки событий затянулась на секунды, то скорее всего это следствие кривого стороннего модуля, который заблокировал nginx или сервер уже не справляется с нагрузкой (рабочий процесс nginx оказался выгружен в своп, ему не дают процессорного времени или заблокирован на диске).
Это что-то новенькое. Можно подробнее?
Стандарты пишутся точно такими же людьми. И помимо того, что людям в принципе свойственно ошибаться, авторы стандартов не всегда умнее разработчиков, которые по этим стандартам что-то реализовывают. Иногда, ради безопасности или эффективности, где-то приходится отступать от стандарта и думать своей головой.
Совсем недавно — это почти два года назад, начиная с nginx 1.9.0. =)
Исключить можно, для этого есть опция
downу директивыserverв блокеupstream. Не считая ряд сторонних модулей, есть статистика для бесплатной версии nginx в виде сервиса.Вот nginx умеет UDP. Какой-нибудь DNS прекрасно балансируется.
Он уже научился балансировать HTTP/2 и UDP? =)
Если nginx работает слишком быстро, то его можно конечно притормозить с помощью Varnish, но я бы не советовал. =)
Обращаю внимание на две бессмысленные директивы
fastcgi_split_path_infoиfastcgi_indexвlocation ~* \.php$. Это либо ошибка, либо копипаста.Самый ужасный браузер с точки зрения поддержки стандартов. Критические баги в реализации HTTP/2 годами не исправляют, зато "быстрее и комфортнее".
SSL или не SSL, а также детали соединения — не являются частью URI.
Типичный HTTP/1.1-запрос выглядит так:
и он так выглядит вне зависимости от того, по SSL/TLS он сделан или поверх голого TCP.
URI в данном случае
/blog. POST-запросы с этой точки зрения выглядят точно также, только еще содержат тело. Так что ваша фраза:вообще лишена смысла.
Если вам обязательно знать, используется ли SSL/TLS или нет на соединении с клиентом с haproxy, так разнесите также эти соединения по разным портам. Пусть haproxy проксирует либо на один порт, либо на другой. В чем проблема?
Либо можно выкинуть haproxy, поставить nginx на его место — и тогда будет счастье. Всю информацию можно будет передавать в заголовках.
URI никогда не передается по proxy protocol, это уже часть HTTP запроса, которых может быть много в одном соединении. Спецификация тут: http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt
Всё должно работать без проблем, если правильно настроить. Реальный IP передается через proxy protocol.
Нет, они такие же. Правки там сделаны только для того, чтобы оно собиралось правильно с новыми версиями.
Правильно использовать собственный DNS-сервер. Например, установленный на той же машине:
Не стоит эти патчи от CloudFlare использовать. Почему не стоит я давал подробное разъяснение у нас в багтрекере: http://trac.nginx.org/nginx/ticket/1029#comment:2
Появление этих патчей было актом самопиара CloudFlare, а не попыткой сделать что-то полезное для общества.
Процитирую документацию:
Встроенный резолвер заточен на производительность, для чего пришлось несколько пожертвовать безопасностью. Он не рассчитан на применение в незащищенных сетях. Не говоря уж о том, что задержка при обращении к гугловому серверу может сказаться на скорости обработки запроса, а его недоступность или неправильная работа и вовсе привести к недоступности вашего сервиса.