Check-Host.cc

Info Ping HTTP TCP UDP MTR DNS

Диагностика MTR nl-eyg-ghosted.check-host.eu

Постоянная ссылка |
Локация Результат
AL Albania, Tirana
AU Australia, Sydney
BA Bosnia and Herzegovina, Novi Travnik
BG Bulgaria, Sofia
CA Canada, Montreal
CH Switzerland, Bern
CL Chile, Santiago
CN China, Hohhot
DE Germany, Nuernberg
DE Germany, Frankfurt am Main
DE Germany, Frankfurt am Main
DE Germany, Limburg
DK Denmark, Glostrup Municipality
ES Spain, Madrid
FI Finland, Helsinki
FI Finland, Helsinki
FR France, Gravelines
FR France, Paris
GB United Kingdom, London
HK Hong Kong, Hong Kong
HR Croatia, Zagreb
HU Hungary, Budapest
ID Indonesia, Jakarta
IN India, New Delhi
IS Iceland, Reykjavik (Miðborg)
IT Italy, Como
LT Lithuania, Pilaite
LV Latvia, Riga
MD Moldova, Chisinau
NL Netherlands, Amsterdam
NL Netherlands, Amsterdam
NL Netherlands, Amsterdam
NL Netherlands, Eygelshoven
QA Qatar, Doha
RO Romania, Bacău
RO Romania, Bucharest
RS Serbia, Belgrade
SG Singapore, Singapore
TW Taiwan, Taipei
US United States, Miami
US United States, Dallas
US United States, Kansas City

Глобальная диагностика маршрутизации и динамическая трассировка сети (My Traceroute)

Аналитическая утилита MTR (My Traceroute), предоставляемая платформой Check-Host, объединяет в себе исчерпывающую пошаговую (hop-by-hop) диагностику классического инструмента `traceroute` с непрерывным мониторингом доступности узлов с помощью интенсивных команд `ping` (ICMP Echo Request). Отправляя серию сегментированных пакетов с калиброванным и постепенно увеличивающимся параметром времени жизни (Time-to-Live, TTL) одновременно с 50 независимых серверов по всему миру, система методично фиксирует каждый транзитный маршрутизатор на пути к целевому серверу. MTR непрерывно обновляет данные о потере пакетов и времени отклика для каждого «прыжка», выстраивая достоверную и динамическую картину всего маршрута передачи данных через магистральные каналы (Backbone networks) интернета.

Анализ маршрутизаторов (Hop-by-Hop), фиксация потери пакетов (Packet Loss) и задержек

Обычный `ping` способен обнаружить только факт доступности конечного сервера (хоста), но бессилен определить источник проблем, если запрос обрывается в центре сети. Использование MTR позволяет инженерам и системным администраторам «просветить» весь маршрут до целевого узла как на рентгене, делая видимыми транзитные магистрали (ISPs). Это неоценимое преимущество дает возможность точно определить, где именно происходит деградация качества связи: возникает ли критическая потеря пакетов (Packet Drop) на загруженных шлюзах операторов уровня Tier-1, или огромные пики задержки (High Latency) провоцируют заторы внутри корпоративной инфраструктуры ещё до того, как пакет дойдёт до защитного экрана (Firewall) вашего сервера.

Выявление неоптимальных путей BGP и диагностика петель маршрутизации (Routing Loops)

Передача данных в глобальной паутине интернета регулируется протоколом BGP (Border Gateway Protocol). Несмотря на его универсальность, этот протокол может принимать математически точные, но физически абсурдные решения при выборе маршрута (BGP-маршрут строится исходя из количества пройденных автономных систем — кратчайшего AS-path), что порой приводит к выбору пути с наибольшей географической удаленностью. Масштабный анализ MTR дает возможность мгновенно выявить аномалии в архитектуре пиринговых соглашений (Peering) дата-центров: неоптимальные маршруты, пролегающие через океаны вместо прямого локального транзита (асимметричный роутинг), а также циклические тупики передачи (Routing Loops), которые безжалостно уничтожают доступность портала и препятствуют нормальному доступу из целых континентальных регионов.

Перекрестная валидация обратных DNS-запросов (rDNS / PTR Records)

Важным дополнением MTR выступает способность платформы выполнять автоматическое разрешение обратных DNS (Reverse DNS) в режиме реального времени. Система мгновенно переводит "сырые" и нечитаемые IP-адреса промежуточных коммутаторов маршрутов в осмысленные публичные доменные имена (Hostnames) конкретных владельцев серверов. Это бесценное свойство позволяет аналитикам с первого взгляда определять, инфраструктура какой корпорации (Level3, Telia, Cogent) в данный момент парализована и влияет на доступность проекта. Примечание: 100% потеря пакетов (Packet Loss) на отдельном транзитном узле, не препятствующая при этом успешному прохождению трафика до конечного хоста, чаще всего означает не сбой, а настроенную блокировку протокола ICMP со стороны брандмауэра транзитного провайдера. Данное ограничение принудительно запрещает маршрутизатору тратить ресурсы на обработку сигналов об истечении срока жизни пакета (TTL-Exceeded).