Раз нету доступа к исходникам тогда разводить приложения на разные location
и в них использовать http://nginx.org/ru/docs/http/ngx_http_sub_module.html
Никита Хрущев Wrote:
---
> Допустим, есть два веб-приложения, которые предлагается запроксиров
Хорошо бы отсекать таких, и выводить в лог, а с лога при помощи fail2ban
блокировать на уровне iptables.
Через iptables не отсеч такие обращения, нужно именно в nginx и чтобы он не
пытался парсить, а учитывал кол-во прочитанных байт на сокете. И при
привышении размера, даже пускай допустимого разме
В письме от Пт, 19 декабря 2014 02:16:55 пользователь Vadim A. Misbakh-
Soloviov написал:
> В письме от Чт, 18 декабря 2014 14:59:22 пользователь sofiamay написал:
> > есть, просто в конфиге проблема. Оказалось что схема работы с буферами
> > совсем иная.
>
> Не совсем "иная". NginX вполне начинае
В письме от Чт, 18 декабря 2014 14:59:22 пользователь sofiamay написал:
> есть, просто в конфиге проблема. Оказалось что схема работы с буферами
> совсем иная.
Не совсем "иная". NginX вполне начинает отдавать после заполнения первого
буфера. Но я вам выше уже ответил. Ваша желаемая схема ничем не
В письме от Чт, 18 декабря 2014 14:56:33 пользователь sofiamay написал:
> Моя схема работы с буфером была бы очень кстати и она никак не блокирует
> работу Nginx, раз уж вы говорите про прелесть неблокируемости :-) Жаль что
> Nginx так не умеет.
Схему я в любом случае, если и соберу, то не ранее з
Aleksandr Sytar Wrote:
---
> "Т.е. получил первый байт в
> буфер и тут же начинает передавать ответ клиенту при этом продолжая
> получать
> данные в буфер. "
- В чем тогда практический смысл буфера, какую он
> роль,
> оп вашему выполняет?
Ну ка
mva Wrote:
---
> см. выше. В случае "быстрых" клиентов это не нужно. А с медленными
> можно
> бороться.
Странный ответ. Уже как несколько лет получаю рассылку, а про борьбу с
медленными клиентами ничего конкретного не было. Постоянные тычки в
д
Hello!
On Thu, Dec 18, 2014 at 08:12:00PM +0300, Anton Yuzhaninov wrote:
> On 12/18/14 17:13, Maxim Dounin wrote:
> >В теории, такое может происходить и случайно - т.к. fallback
> >может случиться просто от того, что не удалось установить
> >соединение с первого раза.
>
> Да, похоже так оно и пр
18 декабря 2014 г., 22:41 пользователь sofiamay
написал:
>
> Aleksandr Sytar Wrote:
> ---
> > А вам не кажется, что в этом случае буфера нет? Или вы путаете
> > буферизацию
> > с кешированием ответов, или одно из двух.
>
> Да нет, не кажется. В т
Aleksandr Sytar Wrote:
---
> А вам не кажется, что в этом случае буфера нет? Или вы путаете
> буферизацию
> с кешированием ответов, или одно из двух.
Да нет, не кажется. В таком варианте буфер есть, самый что ни на есть. А вот
каким боком вы сюда
Hello!
On Thu, Dec 18, 2014 at 01:53:38PM -0500, tester123 wrote:
> нда, значит исправлять не собираются... печально...
Вас просили проверить, воспроизводится ли проблема без сторонних
модулей на свежей версии nginx'а, и предоставить данные по списку. Вы
предоставили? Если да, то дайте ссылк
18 декабря 2014 г., 21:54 пользователь sofiamay
написал:
>
> Вы немножко меня не правильно поняли :-) Я предполагал что Nginx умеет
> одновременно и получать и отдавать свой буфер. Т.е. получил первый байт в
> буфер и тут же начинает передавать ответ клиенту при этом продолжая
> получать
> данные
В письме от Чт, 18 декабря 2014 13:54:53 пользователь sofiamay написал:
> > А смысл от этого?
>
> Что ни на есть смысл, сейчас можно либо отключить буферизацию вообще, в этом
> случае сервер легко будет заDDOSсить медленными клиентами, которые займут
> все потоки Apache, которые будут висеть в пам
> А смысл от этого?
Что ни на есть смысл, сейчас можно либо отключить буферизацию вообще, в этом
случае сервер легко будет заDDOSсить медленными клиентами, которые займут
все потоки Apache, которые будут висеть в памяти занятыми, пока ответ не
будет передан клиентам. Либо можно включить буферизаци
нда, значит исправлять не собираются... печально...
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,250456,255648#msg-255648
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Смысл вопроса прост, а ответ неочевиден: если клиент медленный и отключена
буферизация? Как поступит nginx? Будет в час по чайной ложке забирать у
бэкенда и передавать клиенту данные, задерживая таким образом бэкенд? Или
все же получит куда-то ответ полностью и будет потихоньку его отдавать?
18 де
А смысл от этого?
> Воркфлоу с буферами: создал буферы => получил => отдал => уничтожил буферы
> Воркфлоу без буферов: получил => отдал
>
> Смысл от буферов, если их содержимое уже у клиента? Зачем его (содержимое)
> тогда буферизировать? Куда его дальше девать?
>
>
Смысл очевиден, освободить драго
В письме от Чт, 18 декабря 2014 13:23:56 пользователь sofiamay написал:
> Я читал документацию, даже черезчур усердно. Видимо всё дело в том, что я
> переоценил возможности Nginx, я думал что он может принимать ответ в буфер
> от Apache и при этом одновременно отдавать его медленному клиенту. Т.е.
> > но при этом начинал его передавать сразу же с первого байта.
>
> Это взаимоисключающие параграфы. Либо NginX принимает весь ответ в буфер и
> сразу после принятия отдаёт его, либо он отдаёт его сразу как получил. Или
> так, или так. Третьего не дано.
>
>
Интересно, почему именно "третьего не да
Я читал документацию, даже черезчур усердно. Видимо всё дело в том, что я
переоценил возможности Nginx, я думал что он может принимать ответ в буфер
от Apache и при этом одновременно отдавать его медленному клиенту. Т.е. я
думал что он умеет одновременно и получать и отдавать свой буфер, оказалось
В письме от Чт, 18 декабря 2014 13:00:28 пользователь sofiamay написал:
> но ведь при этом Nginx не будет получать максимально быстро
А как будет? Не максимально быстро? :)
Нет никакой магии. С буферизацией ответа NginX сначала получает ответ, потом
отдаёт его. Без буферизации — отдаёт сразу как
proxy_buffering у меня конечно же On
Если его выключить, то понятно дело ответ будет синхронно передаваться
клиенту от Apache, но ведь при этом Nginx не будет получать максимально
быстро весь ответ от Apache. Теряется весь смысл в буферах и их полезности.
Я конечно же спрашиваю о другом - как настр
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_buffering
--
Best regards,
mva
signature.asc
Description: This is a digitally signed message part.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/ng
Стоял Apache и веб-сервис (php), который работает постоянно и выдаёт ответ в
произвольные моменты небольшими кусочками, всё работало превосходно. Т.е.
открываем в браузере адрес и он так может висеть часами выдавая раз в
секунду или вообще в произвольное время небольшой ответ по 1 или 2 строчки.
П
On 12/18/14 17:13, Maxim Dounin wrote:
В теории, такое может происходить и случайно - т.к. fallback
может случиться просто от того, что не удалось установить
соединение с первого раза.
Да, похоже так оно и происходит. Посмотрел дампы трафика - в них хендшейк
обрывается по таймауту и следующая
On Thursday 18 December 2014 04:56:02 Alexey72 wrote:
> У себя на 4х ядерной машине смоделировал, одно подключение попадает на один
> из worker'ов и загружает 30% ядра(на котором работает worker).
> Да и канал получается тоже забьется.. если их будет больше, и их не скинуть
> вовремя и не добавить
Hello!
On Thu, Dec 18, 2014 at 01:19:03PM +0300, Anton Yuzhaninov wrote:
> После обновления openssl с 1.0.1g до 1.0.1j
> В логи стали в большом количестве сыпаться сообщения вида:
>
> [crit] 767#0: *44215130 SSL_do_handshake() failed (SSL: error:140A1175:SSL
> routines:SSL_BYTES_TO_CIPHER_LIST:i
Допустим, есть два веб-приложения, которые предлагается запроксировать
следующим образом:
https://www.example.com/apps/app1 и https://www.example.com/apps/app2
Но вот беда: оба этих приложения используют для загрузки статических файлов
(картинок там, и прочего) один и тот же путь, скажем
https://ww
Hello!
On Wed, Dec 17, 2014 at 11:03:11PM +0200, Андрей Василишин wrote:
> Всем привет!
> Раз уж в соседнем топике затронули платность нгинкс, интересует не
> планируется ли случайно сделать лицензию наподобие Adobe Media Server 5
> Standard и за те же деньги? То есть скажем покупаешь раз вечную
18.12.2014 8:16, Vadim A. Misbakh-Soloviov пишет:
В письме от Ср, 17 декабря 2014 23:03:11 пользователь Андрей Василишин
написал:
на сервер, нужен только функционал без поддержки.
А чего бы тогда просто не использовать (вкомпилировать) rtmp-модуль самому?
на ранних стадиях результат работ
После обновления openssl с 1.0.1g до 1.0.1j
В логи стали в большом количестве сыпаться сообщения вида:
[crit] 767#0: *44215130 SSL_do_handshake() failed (SSL: error:140A1175:SSL
routines:SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback) while SSL handshaking,
client: 192.0.0.225, server: 0.0.0.0
У себя на 4х ядерной машине смоделировал, одно подключение попадает на один
из worker'ов и загружает 30% ядра(на котором работает worker).
Да и канал получается тоже забьется.. если их будет больше, и их не скинуть
вовремя и не добавить в бан.
Posted at Nginx Forum:
http://forum.nginx.org/read.ph
On Thursday 18 December 2014 04:36:23 Alexey72 wrote:
> Столкнулся с проблемой. Не могу отсеч DDos атаки, злоумышленники не делают
> много запросов, с одного ip не более 10 соединений.
> При подключении без взяких заголовков присылают \n\r , тем самым нагружают
> nginx worker. Ограничения по разм
Столкнулся с проблемой. Не могу отсеч DDos атаки, злоумышленники не делают
много запросов, с одного ip не более 10 соединений.
При подключении без взяких заголовков присылают \n\r , тем самым нагружают
nginx worker. Ограничения по размеру запроса срабатывают видимо после
обработки заголовка, а в
34 matches
Mail list logo
