curl 56 Recv failure: разбор причин

Гоняю обход каталога, примерно 40 тысяч обращений за прогон. На четырёх процентах падает вот это:

curl: (56) Recv failure: Connection reset by peer

Повтор того же адреса через секунду проходит нормально. То есть адрес живой, страница живая, а соединение кто-то рвёт посреди чтения. Четыре процента от 40 тысяч это полторы тысячи повторов за ночь, хочется понять источник.

Пятьдесят шестой у curl означает ровно одно: мы уже отправили запрос, ждём тело ответа, и в этот момент прилетел RST. Больше он ничего не значит, поэтому дальше надо сузить, кто именно прислал.

Ответьте на три вопроса, они делят задачу пополам каждый:

• падает на первом обращении к хосту или на переиспользованном соединении;
• падает на GET или на POST с большим телом;
• падает равномерно по времени или пачками.

Быстрый способ отделить переиспользование: прогоните ту же сотню адресов с запретом на повтор соединения и сравните долю отказов.

Если картина такая же, вы держите соединение дольше, чем его готова держать та сторона. Она молча закрывает по своему таймауту, вы стучитесь в закрытую дверь и получаете RST.

Проверю сегодня же, зацепка похожа на мою картину. Пачками, кстати, да.

Пока проверяете, поставьте рядом слушателя. Догадки про RST хороши, но видно его прямо в проводе, и там же видно, от кого он пришёл.

Смотрите на адрес источника. Приходит с адреса сайта, значит закрывает сайт. Приходит с ближнего узла, значит режет что-то по дороге.

а повтор на 56 вообще нормально ставить или это костыль

Ставить нормально, 56 по своей природе повторяемый: тело ответа вы не получили, ничего не испортили, обращение можно смело слать заново.

Только повторяйте с растущей паузой и на новом соединении, иначе снова попадёте в тот же дохлый канал. И считайте повторы отдельной цифрой, чтобы не потерять момент, когда их станет вдвое больше обычного.

Отдельно про POST с телом больше килобайт на пятьдесят: там 56 бывает от разного размера пакета по дороге. Проверяется просто, тем же обращением с уменьшенным телом.

Отчитываюсь, разбор сошёлся.

Сайт закрывает простаивающее соединение через пятнадцать секунд, у меня в пуле стояло шестьдесят. Между двумя обращениями к одному хосту у меня как раз проходило секунд двадцать пять, потому и пачками: пачка идёт, когда очередь дотягивается до давно лежавшего канала. tcpdump подтвердил, RST приходил с адреса сайта, ближние узлы ни при чём.

Что помогло: срезал время жизни простаивающего соединения до десяти секунд и включил повтор на 56 с новым каналом. Отказы упали с четырёх процентов до трёх сотых, оставшиеся ловит повтор с первого раза. Ночной прогон стал короче на сорок минут, потому что полторы тысячи повторов ушли.