By 
В инструментарий первичной диагностики неполадок в сетях на базе стека протоколов TCP/IP, утилита traceroute вошла уже давно. Общая идея алгоритма осталась неизменной еще с 1987 года, когда она впервые была реализована программно Van Jacobson, сотрудником группы сетевых исследований (Network ResearchGroup) в Национальной лаборатории Беркли (Lawrence BerkleyNational Laboratory). За более чем 20-ти летний период времени, этот простой в использовании инструмент стал обыденным и привычным, и мало уже кто задумывается о том, что получаемые результаты «трассировки» хорошо демонстрируют один из краеугольных принципов построения сетей связи. Речь идет об аспекте разграничения зон обслуживания, на котором в том числе тоже держится связь, и о котором сейчас часто забывают.
Он хорошо известен связистам «старой школы», когда требование работоспособности в пять девяток считалось не нонсенсом, как сейчас, а всего лишь заурядным показателем работы систем телефонной связи. Дома могло не быть света, — где-то оборвало электрический кабель, висящий на опорах. Воду могли отключить, — на водонапорной башне отключили электроэнергию, потому что «где-то оборвало кабель, висящий на опорах»… Вот только телефон, правда, у тех у кого он имелся в наличии, должен был работать. И даже сейчас, имея дома уже много лет обыкновенный кнопочный аппарат, я так и не смог вспомнить, когда последний раз обращался к своему оператору телефонной связи с какой-то жалобой на аварию. Понятно, я утрирую. Но все-таки, а Вы вспомните?
Совершенно другая ситуация наблюдается в сетях «нового» мира, мира пакетной передачи, ярким проявлением которого является уже такое обыденное явление как интернет. Ирония в том, что сам интернет, в своей первоначальной ипостаси вышел из проекта ARPANET, — как ответ министерства обороны США для надежной системы передачи информации на случай глобальной ядерной войны и тотальных разрушений. Так почему же сейчас, когда призрак ядерной войны ушел в небытие, а катаклизмы и разрушения в своей массе затрагивают нас очень редко — ситуация кардинально иная? Стоит взглянуть на ветку форума «XYZ упал:(» этого сайта. Топик существует чуть более года, а счетчик сообщений скоро перешагнет полторы тысячи. И это только по магистральным каналам связи, аварии на которых затрагивают значительные группы абонентов. В чем дело?
Прежде чем ответить на вопрос, надо вернуться к теме статьи, вынесенной в ее заголовок, утилите traceroute. Как оказалось, на сайте бывают и обыкновенные пользователи, хоть и продвинутые. Небольшой ликбез не помешает. Суть алгоритма утилиты очень проста: в IP-пакетах поле TTL (Time To Live) задает время жизни отправленной в сеть дейтаграммы. Каждый узел, который обрабатывает пакет и пересылает его дальше, уменьшает значение поля TTLна единицу. Когда TTL становится равным 1 или 0, пакет уничтожается, а отправителю отсылается сообщение ICMP«time exceeded» (время превышено). Нужно это для того, что бы дейтаграмма бесконечно не «гуляла» по сети, если не сможет дойти до адресата. Максимальное значение TTL ограниченно его разрядностью (8 бит) и составляет 255, реальные же значения TTL по умолчанию устанавливаются каждой системой по разному. Стоит отметить, что TTLтакже уменьшается каждую секунду нахождения его на узле, хотя для современных сетей это часто не принципиально, за исключением, наверное, «шейпера» трафика (bandwidth control, ограничение полосы) с достаточно жесткими параметрами.
Пример реализации traceroute
Именно механизм TTL задействован для определения пути следования пакета. Классическая реализация tracerouteпосылает серию из трех UDP-пакетов на произвольный порт (по умолчанию 33434) с TTL = 1. По поступлению ответов ICMP «time exceeded» определяется время прохождения и доменное имя узла. Затем процедура повторяется с TTL = TTL + 1 до тех пор, пока пакет не достигнет конечного узла, который ответит «port unreachable» (порт не доступен). В зависимости от реализации, вариации traceroute могут различаться. К примеру, консольная утилита tracert.exe в семействе Windows использует запросы ICMP «echo», которые обычно используются утилитойping. В любом случае, результат работы утилиты будет включать в себя определенный набор информации: список узлов, через которые проходит пакет от адреса источника до адреса назначения и задержки при передаче пакетов. Последний важный аспект. Нельзя забывать, что пути пакетов в интернет неисповедимы. Уходя одним путем, ответ на запрос может возвращаться другим. Поэтому для анализа полной информации нужны результаты traceroute и с обратной стороны.
Пример результата работы traceroute.
Так вот, возвращаясь к поставленному ранее вопросу «в чем дело?» теперь можно и ответить. То есть указать всего лишь один из возможных вариантов ответа. Наверное, во всем виноваты программисты. Как говорит известная притча, «если бы они строили цивилизацию, то залетевшая внутрь птица развалила бы ее как карточный домик». Именно программисты внесли в связь, лет пятнадцать с лишком назад еще девственную и непорочную, свою культуру, взятую от утверждения, где «баг и не баг вообще, а просто фича». Да, да, — это шутка! И все-таки доля правды в ней есть. Телеком, стоя на острие инновационного развития, порожденного информационно-компьютерными технологиями, сам же и развивался за счет них. Хотите пример взаимной интеграции? Пожалуйста. Попробуйте навскидку определить, что делает нижеприведенный код:
int f1 (int a, int b) { if (sign(a) != sign(b)) return (a+b)/2; else return a+(b-a)/2; }
Угадали? А ведь все очень просто. Это функция для вычисления среднего значения двух аргументов. А теперь определите по приведенному ниже скану из форума, где находятся зоны ответственности операторов с точки зрения простого пользователя, грешным делом решившего запустить стандартную для Windows (>90% абонентов) версиюtracert, чтобы попробовать понять, на чьей стороне проблема. Только, пожалуйста, без всяких там whois сервисов, о которых даже продвинутый пользователь имеет право не знать.
Не правда ли, очень гармонирует с примером функции вычисления среднего значения? И там и там страдает визуализация. В первом случае визуализация программного кода осложнена записью в одну строку. Во втором случае отсутствие имен узлов мешает пользователю отследить пути следования пакетов. Отметим, что эта беда не только российских компаний. Она международного характера. В приведенном выше примере traceroute черезwebtrace.info надо смотреть на AS7132 и AS7018. А ведь если проблема действительно находится за пределами сети оператора, здравые имена узлов позволяют снизить поток жалоб от абонентов в адрес оператора. Ведь оперировать к именам, имеющим значение, всегда проще, чем к каким-то там цифрам. Ясно, что таких клиентов, пытливый ум которых будет стремиться узнать, из-за кого провайдера «та сволочь в любимой онлайн — игре отстрелила ему башку», — очень мало. Насколько активны они в форумах, мне судить сложно.
Только есть еще и другая группа потребителей. Я говорю о корпоративных пользователях, тех, у кого есть или системные администраторы, или даже целые отделы ИТ. Корректно ли заставлять их «лезть» в ripe, чтобы определить стыки, а значит и зоны ответственности сетей, когда интернет не работает или «работает, но как-то не так»?! В ответ появляются такие решения, как «Улучшитель кармы трафика». Для тех, кто побогаче — аппаратное решение, а для тех, кто победней скоро планируется выпуск программного продукта. А если серьезно? Может ли видимое пренебрежение оператора к разграничению зон ответственности являться пренебрежением реальным? Вероятно, нет. Зная уровень технических специалистов ЮТК, попавшей в примеры к статье, — НЕТ с уверенностью в 99,999%. Знает ли об этом клиент?! Вероятно, ТОЖЕ нет. Поэтому в случае аварии tracert свою функцию выполнит и расскажет клиентам, и так изнывающим, о том, что якобы их провайдер не может даже имя узлов «сконфигурировать». О каком уж там разделении зон ответственности вести речь? Стоит ли этого мнения призрачная безопасность топологии сети, а может и просто нежелание немного «повозиться»? Пускай каждый провайдер решает для себя сам…
Автор: Егор Дробышев
NAG.RU
Comments