ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[4]: Постоянные обрывы коннектов



Wednesday, April 8, 2009, 7:19:39 PM, you wrote:

> On 08.04.2009, at 18:44, Vladimir Getmanshchuk wrote:

>> Просматривая логи nginx обнаружил многократно повторяющиеся
>> записи скачивания с одного и того же URL, одним и тем же клиентским
>> IP, одной и той же длины. Пример :
>>
>> 2009-03-29T04:49:00+0300 XX.XX.XX.XX - - [29/Mar/2009:04:48:59
> а чему здесь равно XX.XX.XX.XX ?
> оч. интересно
> тоже такое встречал и после банил на фаерволе
XX.XX.XX.XX - это IP-шник клиента. И если б он был один или два,
но их много! На разных серверах, в сетях разных городов, т.е.
всех не забанишь - явление массовое.

>> +0300] "GET /fetch/mp3/hch...Wbg==/kreschenie.mp3 HTTP/1.1" 200 33396
>> "Mozilla/4.0(compatible; MSIE 5.00; Windows 98)"
>>
>> Пытался смотреть на то, что происходит, tcpdump'ом - видно, что
>> после клиентского GET-запроса сервер отвечает HTTP-заголовком,
>> начинает передавать содержимое файла и после второго посланного
>> пакета клиент присылает FIN и RST, после чего все повторяется заново.>>
>>
>> Просто как версия(ногами не бить):
>> этот url у юзера в playlist, при старте, программа проверяет  
>> содержимое
>> плейлиста(если это локальные mp3 - то теги, если это URL - то  
>> считывает
>> хедер mp3), отсюда и запросы...
Повторные запрос/обрыв идут с интервалом 1-2 сек, иногда по нескольку
за 1 сек. Весь вопрос в том - почему происходит обрыв.


С уважением, Владимир.
-- 
mailto:fursin@xxxxxxxxx

>>
>>
>>
>> 2009/4/7 Vladimir Fursin <fursin@xxxxxxxxx>
>>
>>> Здравствуйте, Антон.
>>>
>>>
>>> Правильно ли я понял, что патч решил Вашу проблему
>>>
>>> с обрывом коннектов? Если да, то пришлите, пожалуйста
>>>
>>> этот патч и конфиг с которым он работает. На прошлой неделе
>>>
>>> я обращался в лист с очень похожей проблемой
>>>
>>>
>>> <http://www.lexa.ru/nginx-ru/msg23500.html>
>>>
>>> http://www.lexa.ru/nginx-ru/msg23500.html
>>>
>>>
>>> но ответа так и не получил :(
>>>
>>>
>>> С уважением, Владимир.
>>>
>>> --
>>>
>>> mailto:fursin@xxxxxxxxx <fursin@xxxxxxxxx>
>>>
>>>
>>> Friday, April 3, 2009, 2:05:50 PM, you wrote:
>>>
>>>
>>> 2009/4/3 Maxim Dounin <mdounin@xxxxxxxxxx>
>>>
>>> Hello!
>>>
>>>
>>>
>>> On Fri, Apr 03, 2009 at 11:03:19AM +0200, Sergey Bondari wrote:
>>>
>>>
>>>> Hello Maxim,
>>>
>>>>
>>>
>>>>
>>>
>>>> MD> Если используется limit_req - надо либо накатить патч (пробегал
>>>
>>>> MD> тут давеча), либо использовать limit_req ... nodelay.
>>>
>>>> Патч кстати проблему решил. Один вопрос - этот патч временная  
>>>> заплатка
>>>
>>>> от вас или уже включена в транк? В смысле каждый раз его пока
>>>
>>>> накатывать после апдейта nginx?
>>>
>>>
>>>
>>> Пока - накатывать.
>>>
>>>
>>> Maxim Dounin
>>>
>>>
>>> --
>>>
>>> Best regards,
>>>
>>> Anton Kuznetsov.
>>>
>>>
>>>
>>>
>>
>>
>> -- 
>> Yours sincerely,
>> Vladimir Getmanshchuk
>>
>> Senior Unix System Administrator
>> Openfilm, LLC
>>
>> Email: vladget@xxxxxxxxxxxx
>> Skype: vladimir.getmanshchuk





 




Copyright © Lexa Software, 1996-2009.