Почему пинг и проверка связи - разные вещи : Сеть

Заколебали, извините. Начинаем разговаривать про обрывы подключения к какому-то сервису, в ответ "но пинг-то есть!".
Итак, есть разные протоколы, которые работают в принципе по разному. Пинг относится к протоколу ICMP, примитивнейшему протоколу, суть которого в следующем: с машины, откуда пингуете, отправляется маленький пакет ICMP 8 типа (echo). И вот он полетел к пингуемому серверу, долетел до пингуемого сервера - полетел обратно пакет ICMP типа 0 (echo reply), ответ. Или если какое-то устройство не может передать пакет дальше, то вернет пакет ICMP типа 3 (destination unreachable), например. Или какую-то другую ошибку, не суть.

Большинство соединений (к базе, удаленного доступа и т.п.) работает по протоколу TCP. При подключении передается достаточно много пакетов, есть требования ко времени передачи и проверка потерь пакетов, иногда соединения рвутся по бездействию. Помимо этого, есть анализаторы TCP-траффика и его блокираторы, которые игнорируют ICMP-траффик.

Это все к чему. Есть масса причин, по которым ICMP, т.е. пинг будет работать нормально, при том, что TCP работать будет с перебоями, разрывами или не будет работать вообще.

А бывает и обратная картина: TCP работает нормально, а пинг не проходит.
правда очень редко.

Да, конечно. Некоторые закрывают ICMP, чтобы "нельзя было определить в онлайне ли хост". Бред полный, поскольку хост светится еще кучей способов, а ICMP иногда используется в служебном траффике.
В чем они сходятся (TCP и ICMP), в том, что оба не работают, если полный обрыв на линии. Но это слишком очевидное по множеству других параметров и редко не ловится, т.е. служит поводом для неуловимых глюков.

Смотря о какой связи реч. Я пингами проверяю жив ли канал связи, насколько сильно загружен. Пинги отправляю с шлюза в сторону общедоступных сервисов таких как google, yandex. Если потери 100% до всех проверяемых хостов - лежит канал, если потери не 100% а от 20% и выше причём одинаково до всех хостов то скорее всего имеет место быть пиковая загрузка канала. И в том и в другом случае, шлюз переключается на использование резервного канала для новых исходящих соединений. Входящие как принимались так и продолжают приниматься с обоих каналов. При "восстановлении" работоспособности основного канала возвращаюсь на него.

Т.е. я фактически проверяю связь пингами.

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

"В любой не понятной ситуации, пингуй яндекс" :)

Я не говорю о том, что пинг - бессмысленная утилита, сам использую ее тут:



но подчеркиваю другое, что наличие 100% пинга с маленькими задержками совсем не гарантирует точно такой же уровень качества работы TCP, в чем убеждены многие.

Вот с этим не поспоришь. Разнообразные системы фильтрации могут блокировать как всё разом так и выборочно. Без четкого понимания данного вопроса и возможностей управлять этими системами (в случае наличия на них ограничений) команда "ping" мало пользы принесёт.