Инструмент Ping-теста

Ping-тест проверяет, доступен ли целевой хост по сети, и оценивает задержку ответа. Классический ping отправляет ICMP echo requests и измеряет round-trip time; в браузере или веб-среде могут использоваться другие методы, потому что прямого доступа к ICMP нет. Ping полезен для диагностики сети, мониторинга серверов, сравнения задержек, проверки подозрений на DNS и разделения локальных проблем от проблем удаленного хоста. Успешный ping не доказывает, что сайт, порт, база данных или вход работают, а неудачный ping не всегда означает падение сервера, потому что firewall и политики могут блокировать ICMP. Результат нужно сопоставлять с DNS, traceroute, портами и проверками приложения.

Инструмент ping отправляет зонд с сервера ToolAct к целевому хосту, измеряя доступность и задержку обратного пути. Традиционный ping работает на 3 уровне модели OSI с использованием ICMP (Internet Control Message Protocol, RFC 792): источник отправляет ICMP Echo Request (Type 8, Code 0) с порядковым номером и полезной нагрузкой, а получатель отвечает ICMP Echo Reply (Type 0, Code 0). Время кругового обхода (RTT) — интервал между отправкой запроса и получением ответа, измеряемый в миллисекундах. Поскольку браузеры не могут отправлять необработанные ICMP-пакеты (Socket API не предоставляет необработанные сокеты веб-контенту), этот инструмент проксирует ping через бэкенд-API — серверный процесс выполняет фактический обмен ICMP и возвращает результаты в браузер. Поле TTL (Time to Live) в заголовке IP уменьшается на 1 при каждом промежуточном маршрутизаторе; когда TTL достигает 0, маршрутизатор отбрасывает пакет и возвращает ICMP Time Exceeded (Type 11). Это механизм, лежащий в основе traceroute, но в тесте ping начальное значение TTL раскрывает ОС цели: Windows по умолчанию использует 128, Linux/macOS — 64, сетевое оборудование часто — 255. Вычитание полученного TTL из значения по умолчанию даёт приблизительное количество хопов до цели. Потеря пакетов рассчитывается как (отправлено пакетов - получено пакетов) / отправлено пакетов × 100%. Нулевые потери означают, что все зонды вернулись в пределах тайм-аута; прерывистые потери могут указывать на перегрузку, неисправное оборудование, ограничение скорости или отключение ICMP целью или промежуточным файрволом. Многие продакшен-серверы и облачные провайдеры полностью отключают ICMP на границе, поэтому результат 100% потерь не обязательно означает, что хост недоступен — возможно, ICMP отфильтрован. Инструмент сообщает минимальную, максимальную и среднюю задержку по всем успешным зондам, которые вместе выявляют джиттер: низкое среднее с высоким максимумом указывает на случайные всплески, а совпадающие min/max — на стабильное соединение.

• Механизм ICMP Echo (RFC 792): Echo Request (Type 8) несёт 16-битный идентификатор, 16-битный порядковый номер и опциональную полезную нагрузку — Echo Reply (Type 0) возвращает тот же идентификатор и порядковый номер, позволяя отправителю сопоставлять ответы с запросами.
• Измерение RTT: время кругового обхода — это интервал от отправки запроса до получения ответа, включающий задержку распространения в сети, очередирование маршрутизаторов и время обработки целью — значения менее 1 мс указывают на нахождение цели в одной LAN, а 100+ мс — на межконтинентальные пути.
• Определение числа хопов по TTL: начальные значения TTL следуют соглашениям ОС (Windows 128, Linux/macOS 64, сетевое оборудование 255); приблизительное число хопов = начальный TTL − полученный TTL — полученный TTL 117 от хоста Windows указывает примерно на 11 маршрутизаторных хопов.
• Интерпретация потерь пакетов: <2% потерь на хорошо соединённом пути — норма; 2–10% указывает на перегрузку или нестабильное соединение; >10% — серьёзная проблема — но фильтрация ICMP файрволами или облачными провайдерами может дать ложные 100% потерь на иначе здоровом хосте.
• Статистика задержки: минимум, максимум и среднее арифметическое по N зондам выявляют джиттер — низкое среднее с высоким максимумом указывает на спорадическую перегрузку; стандартное отклонение (не отображается, но вычисляется из таблицы по пакетам) количественно определяет разброс.
• Ограничение браузера: JavaScript не может отправлять необработанные ICMP-пакеты, поскольку API WebSocket, fetch и XMLHttpRequest работают на прикладном уровне (TCP/TLS/HTTP) — инструмент проксирует ping через бэкенд-API, поэтому измеренная задержка включает дополнительный HTTP-круговой обход к серверу ToolAct.
• Ограничение скорости ICMP: многие хосты и маршрутизаторы применяют ограничение скорости ICMP (параметр ядра Linux net.ipv4.icmp_ratelimit, по умолчанию 1000 мс) — отправка зондов быстрее лимита вызывает искусственные потери пакетов, не отражающие реальное состояние сети.