Re: "client prematurely closed connection" между двумя nginx

Evgeniy Berdnikov bgx на protva.ru
Пн Окт 3 09:54:22 UTC 2016


On Sun, Oct 02, 2016 at 10:03:06PM -0400, Trurl wrote:
> Evgeniy Berdnikov Wrote:
> -------------------------------------------------------
> > On Sat, Oct 01, 2016 at 09:59:51PM -0400, Trurl wrote:
> 
> > 
> >  Заголовок content-length: присутствует в ответе?
> 
> на выходе получается 415я ошибка, а nginx при этом всё "лишнее" выкидывает

 Я имел в виду ответ того сервера, который выдаёт файлы. Для статики
 наличие content-length: нормально, и наоборот, было бы странно, если бы
 такой хедер отсутствовал. А если такой хедер есть, непонятно, как клиент
 может "не заметить" оборванный при передаче ответ и ничего не написать
 при этом в error_log.

> > > Размер кусочка всегда 17376 байт (не зависимо от размера
> > оригинального
> > > файла).
> > 
> >  Похоже на 12 сегментов с mss=1448 (17376=12*1448), интересно было бы
> >  взглянуть на дамп трафика для такой коннекции. Если есть активное
> >  оборудование между узлами -- сравнить дампы с обеих сторон.
> 
> Это все происходит в локалке в датацентре, и трафик между файлером и нодами
> там слишком интенсивный, чтобы что-то мониторить. А если нагрузки нет - то и
> ошибок нет. А так там даже просто логи включать "больно".

 Запись дампа на нагруженной системе может быть непростым делом, да. :)

 Но можно начать с простого: взять лишь пакеты SYN, FIN и RST, и проверить
 фильтром, все ли они имеют mac-адреса серверов с nginx (проверка гипотезы
 об обрыве коннекций каким-то активным оборудованием по пути или со стороны).
 Полезно также помониторить icmp.
-- 
 Eugene Berdnikov



Подробная информация о списке рассылки nginx-ru