Постоянные обрывы коннектов

[Maxim Dounin]

Hello!

On Mon, Jul 06, 2009 at 02:54:41PM +0200, Anton Kuznetsov wrote:

> > > tcp_nodelay    on;
> > > limit_req_zone $binary_remote_addr  zone=avi:10m   rate=5r/m;
> > > ....
> > > location ~* ^/film/.*\.(avi|mpg|gif|jpg)$ {
> > >           limit_req   zone=avi  burst=5;
> > > ....
> >
> > Для того чтобы был limit_req ... nodealy - должно быть написано
> > limit_req  ...  nodelay.  А не просто limit_req.  Логично?
> >
> 
> Мда, спасибо. :) надо еще раз прочитать матчасть и выучить все настройки где
> есть слово nodelay. :)
> 
> 
> > [...]
> >
> > > 2009/07/06 13:43:01 [debug] 62060#0: *117 free: 0829E200, unused: 56
> > > 2009/07/06 13:43:14 [error] 62100#0: *117 limiting connections by zone
> > > "one", client: 95.32.50.65, server: film.arjlover.net, request: "GET
> > > /film/vyzyvaem.ogon.na.sebja.2.avi HTTP/1.0", host: "ivanka.arjlover.net
> > ",
> > > referrer: "http://film.arjlover.net/film/"
> > >
> > > Последняя строчка непонятно как попала в этот grep по 117
> > > Все строчки про limit_req - убраны.
> >
> > Последняя строчка - это limit_conn.  В целом нормальный такой
> > range запрос, отработал штатно, вернул в точности то что
> > запросили.
> >
> 
> access.log:
> 220.231.30.195 - - [06/Jul/2009:13:42:56 +0400] GET /film/zerkalo.avi
> HTTP/1.1 XX 206 92546
> 
> Вот это запросили? 92645 байтов? Как это возможно?

Да, именно это запросили.  Я специально процитировал заголовк Range от 
клиента.  Возможно это с помощью протокола (сюрприз!) http, читать 
RFC2616.

> Разрешен один поток, если
> бы это был последний кусок - было бы http 200, если он не последний, то...

Код ответа будет 200 если качали весь файл целиком.  А если был 
range-запрос - то код ответа будет 206.  Вне зависимости от.  У 
вас явные проблемы с пониманием протокола http, перечитайте 
RFC2616 на досуге.

> Даже не знаю, теоретически можно кончено делать такие запросы, но смысл? И
> какие качалки могут так делать? Как-то не верится, учитывая, что случается
> по прежнему 50 раз в минуту...

AFAIK, многие качалки *всегда* пытаются открывать много потоков, 
раскидывая по ним запросы на разные куски.  Если вы ограничили 
количество потоков на стороне сервера - это никак не влияет на их 
логику работы.  По прежнему будут запрашиваться куски, только в 
один поток.

> Недолго я радовался что все хорошо работает без limit_req - мне быстро
> напомнили зачем я это сделал, в целом все хорошо, но отдельные товарищи
> любят делать вот так:
> 
> 193.232.126.36 - - [06/Jul/2009:16:33:39 +0400] GET /film/pyatyi.okean.avi
> HTTP/1.1 ZZ 206 1485423
> 193.232.126.36 - - [06/Jul/2009:16:33:43 +0400] GET /film/pyatyi.okean.avi
> HTTP/1.1 ZZ 206 2908171
> 193.232.126.36 - - [06/Jul/2009:16:33:46 +0400] GET /film/pyatyi.okean.avi
> HTTP/1.1 ZZ 206 1487151
> 193.232.126.36 - - [06/Jul/2009:16:33:46 +0400] GET /film/pyatyi.okean.avi
> HTTP/1.1 ZZ 206 776981
> 193.232.126.36 - - [06/Jul/2009:16:33:48 +0400] GET /film/pyatyi.okean.avi
> HTTP/1.1 ZZ 206 422760
> 193.232.126.36 - - [06/Jul/2009:16:33:48 +0400] GET /film/pyatyi.okean.avi
> HTTP/1.1 ZZ 206 782785
> 
> Тоже не очень понимаю как это у них получается и зачем, но достает. :(
> Кстати неплохо заливает за одну секунду, еще бы без обрывов - цены б ему не
> было. :)

Смотрите внимательно - код ответа 206, это ответы на 
range-запросы.  Там нет обрывов скорее всего.  Чтобы знать точно - 
надо ещё и знать что именно запросили, т.е. логгировать заголовок 
Range.

> Без nodelay играть с сотнями качалок в перестрелку 503 - не хочется, хочу
> держать коннект, мне кажется nginx это делает легко и красиво.
> Но насколько я понимаю - без патча это толком не работает?

Нет, без патча это не работает.

> Ни в 7 ни 8 версии патча нет?

Нет, ни в 0.7.*, ни в 0.8.* патча нет.

> Кстати, а можно как-то все коннекты что сверх лимита по коннектам тоже на
> удержание вешать? На этом фронте тоже идет перестрелка 503. :( Все что я
> смог сейчас сделать - повесить скорость 1b/s на 503.html - хоть как-то
> сдерживает это безумие, но хочется более красиво. И чтобы работало без
> патча. :)

Можно попробовать применить limit_req с задержкой для 503.

> Заморочка с пропатчиванием дюжины серверов и поддержанием патча в дальнейшем
> - как-то убивает весь энтузиазм. :(

За то время, что вы провели тут, тратя своё и чужое время - могли 
бы уже две дюжины серверов пропатчить.  Я уж не говорю про сделать 
порт/пакет и накатить хоть на пару тысяч.

Maxim Dounin