Reset Connection Reset by peer означает, что удаленная сторона завершает сессию. Эта ошибка генерируется, когда ОС получает уведомление о сбросе TCP (RST) от удаленного пира.
Пониманием Connection Reset by peer
Reset Connection Reset by peer означает, что поток TCP был аномально закрыт с другого конца. Был получен TCP RST, и соединение теперь закрыто. Это происходит, когда пакет отправляется с нашего конца соединения, но другой конец не распознает соединение; он отправляет обратно пакет с установленным битом RST, чтобы принудительно закрыть соединение.
"Connection reset by peer" - это эквивалент TCP/IP, когда телефон снова нажимает на крючок. Это более вежливо, чем просто не отвечать, оставляя человека в подвешенном состоянии. Но это не FIN-ACK, ожидаемый от действительно вежливого TCP/IP.
Понимание флага RST TCP
RST используется для прерывания соединения. Он очень полезен для устранения неполадок в сетевом соединении.
RST (сброс соединения). Указывает, что соединение прерывается. Для активных соединений узел посылает сегмент TCP с флагом RST в ответ на некорректный сегмент TCP, полученный на соединении, что приводит к прерыванию соединения.
Отправка сегмента RST для активного соединения принудительно прерывает соединение, в результате чего данные, хранящиеся в буферах отправки и получения или находящиеся в пути, будут потеряны. Для устанавливаемых TCP-соединений узел посылает сегмент RST в ответ на запрос установления соединения, чтобы отклонить попытку соединения. Отправитель получит ошибку Connection Reset by peer error.
Проверка сетевого подключения
Команда "ping" - это инструмент, используемый для проверки доступности сетевого ресурса. Команда "ping" отправляет серию пакетов на сетевой ресурс, а затем измеряет время, необходимое для возврата пакетов.
Если вы хотите выполнить ping удаленного сервера, вы можете использовать следующую команду: ping <удаленный сервер>.
В этом примере "<удаленный сервер>" - это IP-адрес или имя хоста удаленного сервера, который вы хотите пропинговать.
Выполните ping удаленного узла, к которому мы подключились. Если он не отвечает, возможно, он находится в автономном режиме или на пути к нему возникла сетевая проблема. Если он отвечает, проблема может быть временной (поэтому мы можем переподключиться сейчас).
Если вы испытываете потерю пакетов при пинге удаленного сервера, есть несколько способов устранения неполадок.
Первое, что вы можете сделать, это проверить сетевой интерфейс удаленного сервера. Для этого используйте команду "ifconfig". Вывод команды "ifconfig" покажет вам состояние всех сетевых интерфейсов в системе. Если с одним из интерфейсов возникли проблемы, это будет показано в выводе.
Вы также можете использовать команду "ip route" для проверки информации о маршрутизации. В результате выполнения команды "ip route" вы увидите список всех маршрутов в системе. Если есть проблема с одним из маршрутов, это будет показано в выводе.
Если вы все еще испытываете потерю пакетов, вы можете попробовать использовать другой сетевой интерфейс. Для этого используйте команду "ping" с опцией "-i". Например, следующая команда будет использовать интерфейс eth0:
| 1 | ping -i eth0 google.com |
Проверьте, открыт ли порт удаленной службы
Порт - это логическая сущность, которая действует как конечная точка связи, связанная с приложением или процессом в операционной системе Linux. Мы можем использовать некоторые команды Linux для проверки состояния удаленного порта.
Такие команды, как nc, curl, могут быть использованы для проверки того, открыты ли удаленные порты или нет. Например, следующая команда проверит, открыт ли порт 80 на сайте google.com:
| 1 | nc -zv google.com 80 |
Вывод вышеприведенной команды должен выглядеть примерно так: Подключение к порту 80 [tcp/80] сайта google.com успешно!
Это означает, что порт открыт и мы можем установить соединение с ним.
Проверьте журнал приложений на удаленном сервере
Например, если ошибка связана с SSH, мы можем отладить ее на удаленном сервере по журналам sshd. Записи журнала будут находиться в одном из файлов в каталоге /var/log. SSHD будет записывать что-то в журнал каждый раз, когда он отбрасывает нашу сессию.
| 1 | Oct 22 12:09:10 server internal-sftp[4929]: session closed for local user fred from [192.0.2.3] |
Проверьте соответствующие параметры ядра Linux
Параметр ядра также связан со сбросом соединения при ошибке пира. Концепция keepalive очень проста: когда мы устанавливаем TCP-соединение, мы связываем набор таймеров. Некоторые из этих таймеров связаны с процедурой keepalive. Когда таймер keepalive достигает нуля, мы посылаем нашему аналогу пакет зонда keepalive без данных и с включенным флагом ACK.
Мы можем сделать это благодаря спецификациям TCP/IP, как своего рода дублирующий ACK, и у удаленной конечной точки не будет аргументов, поскольку TCP - это протокол, ориентированный на поток. С другой стороны, мы получим ответ от удаленного узла (который вообще не должен поддерживать keepalive, только TCP/IP), без данных и с установленным ACK.
Если мы получим ответ на запрос keepalive, мы можем утверждать, что соединение все еще работает, не беспокоясь о реализации на уровне пользователя. Фактически, TCP позволяет нам работать с потоком, а не с пакетами, поэтому пакет данных нулевой длины не опасен для пользовательской программы.
Обычно мы используем tcp keepalive для двух задач:
- Проверка наличия мертвых пиров
- предотвращение отключения из-за неактивности сети.
Проверьте конфигурацию сердцебиения приложения
Сброс соединения по ошибке пира также связан с приложением. Некоторые сетевые инструменты (HAproxy, AWS ELB) и оборудование (аппаратные балансировщики нагрузки) могут завершать "неработающие" TCP-соединения при отсутствии активности на них в течение определенного периода времени. В большинстве случаев это нежелательно.
В качестве примера мы будем использовать rabbitmq. Когда на соединении включено сердцебиение, это приводит к периодическому небольшому сетевому трафику. Поэтому сердцебиение имеет побочный эффект защиты клиентских соединений, которые могут простаивать в течение определенного времени, от преждевременного закрытия прокси-серверами и балансировщиками нагрузки.
При таймауте сердцебиения в 30 секунд соединение будет производить периодический сетевой трафик примерно каждые 15 секунд. Активности в диапазоне от 5 до 15 секунд достаточно, чтобы удовлетворить настройки по умолчанию большинства популярных прокси-серверов и балансировщиков нагрузки. Также см. раздел о низких таймаутах и ложных срабатываниях выше.
Проверка метрики ОС на стороне пира
Сброс соединения со стороны пира может быть вызван загруженностью системы. Мы можем установить мониторинг для нашей Linux системы на такие метрики как CPU, память, сеть и т.д. Если система слишком загружена, это повлияет на сеть.
Например, мы можем использовать команду "top" для проверки использования процессора. Вывод команды "top" покажет нам список процессов, отсортированных по использованию ЦП. Если есть процесс, который использует много ЦП, мы можем исследовать его дальше, чтобы узнать, является ли он причиной сетевых проблем.
Мы также можем использовать команду "netstat" для проверки сетевой статистики. Вывод команды "netstat" покажет нам список активных сетевых соединений. Если установлено слишком много соединений, это может быть причиной проблем с сетью.
Мы можем использовать эти команды для устранения сетевых проблем в системе Linux. Используя эти команды, мы можем определить основную причину проблемы и устранить ее.