У меня есть веб-сервер под управлением Centos7, который делает запросы curl к другим ресурсам. При скорости 5-10 запросов в секунду все работает нормально, за исключением того, что я получаю разные ошибки curl каждые 2-10 минут. Я думаю, это начало происходить со временем, когда количество запросов росло, что заставляет меня думать, что это как-то связано с сетью, но я полный новичок в этом. Как узнать, что вызывает эти ошибки и что я могу с этим сделать?
Network: CURL error 56: TCP connection reset by peer
Network: CURL error 7: Failed to connect to ip: Network is unreachable
Network: CURL error 18: transfer closed with 1473 bytes remaining to read
решение1
Вероятнее всего, причины этих ошибок можно в целом классифицировать как «SNAFU»… Ситуация нормальная, все в полном порядке.
Интернет — это огромная сеть взаимосвязанных компьютеров и сетевых устройств. Те другие машины, которые вы не контролируете, не всегда делают то, что должны. У них случаются сбои в электропитании. У них случаются сбои в работе оборудования. На них воздействует космическая радиация. Всякое случается.
Сетевые технологии, лежащие в основе Интернета, разработаны с учетом этого. Причина, по которой Интернет вообще работает, — это огромный уровень избыточности. Если попытка подключиться к пункту назначения по одному маршруту не удалась... последний сработавший "прыжок" в этой цепочке запомнит неудачу и попробует другой "следующий прыжок" для будущей связи. На самом деле все гораздо сложнее... но вы поняли суть.
Большинство веб-приложений будут повторять неудачные соединения специально для того, чтобы воспользоваться этой избыточностью. Однако не все. Чем проще приложение, тем больше вероятность, что оно просто выйдет из строя. Это становится особенно верно для терминальных приложений, которые применяют принципы *nix для небольших инструментов с одним заданием. Повтор — это работа другого инструмента. curl— одно из таких приложений. Согласноcurlстраница руководства:
--повторить попытку
Если при попытке curl выполнить передачу возвращается временная ошибка, он повторит попытку указанное количество раз, прежде чем прекратить попытку.Установка числа 0 заставляет curl не делать повторных попыток (что является значением по умолчанию). Временная ошибка означает: тайм-аут, код ответа FTP 4xx или код ответа HTTP 408 или 5xx.
Я не уверен, какой именно у вас вариант использования для curlполучения ресурсов, но если вы используете curl для предоставления ресурсов автоматизированным способом, вам определенно нужно настроить его с флагом --retryсо значением 3-5. Потому что ошибки, подобные тем, что вы показали, совершенно нормальны... и их нужно учитывать.
2. Почему надежность вашего производственного сервера хуже, чем у локального компьютера?
В идеальном мирепроизводственный сервер всегда будет иметь более надежное подключение к интернет-ресурсам, чем любое домашнее или офисное интернет-подключение. Поскольку в данном случае это не так, то вы правы, что интересуетесь причиной. Однако это все еще не обязательно означает, что вам следует беспокоиться, поскольку, опять же, это не обязательно проблема, вызванная вашим сервером.
Поймите, что ваш локальный компьютер и ваш сервер почти наверняка не используют один и тот же маршрут к ресурсам, о которых идет речь. Например. Если я выполняю tracerouteс моего локального домашнего сервера, чтобы сказать... superuser.comЯ получаю это:
user@home ~ $ sudo traceroute -I superuser.com
traceroute to superuser.com (151.101.1.69), 30 hops max, 60 byte packets
1 rtr.scrapyard.local (10.5.0.1)
2 96.120.58.37 (96.120.58.37)
3 po94-sr22.dothan.al.pancity.comcast.net (68.85.202.165)
4 162.151.221.209 (162.151.221.209)
5 be-3666-cr02.56marietta.ga.ibone.comcast.net (68.86.90.209)
6 * * *
7 50.242.151.138 (50.242.151.138)
8 151.101.1.69 (151.101.1.69)
Но если я выполню ту же команду с одного из моих рабочих серверов, то получу следующее:
user@production ~ $ sudo traceroute -I superuser.com
traceroute to superuser.com (151.101.1.69), 30 hops max, 60 byte packets
1 * * *
2 ae-20-202.gw-distp-a.slr.lxa.us.oneandone.net (74.208.138.130)
3 ae-10-0.bb-a.ga.mkc.us.oneandone.net (74.208.1.237)
4 kanc-b1-link.telia.net (80.239.196.109)
5 dls-b22-link.telia.net (62.115.125.159)
6 fastly-ic-340339-dls-b22.c.telia.net (62.115.166.191)
7 151.101.1.69 (151.101.1.69)
Единственное общее место в этих двух маршрутах — это пункт назначения. Все остальные машины, через которые они проходят, отличаются. Так что если бы, скажем, dls-b22-link.telia.netвел себя неправильно, это повлияло бы на попытки моего сервера связаться с superuser.com... но не на попытки моего домашнего компьютера сделать то же самое.
К сожалению, если естьбылпроблема с dls-b22-link.telia.netтам, я бы не смог сделать многого. И учитывая прерывистый характер проблемы, было бы не так уж и легко определить, что dls-b22-link.telia.netбыло источником проблемы изначально.
Так...
2б. Действительно ли это проблема?
Первое, что вам следует сделать, это подтвердить, что это вызывает реальную проблему, которую простое повторение неудачных подключений не исправит. Это означает, что ваш производственный сервер каким-то образом нарушается в выполнении своей работы. Я предполагаю, что вы имели в виду определенную цель, когда настраивали это.Достигается ли эта цель таким образом, что вам не нужно предпринимать никаких действий?Это ключевой вопрос.
Возвращаясь к тому, что я сказал ранее, такие неполадки — это просто часть интернета. В идеальном мире они бы не случались, но мы живем не в идеальном мире... поэтому избыточность — это основополагающий принцип всех технологий, на которых построен интернет. Вот почему повторные попытки после таких сбоев соединения — это стандартная рабочая процедура. И вот почему вам не стоит слишком беспокоиться о таких сбоях, если только они активно не наносят ущерб вашему серверу.
2c. Это под вашим контролем?
Вам нужно сузить потенциальный источник проблемы. Для этого просто выполните те же тесты, которые вы уже делали (подсчитайте количество сбоев за определенный промежуток времени), но на этот раз заставьте сервер запрашивать ресурсы из радикально другого места. Я бы посоветовал настроить простой веб-сервер на вашем домашнем компьютере с парой файлов, похожих на те, с которыми вы работали, и использовать их curlна своем сервере, чтобы захватить их.
Если сервер не испытывает сбоев при выполнении этого, то проблема вряд ли связана с вашим сервером или хостинг-провайдером вашего сервера. И ваши существующие тесты уже исключили вашу локальную сеть и интернет-провайдера, а также место, где размещены сами ресурсы, из потенциальных источников проблемы. Это оставляет узлы между вашим хостинг-провайдером и хостинг-провайдером ресурсов и полностью попадает под категорию «вещей, которые вы не можете контролировать».
Если серверделаетиспытываете проблемы во время вышеуказанного теста, то, поскольку вы уже исключили вашу локальную сеть/провайдера как проблему, вы можете быть почти уверены, что проблема либо в вашем сервере, либо в хостинг-провайдере сервера. Это означает, что вы можете это исправить. Это также означает, что вам предстоит еще больше работы по устранению неполадок.
2d. Что дальше?
Если проблема не в вашем сервере, хостинг-провайдере вашего сервера или ресурсах, которые вы запрашиваете... то причина сама по себе не находится под вашим контролем. В этом случае лучшим вариантом будет переместить сервер (свяжитесь с вашим хостинг-провайдером и узнайте, какие варианты они могут вам предложить).надеятьсячто, сделав это, вам больше не нужно будет использовать маршрут, на котором находится неисправный узел. Это довольно суровое испытание, и нет гарантии, что оно сработает. Это может даже привести к новым проблемам. Вот почему это определенно должно быть серьезной проблемой, прежде чем вы предпримете такой шаг.
С другой стороны, если вы сузили проблему до вашего сервера или хостинг-провайдера вашего сервера, то вы, вероятно, сможете ее исправить. Если у вас есть соглашение об управляемом хостинге, то позвоните своему хостинг-провайдеру и попросите их исправить это. Если у вас нет соглашения об управляемом хостинге, то вам нужно исключить конфигурацию вашего сервера из числа потенциальных виновников. И вот тут, к сожалению, я схожу с поезда. Мы приближаемся к пределам моей компетентности.
Как правило, если это прерывистая проблема, вызванная вашим сервером, то, скорее всего, это как-то связано с сетевой буферизацией или является результатом какой-то автоматизации. Некоторые обоснованные предположения:
- Предприняли ли вы какие-либо шаги для защиты своего сервера от вредоносных зондирований и атак?
- Вы что-то напутали со своими
/etc/sysctl.confфайлами или файлами в/etc/sysctl.d/? - Настроили ли вы какое-либо программное обеспечение для проверки состояния пакетов или обнаружения вторжений (брандмауэры на базе iptables/netfilter, snort и т. д.)?
Независимо от этого, если вы находитесь на этапе устранения неполадок на самом сервере, я бы посоветовал вам использовать собранную вами информацию и задать новый вопрос наServerFault. У людей там гораздо больше опыта в решении проблем с серверами, чем у людей здесь, на SuperUser, и они, скорее всего, знают, что делать дальше.
3. Относительно очевидной последовательности ошибок
Теперь, почему вы получаете одну и ту же конкретную ошибку снова и снова и снова? Трудно сказать. Если предположить, что это действительно происходит как по часам каждые 5 минут... все равно может быть что угодно. Эти устройства имеют часы и таймеры для самых разных целей. Это может быть что-то, что одно из них настроено делать каждые пять минут, что вызывает этот небольшой сбой.
Возможно, проблема с вашим сервером. Или проблема с вашим хостинг-провайдером. Или проблема с интернет-провайдером вашего хостинг-провайдера. Или проблема с вашим домашним/офисным интернет-провайдером. Или где-то посередине. Если проблема не в вашем сервере, и, скорее всего, это не основано на том, что вы мне сказали, то суть в том, что вы не можете ничего с этим поделать... кроме как убедиться, что вы настроены на повтор неудачных подключений. Все современные веб-браузеры, например, повторяют попытку несколько раз, прежде чем отказаться от получения ресурса с веб-сервера.
ПРАВКИ
- Добавлены второй и третий разделы в ответ на комментарий с просьбой о дополнительных разъяснениях.
- Переписан второй раздел с учетом исправлений.